Inhaltsverzeichnis
Welche Rolle spielt die richtige Definition der Design Levels für Ihre Medical Device Requirements?
Die Entwicklung eines Medizinproduktes ist ein komplexer Prozess, der von der ersten Idee bis zum marktfähigen Produkt zahlreiche Herausforderungen birgt. Ein zentraler Aspekt, der oft unterschätzt wird, ist die richtige Abstimmung der Anforderungen (Requirements) in Bezug auf die verschiedenen Design Levels. Wir sprechen hier von der „richtigen Flughöhe“ für Ihre Anforderungen. Eine falsche Flughöhe kann zu erheblichen Problemen im Designprozess führen, die Effizienz beeinträchtigen und letztendlich die Sicherheit und Wirksamkeit Ihres Produktes gefährden.
In einem strukturierten Designprozess betrachten wir das Produkt aus verschiedenen Perspektiven oder auch „Flughöhen“. Das hier vorgestellte Konzept gliedert sich in drei typische Hauptebenen:
- Stakeholder-Ebene (L1): Auf dieser Ebene definieren die Stakeholder – alle relevanten Personen oder Personengruppen die ein Interesse an dem Produkt haben – aus ihrer Sicht, welche notwendigen Funktionen und Eigenschaften das Produkt haben soll. Der Fokus liegt auf dem „Was“ und „Warum“, d.h. Welche spezifischen Probleme das Produkt lösen soll. Technische Details spielen hier eine untergeordnete Rolle, so dass auf dieser Ebene nur über das Produkt als solches und nicht seine technische Realisierung gesprochen wird.
- Systemebene (L2): Hier übersetzen Systemarchitekten unter Berücksichtigung technologischer Konzepte die Anforderungen der Stakeholder in eine Systemarchitektur, die in funktionalen Baugruppen gegliedert wird. Der Schwerpunkt liegt auf dem prinzipiellen „Wie“, das grundsätzliche technologische Prinzip, mit der die Stakeholder Requirements erfüllt werden sollen und das Zusammenspiel der Systemkomponenten bzw. Baugruppen. Es werden die technologischen Grundlagen umrissen, ohne dabei in detaillierte Spezifikationen (Designoutputs) einzelner Komponenten einzutauchen.
- Output Ebene (L3): Auf dieser Ebene erfolgt die konkrete technische Umsetzung der Systemkonzepte durch die Designer und Konstrukteure. Hier werden die einzelnen Module und Komponenten detailliert spezifiziert. Es entstehen z.B. Schaltplänen, Konstruktionszeichnungen und Stücklisten. Der Fokus liegt auf der detaillierten technischen Umsetzung und den Vorgaben für die Fertigung – die „Blaupause“ für das fertige Produkt.
Bei komplexen Produkten werden häufig Zwischenebenen zwischen den hier vorgestellten Ebenen (L2) und (L3) etabliert, um weitere Gliederungsstrukturen zu etablieren.
Für einen reibungslosen und effizienten Entwicklungsprozess ist die richtige „Flughöhe“ der Anforderungen entscheidend. Nur mit einer richtigen Justage auf jeder Ebene kann sichergestellt werden, dass:
- die (L1)-Requirements die Bedürfnisse der Stakeholder systematisch und korrekt erfassen.
- die Systemarchitektur die funktionalen Anforderungen, die an das Produkt gestellt werden, optimal unterstützt.
- das Design Output die Systemanforderungen präzise umsetzt.
- die systematische Nachvollziehbarkeit der Abhängigkeiten über alle Entwurfsebenen gewährleistet ist.
- Änderungen effizient verwaltet und ihre Auswirkungen analysiert werden können.
- Tests die Anforderungen adäquat abdecken.
Typische Fehler und ihre Auswirkungen
Eine falsche „Flughöhe“ der Anforderungen kann zu folgenden Problemen führen:
- Zu spezifische Anforderungen auf Stakeholder-Ebene (L1): Wenn Stakeholder bereits detaillierte technische Lösungen oder präzise Komponenten vorgeben, kann dies den kreativen Spielraum der Designer einschränken und möglicherweise zu einer weniger optimalen oder weniger zukunftssicheren Lösung führen. Außerdem besteht die Gefahr, dass technische Annahmen getroffen werden, die sich später als ungeeignet erweisen. Da technologische Interessen der Stakeholder marktrelevant sind, müssen diese erfasst werden. Diese sollten primär jedoch nicht als funktionale sondern als nicht-funktionale Anforderungen (z.B. Randbedingungen) formuliert werden.
- Zu spezifische Anforderungen auf den übergeordneten Entwurfsebenen führen auch zu Problemen beim Änderungsmanagement. Komponenten müssen z.B. im Lebenszyklus optimiert werden oder Technologien entwickeln sich weiter. Wird auf technische Informationen bereits unnötigerweise in übergeordneten Entwurfsebenen Bezug genommen, so muss diese Ebene bei Designänderungen in den Änderungsprozess einbezogen werden. Das erhöht den Aufwand, da Schnittstellen ggf. zwischen den Designebenen verwaltet und gepflegt werden müssen oder bei Änderungen Ebenen in die Verifizierungen bzw. Validierungen einbezogen werden müssen, bei denen dies gar nicht erforderlich wäre. So hätte z.B. der Austausch einer technischen Komponente auf (L3) durch eine Komponente mit vergleichbarer Spezifikation keinen Einfluss auf die Technologie oder die Anforderungen der Stakeholder. Anders sieht es aus, wenn diese bereits auf (L1) oder (L2) spezifiziert worden ist.
- Zu abstrakte Anforderungen auf der Detailebene (L3): Vage oder unklare Anforderungen auf dieser Ebene führen zu Interpretationsspielräumen bei der technischen Umsetzung, die zu Fehlentwicklungen, Inkompatibilitäten und Schwierigkeiten bei der Verifikation führen können. Anforderungen auf (L3) müssen präzise, messbar und detailliert sein, um eine eindeutige Grundlage für Konstruktion und Fertigung zu bilden. Die Spezifikation einer Komponente durch das Datenblatt eines Lieferanten zu ersetzen ist auch keine Lösung, da bei einem Austausch der Komponente nicht klar wäre, wo die Einhaltung der Spezifikation dringen erforderlich ist und wo bei der Beschaffung der Alternativen abgewichen werden kann. Das führt zu Komplikationen beim Einkauf oder zu höheren Kosten, wenn Teile beschafft werden, die für ihre Zweckbestimmung zu hoch spezifiziert wurden.
- Vermischung von Entwurfsebenen in Anforderungen: Wenn eine Anforderung Details aus verschiedenen Entwurfsebenen enthält, kann dies zu Verwirrung, Missverständnissen und unnötigem Abstimmungsaufwand führen. Es führt zu mehr oder weniger redundanten Requirements, erschwert die Rückverfolgbarkeit der bestehenden Abhängigkeiten und die Auswirkungsanalyse bei Änderungen. Einen klaren Hinweis auf so eine Vermischung erhält man, wenn z.B. identische Tests auf verschiedenen Ebenen durchgeführt werden oder das Tests über die Designgrenzen hinweg aufeinander verweisen. Jede Anforderung sollte daher eindeutig einer bestimmten Entwurfsebene zugeordnet werden.
Um die „richtige Flughöhe“ Ihrer Anforderungen sicherzustellen, beachten Sie die folgenden Punkte:
- Stakeholder-Ebene (L1): Konzentrieren Sie sich auf die Bedürfnisse, Ziele und den Verwendungszweck der Stakeholder. Beschreiben Sie die Kernfunktionen (Core Tasks), die der Nutzer benötigt, um den Verwendungszweck zu erfüllen. Formulieren Sie allgemeine und langfristig gültige Anforderungen, die dem Systemarchitekten genügend Optionen für die Technologieauswahl lassen. Vermeiden Sie das Nennen technischer Präferenzen.
- Systemebene (L2): Die Beschreibung der funktionalen Baugruppen (Module) des Systems und ihrer Interaktionen sollte sich auf die technischen Grundprinzipien konzentrieren (z.B. Bereitstellung von Wärmeenergie, Bestimmung einer Zustandsgröße). Die Spezifikation der Schnittstellen erfolgt hinsichtlich der Art, Menge und Qualität der auszutauschenden Stoffe, Energien oder Informationen, ohne bereits konkrete technische Lösungen vorzugeben (z.B. geschützte Übertragung von Information X von Modul A nach Modul B auf Anforderung von Modul B). Verwenden Sie Gruppierungen in Ihrem Design, wie sie im Rahmen der Wiederverwendbarkeit in Produktplattformen oder bei der Auslagerung von Lieferungen und Leistungen sinnvoll erscheinen.
- Detaillierungsgrad (L3): Spezifizieren Sie die einzelnen Komponenten und deren Parameter präzise und messbar. Verwenden Sie gebräuchliche Maßeinheiten und geben Sie Toleranzbereiche an. Berücksichtigen Sie bereits Fertigungsaspekte und Prüfkriterien. Externe Komponenten sollten nicht nur durch Datenblätter spezifiziert werden, sondern es sollte anhand der Datenblätter nachgewiesen werden, dass die Bauteile die geforderten Spezifikationen erfüllen.
- Klare Trennung von Design und Aufgabe: Die Designspezifikation ist klar vom Entwicklungsauftrag zu trennen. Der Entwicklungsauftrag kann neben fachlichen Anforderungen auch spezifische Implementierungsanweisungen über alle Designstufen hinweg enthalten, die Designspezifikation sollte dies zwar berücksichtigen, sich aber strikt an den Designstufen orientieren. Gleiches gilt z.B. bei agilen Projekten. So sind die User Tasks beim Sprint in Scrum Aufgaben, die auch Machbarkeitsanalysen und Mockups enthalten, und können daher nicht mit dem Design Output gleichgesetzt werden.
- Einheitliche Strukturen: Verwenden Sie Attribute für Ihre Anforderungen, um den Kontext (z.B. welcher Stakeholder, welches Systemmodul) und die Art der Anforderung (funktional, nicht-funktional bzw. Schnittstellenanforderung, Benutzerinteraktion) klar zu definieren. Dies unterstützt die korrekte Klassifizierung auf der entsprechenden Entwurfsebene. Vermeiden Sie Fließtext. Nutzen Sie Formularvorgaben, um Anforderungen in ihre Kernaussagen, wie z.B. Voraussetzung, Funktion oder Scope zu zerlegen. So schaffen Sie innerhalb der Entwicklungsteams einheitliche Designvorgaben.
- Traceability: Neben der vertikalen Traceability zu Risiken und Tests ist eine durchgängige horizontale Traceability zwischen den Anforderungen der verschiedenen Entwurfsebenen zu implementieren. Diese stellt sicher, dass alle Stakeholder-Anforderungen in das Produktdesign überführt und verifiziert werden. Die Traceability hilft ihnen auch, Ihre Informationen formal auf Konsistenz zu prüfen. So kann sichergestellt werden, dass einem als „Source of Risk“ klassifizierten Requirement auch wirklich ein Risiko zugeordnet wurde oder einer Mitigierung auch ein Test Case vom Typ „Effectiveness“.
- Reviews: Regelmäßige Design Reviews durchführen, um die Angemessenheit der „Flughöhe“ der Anforderungen auf jeder Ebene zu überprüfen und Inkonsistenzen frühzeitig zu erkennen.
Fazit
Die richtige Zuordnung der Anforderungen zu den Entwurfsebenen ist ein grundlegender Baustein für eine erfolgreiche und effiziente Entwicklung von Medizinprodukten. Achten Sie auf einen angemessenen Detaillierungs- und Abstraktionsgrad auf jeder Ebene. So vermeiden Sie bereits eine Vielzahl möglicher Fehler, verbessern die Designqualität zu erfüllen per se wichtige regulatorischen Anforderungen. Mit der Wahl der „richtigen Flughöhe“ legen Sie einen entscheidenden Grundstein für ein sicheres und effizientes Medizinprodukt.
