Software-Anforderungen IEC-62304-konform dokumentieren

Medizinproduktehersteller müssen die Software-Anforderungen spezifizieren und dokumentieren, und zwar unabhängig von der Sicherheitsklasse dieser Software.

1. Grundlagen

a) Ziele

Eine Software-Anforderungsspezifikation (englisch: Software Requirements Specification, SRS) soll dem Software-Entwicklungsteam die Informationen geben, mit denen es möglichst ohne weitere Rückfragen die Software entwickeln kann.

b) Definition

Weder die IEC 62304 noch die FDA definieren den Begriff Software-Anforderungen (engl.: Software Requirements).

Die Definition des Begriffs „Anforderung“ in der ISO 9000:2015 ist nur bedingt hilfreich:

Aber Beispiele helfen, den Begriff Software-Anforderungen zu verstehen:

Eine Software-Anforderungsspezifikation (SRS) sollte beispielsweise beschreiben,

• welche Daten die Software einlesen, entgegennehmen bzw. verarbeitet muss,
• welche Outputs sie in welcher Form wie schnell erzeugt,
• wie sie die Daten verarbeiten muss,
• wie die grafische Schnittstelle aussehen und sich bei Interaktion mit den Anwendern verhalten soll und
• in welcher technischen Umgebung (z. B. Hardware) die Software lauffähig sein muss.

b) Abgrenzung von Software-Anforderungen und Software-Spezifikation

Beide Begriffe sind nicht identisch. Die Software-Anforderungen beschreiben die Anforderungen allgemein. Die Software-Spezifikation gibt vor, wie diese Anforderungen umgesetzt werden sollen. Hier einige Beispiele zur Erläuterung:

Software-Anforderung	Software-Spezifikation
Das Software-System / die Software muss den Patientennamen anzeigen.	Das System zeigt den Patientennamen in 18 Punkt Arial 20 Pixel vom rechten Bildschirmrand (gemäß Mockup-Screen X) an.
Die Software muss die Daten per HL7 an angeschlossene Nachbarsysteme verschicken können.	Sobald ein neuer Patient erfasst wird, schickt das System über die Datenschnittstelle X eine HL7-V2.6 ADT-A01-Nachricht, wobei das System als „KIS“ im MSH Segment als sendendes System eingetragen ist.
Die Software muss die Daten mit 1024-Bit-Verschlüsselung intern ablegen.	—

Wir empfehlen die Erstellung einer Software-Spezifikation, weil die Prüfungen (z. B. Tests) präzise Vorgaben benötigen.

2. Regulatorische Anforderungen

a) Europa

EU-Richtlinien

MDR und IVDR fordern zwar nicht explizit eine Software-Anforderungsspezifikation, aber die Verifizierung der Software. Die ist nur möglich, wenn es eine Spezifikation gibt, gegen die der Hersteller verifizieren kann. Genau das sind Software-Spezifikation bzw. Software-Anforderungen.

IEC 62304

Die IEC 62304 verpflichtet die Hersteller im Kapitel 5.2, die Software-Anforderungen zu spezifizieren und diese Spezifikation zu verifizieren (Tipps unten beachten).

Die Anforderungen an die Software müssen beispielsweise betreffen:

• Inputs und Outputs, z. B. die Benutzungsschnittstelle
• Technische Umgebung wie Hardware
• IT-Sicherheit

b) USA

Die FDA erkennt die IEC 62304 als „recognized standard“ an. Aber die relevantesten Vorgaben an die Software-Anforderungen formuliert die Behörde in ihrer Leitlinie zur Software Validation.

Das Guidance-Dokument Content of the premarket submission gibt vor, welche Unterlagen Hersteller einreichen müssen. Darin macht die FDA auch Vorgaben für die Software Requirements Specification.

3. Fünf Tipps für die Software-Anforderungen

Tipp 1: Blackbox-Modell nutzen

Das Johner Institut empfiehlt, Software als Blackbox zu spezifizieren, d. h. über dessen externe Schnittstellen.

Schnittstellentyp	Elemente der SRS
Benutzerschnittstelle (UI)	Spezifikation des statischen Aussehens der UI, z. B. mit Mockups und Styleguides Beschreibung des dynamischen Verhaltens, z. B. mit interaktiven Mockups und Prototypen oder mithilfe von Diagrammen für den „Screen flow“
Datenschnittstellen	Beschreibung aller vier Ebenen des Interoperabilitätsmodells Angabe „nicht-funktionaler“ Aspekte wie Zeitverhalten und Umgang mit fehlerhaften Inputs (Fehlertoleranz)
Schnittstelle zur Laufzeitumgebung	Spezifikation aller erlaubten Kombinationen von Hardware (CPU, I/O, Festplatte, RAM, Bildschirmgrößen und Auflösungen etc.) und Software (Betriebssystem, Browsertypen und -versionen, Firewalls etc.)

Hersteller können die Software Requirements Specification sogar gemäß dieser Aufteilung strukturieren (s. Tipp 4).

Tipp 2: ISO 25010 verwenden

Die ISO 25010 bietet eine sehr hilfreiche Taxonomie der Qualitätseigenschaften von Software. Diese lässt sich gut als Checkliste nutzen, um die Vollständigkeit der Anforderungen zu überprüfen. Besonders wirksam ist diese Methode, wenn sie mit den Schnittstellentypen (s. Tipp 1) kombiniert wird.

Beispiel für eine Frage, die sich daraus ergibt:

„Ist für die Nutzungsschnittstelle festgelegt, wie schnell diese auf Benutzereingaben reagieren muss?“

Tipp 3: SRS-Checkliste nutzen

Sie können sich diese Arbeit sogar sparen, wenn Sie die Checkliste des Johner Instituts heranziehen.

Tipp 4: Nicht die Struktur von IEC oder ISO übernehmen

Als Kapitelstruktur für die Software Requierements Specification empfehlen sich weder die Struktur des Kapitels 5.2 der IEC 62304 noch die Struktur der ISO 25010.

Hilfreicher ist die folgende Kapitelstruktur:

1. Metainformationen
2. Benutzerschnittstelle
3. Datenschnittstellen
4. Laufzeitumgebung
5. Anforderungen an weitere Entwicklungsphasen
6. Sonstige Anforderungen

Tipp 5: Möglichst knapp spezifizieren

Eine SRS sollte so kurz wie möglich, aber so ausführlich wie nötig sein.

• Nicht die Zweckbestimmung in der SRS wiederholen
• Abkürzungsverzeichnis nur referenzieren und nicht wiederholen
• Keine langen Metainformationen (z. B. über die Ziele der SRS)
• Statt langer Anforderungslisten, wie eine UI aussehen soll, besser ein Link auf ein versioniertes Mock-up
• Bilder und Diagramme statt viel Text