User Stories werden in der agilen (Software-)Entwicklung genutzt, um die Kundenanforderungen zu erheben und zu dokumentieren.

Aber sind User Stories auch geeignet, um die Anforderungen an Medizinprodukte (normenkonform) zu beschreiben? Erfüllen sie die Anforderungen einer IEC 62366? Und wie hängen diese mit den Use Scenarios zusammen? Dieser Beitrag gibt Antworten.


User Stories: Nicht nur für Medizinprodukte

User Stories: Ziel und Formulierung

Hersteller verwenden User Stories, um Anforderungen — meist an eine Software — in der Sprache der Kunden/Anwender zu formulieren. Sie nutzen dazu „natürliche“ Formulierungen, die der Alltagssprache entsprechen, greifen aber meist auf Satzschablonen zurück wie „As a <role> I can <activity> so that <business value>“.

Als Beispiel für eine User Story wird mir genannt:

„As an EPAT (Extracorporeal Pulse Activation Technology) technician I can adjust the energy delivered in increments so as to deliver higher or lower energy pulses to the patient’s treatment area.“

User Stories aus regulatorischer Brille

Die Regularien wie die ISO 13485, IEC 62366 oder die FDA fordern meist keine Methoden und damit auch keine User Stories. Allerdings fordern sie, dass folgende Aspekte explizit dokumentiert sind, um ein Tracing untereinander zu ermöglichen:

  • Zweckbestimmung
  • Stakeholder-Anforderungen wie Nutzungsanforderungen
  • Usage Scenarios, Benutzungsszenarien
  • System Anforderungen / System Spezifikation

User Stories vermischen leicht einige dieser Aspekte: Der beispielhaft formulierte Satz entspricht einer Nutzungsanforderung: „Der Nutzer muss am System die zu verabreichende Energie auswählen können“. Hingegen formuliert man das „um … zu“ nicht bei den Nutzungsanforderungen, sondern bei den Erfordernissen, von denen man im Rahmen des angesprochenen Verfahrens (bzw. der Zweckbestimmung) die Nutzungsanforderungen ableitet.

Es sind also zwei Dinge, die mir etwas Bauchweh machen:

  1. Man vermischt die Erfordernisse (nur diese kennen den Zweck, hier „Business Value“ genannt) bzw. die Zweckbestimmung mit Nutzungsanforderungen. Nur die beiden letzteren kann man validieren.
  2. Man glaubt, durch das Formulieren dieser User Stories die wirklichen User bzw. Stakeholder-Anforderungen zu kennen. Die Formulierungsschablonen ersetzen aber keine Methodik zum Ableiten dieser. Man kann jede User Story formulieren, ohne dass es sich prüfen ließe, ob diese korrekt und berechtigt ist. Möglicherweise muss man die Energie überhaupt nicht einstellen können…

User Stories und Usage Scenarios

Usage Scenarios (oder Use Scenarios bzw. die Nutzungsszenarien) beschreiben die Abfolge von Nutzeraktionen und Systemreaktionen. Sie leiten sich aus den Kernaufgaben und den Stakeholder- (insbesondere Nutzungs-)Anforderungen ab. Usage Scenarios können Sie aber nicht systematisch aus User Stories ableiten. User Stories ersetzen auch keine Usage Scenarios. Letzte müssen Sie aber laut IEC 62366 dokumentieren.

Fazit: Verzichten Sie auf User Stories. Sie richten mehr Schaden als Nutzen an. Gehen Sie stattdessen wie folgt vor:

  • Formulieren Sie die Zweckbestimmung und damit den medizinischen Zweck und die spezifizierten Nutzer.
  • Leiten Sie mit der Kontextmethode die Erfordernisse, die Nutzungsanforderungen und Kernaufgaben ab.
  • Spezifizieren Sie anhand dieser die Usage Scenarios und darauf basierende das interaktive Produkt.
  • Validieren Sie diese Spezifikation

PS: Use Cases

Die Benutzungsszenarien liegen näher an den Use Cases. Doch sind beide Begriffe synonym zu verstehen? Antworten gibt Ihnen ein Beitrag zur Gemeinsamkeiten und Unterschieden von Use Cases und Benutzungsszenarien.

In mehreren Videotraininings des Auditgarant erkläre ich Schritt für Schritt, wie Sie diese Erfordernisse und Nutzungsanforderungen (nicht nur) für Medizinprodukte methodisch, d.h. systematisch und objektiv ableiten, wie Sie Benutzungsszenarien beschreiben und Prototypen validieren.

Wie hilfreich war dieser Beitrag?

Bitte bewerten Sie:

Durchschnittliche Bewertung 0 / 5. Anzahl Bewertungen: 0

Geben Sie die erste Bewertung!


Kategorien: Auf was Sie bei der Systementwicklung von Medizinprodukten achten müssen, Software & IEC 62304, Usability & IEC 62366
Tags: ,

