Software-Anforderungen IEC 62304 konform dokumentieren

Die IEC 62304 fordert in Kapitel 5.2, die Software-Anforderungen (auf englisch Software Requirements Specification) zu spezifizieren.

Dieser Artikel zeigt Ihnen, wie Sie Ihre Software-Anforderungen nicht nur normenkonform, sondern auch mit wenig Aufwand, präzise, schlank und vollständig dokumentieren können. Das hilft Ihnen, Ihre Produkte schneller und kostengünstiger zu entwickeln und Ärger im Audit zu vermeiden.

Was sind Software-Anforderungen?

Weder die IEC 62304 noch die FDA definieren den Begriff Software-Anforderungen (auf englisch Software Requirements Specification SRS). Auch die Definition des Begriffs Anforderung in der ISO 9000:2015 ist nicht sehr hilfreich:

Definition: Anforderung

„Erfordernis oder Erwartung, das oder die festlegt, üblicherweise vorausgesetzt oder verpflichtend ist“

Quelle: ISO 9000:2015 (3.6.4)

Daher nähert man sich dem Begriff einfach anhand von Beispielen: Die Software-Anforderungen sollten beschreiben,

  • welche Daten eingelesen/entgegengenommen/verarbeitet werden werden müssen,
  • wie die Daten verarbeitet werden müssen,
  • wie die grafischen Benutzungsschnittstelle aussehen und sich bei Interaktionen mit den Anwendern verhalten soll,
  • auf welcher Hardware die Software lauffähig sein muss.

Gelegentlich unterscheiden Firmen Software-Anforderungen und Software-Spezifikationen. Lesen Sie dazu weiter unten mehr.

1. Wie man Software-Anforderungen beschreibt

a) Tipp des Johner Instituts

Das Johner Institut empfiehlt, dass eine Software Requirements Specification SRS die Anforderungen an die Software als Blackbox beschreiben muss. D.h. sie sollte festlegen, wie sich das System nach außen verhält und wie die Software über die Schnittstellen, seien es die zum Anwender (GUI) oder zu anderen Systemen, reagieren soll.

Daher sollte eine SRS beschreiben:

  • Benutzerschnittstelle(n)
  • Die GUI: Positionierung von Elementen, Style Guides, …
  • Verhalten des Systems auf Benutzeraktionen im Normal- und Fehlerfall: Vom System angezeigte Informationen, Berechnungen, Grafiken, Meldungen, Warnungen, “Screenflow”, …
  • Die Geschwindigkeit, mit der diese Reaktionen geschehen
  • Auf welchen Umgebungen, sich die Software (Blackbox) installieren lassen soll (Betriebssystem, vorausgesetzte Datenbanken und andere Server, Hardware einschließlich RAM) und wie diese Installation von statten gehen soll.
  • Wie sich das System auf Benutzerfehler und Überlast reagieren soll.
  • Technische Schnittstellen (zu anderen Systemen)

b) Weshalb sie damit die Forderungen der IEC 62304 Kapitel 5.2 erfüllen

Kommt Ihnen diese Liste bekannt vor? Dann sehen Sie mal in der ISO 9126 bzw. der Nachfolgenorm ISO 25010 nach, hier finden Sie eine wunderbare Taxonomie. Hier hat sich auch die IEC 62304 für das Kapitel 5.2 zu den Software-Anforderungen eifrig bedient. Sie können alle in diesem Kapitel genannten Forderungen mit der oben genannten Vorgehensweise erfüllen. Wir raten Ihnen aber davon ab, die Software-Anforderungen zu gliedern wie die Forderungen in der IEC 62304.

Und was gehört nicht in eine SRS?

  • Nutzungsanforderungen
  • Anforderungen an die zu verwendenden Technologien
  • Lösungsvorgaben wie “Ideen” für die Architektur, die Datenbank
  • Usw.

c) Software-Anforderungen schnell, schlank und konform mit IEC 62304 dokumentieren

Diese kostenlosen(!) Videotrainings zeigen Ihnen Schritt für Schritt den Weg zu präzisen Software-Anforderungen

Software-Anforderungen-Auditsicher-Dokumentieren-Videoserie

