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:

  1. Typen an Requirements/Anforderungen
  2. Regulatorische Anforderungen an diese Requirements
  3. Möglichkeiten der Unterstützung beim Erheben und Nachweisen

Zu allen Themen gibt es Verweise auf weiterführende Artikel.

1. Typen an Requirements / Anforderungen

Während der verschiedenen Entwicklungsphasen gilt es, die verschiedenen Typen an Anforderungen zu erheben und diese zu erfüllen (s. Abb. 1).

Im V-Modell lassen sich die Phasen erkennen, in denen die Anforderungen erhoben werden: Grün: Stakeholder-Anforderungen; Blau: Technische Anforderungen

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

Die Stakeholder-Anforderungen (grün) und die technischen Anforderungen (blau) haben jeweils Untertypen.

Abb. 2: Die Stakeholder-Anforderungen (grün) und die technischen Anforderungen (blau) haben jeweils Untertypen.

Weiterführende Informationen

Diese Artikel stellen Ihnen die verschiedenen Anforderungstypen mit den jeweiligen Methoden zum Erheben und Nachweisen sowie die regulatorischen Anforderungen daran im Detail vor:

2. Regulatorische Anforderungen

Es gibt regulatorische Anforderungen an die Requirements, konkret an das Erheben, Nachverfolgen und Nachweisen der Requirements.

a) Anforderungen an das Erheben von Requirements

Die regulatorischen Anforderungen an die Medizinprodukte verpflichten die Hersteller dazu, alle diese Typen an Anforderungen zu erheben und nachzuweisen.

Beispiele
  • Die MDR verlangt, die relevanten grundlegenden Anforderungen zu bestimmen. Sie fordert Akzeptanzkriterien, beispielsweise bei klinischen Studien.
  • Die IEC 62304 besteht auf Akzeptanzkriterien bei der Verifizierung der Software-Einheiten.
  • Die IEC 62366-1 fordert Akzeptanzkriterien, konkret bei der Bewertung des User Interfaces.
  • Die IEC 60601-1 spezifiziert zahlreiche Akzeptanzkriterien (z. B. maximale Ableitströme und Temperaturen), die sie auch als Prüfkriterien bezeichnet.
  • Die ISO 13485 fordert, die Anforderungen der Kunden zu erheben, sowohl die explizit genannten als auch die nicht genannten. Sie verpflichtet die Hersteller dazu, alle regulatorischen Anforderungen zu identifizieren.

b) Anforderungen an das Tracing von Requirements

Aus den Gesetzen und Normen folgt auch, dass die Hersteller die Anforderungen nachvollziehen müssen. Hersteller sollten dabei zwei Arten der „Traceability“ unterscheiden:

  1. Horizontale Traceability
    Die horizontale Traceability (gepunktete rote Linien in Abb. 3) soll sicherstellen, dass die Erfüllung aller Anforderungen auch tatsächlich bei der Verifizierung und Validierung überprüft wird.
  2. Vertikale Traceability
    Die vertikale Traceability (gestrichelte rote Linien in Abb. 3) soll sicherstellen, dass die Anforderungen bei der weiteren Entwicklung tatsächlich berücksichtigt werden.
Man unterscheidet horizontale (gepunktete Linien) und vertikale (gestrichelte Linien) Traceability.

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.

c) Anforderungen an den Nachweis von Requirements

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.

Beispiel

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.

Tipp

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.

Unterstützung beim Erheben und Nachweisen der Requirements

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

Lastenheft und Pflichtenheft

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
Funktionale Anforderungen und nicht-funktionale Anforderungen unterscheidet die ISO 9126

Funktionale Anforderungen versus nicht-funktionale Anforderungen

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.

Weiterlesen

Use Scenario – User Story – User Task: Endlich durchblicken

Die 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

Mit User Centered Design die falschen Produkte entwickeln

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

‚Personas‘: die 5 häufigsten Fehler vermeiden

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…

Weiterlesen
IEC TR 62366-2 Projekt (Ausschnitt)

IEC TR 62366-2:2016: Gebrauchsanleitung für die IEC 62366-1:2015

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.

Weiterlesen

Design Input: Was Sie nicht vergessen sollten

Unter „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 »

Weiterlesen