Die GUI Spezifikation legt offensichtlich fest, wie eine Benutzungsschnittstelle gestaltet werden muss. Aus der Definition des Begriffs alleine lässt sich nicht ableiten, wie und in welchem Detailgrad das zu erfolgen hat.
UI-Spezifikation aus Sicht der IEC 62366
Definitionen rund um den Begriff „GUI Spezifikation“
Die IEC 62366 kennt mehrere Begriffe im Kontext der „GUI Spezifikation“:
- Spezifikation der Gebrauchstauglichkeit: Dokument, das die Anforderungen an die Benutzungsschnittstelle im Hinblick auf die Gebrauchstauglichkeit beschreibt
- Spezifikation der Anwendung: Dokument, das u.a. die vorgesehene Indikation, die vorgesehene Patientengruppe, das vorgesehene Benutzerprofil und die physikalische Funktionsweise beschreibt. Das entspricht einer erweiterten Zweckbestimmung.
Den Begriff „GUI Spezifikation“ kennt die Norm nicht.
Forderungen der IEC 62366
Eine Spezifikation der Benutzungsschnittstelle, insbesondere eine „GUI Spezifikation“ kennt die IEC 62366:2007 nicht. Sie fordert nur, dass überprüfbare Anforderungen an die Benutzungsschnittstelle festgelegt werden und dass dabei
- die Hauptbedienfunktionen zu berücksichtigen seien
- die Benutzungsszenarien zu beschreiben sind
- und Maßnahmen festgelegt werden müssen, um die Risiken durch (mangelnde) Gebrauchstauglichkeit zu minimieren.
Die Norm legt also nicht fest, dass eine GUI Spezifikation beispielsweise in Form von Mockups vorliegen muss. Allerdings fordert die IEC 62366:2015 ebenso wie die FDA die entwicklungsbegleitende Evaluierung. Und die wird ohne eine Form einer Benutzerproduktschnittstelle — sei es ein Mockup, ein Prototyp oder ein Teil des Medizinprodukts — nicht möglich sein. Und damit muss die Benutzungsschnittstelle zumindest implizit spezifiziert sein, d.h. eine UI Spezifikation ist (indirekt) verlangt.
GUI Spezifikation
Spezifikationstiefe
Ich plädoyiere klar für ein UI-Spezifikation, die so detailliert ist, dass ein Entwickler die UI ohne große „Fehlermöglichkeit“ umsetzen kann. Aus folgenden Gründen:
- Ein Entwickler ist ein Entwickler und kein Usability Engineer insbesondere kein Interaktionsdesigner. Aufgaben sollten immer die Personen erledigen, die die dazu notwendigen Kompetenzen haben. Mit diesem Grundsatz vermeidet man Benutzer-Produkt-Schnittstellen, die nicht gebrauchstauglich sind und so
- zu mangelnder Benutzerakzeptanz führen,
- zeitaufwändig und kostenintensiv korrigiert werden müssen und ggf. sogar
- sicherheitskritisch sind.
- Das Risikomanagement insbesondere im Zusammenspiel mit der Gebrauchstauglichkeit bedingt, dass man Risiken durch mangelnde Gebrauchstauglichkeit identifiziert, dass man diese Risiken beherrscht und diese durch entwicklungsbegleitende(!) Prüfungen evaluiert. Solang man keine UI hat, lässt sich nichts analysieren geschweige denn evaluieren.
Wie bereits oben geschrieben: Die Regularien verlangen aber nicht(!!), dass diese UI-Spezifikation pixelgenau ist. Da sind die Regularien viel zu „fuzzy“.
Selbst eine pixelgenaue Spezifikation treibt den Aufwand für die Verifizierung nicht notwendigerweise stark in die Höhe. Sie würden Sie ja nicht jedes Pixel einzeln spezifizieren und mit einer „Requirements-ID“ versehen. Vielmehr könnten Sie festlegen, dass der endgültige Screen gemäß einem Mockup gestaltet sein muss und dass Änderungen daran erlaubt sind, solange diese im Risikomanagement bewertet wurden. D.h. man hätte pro Screen eine einzige Anforderung, zumindest was dessen statische Darstellung betrifft.
Idealer Zeitpunkt des Erstellen einer (G)UI Spezifikation
Umso früher im Entwicklungsprozess Sie eine GUI Spezifikation erstellen, desto früher können Sie diese GUI bewerten, Feedback einholen und verbessern bevor das Produkt entwickelt ist und jede Verbesserung zu einem hohen Änderungsaufwand führt.
GUI Spezifikation versus Usability Spezifikation
Wie oben geschrieben muss die Usability Spezifikation (die Spezifikation der Gebrauchstauglichkeit) die Anforderungen an die Benutzungsschnittstelle im Hinblick auf die Gebrauchstauglichkeit beschreiben. Wie unterscheidet sich das von der GUI Spezifikation?
Die Norm ist hier nicht sehr genau, wie die beiden folgenden Beispiele klarmachen:
- Der Nutzer muss auch aus drei Meter Entfernung den Patientennamen lesen können.
- Das System muss den Patientennamen in Arial-Schriftart mit 30px Größe anzeigen.
Beides sind prüfbare Anforderungen. Die erste Anforderung ist aber auf Ebene der Nutzungsanforderungen (als ein Typ von Stakeholder-Anforderungen), die zweite auf Ebene der Systemanforderungen bzw. Software-Anforderungen konkreter der System- bzw. Software-Spezifikation.
D.h. die Usability Spezifikation kann ein Teil System-/Software-Spezifikation sein (und der GUI Spezifikation entsprechen) oder das Input-Dokument sein, mit Hilfe dessen die Systemspezifikation bzw. Software-Spezifikation erstellt wird.
Falls Sie die Usability Spezifikation auf Ebene der Stakeholder-Anforderung zu finden ist, müsste die Traceability zwischen den beiden Spezifikationstypen (Usability Spezifikation und GUI Spezifikation) sichergestellt werden. Zudem empfiehlt es sich, die GUI-Spezifikation durch eine entwicklungsbegleitende (formative) Bewertung z.B. eine Usability Validierung zu prüfen.
Dass die GUI Spezifikation umgesetzt ist, würde man hingegen im Rahmen einer Inspektion (z.B. beim Systemtest) verifizieren. (Hier mehr zum Unterschied von Verifizierung und Validierung.)
Dokumentation
In den Videotrainings des Auditgarant lernen Sie, eine wirklich gebrauchstaugliche GUI schnell, schlank und IEC 62366 zu spezifizieren.