Weil wir immer und immer wieder auf diese Probleme stoßen, die eigentlich so einfach zu vermeiden wären, haben wir beschlossen, eine kostenlose Serie an Videotrainings zu veröffentlichen. Wenn Sie sich an diese Tipps halten, werden Sie zu stabilen und vollständigen Software-Anforderungen kommen. Davon profitieren Sie gleich mehrfach:

  • Sie bekommen Ruhe ins Projekt und vermeiden ständige Nachbesserungen
  • Sie vermeiden mit einem klaren Verständnis für Verantwortlichkeiten die ständigen Reibereien zwischen Produktmanagement und Entwicklung
  • Sie sparen sich den Audit-Stress und können mit vorbildlichen Dokumenten glänzen

Software-Anforderungen-Dokumentieren

Wie gesagt, die Videotrainings sind kostenlos. Sie müssen sich nur einmalig registrieren.

Sehen Sie sich gleich das erste Video an!

2. Typische Fehler beim Spezifizieren von Software Requirements

Die typischen Fehler vieler Software Requirement Specifications (SRS) sind die folgenden:

  • Die Software-Anforderungen sind unvollständig und erlauben es daher den Entwicklern nicht, ohne weitere Rückfragen das Produkt zu entwickeln.
  • Das Dokument ist fehlerhaft oder gar widersprüchlich, weil die Autoren kein mentales Modell, wie ein Software-Anforderungsdokument zu schreiben ist.
  • Die Software-Anforderungen sind eine krude Mischung aus Zweckbestimmung, Kundenwünschen, Projektvorgaben (also nicht nur Produkt), Nutzungsanforderungen, Systemanforderungen und Vorgaben für die konkrete Lösung (z.B. die Architektur betreffend). Dieses Problem trifft v.a. Firmen, die mit dem Konzept der Lasten- und Pflichtenhefte arbeiten (zu diesem Drama hier mehr).

Fehlerhafte Software-Anforderungen

  • führen zu kostenintensiven Nachbesserungen und zu Projektverzögerungen,
  • erschweren das Testen, weil man für die Verifizierung keine konkreten Spezifikationen,
  • erlauben es nicht, die Validierung und Verifizierung zu trennen und
  • werden beim Audit zum Problemen, weil die regulatorischen Forderungen nicht erfüllt sind.

Manche Firmen versuchen diese Folgen zu vermeiden, in dem sie „überdokumentieren“ und einen gefährlichen QM-Overhead produzieren.

3. Die Checkliste für Software-Anforderungen

a) Wer die Checkliste nutzen sollte

Solch eine Checkliste für Software-Anforderungen kommt bei einem Dokumenten-Review zum Einsatz. Die IEC 62304 nennt dies im Kapitel 5.2 die Verifizierung der Software-Anforderungen. Daran sollten immer teilnehmen

  • der Autor
  • der Verantwortliche für den Input des Dokuments (hier: die Person, die für die Stakeholder-Requirements verantwortlich ist)
  • der- oder diejenige, die mit dem Dokument weiterarbeiten muss (hier: der Software-Architekt) und
  • die Person, die die zugehörigen Tests verantwortet (hier: Software-System-Tester).

Dieses Review erfüllt übrigens die Anforderung der IEC 62304 (Kapitel 5.2) nach einer Verifizierung der Software-Anforderungen.

Probieren Sie es gleich aus und laden Sie sich die Checkliste herunter.

Checkliste für Software-Anforderungen herunterladen

b) Weshalb sich die IEC 62304 Kapitel 5.2 nicht als Checkliste eignet

Könnte man nicht auch die IEC 62304 Kapitel 5.2 als Checkliste für Software-Anforderungen nutzen, um die Vollständigkeit und Normenkonformität des eigenen Dokuments zu prüfen?

Videotraining-Software-Anforderungen-verifzieren-IEC-62304

