Nun zum letzten Teil der Blogserie „Wie viel Usability Engineering (UE) braucht das RE?“, in dem wir uns mit dem Transfer der bereits vorgestellten Methoden und Artefakte des Usability Engineerings ins Requirements Engineering beschäftigen.
Um eines vorweg zu nehmen: Es gibt keine Standardlösung, wie und wann man UE und RE miteinander verknüpft.
Betrachten wir folgende Vorgehensweisen:
- 1. Ansatz: Zuerst UE, dann RE (UE → RE)
- 2. Ansatz: Zuerst RE, dann UE (RE → UE)
- 3. Ansatz: UE parallel zu RE (UE ↔ RE)
Unsere vorigen Blogeinträge beruhten auf reinem Usability Engineering, ohne zuvor RE durchgeführt zu haben.
Wir starteten mit der Erstellung von Personas, aus deren Aktivitäten wir Kontextszenarien extrahiert haben. Diese Szenarien waren daraufhin Basis für die Erhebung von Bedürfnissen.
Das Ergebnis, eben diese Bedürfnisse, war umgemünzt ins RE, eine Art von meist nicht-funktionalen Anforderungen.
Dies zeigt uns, dass wir mit unserem Vorgehen eine Reihe von user-zentrierten Anforderungen ermittelt haben, die wir ohne den Einsatz der UE-Methodik eventuell nie gefunden hätten.
Für den ersten Ansatz (UE → RE) könnte es somit folgende Transfermöglichkeiten geben:
- Personas → Stakeholderliste
- Szenarien → Use-Case-Spezifikationen
- Bedürfnisse → nicht-funktionale Anforderungen
Der zweite Ansatz (RE → UE) unterscheidet sich fast nicht vom ersten (UE → RE). Hierbei besitzt man eine, aus RE-Sicht, vollständige Spezifikation und versucht den UE-Aspekt im Nachhinein hinzuzufügen. Die Vorgehensweise unterscheidet sich vom ersten Ansatz in dem Punkt, dass bereits Stakeholder bestehen und man von Projekt zu Projekt evaluieren muss, ob weitere fiktive Personas erstellt werden sollten.
Zu beachten ist jedoch, dass die Struktur, auf deren Basis man die Spezifikation aufbaut, die des RE ist, egal welchen der drei Ansätze man verwendet.
Der dritte und letzte Ansatz (UE ↔ RE), Usability-Engineering und Requirements-Engineering zu parallelisieren, ist die wohl praktikabelste Möglichkeit, die beiden Disziplinen zu vereinen.
Es ist dabei kein einheitliches Vorgehen vorgeschrieben wir raten allerdings dazu, die Punkte aus Ansatz 1 (UE → RE) aufzugreifen und somit:
- die Personaerstellung parallel zur Stakeholderanalyse,
- die Szenarienerstellung parallel zur Use-Case-Analyse
- und die daraus resultierende Bedürfnis-Extraktion parallel zur Erhebung der nicht-funktionalen Anforderungen durchzuführen.
Fazit:
Usability Engineering ist auf dem Weg zu einer guten und vollständigen Spezifikation ein sehr wichtiger (, vielleicht sogar unerlässlicher) Faktor. Das zu entwickelnde System wird dabei von einem user-zentrierten Blickwinkel betrachtet, der nicht unterschätzt werden sollte, um Bedienerfreundlichkeit und damit häufig Kundenzufriedenheit zu gewährleisten.
Nachdem nun einige Usability Engineering Methoden näher beleuchtet wurden und wir diese in dem vierten und letzten Teil der Blogserie auf Requirements Engineering Methoden gemappt haben, ist letztendlich festzustellen, dass:
- Requirements Engineering mit Sicherheit eine Menge Usability Engineering braucht
- es keine feste Vorgehensweise gibt, wie man UE ins RE integriert. Dies sollte von Projekt zu Projekt neu evaluiert werden.
Wir hoffen, Ihnen mit dieser Blogreihe einige interessante Einblicke in die Methodik des Usability Engineering geschaffen zu haben. Da das Forschungsprojekt noch lange nicht am Ende ist, werden sich bestimmt noch einige interessante Aspekte ergeben, die wir Ihnen dann in Zukunft auch nicht vorenthalten möchten.
Hier finden Sie den 3. Teil der Blogserie „Wie viel Usability Engineering braucht das RE?“.