Schon in der Blogserie „Wie viel Usability Engineering braucht das RE?“ haben wir uns damit beschäftigt, wie man Usability Engineering (UE) und Requirements Engineering miteinander verbinden kann. Inzwischen haben wir weiter geforscht und wollen Ihnen die Ergebnisse nicht vorenthalten.
Aber, holen wir Sie erst noch einmal ab, bevor es weiter geht:
Im Requirements Engineering ist eines der wichtigsten Ziele, aber auch gleichzeitig eine der größten Herausforderungen, Anforderungen vollständig zu erfassen. Aber leider stehen uns nicht immer alle Stakeholder zur Verfügung, um Informationen zu sammeln. Oder haben Sie schon einmal einen Endkunden zu seinen Wünschen und Bedürfnissen in Bezug auf Ihr neues Produkt befragt, das noch gar nicht auf dem Markt ist?
Dazu kommt, dass wir im Requirements Engineering unseren Fokus auf Systeme und Systemprozesse legen und die Benutzer, bzw. die Bedienbarkeit einer Anwendung nur wenig berücksichtigt wird. Hier kommt uns das Persona-Konzept nach Kim Goodwin zur Hilfe. Es ist ein Konzept, das eigentlich im Usability Engineering verwendet wird, um Anwendungen möglichst benutzerfreundlich und effizient zu gestalten, um so die Schnittstelle zu den Benutzern zu verbessern. Dabei werden Personen oder Personengruppen als fiktive User-Archetypen definiert und im weiteren Analyseverlauf wie reale Personen behandelt.
Eine Persona wird definiert, in dem zunächst Annahmen getroffen und die Personen untersucht werden. In einem Persona-Steckbrief werden die Ergebnisse dann dokumentiert. Und aus diesem Steckbrief können wir, aus der Sicht des Requirements Engineerings, etliche Informationen und Schlüsse ziehen, die unsere RE-Artefakte ergänzen. Hier die Variablen, die für jede Persona im Steckbrief definiert werden:
Zum einen wird eine Rolle definiert, wie z.B. Stammgast, Gästegruppe in einem Restaurant. Dazu passend kommen die demografischen Variablen, wie Name, Alter, Familienstand, etc. dazu.
Verhaltensvariablen
Bei den Verhaltensvariablen wird es nun spannend. Wir geben Ihnen eine kurze Definition dazu:
|
Aktivitäten |
Eine Aktivität ist eine Tätigkeit, die eine Persona mit Hilfe der Anwendung oder im Anwendungskontext durchführt. Auch die Häufigkeit und der Umfang der Tätigkeit werden hier dokumentiert. Z.B.: Der Gast gibt einen Tag vorher telefonisch beim Rezeptionisten eine Reservierung für 2 Personen auf. Er bevorzugt seinen Lieblingsplatz am Fenster. |
|
Nutzungskontext |
Der Nutzungskontext ist die physikalische Umgebung, in der sich die Persona befindet und in der das System benutzt wird. Z.B.: Die Geräuschkulisse ist je nach Gästen laut bis sehr laut. Durch die Gespräche an jedem der Tische ist immer ein gewisser Lautstärkepegel vorhanden. |
|
Einstellungen |
Denkweise des Nutzers über Produktbereich und Technologie. Z.B.: Der Stammkunde denkt positiv über den technischen Fortschritt und ist von allem schnell zu begeistern. |
|
Fähigkeiten |
Die Ausbildung bzw. das Bildungsniveau des Nutzers und seine Fähigkeit zu lernen. |
|
Ziele (Motive) |
Personaspezifisches Nutzer- oder Kundenziel, das durch die Funktionen der Anwendung erreicht werden soll. Sprich, die Gründe, warum sich der Benutzer mit dem Produktbereich beschäftigt. Z.B.: Der Stammgast möchte persönlich Angesprochen werden. Er hat bestimmte Vorlieben, und genießt es, wenn der Service sie vom letzten Besuch in Erinnerung hat. |
|
Vorkenntnisse |
Sie beinhalten die Fähigkeiten des Nutzers, die mit Produktbereich und den Technologie zu tun haben. Z.B. Vertrautheit mit der Handhabung von Endgeräten. |
|
Mentales Modell |
Es beschreibt die subjektive Vorstellung einer Persona von der neuen Anwendung oder den neuen Funktionalitäten. Das Mentale Modell beschreibt die Repräsentation, wie sich ein Benutzer ein System vorstellt und wie es tatsächlich arbeitet. |
Eine fertige Persona wird als Stakeholder in die Stakeholderliste aufgenommen, so dass sie durch eine reale Person in Terminen und Abstimmungen mit einbezogen werden kann. Umgekehrt können aber auch Stakeholdergruppen gebildet und als Persona definiert werden.
Wie Sie den Persona-Steckbrief konkret im Requirements Engineering, für die Analyse von Use-Cases, die Ergänzung des Systemkontext oder die Ableitung von Anforderungen einsetzen können, erfahren Sie im nächsten Teil dieser Blogserie.
Quellen:
Chris Rupp und die SOPHISTen: Requirements-Engineering und –Management – Professionelle, iterative Anforderungsanalyse für die Praxis, Hanser Verlag, München 2009.
Goodwin, Kim: Designing For The Digital Age. Wiley Publishing, Inc., Indianapolis, 2009.