Natürlich könnte man das, aber die IEC 62304 ist in Kapitel 5.2 an manchen Stellen zumindest missverständlich. Würde man beispielsweise gemäß der Norm prüfen, müsste man untersuchen, ob die „regulatorischen Anforderungen“ genannt sind. Das wäre aber genau falsch, denn die regulatorischen Anforderungen sind Stakeholder-Anforderungen und gehören in das entspechende Dokument und eben gerade NICHT in die Software-Anforderungen. Die Software-Anforderungen würden vielmehr beschreiben, wie man die regulatorischen Anforderungen aus Blackbox-Sicht umgesetzt hat.

Auch sind die darin genannten Punkte viel zu allgemein, um bei einem Review schnell und eindeutig prüfen zu können, ob die Software-Anforderungen präzise formuliert sind. Beispielsweise verlangt, dass Sie die „Schnittstellen zwischen dem SOFTWARE-SYSTEM und anderen SYSTEMEN“ beschreiben. Das ist zu ungenau und daher nicht eindeutig prüfbar. Besser wäre es gewesen zu fragen, ob für jede Schnittstelle die Antwortzeit spezifiziert ist, ob beschrieben ist, wie sich das Produkt verhält, wenn über die Schnittstelle zu viele, keine, verspätete oder ungültige Daten übergeben werden.

Genau diese konkreten Fragen nennt Ihnen die Checkliste für Software-Anforderungen.

Checkliste für Software-Anforderungen herunterladen

4. Wie wir Sie unterstützen

a) Auditgarant: Die Schritt-für-Schritt-Videotrainings (nicht nur) zur normenkonformen Software-Entwicklung

Wenn Sie noch mehr über die Entwicklung medizinischer Software erfahren wollen, empfehle ich Ihnen den Auditgarant. In mehreren Videotrainings lernen Sie, wie Sie die Software-Anforderungen schnell und IEC 62304-konform dokumentieren können.

b) Auditleitfaden: Die Software-Checkliste Ihrer Auditoren

Wenn Sie schon eine SRS haben, die Sie auf Sinnhaftigkeit und Normenkonformität prüfen möchten, dann empfehle ich den Auditleitfaden mit der kompletten Checkliste für alle Entwicklungsphasen, auch für die Erstellung der Software-Requirements-Specification. Den Auditleitfaden haben wir für benannte Stellen entwickelt, die damit Medizinsoftware-Audits durchführen.

c) Beratung (z.T. sogar kostenfrei)

Bei unserem Berater-Team aus Lead-Auditoren und Software-Experten (ja, wir entwicklen auch selbst) bekommen Sie jederzeit Unterstützung. Schnell, höchst professionell und unkompliziert. Und bei kleinen Problemen sogar kostenfrei. Nutzen Sie dazu unsere kostenlose Micro-Consulting oder nehmen Sie mit uns Kontakt auf.

d) Kurz-Checkliste für Software-Anforderungen

Der einfachste Weg, um Ihre Software-Anforderungen schnell auf IEC 62304-Konformität zu prüfen und mögliche Probleme im Audit frühzeitig zu erkennen.

Software-Anforderungen zu schreiben, ist die eine Sache. Eine andere Sache ist es, bestehende Software-Anforderungen zu prüfen. Wie will man sicher sein, ob man die Software-Anforderungen vollständig erhoben hat? Ob IEC 62304-Konformität gegeben ist?

Eine Checkliste für Software-Anforderungen ist eine gute Möglichkeit, sich schnell Gewissheit darüber zu verschaffen.

Checkliste für Software-Anforderungen

Wir haben Ihnen eine solche kostenlose Checkliste für Software-Anforderungen  erstellt. Sie erlangen damit aber nicht nur Gewissheit, wie wahrscheinlich Ihre Software-Anforderungen beim Audit bestehen werden. So können Sie auch Fehler frühzeitig erkennen und beheben. Damit vermeiden Sie bei der Entwicklung zeitaufwändige und kostspielige Nachbesserungen und Iterationen.

Checkliste für Software-Anforderungen herunterladen

e) Selbsttest: Herausfinden, ob man es selbst verstanden hat

