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

Heute kommen wir zum letzten Teil unserer Blogserie zum Thema Anforderungen und Benutzerfreundlichkeit. Dabei möchten wir noch auf das Thema Qualitätssicherung im Requirements Engineering unter Usability-Aspekten eingehen und ein abschließendes Fazit ziehen.

Qualitätssicherung im Requirements Engineering unter Usability-Aspekten
Wenn Sie das Persona-Konzept in Ihrer Analysearbeit berücksichtigen, stellen Sie die Qualität natürlich trotzdem mit den vertrauten Mitteln, wie Stellungnahme, Walkthrough oder Inspektion sicher. Aber Sie sollen sich Gedanken machen, ob sie nicht auch folgende Tipps in Ihrem Projekt sinnvoll anwenden können:

  • Setzen Sie perspektivenbasiertes Lesen ein: je Persona sollte ein Reviewer benannt werden, der die Persona real vertritt
  • Einsatz von Prototypen: von der Skizze bis hin zu einem programmierten Prototyp ist alles möglich. Skizzierte Storyboards sind zudem hilfreiche zusätzliche Artefakte
  • Priorisieren Sie die Benutzerinteraktionen aus User-Sicht:

Die Priorität der Benutzerinteraktionen und Informationen auf der Oberfläche sollte aus der Anforderungsbeschreibung hervor gehen und ist eine wichtige Zulieferung für den grafischen Designer.

Priorisiert werden könnte nach: dringend, wichtig, gewöhnlich, unwichtig.

Fazit:
Abschließend kommen wir zu folgenden Schlüssen:

1. Anforderungen vollständig zu erheben ist eine Herausforderung für jeden Requirements Engineer.

2. Vollständige Anforderungen sind entscheidend für den Erfolg eines Projektes oder Produktes.

  • Fehlende oder nicht verfügbare Stakeholder führen oft zwangsläufig zu Lücken
  • Implizite Erwartungen und Vorstellungen an die Bedienbarkeit einer Anwendung existieren
  • Die Anordnung von Informationen und Aktionen in einer Anwendung wird häufig den Designern überlassen, ohne dabei die fachliche Priorität zu berücksichtigen.

3. Bedienbarkeit ist ein Qualitätsmerkmal und ein Erfolgskriterium:

  • Ein Produkt, dass nicht benutzbar ist, wird nicht gekauft
  • Ein Produkt, dass nicht benutzt bzw. gekauft wird, wird nicht weiterentwickelt

4. Ziele, Systemkontext, Use-Cases, Aktivitätsdiagramme und das Begriffsmodell lassen sich

Daher empfiehlt es sich, die Usability, aber insbesondere das Persona-Konzept nach Kim Goodwin, in das Requirements Engineering einfließen zu lassen. Besonders natürlich, wenn Stakeholder nicht (oder noch nicht) verfügbar sind. Der Mehraufwand für die Erstellung eines Persona-Steckbriefs und die Ableitung von personaspezifischen Anforderungen lohnt sich im Vergleich zu den Aufwänden werden, um die Fehler die durch lückenhaft erhobene Anforderungen entstanden sind zu beseitigen.

Wenn Ihnen unser Thema gefallen hat und Sie mehr über Anforderungen und Usability wissen wollen, beraten wir Sie gerne, welche unserer Trainings für Sie und Ihr Team geeignet wären. Natürlich haben wir auch Trainings parat, wenn es um Methodenwissen rum um Requirements Engineering, Requirements Modeling oder Agilität im Requirements Engineering geht. Kontaktieren Sie uns einfach unter training@sophist.de – oder Sie stöbern einfach selbst in unserem Trainingskatalog.

Das war der letzte Teil unserer Blogserie und wir hoffen, wir konnten Ihnen Interessantes und auch Neues vermitteln. Sie haben den Anfang verpasst? Na, dann schauen Sie doch einfach hier den ersten Teil der Serie an, in dem das Persona-Konzept einleitend erläutert wird.

Wir freuen uns, wenn Sie wieder mal vorbei schauen!

Bis dahin,

Ihre SOPHISTen

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.

Hinterlasse eine Antwort

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


neun − = 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>