Unter Traceability versteht man die Nachvollziehbarkeit verschiedener Aktivitäten entlang des Entwicklungslebenszyklus. Die für Medizinprodukte spezifischen Normen wie die ISO 14971 und die IEC 62304 stellen teilweise konkrete Anforderungen an die Traceability.
Die Podcast-Episode mit Beat Keller und Professor Johner gibt eine Übersicht über das Thema Traceability und welche geforderten Dimensionen der Traceability wie abgedeckt werden können.
Diese und weitere Podcast-Episoden finden Sie auch hier.
1. Traceability und IEC 62304
Die IEC 62304 verlangt die Traceability u.a.
- von den System-Anforderungen zu den Software-Anforderungen
- von den Software-Anforderungen in die Software-Architektur
- vom detaillierten Design zur Software-Architektur
- von den Software-Systemtests zu den Software-Anforderungen
a) Traceability zwischen Software-Anforderungen und Software-Architektur
„Der Hersteller muss verifizieren und dokumentieren, dass die Software-Architektur die System- und Software-Anforderungen […] implementiert“ lautet die Forderung der IEC 62304 im Kapitel 5.3.6 zur Verifizierung der Software-Architektur. Ein kurzer Satz, der viele Herstellern fragen lässt: „Und wie mache ich das?“
Diese Nachverfolgung der Software-Anforderungen zur Software-Architektur ist alles andere als trivial. Oft gelingt es noch, die Anforderungen eindeutig zu nummerieren. Ab wie soll man von dort auf ein einziges Architektur-Dokument verlinken können? Ein Dokument, in dem die verschiedensten architekturellen Aspekte behandelt werden: Von der Wahl der Programmiersprache über ER-Diagramme für die statische Sicht bis hin zu UML-Verteilungsdiagrammen und Begründungen für bestimmte Architekturpattern.
Antipatterns
Diese Verbindung (die Traceability zwischen Requirements und Architektur) wird besonders dann Schwierigkeiten bereiten, wenn das Architekturdokument viel (unstrukturierten) Fließtext enthält. Fließtext ist manchmal herausfordernd. Denn unsere Sprache ist so vielgestaltig und nuanciert, dass die Eindeutigkeit schnell leidet:
Eine Passivkonstruktion, und schon muss man über den Akteur keine Aussage machen. Ein Konjunktiv, und schon bleibt es im Unklaren, ob dieser Aspekt verpflichtend ist oder nicht, oder nur eine Überlegung des Autors wiedergibt.
Dennoch kann es hilfreich sein mit Fließtext den Kontext zu beschreiben.
Best Practices
Daher das Plädoyer:
- Nutzen Sie lieber Modelle statt Text. Hier sind die Ausdrucksmöglichkeiten sehr eingeschränkt und die Aussagen damit eindeutiger. Modelle in Form von Bildern erlauben einen schnellen Überblick und einfachere Diskussion.
- Halten Sie Ihr UML-Diagramm „sauber“ von zu vielen Metadaten. Verunstalten Sie es nicht durch Links zu den Software-Anforderungen. Ich empfehle Ihnen aber, im UML-Klassen/Komponentendiagramm die Sicherheitsklassen gemäß IEC 62304 (farblich) zu kennzeichen, ebenso Komponenten anderer Hersteller (SOUPs).
- Strukturieren Sie das Architektur-Dokument in viele Kapitel. Ein Textabschnitt sollte eine halbe Seite nicht überschreiten, bevor er durch eine neue Überschrift unterbrochen wird. So können Sie über die Überschriften relativ genau auf einen Architekturaspekt verweisen (verlinken): „realisiert in Komponente X (siehe Kapitel m)“, „wird berechnet durch Methode Y (siehe Kapitel n)“, „ist gelöst durch Wahl der Technologie Z (siehe Kapitel o)“.
- Fügen Sie ein eigenes Kapitel (ggf. sogar ein eigenes Dokument) ein, das der Traceability gewidmet ist. Listen Sie darin die Anforderungen (erneut) auf und schreiben Sie zu jeder einen ganz kurzen Satz mit einem Verweis auf eines dieser Teilkapitel im Architekturdokument.
b) Traceability zwischen Software-Anforderungen und Software-Systemtests
Das Tracing zwischen Software-Anforderungen und Software-Systemtests gestaltet sich hingegen oft etwas einfacher, da Sie sowohl die Software-Anforderungen als auch die Software-Systemtests (im Gegensatz zu Architekturaspekten) einfach durchnummerieren können.
Allerdings benötigt man für diese Traceability zwischen beiden eine n:m-Beziehung. Das lässt sich über eine Tabelle ausdrücken, die zeigt, welche Systemtests welche Anforderungen testen, und welche Anforderungen durch welche Systemtests geprüft werden. Noch mehr eigenen sich Werkzeuge (s.u.).
2. Traceability und ISO 14971
Ähnlich der Beziehung zwischen Software- bzw. System-Anforderungen und Software- bzw. Systemtests verhält es sich bei der ISO 14971. Die Norm fordert die Traceability
- zwischen Risiken und Maßnahmen zur Risikobeherrschung und
- zwischen Maßnahmen und der Verifizierung der Maßnahmen (genauer mit der Überprüfung, ob diese implementiert und wirksam sind).
Beide Beziehungen pflegen Hersteller üblicherweise in einer „Risiko-Tabelle“, die manchmal auch fälschlich als „FMEA-Tabelle“ bezeichnet wird.
3. Traceability und IEC 60601-1
Die IEC 60601-1 kennt ähnliche Anforderungen an die Nachvollziehbarkeit wie die bereits genannte IEC 62304. Sie enthält im Anhang auch die Abbildung, die diese Traces zeigt und die oben schematisch wiedergegeben ist.
Die IEC 60601-1 verlangt zudem, dass die Änderungen nachvollzogen werden können. Man muss wissen, wer eine Änderung beantragt, wer diese genehmigt, wer deren Auswirkungen analysiert, wer diese umgesetzt und wer für den Markt freigegeben hat.
4. Werkzeuge für die Traceability
a) Allgemeines
Die Word-gestützte Dokumentation ist schwierig. Auch der „Marktführer“ für das Tracing, Microsoft Excel, stößt schnell an seine Grenzen. Das gilt besonders, weil die Verlinkung über Dokumentengrenzen hinweg funktionieren soll. Aber das ist ja genau der Grund für Werkzeuge wie MedPack und RiskPack.
Mit solchen Werkzeugen ist es einfacher, das Traceability-Chaos in den Griff zu bekommen. Das finden übrigens auch die Auditoren. Denn diese Tools haben sich in vielen Audits bewährt. Nicht nur deren Auswertungen wegen ist es einfacher, fehlendes Traces direkt anzuzeigen.
b) Anforderungen an Werkzeuge
Werkzeuge sollten folgende Fragen zu beantworten helfen:
- Welche Anforderungen (auf allen Ebenen) wurden durch Tests überprüft? Waren diese erfolgreich?
- Welche Tests müssen noch(mals) durchgeführt werden?
- Woher stammen die Anforderungen? Lassen sich beispielsweise die Software-Anforderungen auf Systemanforderungen zurückführen?
- Wie werden die Anforderungen umgesetzt? Welche Anforderungen wurden umgesetzt, welche noch nicht? Beispielsweise müsste sichergestellt sein, dass alle Stakeholder-Anforderungen z.B. durch Systemanforderungen umgesetzt werden.
- Gibt es Tests, die neu entwickelt werden oder erneut durchlaufen werden müssen, wenn sich eine Anforderung ändert? Welche sind das?
- Welche Anforderungen sind nicht überprüft, wenn ein Test scheitert?
Werkzeuge sollte weitere Anforderungen ergänzen z.B.:
- Standortübergreifende Nutzen
- Implementierung eines Rollenkonzepts, ggf. unter Nutzung bestehender Verzeichnisdienste und Autorisierungsmechanismen
- Berichte erzeugen oder Dashboards bereitstellen, die helfen, die obigen Fragen zu beantworten
- Interoperabilität z.B. Import von Anforderungen aus Word, Integration mit Entwicklungs- und Testwerkzeugen
Ich halte die Verwendung von UML-Diagrammen im Rahmen der Architekturdokumentation für absolut nützlich, weil man komplexe Sachverhalte wie z.B. eine Multi-Tier-Architektur und die Beziehung zwischen den Schichten einfach viel besser visualisieren kann, als sie in Prosa zu beschreiben.
Separate Beschreibungen ein und derselben Abstraktionselemente für bestimmte Einsatzzwecke erzeugen IMHO nur double-maintenance.
Ein Software-Modell in UML-Notation abzubilden hat viele Vorteile, weil man Projektartefakte aus verschiedensten Blickwickeln aus einer *konsistenten* Quelle erstellen kann: Architektur, Risikomanagement, Traceability, Test, Implementierung, usw.
Die Information liegt also gebündelt vor, jedes Modellelement wird genau einmal definiert, kann aber in verschiedenen Kontexten und in verschiedenen Sichten dargestellt werden (je nach dem, welche Information im jeweiligen Kontext benötigt wird).
Außerdem sind die meisten UML-Tools in der Lage, einen Export und Import von Modellen in portablen Formaten wie z.B. XML durchzuführen. Durch geeignete Scripte kann man leicht „Metadaten“ einfügen oder automatisch verarbeiten.
Aber warum überhaupt proprietäre Metadaten verwenden? Die UML bietet für solche Zwecke wie die Kennzeichnung gleichartiger Modellelemente das Mittel der Stereotypen an. Damit kann man leicht risikorelevante Elemente von anderen unterscheiden (und vieles Andere mehr).
Eine manuelle farbliche Kennzeichnung scheint mir im Vergleich dazu weit anfälliger für Fehlinterpretationen und out-dating zu sein.
Aber vielleicht ist das ja alles mehr eine Frage des persönlichen Geschmacks 😉
Sehr geehrter Herr Tietjen,
danke für Ihre Ergänzungen.
Ich bin nicht ganz sicher, ob es mir gelungen ist, mich verständlich zu artikulieren. Wenn der Eindruck entstanden wäre, dass ich UML-Diagramm für ungeeignet halte, wäre das exakt das Gegenteil dessen, was ich ausdrücken wollte.
Ich stimme Ihnen absolut zu, dass Stereotypen geeigneter sind, um Sicherheitsklassen zu charakterisieren, als eine (nur) farbliche Kennzeichnung.
Nochmals besten Dank!
Christian Johner
Hallo Herr Johner,
der Empfehlung, „UML-Diagramme“ nicht mit Anforderungen zu verunstalten, kann ich mich nicht anschliessen.
Ein gutes Werkzeug, welches Mehr als nur Diagramme zeichnen lässt, sondern ein Modell verwaltet besitzt eben diesen Vorteil, die Notwendigkeit eines AArchitekturelements durch Anforderungen nachweisen zu können.
Besonders, wenn die Architektur aufgrund einer Modelländerung/Anforderungsänderung verändert werden muss, ist so eine schnelle Prüfung des Einflusses möglich und die Tragweite der Anforderungsänderung kann plausibel abgeschätzt werden.
Ebenso verhält es sich mit den Risikomitigationen, da diese damit an ein Modellelement geknüpft sind und sich die Auswirkung der Codeänderung auf Risikomitigationen, oder deren Nicht-Auswirkung dokumentiert nacgewiesen ist.
In Kurz:
Durch die Verknüpfung Modellelement und Anforderung wird eine Impactanalyse vereinfacht und das Projekt/Produkt wartbarer gestaltet.
Beste Grüße
Stefan Bolleininger
Sehr geehrter Herr Bolleininger,
danke für Ihre wertvollen Gedanken. Die Verlinkung von Anforderungen im Architektur-Diagramm kann durchaus funktionieren, da bin ich ganz bei Ihnen. Es funktioniert v.a., wenn man nicht 1000e Anforderungen zu tracen hat, wenn das Modell so detailliert erstellt wurde, dass man die Traces überhaupt sinnvoll lokalisieren kann und wenn die Anforderungen sich überhaupt im Modell abbilden lassen.
Viele Grüße
Christian Johner
Neben der hier erwähnten Traceability von Anforderungen-Implementation-Tests gibt es noch mindestens zwei weitere Traceabilities welche Medizinproduktehersteller nicht vergessen sollten:
1. Traceability der Medizinprodukte: welche Materialien/Komponenten habe ich als Hersteller in welches Medizingerät verbaut und wo ist das Gerät hin? Fehlt mir diese Traceability, wird der Rückruf oder eine Feldmassnahme zum (noch grösseren) Albtraum.
2. Traceability oder Rückführbarkeit der Messergebnisse. Ist das 1V dass ich gemessen habe auch 1 Volt oder wären es doch 2V gewesen? Ohne eine Sicherheit dass die Messergebnisse (im Rahmen der Messunsicherheit) stimmen, kann ich als Hersteller nicht sicherstellen, dass das Gerät funktioniert wie es sollte.
Danke für die hilfreiche Ergänzung, Herr Keller!