Haben Sie verstanden, was ein Software-Anforderungsdokument enthalten muss und was nicht? Wüssten Sie, welche der folgenden Sätze in eine Software Requirements Specification gehört?

  1. Die Software muss auf dem Motorola Processor A383B lauffähig sein.
  2. Die Software muss die Elektrode mit 50 Pulsen pro Minute ansteuern.
  3. Die Software muss die Daten auf dem Display so anzeigen, dass sie ein normalsehender aus 2 Meter ablesen kann.
  4. Die Software muss gut wartbar sein.
  5. Die Software muss in 4 Monaten in einer Beta-Version vorliegen.
  6. Vom dem Gerät sollen 5000 Stück innerhalb von 24 Monaten verkauft werden.

Unser Selbsteinschätzungstest gibt Ihnen Antworten. Und wie gut weiß Ihr Team Bescheid?

Self-Assessment-Software-Requirements-Specification

Doch Wissen alleine genügt nicht. Auch im Audit zählt Ihre dokumentierte Software Requirements Specification.

Wenn Sie herausfinden wollen,

  • wie viel Sie vom Schreiben von Software-Anforderungen verstehen,
  • was Ihr Team zu dem Thema weiß,
  • wie wahrscheinlich Ihr Dokument im Audit Bestand haben wird,

dann nehmen Sie sich ca. 8 Minuten Zeit, und füllen den Selbsteinschätzungstest aus. Dann wissen Sie Bescheid.

Also versuchen Sie sich! Ich bin auf Ihre Rückmeldung gespannt!

Hier geht es zum Selbsteinschätzungstest

5. Nur für Profis: Software-Anforderungen versus Software-Spezifikation

Der englische Begriff lautet Software Requirements Specification. Darin stecken die Requirements (Anforderungen) und die Specification (Spezifikation). Streng genommen sind beide nicht identisch. Wie empfehlen, die Software als Blackbox zu spezifizieren. Das wäre eigentlich eine Software-Spezifikation. Da die IEC 62304 aber nur von den Software-Anforderungen spricht, nutzen wir diesen Begriff ebenfalls, meist sogar synonym.

Trennt man beide Begriffe, würden die Software-Anforderungen die Anforderungen allgemeiner formulieren als das eine Software-Spezifikation täte. Beispiele:

Software-Anforderung Software-Spezifikation
Das System muss den Patientennamen anzeigen Das System zeigt den Patientennamen in 18 Punkt Arial 20 Pixel vom rechten Bildschirmrand (gemäß Mockup-Screen X) an
Das System 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.
Das System muss die Daten mit 1024-bit Verschlüsselung intern ablegen

Wir empfehlen die Blackbox-artige Spezifikation, weil nur diese im zugehörigen Software-Systemtest prüfbar sind. Außerdem sind fast alle Software-Anforderungen präziser, vollständiger, eindeutiger (und einfacher testbar) als Blackbox-Eigenschaft spezifizierbar. Die obige Tabelle nennt in der letzten Zeile eines der wenige Gegenbeispiele.


Dienstag 26. September 2017 von Prof. Dr. Christian Johner

Die FDA hat das Guidance Dokument ‚Interoperable Medical Devices‘ am 6. September 2017 veröffentlicht.

Die US-Behörde möchte damit der Tatsache Rechnung tragen, dass einerseits die Interoperabilität von Medizinprodukten immer wichtiger für die Gesundheitsversorgung wird. Andererseits führen Probleme mit mangelnder Interoperabilität immer häufiger zu Risiken.

Dieser Beitrag verschafft Ihnen einen schnellen Überblick über die Anforderungen der FDA an ‚Interoperable Medical Devices‘ und gibt Tipps wie Sie diese erfüllen können.

Den ganzen Beitrag lesen »


Mittwoch 23. März 2016 von Prof. Dr. Christian Johner

Der TIR45 („Guidance on the use of AGILE practices in the development of medical device software“) ist ein Technical Information Report (daher TIR) der AAMI, der Association for the Advancement of Medical Instrumentation.

Der 2012 veröffentlichte TIR45 hat sich vor allem ein Ziel gesetzt: Medizinprodukte-Herstellern eine Anleitung zu geben, wie sie Software agil und konform mit den FDA-Forderungen, speziell denen in den Guidance Documents, entwickeln können. Auch die IEC 62304 hat der Technical Report im Fokus.

Lesen Sie hier eine kompakte Zusammenfassung.

Den ganzen Beitrag lesen »


