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 verschafft Klarheit.

1. Weshalb Sie sich mit Use Scenarios und User Tasks beschäftigen sollten

a) Weil es gesetzlich gefordert ist

Hersteller müssen die Gebrauchstauglichkeit ihrer Medizinprodukte und deren sichere Anwendung nachweisen. Das fordert die FDA genauso wie die Gesetze in Europa und anderen Märkten.

Die Use Scenarios und User Tasks sollten Hersteller sowohl für den US- als auch EU-Markt beschreiben. Weder Use Cases noch User Stories sind gefordert.

Übersicht

Regularien / zu beschreibendes Konzept	FDA	MDR/IVDR	IEC 62366-1
Use Scenario	Ja	Nein	Ja
Gefährdungsbezogenes Use Scenario	Nein [1]	Nein	Ja
User Task	Ja	Nein	Ja
Critical Task	Ja	Nein	Nein
Use Case	Nein	Nein	Nein
User Story	Nein	Nein	Nein

Anforderungen der FDA

Die FDA verpflichtet die Hersteller in ihrem Guidance-Dokument Content of Human Factors Information in Medical Device Marketing Submissions dazu, Critical Tasks zu identifizieren und nutzungsbezogene Gefährdungen zu beseitigen oder zumindest zu verringern. Die gleiche Forderung findet sich auch im HFE Guidance der FDA.

Im gleichen Dokument verpflichtet die FDA auch dazu, die Use Scenarios beschreiben:

“The submitter should also describe each use scenario included in the human factors validation testing and list the critical and non-critical tasks that constitute each use scenario.”

FDA Draft Guidance: Content of Human Factors Information 
in Medical Device Marketing Submissions 

Anforderungen von MDR und IVDR

Die EU-Verordnungen MDR und IVDR verlangen nur, die „durch Anwendungsfehler bedingten Risiken“ auszuschließen bzw. zu minimieren. Die Begriffe „Use Scenario“ und „Critical Task“ verwenden die Verordnungen nicht.

Anforderungen der IEC 62366-1

Wie bei allen grundlegenden Sicherheits- und Leistungsanforderungen sollten Hersteller harmonisierte Normen nutzen, um die Konformität mit diesen Anforderungen nachzuweisen.

Im Fall der Gebrauchstauglichkeit ist die EN IEC 62366-1 die zu harmonisierende Norm. Sie verlangt von den Herstellern,

• die gefährdungsbezogenen Use Scenarios zu ermitteln und zu beschreiben. Das setzt voraus, dass die Hersteller die Use Scenarios insgesamt ermittelt und beschrieben haben.
• die Aufgaben (tasks) und deren Reihenfolge zu beschreiben,
• die gefährdungsbezogenen Use Scenarios auszuwählen, die Teil der summativen Evaluation (i. d. R. Usability-Tests) sein sollen,
• diese Auswahl zu begründen,
• das UI auf Basis der Use Scenarios zu spezifizieren sowie
• die summative Evaluation für jedes ausgewählte gefährdungsbezogene Use Scenario zu planen und durchzuführen.

b) Weil damit bessere Produkte entwickelt werden können

Produkte sind dann gebrauchstauglich, wenn sie die Aufgaben der Nutzer möglichst effektiv, effizient und zu deren Zufriedenheit erfüllen. Das ist sogar die Definition des Begriffs „Gebrauchstauglichkeit“ (gemäß DIN EN ISO 9241-11:2018-11).

Dazu ist es notwendig, die Aufgaben zu identifizieren und zu überlegen, wie und in welcher Reihenfolge die Nutzer mit dem Produkt interagieren sollen. Das sind die Use Scenarios (wie das die Definition zum Ausdruck bringt).

2. Definitionen und Abgrenzungen

a) Use Scenario und gefährdungsbezogenes Use Scenario

Die IEC 62366-1 definiert den Begriff „Use Scenario“ (Benutzungsszenario):

Besonders relevant ist die Untermenge der gefährdungsbezogenen Use Scenarios:

Die Norm merkt an, dass die gefährdungsbezogenen Use Scenarios häufig mit einem Use Error verbunden sind. In der Praxis dürfte das sogar fast immer der Fall sein.

b) (User) Tasks und Critical Task

Die IEC 62366-1 spricht zwar von den Aufgaben, kennt aber im normativen Teil kein Konzept von „kritischen Aufgaben“. Im informativen Teil schreibt sie:

