Effizientes Usability Engineering

In unserem letzten Beitrag haben wir die Strukturierung von Requirements und die verwendeten Ebenen erläutert. Sie haben den Beitrag verpasst? Hier geht es zum ersten Teil der Serie: Part #1.

In diesem Beitrag zeigen wir Ihnen, warum diese Aufteilung sinnvoll ist und wie sie Ihnen dabei hilft, die Usability-Anforderungen der IEC 62366-1 zu erfüllen.

Grundfunktionen

Wie in Part #1 beschrieben, enthält die Requirement-Struktur eine Schrittweise Umsetzung und Detallierung der Anforderungen nach dem Design. Diese Schrittweise Detaillierung betrifft nicht nur Design Requirements, sondern auch Usability-Anforderungen. Dies vereinfacht die Ausarbeitung einzelner Anforderungen und die gesamte Anforderungsdokumentation, da Sie direkt mit den Requirements selbst arbeiten.

Struktur der Anforderungen

Die Requirement-Struktur folgt nicht nur dem Design, sondern auch der Funktionalität des Produkts. Wir beginnen auf der obersten Ebene mit den Kernaufgaben (Core-Tasks) des Produkts, die sich aus der Zweckbestimmung ableiten. Diese beschreiben:

• Wer: Welcher Nutzer…
• Wie: …durch welche Interaktion mit dem Produkt…
• Was: …einen bestimmten Zweck erfüllen oder einen Nutzen erzielen

Parallel zur Entwicklung der Designarchitektur auf drei Ebenen werden diese Handlungen ebenfalls auf den entsprechenden Ebenen festgelegt. Anders als bei Use Cases in der UML (Unified Modeling Language) betrachten wir hier die Benutzerinteraktion und die jeweilige Designkomponente zusammen.

Die Kernaufgaben fokussieren sich ausschließlich auf Benutzerinteraktionen und bilden die Grundlage für die Usability-Betrachtungen. Da die Interaktionen direkt mit den Requirements analysiert und definiert werden, ist das Geräteverhalten mit weiteren Abhängigkeiten ebenfalls definiert. Dies ermöglicht es, die Anforderungen der FDA HFE (Human Factors Engineering) direkt zu erfüllen und Überlegungen zu Cybersecurity zu berücksichtigen (mehr dazu später).

Anforderungen und mehrere Ebenen

• Höchste Ebene: Anforderungen werden von Stakeholdern (z.B. Ärzte, Pfleger, Patienten) gestellt. Beispiel: Das Produkt soll eine Absaugfunktion zur Verfügung stellen, die eine Operation unterstützt. (die konkrete medizinische Anwendung sollte hier definiert werden)
• Unterste Ebene: Eine spezifische technische Lösung wird beschrieben. Beispiel: Ein farbiger Taster.