Montag 7. März 2016 von Prof. Dr. Christian Johner

„Findet ein Software-Audit statt?“ lautet eine Frage, die mich über unser Micro-Consulting erreicht. „Und kann ich durch eine geeignete Wahl der Software-Sicherheitsklasse so ein Software-Audit vermeiden?“

Erst ist mir weder klar, was genau mit „Software-Audit“ gemeint, noch was die genaue Befürchtung ist. Doch dann verstehe ich und finde die Frage sehr bedeutsam für alle Medizinprodukte-Hersteller.

Den ganzen Beitrag lesen »


Freitag 4. März 2016 von Prof. Dr. Christian Johner

Software-Systemtest: Was versteht man genau darunter? Wann sind sie vorgeschrieben? Was sollten Software-Systemtests testen? Auf welche Fallen sollten Sie achten? Antworten gibt Ihnen dieser Beitrag.

Den ganzen Beitrag lesen »


Freitag 5. Februar 2016 von Prof. Dr. Christian Johner

Die Uses Cases, auf Deutsch Anwendungsfälle, finden im Gegensatz zu User Stories in der agilen Entwicklung nicht mehr so viel Verwendung. Kann man mit der Modellierung von Use Cases zumindest die Forderungen der IEC 62366-1:2015 nach Benutzungsszenarien erfüllen? Sind die Begriffe Use Case und Benutzungsszenario synonym zu verstehen? Dieser Beitrag gibt Ihnen Antworten und Tipps.

Den ganzen Beitrag lesen »


Freitag 30. Oktober 2015 von Prof. Dr. Christian Johner

Entscheidungstabellen sind nicht nur ein hilfreiches Werkzeug, um Software-Tests zu spezifizieren, d.h. um Testfälle systematisch herzuleiten. Sie sind genauso nützlich beim Spezifizieren von Medizinprodukten (Systemen), von Komponenten oder von Software selbst.

Den ganzen Beitrag lesen »


Donnerstag 24. September 2015 von Prof. Dr. Christian Johner

Ein Algorithmus ist eine Rechenvorschrift, die beispielsweise in Software umzusetzen ist. Vielen Medizinprodukteherstellern ist unklar, ob solch ein Algorithmus als Teil der Stakeholder-Anforderungen, in der Software-Anforderung oder in der Software-Architektur zu spezifizieren ist. Kein Wunder, denn die Sache ist gar nicht ganz so einfach.

Den ganzen Beitrag lesen »


Mittwoch 19. August 2015 von Prof. Dr. Christian Johner

Software-Systeme sollten aus Komponenten bestehen, die über Software-Schnittstellen miteinander kommunizieren. Dieser Artikel beschreibt, wie Sie Software-Schnittstellen IEC 62304 konform dokumentieren können. Dabei zeigt er Konzepte, die sich nicht nur auf interne und externe Software-Schnittstellen, sondern auch auf Hardware-Schnittstellen übertragen lassen.

Update: Internet als interne Schnittstelle?

Den ganzen Beitrag lesen »


Montag 10. August 2015 von Prof. Dr. Christian Johner

Die ISO 9126 ist eine nicht-harmonisierte Norm, die Qualitätseigenschaften für Software klassifiziert. Diese Taxonomie diente auch als Grundlage für das Kapitel 5.2 (Software-Anforderungen) der IEC 62304.

Den ganzen Beitrag lesen »


Freitag 15. Mai 2015 von Prof. Dr. Christian Johner

Scrum ist eher ein Rahmen (Framework) für das agile Projektmanagement als ein Vorgehensmodell im Sinne eines Prozessmodells. Bereits deshalb kann ein Vorgehen nach Scrum durchaus konform mit den regulatorischen Anforderungen an die Entwicklung von Medizinprodukten (insbesondere Software) und der IEC 62304 sein.

Dieser Beitrag hat nicht zum Ziel, Scrum zu beschreiben (das ist an anderer Stelle z.B. Wikipedia bereits erfolgt). Vielmehr möchte er diskutieren, welche Voraussetzungen erfüllt sein müssen und typische Gefahren vermieden werden sollten.

Den ganzen Beitrag lesen »