3 Kommentare

  1. Martin Heinemann | Mittwoch, 13. Mai 2015 um 13:32 Uhr - Antworten

    Hallo Herr Johner,

    bei agiler Entwicklung ganz auf User-Stories zu verzichten ist ein nicht leichtes unterfangen, da sie in vielen Entwicklungsprozessen die Basis aller Arbeiten darstellen und wir wollen die Entwickler ja auf unserer Seite behalten.

    Meiner Erfahrung nach haben User-Stories auch bei der Entwicklung von medizinischer Software durchaus eine Daseins-Berechtigung wenn (wichtig!) alle begreifen, dass man alleein über User-Stories keine Design- und Architektur-Dokumentation zusammenträgt. Das funktioniert nämlich gar nicht. (Dazu später mehr)

    User-Stories sind das Transportmittel für Anforderungen in agilen Entwicklungsprozessen. Sie werden auf Basis von Anforderungen erstellt, durch Groomings mit weiteren Informationen angereichert und beenden ihr Leben zum Ende des Sprint in dem sie fertig gestellt werden.
    Stünden zu Beginn der Entwicklungsphase alle Designs und Architekturen schon fest, so könnte man die Gesamtheit aller User-Stories als Beschreibung des entwickelten Systems verwenden. Aber dann wären wir wieder im V-Model/Wasserfall.

    Da sich aber durchaus Anforderungen in der laufenden Entwicklung ändern können, oder Funktionen nach und nach implementiert werden, bedingt das User-Story Model, dass eine jetzt zu bearbeitende Story eine in einem früheren Sprint umgesetzte Story verändert, ersetzt oder gar ungültig machen kann. Nutzt man die Stories weiterhin als Beschreibung des Systems wird es jetzt schwierig da man die alte Story irgendwie markieren muss als „Ersetzt durch Story-45“ oder „Teilweise-Verändert durch Story-87“. Würde man dies durch viel Arbeit pflegen können, gibt es ein weiteres Problem: die neue Story macht die Einhaltung der Definition of Done der alten Story ungültig da sich die Funktionen geändert haben. Eine Beweiskette, dass die alte Story mal korrekt abgeschlossen wurde, lässt sich dadurch sehr schwer aufrecht erhalten.

    Die Lösung der Problematik liegt in einer Aufspaltung: Wir brauchen einerseits eine Dokumentation über Anforderungen, Use-Szenarien, Design, Architektur, etc. und anderer Seits brauchen wir Prozess-Dokumentation die belegt, dass wir uns an unseren Scrum/Agilen-Prozess gehalten haben.
    User-Stories sind unsere Prozess-Dokumentation, angereichert mit all den Artefakten die durch Planung, Grooming, Entwicklung und Test entstanden sind.
    Die geforderte Dokumentation von Design, Architektur etc. sind „einfache“ Aufgaben/Artefakten, die bei der Umsetzung einer Story erstellt werden müssen und damit Punkte die auf eine „Definition of Done“ gehören. Tut man dies, wird auch der schreibfaulste Entwickler bald zu jeder Story ein paar Zeilen in die Architektur-Dokumentation schreiben und alle sind am Ende des Sprints stolz auf das Gesamt-Paket das erstellt wurde.

    Wir haben mit diesem Vorgehen sehr gute Erfahrungen gemacht. Dadurch muss man den agilen Gedanken nicht verbiegen sonder flechtet die geforderten Anforderungen geschickt in den Prozess ein.


  2. Raphael Müller | Dienstag, 17. März 2020 um 16:44 Uhr - Antworten

    Guten Tag Herr Johner,
    Guten Tag Herr Heinemann,

    Ich möchte hier sowohl meinen Vorredner and auch Sie fragen:

    Zentrale Frage: Decken User Stories inkl. Acceptance Criteria die Stakeholder-Anforderungen & Software Anforderung (nach ISO 13485 und IEC 62304) ab?

    Wir verlinken alle Anfragen/Bugs, falls wir diese Entwicklen, mit Requirements in User Story form ab.

    Ich verlinke hiermit auf ihren Beitrag zum V-Modell und Requirements: https://www.johner-institut.de/blog/tag/requirements/

    Somit würden also ein Katalog an User Stories genügen um die Nutzeranforderungen abzuholen. Diese verlinkt (traceability) mit A. einem automatischen Test (Validierung) und B. mit einer Spezifikation/Architektur welche wiederum einer Verifizierung unterliegt. Sind meine Annahmen korrekt?

    Vielen Dank


    • Prof. Dr. Christian Johner | Dienstag, 17. März 2020 um 21:01 Uhr - Antworten

      Sehr geehrter Herr Müller,

      die regulatorischen Vorgaben für die Stakeholder-Anforderungen sind etwas wage. Dennoch kann man sagen, dass die User Stories nicht alle Stakeholder-Anforderungen abdecken. Ein Beispiel für das Gap wären die regulatorischen Anforderungen.

      Die Anforderungen der IEC 62304 Kapitel 5.2 bekommt man mit User Stories nicht wirklich erfüllt.

      Die User Stories halte ich ingesamt für nicht problemfrei im regulatorischen Kontext, da sie eine Vermischung von Zweckbestimmung, Stakeholder-Anforderungen und Systemanforderungen darstellen. Man kann sie aber in diese Konzepte zerlegen.

      Beste Grüße, Christian Johner


Hinterlassen Sie einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.