Medizinproduktehersteller müssen die Requirements (Anforderungen) an ihre Produkte ermitteln und nachweisen, dass diese erfüllt sind. Dabei kommt es häufig zu regulatorischen Problemen, auch weil es Missverständnisse mit den verschiedenen Typen an Requirements (Anforderungstypen) gibt.
Inhalt
Diese Seite verschafft einen schnellen Überblick über:
Zu allen Themen gibt es Verweise auf weiterführende Artikel.
Während der verschiedenen Entwicklungsphasen gilt es, die verschiedenen Typen an Anforderungen zu erheben und diese zu erfüllen (s. Abb. 1).
Abb. 1: Im V-Modell lassen sich die Phasen erkennen, in denen die Anforderungen erhoben werden. Stakeholder-Anforderungen (grün); technische Anforderungen (blau)
Die Stakeholder-Anforderungen und die technischen Anforderungen unterteilen sich in weitere Typen (s. Abb. 2).
Abb. 2: Die Stakeholder-Anforderungen (grün) und die technischen Anforderungen (blau) haben jeweils Untertypen.
Diese Artikel stellen Ihnen die verschiedenen Anforderungstypen mit den jeweiligen Methoden zum Erheben und Nachweisen sowie die regulatorischen Anforderungen daran im Detail vor:
Es gibt regulatorische Anforderungen an die Requirements, konkret an das Erheben, Nachverfolgen und Nachweisen der Requirements.
Die regulatorischen Anforderungen an die Medizinprodukte verpflichten die Hersteller dazu, alle diese Typen an Anforderungen zu erheben und nachzuweisen.
Aus den Gesetzen und Normen folgt auch, dass die Hersteller die Anforderungen nachvollziehen müssen. Hersteller sollten dabei zwei Arten der „Traceability“ unterscheiden:
Abb. 3: Man unterscheidet horizontale Tracebaility (gepunktete Linien) und vertikale Traceability (gestrichelte Linien).
Die Traceability setzt voraus, dass die einzelnen Anforderungen eindeutig identifiziert sind, beispielsweise mit einer ID.
Die Gesetze und Normen verpflichten die Hersteller nachzuweisen, dass die Produkte alle an sie gestellten Anforderungen erfüllen. Dabei setzen viele Hersteller Anforderungen mit Akzeptanzkriterien gleich. Auch wenn das in der Praxis oft funktioniert, sind die beiden Begriffe nicht synonym.
Akzeptanzkriterien beschreiben, woran man entscheidet, ob man eine Anforderung als erfüllt sieht.
Wenn eine Anforderung lautet, dass eine Software-Unit das Quadrat einer Zahl berechnen soll, dann lassen sich die Akzeptanzkriterien als die Testfälle formulieren, mit denen das geprüft wird. Aber die Testfälle sind nicht das Requirement.
Das Johner Institut empfiehlt, dass die Systemanforderungen spezifizieren, wie sich ein System als Blackbox verhält.
Es gibt Akzeptanzkriterien, die nicht(!) diese Blackbox betreffen. Dazu zählt beispielsweise die Einhaltung von Kodierrichtlinien bei einer Software-Unit. Diese Einhaltung wäre keine Anforderung an die Software-Unit selbst, sondern an deren Entwicklung.
Dass die Akzeptanzkriterien erfüllt sind, ist notwendig, aber nicht hinreichend für den Nachweis, dass auch die Anforderungen erfüllt sind. Aber in der Praxis reicht der Nachweis erfüllter Akzeptanzkriterien meist als „objective evidence“ aus.
Haben Sie noch Fragen zu den Requirements? Sie erhalten Antworten über unser kostenloses Micro-Consulting.
Im Seminar Usability, Requirements und IEC 62366-1 lernen Sie, die Anforderungen systematisch und normenkonform zu erheben.
Melden Sie sich, wenn Sie Unterstützung wünschen. Wir helfen Ihnen gerne dabei, schnell, einfach und gesetzeskonform alle relevanten Anforderungen zu erheben und nachzuweisen. Denn damit werden Ihre Produkte sicher und nachgefragt und kommen schnell in den Markt.
Lastenheft und Pflichtenheft, Systemspezifikation und Systemanforderungen Die Vorstellungen darüber, was Lastenhefte und Pflichtenhefte enthalten müssen, gehen weit auseinander – manchmal auch innerhalb einer Firma. Das liegt u. a. daran, dass die beiden Dokumente die verschiedenen Anforderungstypen nicht konsequent unterscheiden. Vielmehr unterscheiden sie sich in der Granularität und dem Detailgrad. Schon aus regulatorischer Sicht sollten Sie…
Weiterlesen
Viele Lastenhefte und Pflichtenhefte unterscheiden funktionale Anforderungen und nicht-funktionale Anforderungen. Funktionale Anforderungen sind Anforderungen mit Bezug zur Zweckbestimmung des Produkts. Zu den nicht-funktionale Anforderungen zählen Anforderungen wie die Zuverlässigkeit und das Zeitverhalten. Dieser Artikel hilft mit Beispielen, beide Anforderungstypen zu unterscheiden, und erläutert die Auswirkung auf deren Dokumentation.
WeiterlesenDie IEC 62366-1 nutzt das Konzept (Hazard-Related) Use Scenario, auf deutsch „(gefährdungsbezogenes) Benutzungsszenario“. Die FDA kennt die Critical (User) Tasks. In der Entwicklung arbeitet man mit Use Cases und User Stories. Diese Begriffsvielfalt erschwert ein gemeinsames Verständnis. Das aber ist notwendig, um konsistente und gesetzeskonforme Gebrauchstauglichkeitsakten zu erstellen und regulatorische Probleme zu vermeiden. Dieser Artikel…
Weiterlesen
Das User Centered Design zielt darauf ab, künftige Anwender von Anfang an in die Entwicklung einzubeziehen. So einleuchtend dieser Ansatz klingt, so häufig führt er zu fatalen Fehlentwicklungen. Sie erreichen das Gegenteil dessen, was Sie wollten, nämlich unsichere und gebrauchsuntaugliche Produkte, die gegen regulatorische Vorgaben verstoßen. Doch mit drei Schritten wird es gelingen, das wirkliche…
WeiterlesenViele Medizinproduktehersteller schwören auf die agile Softwareentwicklung. Der nicht nur rechtlichen Implikationen ist man sich aber häufig nicht bewusst.
Viele Firmen verwenden Personas als Methode im Usability und Requirements Engineering. Eine Persona ist eine fiktive Person, die als repräsentativer Vertreter einer Gruppe dient, typischerweise einer Gruppe potenzieller Benutzer eines Systems. Besonders in der agilen Software-Entwicklung sowie bei Marketing- und Design-Agenturen sind Personas beliebt. Doch die Methode wird häufig missverstanden und birgt Risiken, die den meisten…
WeiterlesenUnter Mockups versteht man in unserer Domäne meist einfache (UI-) Prototypen, mit denen Hersteller insbesondere die Gebrauchstauglichkeit von Medizinprodukten früh im Entwicklungsprozess – beim Prototyping – prüfen können.
Der IEC TR 62366-2 ist ein „Technical Report“, den Medizinproduktehersteller als „Gebrauchsanweisung“ für die IEC 62366-1 nutzen können. Der Technical Report gibt konkrete Handlungsleitung beim Usability Engineering, um die Anforderungen der IEC 62366-1 zu erfüllen. Dieser Artikel verschafft Ihnen einen Überblick über den mehr als hundertseitigen IEC TR 62366-2.
WeiterlesenUnter „Design Input“ versteht man die Entwicklungsvorgaben, an die nicht nur die FDA konkrete Forderungen stellt. Dieser Artikel beschreibt, welche Inhalte Ihr Design Input enthalten sollte. Sie erfahren, wie das Risikomanagement mit dem Design Input zusammenspielt. Inhaltsübersicht Definition „Design Input“ » Regulatorische Anorderungen » Inhalte des Design Inputs » Risikoanalyse als Design Input »
WeiterlesenBeim Wort „Produktmanager“ oder „Produktmanagement“ verdrehen viele Entwickler die Augen. Die Zusammenarbeit der beiden Abteilungen ist oft von Reibungsverlusten geprägt. Lesen Sie hier, weshalb dem so ist und was Sie dagegen machen können.