„Eine AUFGABE in einem GEFÄHRDUNGSBEZOGENEN USE SCENARIO, bei der ein USE ERROR zu einem beträchtlichen SCHADEN führen kann, kann als „kritische Aufgabe“ betrachtet werden.“

Hingegen kennt und definiert die FDA den Begriff “Critical Task”:

Im gleichen Dokument definiert sie auch die Begriff “Task” und „Serious harm“:

Bei der Definition des Begriffs „harm“ greift die FDA auf die Definition der IEC 62366-1 zurück.

Die Definition von „serious injury“ findet sich an anderer Stelle:

c) Abgrenzung von Use Scenario und User Task

Ein Use Scenario umfasst aus einer Abfolge von User Tasks an einem System (Produkt) (s. Abb. 1).

d) Abgrenzung von Use Scenario und Use Case

Definition von „Use Case“

Leider gibt es keine einheitliche und verbindliche Definition des Begriffs „Use Case“: Es finden sich beispielsweise die folgenden:

• „A use case describes a sequence of actions a system performs that yields an observable result of value to a particular actor.” [Ivar Jacobson].
• „Ein Use Case ist eine Abfolge von Handlungen oder Schritten, die typischerweise die Interaktion zwischen einer Rolle (in der UML auch Aktor genannt) und einem System definieren, um ein Ziel zu erreichen.“ [Quelle]
• „Ein Use Case spezifiziert eine Sequenz von Aktionen, die das System in Interaktion mit der Umwelt ausführt.“ [Quelle]

Vergleich der Definitionen mit Use Scenarios

Diese Definitionen sind nicht deckungsgleich.

1. Laut Ivar Jacobson geht es nur um das System. Es handelt sich NICHT um die Aktionen eines Benutzers.
2. Die zweite Definition spricht von „Actors“. Beispiel für diese Aktoren sind nicht nur die Benutzer, sondern auch andere Systeme.
3. Die dritte Definition spricht zwar von einer Sequenz von Aktionen. Allerdings sind das Aktionen, die das System mit der Umwelt ausführt, und nicht Aktionen, die ein Nutzer mit dem System ausführt.

Damit wird klar, dass Use Cases (nach der Definition von Ivar Jacobson) und Benutzungsszenarien direkt nichts miteinander zu tun haben:

Use Scenarios	Use Cases
Mit Benutzungsszenarien spezifiziert man die Abfolge von Aktionen der Benutzer und der Reaktionen des Systems auf der Nutzungsebene; und zwar so, dass damit die Nutzungsanforderungen erfüllt werden.	Use Cases übersetzen die Benutzungsszenarien in Szenarien, die nun die Leistungen des Systems spezifizieren. Man ist damit bereits – aus der Sicht der Gebrauchstauglichkeit – auf der Lösungsebene:  Was muss das System leisten, um die Nutzungsanforderungen zu erfüllen?

Genau das macht Use Cases wertvoll: Sie erlauben, die Benutzungsszenarien in Systemleistungen zu übersetzen, ohne sich zu sehr anzustrengen, ganz natürlich! Konsequenterweise verwendet man Use Cases, nachdem man zuvor Nutzungsanforderungen und Benutzungsszenarien spezifiziert hat.

e) Abgrenzung von Use Scenario und Kernaufgabe

Ein Use Scenario entspricht nicht einer Kernaufgabe. Eine Kernaufgabe ist eine Aufgabe, die eine Person durchführen muss, um ein Ziel (typischerweise im Sinne der Zweckbestimmung) zu erreichen.

Eine Kernaufgabe muss sich nicht konkret auf die Benutzung eines Produkts beziehen. Eine Kernaufgabe könnte z. B. „Puls messen“ sein, was auch ohne ein Produkt erledigt werden könnte. Ein Use Scenario hingegen schließt die technische Lösung ein, würde also die Verwendung eines Pulsmessgeräts aus Sicht des Users beschreiben.

Eine Kernaufgabe besteht üblicherweise aus mehreren Teilaufgaben. Systeme unterstützen einen Teil dieser Teilaufgaben, manchmal sogar alle. Die Teilaufgaben, welche die Nutzer am System durchführen, bilden das Use Scenario.

f) Abgrenzung von Use Scenario und Workflow

Der Begriff Workflow ist mehrfach belegt, was nicht nur im Usability Engineering zu Schwierigkeiten führt.

Workflow und Prozesse

Zum einen gibt es Workflows im Sinne von Prozessen. Sie legen die rollen- bzw. organisationseinheitenübergreifende Zusammenarbeit von Personen fest.

