Requirements und Usability – wie sich Anforderungen und Benutzerfreundlichkeit ergänzen, Teil 4

Im letzten Teil der Blogserie haben wir uns damit beschäftigt, wie eine Anforderungsliste aussehen kann und wie aus den benutzerzentrierten Szenarien Anforderungen ermittelt werden können. In diesem Teil geht es nun darum, diese Liste aus Sicht der Benutzer zu vervollständigen, und die Benutzerinteraktionen in Form von Abläufen, sogenannten Nutzungsabläufen, zu dokumentieren.

Die Anforderungsliste vervollständigen

Um weitere Anforderungen aus dem Persona-Steckbrief abzuleiten, betrachten Sie einfach die einzelnen Verhaltensvariablen und leiten Sie daraus jeweils Anforderungen ab. Auch bezüglich der Extraktion nicht-funktionaler Anforderungen eignen sich die Verhaltensvariablen, jedoch am ehesten die Variablen mentales Modell und Nutzungskontext. Untersuchen Sie die Inhalte auf implizite Anforderungen und notieren Sie diese in der Anforderungsliste.

Hier ein Auszug aus der Anforderungsliste auf Basis des Persona-Steckbriefs für die Persona Stammgast:

Nutzungskontext Anforderungen
Umgebung und Geräuschkulisse:
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.
Das System muss dem Stammgast die Möglichkeit bieten, die Laustärke regulieren zu können.

Funktionale Anforderungen als Nutzungsabläufe dokumentieren
Alle Anforderungen in der Anforderungsliste bilden die Basis der funktionalen und nicht-funktionalen Anforderungen aus der Benutzersicht.

Die funktionalen Anforderungen entsprechen den tatsächlichen Benutzerinteraktionen mit der Anwendung und umschreiben damit quasi die „Funktionselemente“, die ein Benutzer zum Anzeigen oder Bearbeiten von Daten benötigt. Aber Achtung: Damit sind nicht grafische Bedienelemente gemeint, sondern sozusagen nur „Informations- oder Funktionsblöcke“ (sprich Aktionen), die für den Benutzer wichtig sind! Wir stellen diese Blöcke als Aktionen im Aktivitätsdiagramm dar. Aus allen identifizierten Benutzerinteraktionen können dann die Abläufe aus der Sicht des Benutzers dokumentiert werden. Und wie machen wir das? – Genau: natürlich mit Aktivitätsdiagrammen! Die Ablaufdiagramme heißen dann Nutzungsabläufe und sehen z.B. so aus:

SOPHIST_Blog Requirements und Usability_Teil 4_Bild 1

Wie anhand der Grafik deutlich wird, sind nur die Benutzerinteraktionen modelliert und keine Systemaktivitäten. So z.B. ist die erste Aktion nicht als Systemereignis modelliert, sondern als (Benutzer-) Aktion.

Die Nutzungsabläufe werden für alle Personas erstellt und schließlich zusammengefasst. Der Nutzungsablauf wir dadurch um die einzelnen Perspektiven angereichert und immer vollständiger.

Zuletzt folgt dann der Abgleich und die Ergänzung des Aktivitätsdiagramms aus dem Requirements Engineering, das als Ergebnis der über Ermittlungsmethoden gesammelten Anforderungen bereits erstellt wurde.

Die Modellierung von Aktivitätsdiagrammen ist einer der Bestandteile des Lehrplans für den Certified Professional für Requirements Engineering im Foundation Level oder Advanced Level Modeling. Wenn Sie mehr darüber wissen wollen, finden Sie hier unseren Trainingskatalog.

Die Ergebnisartefakte, insbesondere die modellierten Nutzungsabläufe, sind eine fundierte Zulieferung für die Kollegen aus dem Design, die sich dann mit der Darstellung und der spezifischen Gestaltung der Anwendung befassen können. Wenn Sie möchten, können Sie zusätzlich in die Dokumentation mit einfließen lassen, mit welcher Priorität welche Daten anzuzeigen oder zu bearbeiten sind, sofern diese Information bekannt ist. Dann kann in Punkto Akzeptanz auch fast nichts mehr schief gehen!

Um das Thema Anforderungen und Benutzerfreundlichkeit noch abzurunden, gehen wir im nächsten Blog darauf ein, wie Fachklassen und Attribute aus den Persona-Steckbriefen abgeleitet werden können, die dann wieder unser RE-Artefakt Begriffsmodell (Klassendiagramm) vervollständigen. Klingt spannend für Sie? Dann lesen Sie uns wieder, wir freuen uns auf Ihren Besuch!

Herzlichst,

Ihre SOPHISTen

Quellen:
Chris Rupp, Stefan Queins und die SOPHISTen: UML 2 glasklar, Hanser Verlag, München 2012

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.

 

 

 

 

 

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *


+ fünf = 7

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>