Stakeholder-Anforderungen erheben und prüfen

Viele Medizinprodukte-Regularien verlangen, dass die Hersteller die Stakeholder-Anforderungen systematisch erfassen und bewerten.

Definition: Stakeholder-Anforderung

„Eine Anforderung, die beschreibt, was auch Sicht einer Interessensgruppe (Gesetzgeber, Kaufentscheider, Betreiber, Benutzer) an einem System ermöglich werden muss, um ein oder mehrere Erfordernisse zu befriedigen“

Quelle: adaptiert aus ISO/IEC 15288

Wer die Stakeholder mit Anforderungen sind

Stakeholder sind die Personen, die Ansprüche oder Interessen an einem Unternehmen, Produkt oder Projekt haben. Dazu zählen

  • Nutzer / Anwender
  • Investoren
  • Betreiber
  • Betroffene (z.B. Wegrationalisierte)
  • Gesetzgeber
  • Kaufentscheider
  • usw.

Welche Stakeholder-Anforderungen es gibt

Typen von Stakeholder-Anforderungen

Beispiele für Stakeholder-Anforderungen sind:

  • Nutzungsanforderungen: Anforderung an die effiziente Erbringung eines Ergebnisses mit einem interaktiven System (z.B. Software)
  • Gesetzliche Anforderungen: Anforderungen von Gesetzgebern und Behörden z.B. in Form von Richtlinien, Gesetzen, Verordnungen, Normen usw.
  • Fachliche Anforderungen: Anforderung an die Vollständigkeit und Korrektheit eines Arbeitsergebnisses
  • Organisatorische Anforderungen: Anforderung an das Verhalten von Personen oder Organisationseinheiten bei der Erbringung von Arbeitsergebnissen
  • Marktanforderungen: Anforderungen die für die Kaufentscheidung entscheidend / relevant sind

Aus den Stakeholder-Anforderungen sollten Hersteller die System-Anforderungen ableiten.

Überschneidung von Stakeholder-Anforderungen

Die einzelnen Stakeholder-Anforderungen müssen nicht disjunkt (überschneidungsfrei) sein. Beispielsweise könnte eine gesetzliche Anforderungen darin bestehen, dass eine Medikamentenverschreibung ohne Prüfung von Medikamenten-Wechselwirkungen und Kontraindikationen verboten ist. Damit führt eine gesetzliche Anforderung direkt zu einer Nutzungsanforderungen wie beispielsweise die folgende:

„Der Nutzer muss am System Medikamentenwechselwirkungen (und deren potenzielle Auswirkungen auf den Patienten) erkennen können.

Wie man Stakeholder-Anforderungen prüft

Die verschiedenen Klassen an Stakeholder-Anforderungen bedürfen verschiedener Methoden zur Bewertungen, ob die Anforderungen erfüllt sind.

  • Nutzungsanforderungen: Die Prüfung erfolgt u.a. durch eine Usability-Validierung
  • Marktanforderungen: Das sind verkappte Systemanforderungen, die man durch eine Verifizierung prüft.
  • Fachliche Anforderungen (ans Arbeitsergebnis): Das ist die klassische Validierung, auch die klinische Bewertung zählt hierzu
  • Organisatorische Anforderungen: Die richten sich nicht an das Produkt, sondern an den Menschen, sind also weder zu verifizieren noch zu validieren.
  • Gesetzliche Anforderungen: Wie obigen Beispiel illustriert, können gesetzliche Anforderungen zu Nutzungsanforderungen führen (sind also entsprechend zu validieren) oder direkt zu System-Anforderungen, die verifiziert werden müssen.

Dann gibt es noch weitere Anforderungen z.B. Investorenanforderungen (Umsatz, Anzahl verkaufte Geräte, Entwicklungszeit): Diese interessiert die Auditoren/Prüfer überhaupt nicht.

Weiterführende Informationen

Lesen Sie hier mehr zum Unterschied zwischen Verifizierung und Validierung

Regulatorische Anforderungen

Alle Qualitätsmanagementnormen wie die ISO 9001, die ISO 13485 oder der 21 CFR part 820 verlangen, dass die Hersteller, die Stakeholder-Anforderungen erheben. Dazu zählen nicht nur die regulatorischen Anforderungen, sondern auch die Anforderungen, die einen Bezug zum Produkt haben.

Die ISO 13485:2016 unterscheidet sogar Anforderungen, die die Kunden ausdrücken, und solche 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. Dazu gleich mehr.

All die genannten Regularien verlangen zudem, dass die Hersteller sicherstellen, dass die Stakeholder-Anforderungen insbesondere die Zweckbestimmung erfüllt werden.

