Bei der Entwicklung sicherheitskritischer Systeme sind Softwareanforderungen nicht nur ein Punkt auf einer Checkliste – sie bilden das Fundament für alles Folgende. Vom Design und der Verifikation über die Zertifizierung bis hin zur Wartung: Die Klarheit und Korrektheit Ihrer Anforderungen kann über Erfolg oder Scheitern Ihres Produkts entscheiden, insbesondere dann, wenn Leben vom Verhalten des Systems abhängen.

Egal ob Sie eine Insulinpumpe oder einen Druckregler für ein Kernkraftwerk entwickeln: Das Schreiben von Softwareanforderungen für sicherheitskritische Anwendungen erfordert eine disziplinierte Vorgehensweise. Dieser Artikel zeigt, wie man präzise, eindeutige und überprüfbare Anforderungen formuliert, die Industriestandards erfüllen und die Zertifizierung unterstützen.

Hochwertige Anforderungen schreiben

Die meisten Anforderungen werden noch in natürlicher Sprache (NL) formuliert. NL ist flexibel und leicht verständlich, aber anfällig für Mehrdeutigkeit. Schon eine Formulierung wie „bei Bedarf“ kann mehrere Interpretationen zulassen – und damit kritische Fehler verursachen. Deshalb braucht sicherheitsrelevante Entwicklung auch in NL Regeln und Struktur. Eine gute Softwareanforderung ist:

• korrekt und klar
• konsistent und widerspruchsfrei
• testbar und verifizierbar – sie muss messbare Kriterien definieren
• frei von Konjunktionen und Ausnahmen
• rollenspezifisch – benennt den Benutzertyp

Beispielstruktur:

Der Bediener soll in der Lage sein, [Aktion] am [Objekt] durchzuführen, um [gewünschten Zustand] zu erreichen.

Jede Anforderung sollte definieren:

• Wer die Aktion durchführt (Benutzerrolle)
• Was getan wird (Aufgabe und Objekt)
• Warum bzw. welches Ergebnis erwartet wird
• Wer das Ergebnis erhält oder verwendet

Stil und Struktur

Eine gut formulierte Anforderung folgt typischerweise einem Subjekt–Prädikat–Objekt (S-P-O)-Muster:

ISO/IEC/IEEE 29148:2018 beschreibt, wie man klare und testbare Anforderungen schreibt und standardisiert die Verwendung modaler Verben:

• Shall (soll): Kennzeichnet eine verpflichtende Anforderung.
• Will (wird): Beschreibt eine Tatsache oder Absicht, keine Anforderung.
• Should (sollte): Empfohlene Anforderung; nicht verpflichtend, Abweichungen müssen aber begründet werden.
• Must (muss): Wird manchmal für Naturgesetze oder unvermeidbare Folgen verwendet, sollte jedoch nicht anstelle von „shall“ für Anforderungen genutzt werden.

Best Practice: Verwenden Sie „shall“ nur einmal pro Anforderung. Vermeiden Sie zusammengesetzte Anforderungen ohne „und“, „oder“ oder „mit“. Das Kombinieren von Aktionen macht die Anforderung untestbar und erzeugt mehrere Anforderungen in einer. Wörter wie „ist“, „sind“, „war“ oder „muss“ sind für beschreibende oder einleitende Abschnitte geeignet.

Jede Anforderung sollte beschreiben, was das System tun muss, nicht wie es implementiert wird. Das ist entscheidend für Testbarkeit und Rückverfolgbarkeit. Beispiel:

Das System soll eine MySQL-Datenbank zur Speicherung von EKG-Daten verwenden.

Das beschreibt das Wie, nicht das Was. Die Wahl der Datenbank ist eine Designentscheidung, die in nachgelagerten Dokumenten wie dem Software Architecture Document (SAD) oder Detailed Design Document (DDD) festgelegt wird.

Anforderungen durch kontrollierte Sprache verbessern

Eine Möglichkeit, Mehrdeutigkeit zu reduzieren, ist die Einführung einer kontrollierten Sprache – einer vereinfachten Teilmenge des Englischen für technische Dokumentation. In der Luft- und Raumfahrt wird z. B. ASD-STE100 (Simplified Technical English) eingesetzt.

Kontrollierte Sprache erzwingt:

• definierten Wortschatz
• einfache Satzstrukturen
• Vermeidung von Synonymen oder mehrdeutigen Begriffen

Mit einem Styleguide für kontrollierte Sprache lassen sich konsistente und leicht überprüfbare Anforderungen über mehrere Dokumente und Rollen hinweg erstellen.

Mehrdeutigkeit vermeiden

Mehrdeutigkeit kann entstehen durch lexikalische, syntaktische oder semantische Probleme:

• Lexikalische Mehrdeutigkeit: Ein Wort hat mehrere Bedeutungen.
  Beispiel: „Bank“ kann Finanzinstitut oder Flussufer bedeuten.
• Syntaktische Mehrdeutigkeit: Ein Satz erlaubt mehrere grammatikalische Strukturen mit unterschiedlicher Bedeutung.
  Beispiel: „Medizinische Geschichtsdatenbank“ – handelt es sich um eine Datenbank für Krankengeschichten oder um eine historische Datenbank aus Tibet?