Diese Workflows lassen sich beispielsweise mit der Business Process Modeling Notation (BPMN) modellieren und beschreiben.

Workflow im Usability Engineering: Benutzungsszenarien und Aufgaben

Zum anderen wird der Begriff „Workflow“ als Synonym von „Benutzungsszenario“ verwendet. Dann beschreiben ein Workflow, wie (einzelne) Menschen im Rahmen einer Aufgabe mit Systemen interagieren.

g) Abgrenzung von Use Scenario und User Story

Ziel und Formulierungsschablonen

Viele Hersteller verwenden User Stories, um Anforderungen – meist an eine Software – in der Sprache der Kunden oder 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>“.

Ein Beispiel für eine User Story ist:

„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.“

Vergleich mit Use Scenarios

User Stories legen keine Reihenfolgen von Aktivitäten fest. Sie sind damit kein Ersatz für Use Scenarios.

User Stories aus der regulatorischen Brille

Es gibt keine regulatorischen Vorgaben, die Hersteller verpflichten oder es auch nur nahelegen, User Stories zu verwenden.

Das Johner Institut rät sogar explizit davon ab, weil User Stories oft dazu führen, dass Hersteller regulatorische Anforderungen nicht präzise erfüllen. Dazu mehr im Kapitel 4 b).

3. Wie Sie Use Scenarios und User Tasks dokumentieren können

a) Was die regulatorischen Dokumente sagen

Weder die FDA noch die IEC 62366-1 stellen konkrete Anforderungen daran, wie Hersteller die Use Scenarios und Tasks dokumentieren sollen. Die IEC 62366-2 sagt nur, dass es viele Möglichkeiten gäbe:

USE SCENARIOS can be written in many different forms, ranging from story-like narratives to simple lists of USER TASKS or steps in a TASK.

IEC 62366-2:2016, Kapitel 11.1

Eine Aufgabenliste ist oft nicht ausreichend, um der Forderung der IEC 62366-1 nachzukommen, die Use Scenarios zu beschreiben. Es fehlen beispielsweise die zu erzielenden Ergebnisse bzw. Nachbedingungen, anhand derer überprüft werden kann, ob der Benutzer die Aufgabe erfolgreich erfüllt hat.

b) Was das Johner Institut empfiehlt

Auch deshalb empfehlen wir, jedes Use Scenarios wie folgt zu beschreiben:

Teil 1: Aufgabenübergreifende Aspekte

Zuerst erfolgt eine Beschreibung der folgenden Aspekte:

• Vorgesehene Benutzergruppen
  Das kann eine Referenz sein auf die in der Zweckbestimmung oder „Use Specification“ spezifizierten Rollen.
• Vorgesehene Nutzungsumgebung
  Auch hier empfiehlt sich solch eine Referenz, falls die (erweiterte) Zweckbestimmung diese Informationen in ausreichender Granularität beschreibt.
• Vorbedingungen
  In diesem Abschnitt sollten Vorbedingungen beschrieben werden, die im System oder in der Nutzungsumgebung erfüllt sein müssen, z. B.:
  • Im System: Berechtigungen sind vergeben, Daten sind erfasst
  • In der Nutzungsumgebung: Informationen oder zusätzliche Werkzeuge sind vorhanden
• Nachbedingungen
  Die Art der Nachbedingungen sind im Typ den Vorbedingungen vergleichbar. Ein Beispiel für eine Nachbedingung ist, dass bestimmte Informationen im System erfasst sein müssen.

Teil 2: Tabellarische Beschreibung der Aufgaben

Dann folgt eine Tabelle, welche zeilenweise die Aufgaben mit ihren Attributen spezifiziert:

Aufgabe, z. B. Aktion des Nutzers	Reaktion des Systems (via UI)	Mögliche Nutzungs-fehler	Mögliche Gründe	Gefährdungs-situation	Möglicher Schaden mit Schwere-grad	Kritische Aufgabe (j/n)	Maßnahme zur Risiko-beherrschung
Neues Medikament für ausgewählten Patienten eingeben	Neues Medikament für den Patienten anzeigen	Medikament für falschen Patienten eingegeben	Nutzer wurde unterbrochen oder es gibt Patienten mit ähnlichen Namen	Patient nimmt falsches Medikament ein	Schwer	ja	Plausiblitäts-prüfung (Medikament und Diagnosen); Anzeige des Patientenfotos

4. Praxistipps: Was Sie beachten sollten

a) Bei Use Scenarios die richtige Granularität wählen