Erheben von Stakeholder-Anforderungen: Typische Fehler

a) Verwechseln von Stakeholder-Anforderungen und System-Anforderungen

Die IEC 62304 übernimmt aus der IEC 60601-1 die Abbildung mit dem V-Model. Natürlich inklusive Fehler: Sie schreibt, man würde gegen die PEMS-Anforderungen validieren. Und die PEMS-Anforderungen würden sich aus Anwenderbedürfnissen ergeben:

Stakeholder-Anforderungen

Es ist wirklich zum Verzweifeln. Wo ist denn der Begriff „Anwenderbedürfnis“ definiert? Wie kann man die wohl definierten Begriffe Verifizierung und Validierung verwechseln? Wenn schon die Normenschreiber die Aktivitäten nicht sauber zu unterscheiden wissen, wie sollen es dann die Hersteller können?

Also der Reihe nach: Der erste Entwicklungsschritt müsste aus dem Erheben der Stakeholder-Anforderungen bestehen. Diese werden hier seltsamerweise als Anwenderbedürfnisse bezeichnet.

Aus den Stakeholder Requirements leitet man die Systemanforderungen ab, hier als PEMS-Anforderungen bezeichnet. Und gegen PEMS-Anforderungen kann man definitionsgemäß nicht validieren, sondern nur verifizieren.

Vielleicht ein Beispiel, um Nutzungsanforderungen und Systemanforderungen, Validierung und Verifizierung zu trennen:

  • Eine Nutzungsanforderung (und damit Stakeholder-Anforderung) könnte lauten: Der Benutzer kann am System den Blutdruck des Patienten erkennen. Wenn der Benutzer dies tatsächlich tun kann, ist das System validiert.
  • Die Systemanforderungen könnte lauten: Das System soll den Blutdruck in schwarzer Schrift, 20 Punkt Schriftgröße auf weißem Grund in der Mitte des Bildschirms anzeigen. Wenn das System dies tut, ist es verifiziert.

b) Falsche Methoden zum Ableiten von Stakeholder-Anforderungen

Viele Stakeholder-Anforderungen wie die Nutzungsanforderungen lassen sich nicht durch direktes Befragen der Stakeholder (hier der Nutzer) ableiten. Wenn Sie Kunden (Customer) nach deren Anforderungen (Requests) fragen, werden Sie nicht die Customer Requirements erfahren, sondern die Customer Requests. Mehr zum Unterschied zwischen Customer Requirements und Customer Requests lesen Sie hier.

Um Customer, insbesondere Use Requirements (Nutzungsanforderungen) systematisch abzuleiten, bedarf es anderer Methoden, wie der Kontextmethode. Diese Methode beschreibt die ISO 9241 Teil 110.

Weiterführende Informationen

Was die ISO 9241 vorschlägt und wie man die Nutzungsanforderungen systematisch, vollständig und reproduzierbar ableitet, lernen Sie im Seminar „Usability, Requirements und IEC 62366“.


Donnerstag 13. September 2018 von Prof. Dr. Christian Johner

Lastenheft und Pflichtenheft, Systemspezifikation und Systemanforderungen

Die Vorstellungen darüber, was diese Lastenhefte und Pflichtenhefte enthalten müssen, gehen weit auseinander – manchmal auch innerhalb einer Firma.

Regelmäßig beobachtet das Johner Institut, dass die beiden Dokumente die verschiedenen Anforderungstypen nicht konsequent unterscheiden.

Lastenheft und PflichtenheftNur in der Granularität und dem Detailgrad unterscheiden sie sich. Schon aus regulatorischer Sicht sollten Sie die Begriffe Lastenheft und Pflichtenheft gegeneinander abgrenzen.

Lastenheft und Pflichtenheft | Beitrag lesen »


Dienstag 8. Mai 2018 von Prof. Dr. Christian Johner

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 Firmen nicht bewusst sind.

‚Personas‘: die 5 häufigsten Fehler vermeiden | Beitrag lesen »


Montag 20. Februar 2017 von Prof. Dr. Christian Johner

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.

Design Input: Was Sie nicht vergessen sollten | Beitrag lesen »


Dienstag 7. Juli 2015 von Prof. Dr. Christian Johner

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.

UML Unified Modeling Language: Nicht nur für Software-Architekturen | Beitrag lesen »


Dienstag 3. Februar 2015 von Prof. Dr. Christian Johner

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

Gesetzliche Anforderungen an Medizinprodukte: Formulierungsschablone | Beitrag lesen »

Seite 1