• Anbindungs-Mehrdeutigkeit: Eine Phrase (oft Präpositional) kann sich auf unterschiedliche Teile beziehen.
  Beispiel: „Der Zustandsautomat kann als Teil des Treibers für die Kommunikation mit der Watchdog-CPU implementiert werden.“
  Bedeutungen:
  • Der Treiber dient der Kommunikation und der Zustandsautomat ist Teil davon.
  • Der Zustandsautomat dient der Kommunikationssteuerung.
• Semantische Mehrdeutigkeit: Ein Satz ist im Kontext unklar, auch ohne lexikalische oder syntaktische Probleme.
  Beispiel: „Das System soll den Motor stoppen, bevor er überhitzt.“ – Bezieht sich „er“ auf das System oder den Motor?

Mehrdeutigkeit schleicht sich oft durch vage Begriffe, Passivkonstruktionen oder unklare Referenzen ein. Beispiel:

„Das System soll das Warnsignal kurz nach Fehlererkennung aktivieren.“

Was bedeutet „kurz“? Wer aktiviert das Signal? Solche Fragen sind in einem sicherheitskritischen Kontext rote Flaggen.

Vermeiden Sie:

• Relative Begriffe: leistungsfähig, akzeptabel, schnell, zuverlässig
• Unklare Quantoren: alle, die meisten, einige, beliebig
• Passiv: „wird aktiviert“ vs. „der Controller aktiviert“
• Zeitliche Unschärfen: bald, periodisch, später
• Doppelte Anforderungen: zwei „shall“ verbunden mit „und/oder“

Jede Anforderung muss atomar, verifizierbar und eindeutig sein.

Anforderungen formalisieren

Für höhere Sicherheitsstufen ist es notwendig, Anforderungen zu formalisieren. Das bedeutet, sie in eine formale Sprache wie PSL (Property Specification Language) oder LTL (Linear Temporal Logic) zu übersetzen, die Tools prüfen und simulieren können.

Formalisiertes Vorgehen ermöglicht:

• vollständige Analyse von Randfällen
• Rückverfolgbarkeit von High-Level-Anforderungen bis zur Implementierung
• automatisierte Verifikation in Sicherheits-Audits

Praxisbeispiele

Infusionspumpe – Flussratenkontrolle

Natürliche Sprache (NL SR)

„Das System sollte die richtige Dosis mit der richtigen Geschwindigkeit abgeben.“

Probleme: Vage Begriffe wie „richtige Dosis“ und „richtige Geschwindigkeit“. Kein Subjekt definiert. Nicht testbar.

Kontrollierte natürliche Sprache (cNL SR)

„Wenn das Infusionsprogramm gestartet wird, soll die Steuereinheit das programmierte Medikamentenvolumen mit einer Flussrate zwischen 0,1 und 10,0 ml/h mit einer Genauigkeit von ±5 % abgeben.“

• Subjekt: Steuereinheit
• Aktion: soll abgeben
• Parameter: Flussrate, Dosis, Genauigkeit
• Auslöser: Start des Infusionsprogramms

Herzfrequenzmonitor – Alarm auslösen

Natürliche Sprache (NL SR)

„Das System muss einen Alarm auslösen, wenn die Herzfrequenz abnormal ist.“

Probleme: Was bedeutet „abnormal“? Wie laut oder schnell ist der Alarm? Wann genau soll er auslösen?

Kontrollierte natürliche Sprache (cNL SR)

„Wenn die Herzfrequenz des Patienten unter 40 bpm fällt oder 180 bpm überschreitet und dies länger als 3 Sekunden anhält, soll der Alarm-Controller innerhalb von 1 Sekunde einen 90-dB-Alarm auslösen.“

• Klare Grenzwerte: 40 und 180 bpm
• Zeitbedingung: länger als 3 Sekunden
• Aktion: 90 dB Alarm aktivieren
• Zeitgrenze: innerhalb 1 Sekunde

Strahlenbündelaktivierung mit Hardware-Interlock

Natürliche Sprache (NL SR)

„Das System soll den Strahl aktivieren, wenn der Bediener die Behandlung startet.“

Probleme:

• Keine Erwähnung von Sicherheitsverriegelungen oder Bedingungen.
• „Aktivieren“ ist unklar – physisch einschalten oder nur vorbereiten?

Kontrollierte natürliche Sprache (cNL SR)

„Das System soll den Strahlenbündel nur aktivieren, wenn der Ganty in der richtigen Position ist, der Hardware-Interlock geschlossen ist und die Behandlungskonsole einen gültigen ‚Start‘-Befehl vom Bediener erhält.“

• Mehrere notwendige Bedingungen
• Eindeutiges Subjekt und Auslöser
• „Nur wenn“-Logik berücksichtigt Sicherheit

Anforderungsreview

Die Entwicklung eines sicherheitskritischen Produkts ist selten Aufgabe einer Einzelperson. Bevor die nächsten Schritte im V-Modell begonnen werden, müssen die Softwareanforderungen überprüft werden. Aber das ist Thema für das nächste Mal.

Weiterführende Literatur

• From Contract Drafting to Software Specification - AmbiguityHandbook.pdf
• ASD-STE100 - www.asd-ste100.org