Hersteller sollten beim Beschreiben der Use Scenarios die richtige Granularität wählen:

• Eine zu hohe Granularität bedeutet unnötige Aufwände und führt auch bei kleinsten Änderungen dazu, dass sich das Use Scenario ändert. Das erhöht den Aufwand für die „Re-Validierung“.
• Eine zu niedrige Granularität lässt möglicherweise einzelne kritische Aufgaben nicht erkennen, was zur Gefahr führt, dass da diese Aufgaben nicht summativ ausgewählt und evaluiert wurden. Dadurch können mögliche Nutzungsfehler bei deren Identifikation übersehen und ein unsicheres Produkt kann in den Verkehr gebracht werden.

Daher können – insbesondere bei Software-UIs – folgende Heuristiken helfen:

• Eine Kernaufgabe besteht aus sieben +/- zwei Teilaufgaben, wobei Kernaufgaben nicht mit Use Scenarios zu verwechseln sind (siehe oben).
• Einzelne Mausklicks stellen keine Aufgabe dar.
• Bei Screen-basierten Produkten repräsentiert oft ein Screen eine Teilaufgabe bzw. eine Aufgabe innerhalb des Use Scenarios.

b) Bei User Stories Vorsicht walten lassen

Die User Stories vermischen die verschiedenen Konzepte, die Medizinproduktehersteller beschreiben müssen:

Abschnitt der Formulierungsschablone	Inhalt	Geeignete Dokumente
As a <role>…	Charakterisierung der Anwender	Zweckbestimmung oder/und Use Specification
…I can <activity>…	Beschreibung, was der Nutzer am System können muss	Nutzungsanforderung. Wenn bereits beschrieben ist, wie der Nutzer das kann, ist es sogar die Systemspezifikation.
… so that <business value>	Zweck dieser Aktion	Zweckbestimmung

Die Regularien verlangen die „Traceability“ zwischen Zweckbestimmung, Stakeholder-Anforderungen und Systemanforderungen bzw. Systemspezifikationen. Das wird nicht gelingen, wenn alle in einem Satz vermischt werden.

Das Arbeiten mit User Stories ersetzt kein Requirements Engineering, insbesondere kein systematisches Ableiten von Nutzungsanforderungen.

Verzichten Sie daher auf User Stories. Sie richten mehr Schaden als Nutzen an.

c) Professionelles Requirements Engineering nutzen

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 die Kernaufgaben ab.
• Spezifizieren Sie anhand dessen die Usage Scenarios und darauf basierend das interaktive Produkt.
• Validieren Sie diese Spezifikation.

5. Fazit und Zusammenfassung

a) Begriffsvielfalt

Es gibt eine große Anzahl an Begriffen, die ähnlich klingen, aber nicht miteinander verwechselt werden dürfen:

1. Use Scenario und „gefährdungsbezogenes Use Scenario“
2. User Task und Critical Tasks
3. Kernaufgabe bzw. Core Task
4. Use Case
5. User Story

Hersteller dürfen diese Begriffe nicht verwechseln. Sonst drohen regulatorische Schwierigkeiten.

b) Blick durch die regulatorische Brille

Aus regulatorischer Sicht sind nur die ersten beiden Punkte relevant. Auch wenn die FDA etwas stärker auf das Konzept der Tasks bzw. „Critical Tasks“ und die IEC 62366-1 stärker auf das Konzept der „Use Scenarios“ abhebt, ist es doch in jedem Fall essenziell, möglichst detailliert Use Scenarios, deren Aufgaben zu identifizieren und potenzielle Gefährdungen und den Schweregrad eventueller Schäden genauestens zu beschreiben.

c) Vorgehen

Die Beschreibung der Use Scenarios ersetzt weder ein Requirements Engineering, noch bildet sie den Beginn des Requirements Engineerings. Vielmehr stellen die Use Scenarios einen Zwischenschritt dar. Denn Use Scenarios sind bereits Teil der Lösungsdomäne.

d) Bedeutung

Präzise identifizierte Use Scenarios sind entscheidend für

• die Task-Analyse und die Risikoanalyse,
• sichere Medizinprodukte,
• die summative Evaluation der Medizinprodukte,
• eine konforme Gebrauchstauglichkeitsakte und problemlose Zulassungen,
• gebrauchstaugliche und von den Kunden begehrte Medizinprodukte.

Daher sind Hersteller gut aufgestellt, wenn sie die Use Scenarios systematisch identifizieren, beschreiben und bei Usability Test bewerten.