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.

Software Requirement Specification (SRS): Typische Fehler und deren Folgen

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.

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 ich immer und immer wieder auf diese Probleme stoße, die eigentlich so einfach zu vermeiden wären, habe ich beschlossen, eine kostenlose Serie an Videotrainings zu veröffentlichen. Wenn Sie sich an meine 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!

Unser Tipp: Spezifizieren Sie die Software-Anforderungen (SRS) aus Blackbox-Sicht

Eine SRS sollte die Anforderungen an die Software als Blackbox beschreiben.

x

Wie soll sich das System nach außen verhalten? Wie reagiert es über die Schnittstellen, seien es die zum Anwender (GUI) oder zu anderen Systemen?

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)

Weshalb dieses Konzept hilft, die Forderungen der IEC 62304 Kapitel 5.2 zu 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.

Software-Anforderungen selbst prüfen

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

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 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.

Software-Anforderungen: Wie wir Sie unterstützen können

1. 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.

2. 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.

3. 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 Auditsprechstunde oder nehmen Sie mit uns Kontakt auf.


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 »


Mittwoch 13. Mai 2015 von Prof. Dr. Christian Johner

User Stories werden in der agilen (Software-)Entwicklung genutzt, um die Kundenanforderungen zu erheben und zu dokumentieren.

Aber sind User Stories auch geeignet, um die Anforderungen an Medizinprodukte (normenkonform) zu beschreiben? Erfüllen sie die Anforderungen einer IEC 62366? Und wie hängen diese mit den Use Scenarios zusammen? Dieser Beitrag gibt Antworten.

Den ganzen Beitrag lesen »