Medizinproduktehersteller müssen die Stakeholder-Anforderungen systematisch erfassen, bewerten und nachweisen, dass diese erfüllt sind. Dabei gilt es, 5 Typen an Stakeholder-Anforderungen zu unterscheiden.
Inhalt
Diese Seite verschafft Ihnen einen schnellen Überblick
„Eine Anforderung, die beschreibt, was aus Sicht einer Interessensgruppe (Gesetzgeber, Kaufentscheider, Betreiber, Benutzer) an einem System ermöglicht werden muss, um ein oder mehrere Erfordernisse zu befriedigen“
Stakeholder sind diejenigen Personen, die Ansprüche oder Interessen an einem Unternehmen, Produkt oder Projekt haben. Dazu zählen:
| Anforderungstyp | Beschreibung | Beispiel |
| Nutzungsanforderungen | Anforderungen an die effiziente Erbringung eines Ergebnisses mit einem interaktiven System (z. B. Software) | Der Nutzer muss am System die Patienten erkennen können, die Hepatitis-positiv sind. |
| Gesetzliche Anforderungen | Anforderungen von Gesetzgebern und Behörden, z. B. in Form von Richtlinien, Gesetzen, Verordnungen, Normen usw. | Nur befugte Personen dürfen die Laborwerte der Patienten sehen (Datenschutz). |
| Fachliche Anforderungen | Anforderungen an die Vollständigkeit und Korrektheit eines Arbeitsergebnisses | Der Hepatitis-Wert muss im Arztbrief auf eine Nachkommastelle genau angegeben sein. |
| Organisatorische Anforderungen | Anforderung an das Verhalten von Personen oder Organisationseinheiten bei der Erbringung von Arbeitsergebnissen | Die Ärzte müssen die Visite dokumentieren. |
| Marktanforderungen | Anforderungen, die für die Kaufentscheidung entscheidend bzw. relevant sind | Die Software muss sowohl auf Windows als auch auf Linux laufen. |
Aus den Stakeholder-Anforderungen sollten Hersteller die Systemanforderungen ableiten.
Die Anforderungstypen müssen nicht disjunkt (überschneidungsfrei) sein. Beispielsweise könnte eine gesetzliche Anforderung darin bestehen, dass eine Medikamentenverschreibung ohne Prüfung von Medikamentenwechselwirkungen und Kontraindikationen verboten ist. Damit führt eine gesetzliche Anforderung direkt zu einer Nutzungsanforderung, z. B.:
„Der Nutzer muss am System Medikamentenwechselwirkungen (und deren potenzielle Auswirkungen auf den Patienten) erkennen können.“
In folgenden Fachartikeln erhalten Sie weiterführende Informationen:
Die verschiedenen Typen an Stakeholder-Anforderungen bedürfen verschiedener Methoden zur Bewertung, ob die Anforderungen erfüllt sind.
| Anforderungstyp | Möglichkeit zur Überprüfung |
| Nutzungsanforderungen | Die Prüfung erfolgt u.a. durch eine Usability-Validierung (summative Evaluation). |
| Marktanforderungen | Das sind verkappte Systemanforderungen, die man durch eine Verifizierung prüft. |
| Fachliche Anforderungen (an das Arbeitsergebnis) |
Das ist die klassische Validierung. Neben der Usability-Validierung zählt hierzu die klinische Bewertung. |
| Organisatorische Anforderungen | Diese richten sich nicht an das Produkt, sondern an den Menschen und sind weder zu verifizieren noch zu validieren. |
| Gesetzliche Anforderungen | Gesetzliche Anforderungen können zu Nutzungsanforderungen führen (sind also entsprechend zu validieren) oder direkt zu Systemanforderungen, die verifiziert werden müssen. |
| Weitere Anforderungen, z. B. Anforderungen von Investoren an Umsatz, Anzahl verkaufter Geräte, Entwicklungszeit | Wie sich diese Zahlen überprüfen lassen, ist offensichtlich, aber aus regulatorischer Sicht uninteressant. |
Lesen Sie hier mehr zum Unterschied zwischen Verifizierung und Validierung.
Alle Normen für Qualitätsmanagement (z. B. ISO 9001, ISO 13485 oder 21 CFR part 820) verlangen, dass der Hersteller die Stakeholder-Anforderungen erhebt.
Die ISO 13485:2016 unterscheidet Anforderungen, die die Kunden ausdrücken, von den Anforderungen, die die Kunden nicht ausdrücken, die aber notwendig sind, damit das Produkt seine Zweckbestimmung erfüllen kann.
Den Autoren der Norm scheint bewusst zu sein, dass man Kundenanforderungen nicht direkt erfragen kann.
Die genannten Regularien verlangen zudem, dass die Hersteller sicherstellen, dass die Stakeholder-Anforderungen (insbesondere die Zweckbestimmung) erfüllt werden.
Die IEC 62304 übernimmt aus der IEC 60601-1 die Abbildung mit dem V-Modell – inklusive Fehler: Sie schreibt, man würde gegen die PEMS-Anforderungen validieren. Aber PEMS-Anforderungen sind Systemanforderungen. (Das „S“ in PEMS steht für System.) Systemanforderungen werden verifiziert, nicht validiert.
Abb. 1: Die IEC 60601-1 verwechselt die verschiedenen Anforderungstypen.
Weiter behauptet die Norm, die PEMS-Anforderungen ergäben sich aus Anwenderbedürfnissen. Der Begriff „Anwenderbedürfnis“ ist nicht definiert. Er entspräche noch am ehesten den Erfordernissen. Aber Systemanforderungen ergeben sich nicht aus Erfordernissen, sondern auch Stakeholder-Anforderungen. Letzte müssen die Erfordernisse erfüllen.
Wenn Sie tiefer in das Thema eintauchen wollen, dann lesen Sie das Buch „Usability als Erfolgsfaktor“ von Thomas Geis und Christian Johner.
Viele Stakeholder-Anforderungen wie die Nutzungsanforderungen lassen sich nicht durch direktes Befragen der Stakeholder (hier der Nutzer) ableiten. Wenn Sie Nutzer (User) nach deren Anforderungen (Requirements) fragen, erhalten Sie nicht die User Requirements, sondern die User Requests.
Mehr zum Unterschied zwischen User Requirements und User Requests lesen Sie hier.
Haben Sie noch Fragen zu den Requirements? Antworten erhalten Sie in unserem kostenlosen Micro-Consulting.
Im Seminar Usability, Requirements und IEC 62366-1 lernen Sie, die Anforderungen systematisch und normenkonform zu erheben.
Durch Usability Tests in den Labs des Johner Instituts stellen Sie sicher, dass die Stakeholder-Anforderungen normenkonform nachgewiesen sind und Ihre Produkte dank ihrer Gebrauchstauglichkeit erfolgreich werden.
Melden Sie sich gleich hier, wenn Sie Unterstützung wünschen. Wir helfen Ihnen gerne dabei, alle relevanten Anforderungen schnell, einfach und gesetzeskonform zu erheben und nachzuweisen. Denn damit werden Ihre Produkte sicher und gefragt 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…
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…
Weiterlesen
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 „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.
Die UML, die Unified Modeling Language, ist eine standardisierte Sprache, mit der sich Software, aber auch ganze Systeme beschreiben lassen. Durch die wenigen aber genau definierten Notationselemente der UML sind Hersteller befähigt, Sachverhalten eindeutig und präzise zu beschreiben und so Anforderungen z.B. der IEC 60601-1 und IEC 62304 zu erfüllen. Inhaltsübersicht Modellierung der Wirklichkeit » Modellierung von…
WeiterlesenDieser Artikel beschreibt, was gesetzliche Anforderungen sind, wie diese mit Stakeholder-Anforderungen und System-Anforderungen zusammenspielen, welche gesetzlichen Anforderungen es an deren Dokumentation gibt und wie Sie gesetzliche Anforderungen formulieren und damit dokumentieren können.
WeiterlesenWie identifiziert man die wirklichen User Requirements (Kundenanforderungen)? Einfach: Man fragt die User was Ihre Requirements (Anforderungen) seien. Falsch! So erfahren Sie nicht, was die User Requirements sind, sondern die User Requests! Diese Verwechslung kann das Scheitern Ihres Projekts bedeuten!
