[IT kompakt] Usability Engineering kompakt || Usability Engineering im Entwicklungsprozess

2Usability Engineeringim Entwicklungsprozess

Ein Vorgehen für Usability Engineering zu beschreiben, das auf all dieverschiedenen Situationen passt, die Sie antreffen werden, ist unsererAnsicht nach nicht möglich. Sie werden auch kein „Kochbuch“ für dieAnwendung von Usability-Methoden zu lesen bekommen. Die folgendenKapitel sollen vielmehr eine Hilfestellung geben, wie Usability Engi-neering in der Praxis der Software- und Produktentwicklung betriebenwerden kann, wie die wichtigsten Usability-Methoden grundsätzlich ab-laufen, wie sie eingeplant werden können und worauf Sie achten sollten.

Dieses Kapitel gibt eine Übersicht über den Zusammenhang derverschiedenen Usability-Methoden und deren Integration in gängigeSoftware-Entwicklungsprozesse. Im nächsten Kapitel werden die einzel-nen Methoden näher beschrieben.

2.1 Software Engineering:Die vergessenen Benutzer?

Software-Entwicklungsprozesse

Gemäß einer viel zitierten Studie der Standish Group sind unvollständi-ge Anforderungen und mangelnde Einbeziehung der Benutzer die zweiführenden Gründe, warum Software-Projekte scheitern [Standish Group1994–2010]. Aktuelle Vorgehensmodelle nehmen für sich in Anspruch,hier Abhilfe zu schaffen. Tätigkeiten im Bereich Anforderungsanalyse

13M. Richter, M.D. Flückiger, Usability Engineering kompakt, IT kompakt,DOI 10.1007/978-3-642-34832-7_2, © Springer-Verlag Berlin Heidelberg 2013

14 2 Usability Engineering im Entwicklungsprozess

Tab. 2.1 Die sechs primären Software-Engineering-Disziplinen im Unified Process(Quelle: IBM Rational Unified Process®)

Geschäftsprozessmodellierung (Business Modeling)

Anforderungsanalyse (Requirements)

Analyse und Entwurf (Analysis & Design)

Implementierung (Implementation)

Test (Test)

Auslieferung (Deployment)

und -management haben in den meisten neueren Prozessbeschreibungeneinen hohen Stellenwert.

Der Unified Process (RUP), ein etablierter Software-Entwicklungs-prozess, definiert beispielsweise Requirements als eine von sechs pri-mären Disziplinen im Software Engineering (siehe Tab. 2.1).

Die Disziplin Requirements umfasst jene Aktivitäten, bei denen esum das Erfassen, Dokumentieren und Verwalten von Anforderungen derverschiedenen Interessengruppen geht (siehe unter „Hintergrund: Re-quirements Engineering“). Als eine der wichtigsten Interessengruppensollten die Benutzer dabei eine zentrale Rolle spielen!

Agile Vorgehensweisen wie beispielsweise Scrum versprechen nochmehr Kommunikation und engere Feedbackzyklen zwischen allen an derSoftware-Entwicklung Beteiligten (siehe auch „Hintergrund: Agile Soft-ware-Entwicklung“).

Für Usability-Engineering-Aktivitäten sind in modernen Software-Entwicklungsprozessen somit einige wesentliche Rahmenbedingungenerfüllt:

• Die Bedürfnisse der Benutzer werden im Rahmen der Anforderungs-analyse erhoben.

• Die Anforderungen aus Benutzersicht werden modelliert und in dieEntwicklung getragen.

• Eine iterative Vorgehensweise erlaubt die ständige Überprüfung undVerfeinerung von Ergebnissen mit Kunden und Benutzern.

• Einige Best Practices aus dem Usability Engineering, wie User Inter-face Storyboards zur Darstellung von Dialogabläufen, Personas zur

2.1 Software Engineering: Die vergessenen Benutzer? 15

Charakterisierung der Benutzer und die Erstellung von GUI-Prototy-pen, werden in vielen Vorgehensbeschreibungen explizit erwähnt.

Es wäre somit zu erwarten, dass in Software-Projekten generell und inder Entwicklung von Benutzerschnittstellen im Speziellen eine systema-tische Einbeziehung der Benutzer und ihrer Anforderungen stattfindenmüsste.

Ist das Problem damit gelöst? Die Praxis spricht eine andere Sprache.In vielen Projekten wird das User Interface vom Entwickler alleine, ohnefremde Hilfe erstellt. Die späteren Benutzer werden selten einbezogen.

Ein Grund dafür mag in Folgendem liegen: Obwohl die Berücksich-tigung der Benutzeranforderungen in aktuellen Software-Engineering-Vorgehensmodellen als wichtig erachtet wird, fehlen für das tatsäch-liche Einbeziehen von „Endbenutzern“ entsprechende Methoden undTechniken weitgehend. Damit fehlen auch Erfahrungswerte für die Pro-jektplanung. Das Resultat ist, dass viele Projekte benutzerorientierteVorgehensweisen als optional oder als zusätzlichen Aufwand betrachtenund ohne entsprechende Aktivitäten vorgehen.

Hintergrund: Agile Software-EntwicklungIn agilen Vorgehensweisen wird die Entwicklung einer Software in kurze – im All-gemeinen zwei bis vier-wöchige – Abschnitte aufgebrochen. Diese Zyklen werdenIterationen genannt. Das Ergebnis jeder solchen Iteration ist ein realisiertes, getes-tetes und mit Kunden geprüftes Teilprodukt. Dieses kann – soweit es die zu diesemZeitpunkt umgesetzte Funktionalität erlaubt – potenziell verwendet werden.

Eine Iteration soll dabei insbesondere ein Lernprozess sein. Dazu legt das Teamzusammen mit Kunden fest, was genau entwickelt werden soll, realisiert und prüft dievereinbarte Software, reflektiert anschließend die Ergebnisse und das Vorgehen undleitet Verbesserungsmaßnahmen ein. So lernt ein Projektteam über das zu entwickeln-de Produkt, die eingesetzten Technologien und die Zusammenarbeit.

Agile Teams streben aus diesem Grund danach, die Spezifikation so zeitnahwie möglich mit der eigentlichen Entwicklung vorzunehmen und zwar im direk-ten Gespräch mit Kunden anstatt über Dokumente. So entsteht die Spezifikation ausdem entwickelten Teilprodukt, dem besseren Problemverständnis und der optimiertenZusammenarbeit. Ein Projektteam beurteilt immer wieder neu, wie mit den verblei-benden Ressourcen das bestmögliche Produkt realisiert werden kann.

Agile Prinzipien wurden im Manifest für agile Software-Entwicklung [Beck et al.01] festgehalten:

• Die Kommunikation zwischen allen Beteiligten – inklusive der späteren Benut-zer – wird über die Definition von Prozessen und Werkzeugen gestellt.


• Funktionierende Software wird als wichtiger erachtet als umfassende Dokumen-tation.

• Die Zusammenarbeit mit dem Kunden spielt eine wichtigere Rolle als Vertrags-verhandlungen.

• Die Reaktion auf Veränderungen steht über der Befolgung eines Plans.

Agile Vorgehensweisen verfolgen eine Philosophie, die sich stark an den menschli-chen Denkprozessen und der Zusammenarbeit im Team orientiert und versprechendamit eine höhere Produktivität bei der Softwareentwicklung. Mehr zu dieser Thema-tik finden Sie im Buch „Software entwickeln mit Verstand“ [Dirbach et al. 11].

Benutzerorientierte Modelle

Auf der anderen Seite existieren seit gut fünfzehn Jahren benutzer-orientierte Vorgehensmodelle, welche die Anwendung von Usability-Methoden im Entwicklungsprozess beschreiben. User Centered Design(UCD) beschäftigt sich damit, wie Benutzer systematisch in die Ent-wicklung von Systemen und Produkten einbezogen werden können. Andieser Stelle sei auf die hervorragenden, durchgängig benutzerorientier-ten Vorgehensbeschreibungen von namhaften Vertretern des Fachgebietsverwiesen:

• The Usability Engineering Lifecycle von Deborah Mayhew [May-hew 99] beschreibt den Zusammenhang von Usability-Methoden überden gesamten Lebenszyklus bei der Entwicklung einer neuen Lösung.Mayhew illustriert, wie aus Benutzeranforderungen konkrete Usabil-ity-Ziele abgeleitet und in User Interface Entwürfe umgesetzt werden,die wiederum mit Benutzern geprüft werden.

• Contextual Design von Hugh Beyer und Karen Holtzblatt [Beyer et al.98] ist ein benutzerzentrierter Design-Prozess. Er vertieft die Analyseder Benutzer und deren Umfeld und zeigt auf, wie die gewonnenenInformationen in die Entwicklung einfließen. Aus diesem Vorgehenstammt die Methode „Contextual Inquiry“ (vergleiche Abschn. 3.1).

• Goal Directed Design von Alan Cooper [Cooper et al. 10] beschreibteine Vorgehensweise, um Benutzeranforderungen zu modellieren undin ein passendes Interaktionsdesign umzusetzen. Cooper’s Ansatzorientiert sich bei der Gestaltung neuer Lösungen an den über-liegenden Zielen der Benutzer. Um die relevanten Eigenschaften und

2.1 Software Engineering: Die vergessenen Benutzer? 17

Benutzerorientierte Aktivitäten planen

Lösungsvorschlag erfüllt die Anforderungen

Nutzungskontext verstehen

und spezifizieren

Benutzeranforderungenspezifizieren

Lösungsvorschlägeerarbeiten

Lösungsvorschlägeevaluieren

Erforderliche Iterationendurchführen

Abb. 2.1 Die ISO-Norm 9241-210 definiert die Schritte, die für eine benutzerorien-tierte Gestaltung von interaktiven Systemen eingehalten werden müssen. Ein neuerLösungsvorschlag erfüllt die Anforderungen erst dann, wenn er erfolgreich mit Be-nutzern evaluiert wurde

Bedürfnisse der Benutzer darzustellen, hat Cooper die Verwendungprototypischer Benutzer (Personas) eingeführt (siehe Abschn. 3.2).

Ein Prozessmodell für die benutzerorientierte Gestaltung interakti-ver Systeme wurde sogar in einer ISO-Norm verankert [DIN EN ISO9241-210]. In Abb. 2.1 sind die wichtigsten Prozessschritte dargestellt.Eine genaue Beschreibung dieser Schritte ist in ISO 9241-210 enthalten.

Wer nach diesen Ansätzen vorgeht, wird bessere Software und Pro-dukte produzieren – kein Zweifel!

Eines ist indessen nicht von der Hand zu weisen: Eine Integra-tion in gängige Software-Entwicklungsprozesse fehlt weitgehend. Esentsteht unweigerlich das Gefühl, dass diese Ansätze als aufwändige,eigenständige Disziplinen gehandelt werden: „Vergesst eure alten Vor-gehensweisen und nehmt unseren Prozess“. Diese Abgrenzungshaltungmag dazu beitragen, dass Usability Engineering von Auftraggebern und


Projektbeteiligten oft als zeit- und kostenintensiver Zusatz zum beste-henden Vorgehen betrachtet wird.

Wenn Sie nun aber ein Projekt nach einem bestehenden Vorgehensmo-dell oder einem gegebenen Entwicklungsprozess abwickeln müssen, weilIhr Unternehmen dies vorschreibt oder weil Sie darin ganz einfach vielenützliche Hilfsmittel finden, wie können Sie benutzerorientierte Me-thoden integrieren? Sollen Sie nun Geschäftsprozessmodellierung oderBenutzerbeobachtungen in Auftrag geben, um die notwendigen Arbeits-schritte zu analysieren? Verwenden Sie besser Szenarien, User Storiesoder Use Cases für Ihre Spezifikation? Wann testen Sie Ihre neue Lösungam besten mit Benutzern – und mit wie vielen? Die folgenden Kapitelsollen Sie bei solchen und ähnlichen Fragen unterstützen.

Das Beste aus beiden statt zweiWelten

Die Erfahrung aus einer Vielzahl von Projekten hat uns gezeigt, dasssich Usability Engineering nahtlos in gängige Software und Produkt-Entwicklungsprozesse integrieren lässt und sich dadurch viele Vorteilebieten. So hat sich beispielsweise die Anwendung von Usability-Metho-den im Requirements Engineering in der Praxis als äußerst erfolgreicherwiesen. Erstens werden die Anforderungen der Benutzer systematischin die Analyse einbezogen und zweitens kann sichergestellt werden, dassdiese Anforderungen auch ihren Weg in die Realisierung finden. DasErgebnis ist eine Lösung, die sich an ihrem tatsächlichen Verwendungs-zweck ausrichtet.

Eine solche integrierte Sicht bedingt, dass Vorgehensbeschreibungennicht einfach unreflektiert angewendet werden, sondern dass die zugrun-de liegenden Prinzipien beider Welten verstanden und berücksichtigtwerden.

Hintergrund: Requirements EngineeringRequirements Engineering befasst sich damit, die Bedürfnisse der Benutzer, Auftrag-geber und weiterer Interessengruppen (Stakeholder) hinreichend aufzuarbeiten, zuverwalten und zu kommunizieren, damit das Projektteam eine passende Lösung er-stellen kann. Wesentlich für den Projekterfolg ist eine von allen Interessengruppenvereinbarte und getragene Zielvorstellung. Aufbauend darauf kann der Analyst dieRahmenbedingungen und Qualitätsanforderungen erarbeiten sowie den funktionalen

2.2 Usability-Methoden im Zusammenhang 19

Umfang und das Verhalten der neuen Lösung modellieren. Eine gute Übersicht überdie Thematik bietet das Buch „Systematisches Requirements Engineering“ [Ebert 10].

2.2 Usability-Methoden im Zusammenhang

Hinweis: Dieser Abschnitt zeigt die Integration von Usability-Methodenund gängigen Software-Engineering-Vorgehensweisen. Er ist als Über-sicht für den erfahrenen Leser gedacht. Dem Einsteiger in die Materieempfehlen wir, sich im folgenden Kapitel („Die 7 ± 2 wichtigsten Usa-bility-Methoden“) zunächst mit den einzelnen Methoden und Konzeptenvertraut zu machen.

Die Kernaufgaben in der Software- oder Produktentwicklung lassensich vereinfacht in fünf Bereiche zusammenfassen. Die Einteilung inAufgabenbereiche erleichtert das Verständnis von Ziel und Zweck dereingesetzten Methoden und der gewünschten Arbeitsergebnisse. Sie sindunabhängig vom eingesetzten Entwicklungsprozess. Abbildung 2.2 zeigtdiese Aufgabenbereiche in der Übersicht.

Jedem Aufgabenbereich kann ein Ziel im Sinne der Benutzerorientie-rung zugeordnet werden:

• Analyse: Benutzer und Kontext verstehen,• Modellieren: Entwurf und Optimierung einer passenden Lösung,• Spezifikation: Die Lösung in die Entwicklung tragen,• Realisierung: (Unterstützung bei der) Implementierung der Lösung,• Evaluation: Resultate mit Benutzern überprüfen.

Diese Aufgabenbereiche sind nicht im Sinne eines zeitlichen Ablaufszu verstehen. So kann es beispielsweise zielführend sein, zunächst eineEvaluation eines bestehenden Systems vorzunehmen, bevor die Model-lierung einer neuen Lösung angegangen wird. Oder es kann ein erstesModell erstellt werden, das der Analyse dient. In der Praxis werdendiese Aufgaben oft auch wiederholend (iterativ) oder sogar paralleldurchgeführt. In Kap. 4 werden diese zeitlichen Zusammenhänge näherbeschrieben.

Im Folgenden wird für jeden Aufgabenbereich aufgezeigt, welcheAnsätze und Methoden einerseits aus den Software-Engineering-Vorge-hensmodellen und andererseits aus benutzerorientierten Prozessmodel-


Abb. 2.2 PrinzipielleAufgabenbereiche bei derEntwicklung von Produktenund Systemen

len zur Verfügung stehen und wie diese in einem integrierten Vorgehenzusammenspielen. Die Details der einzelnen Usability-Methoden werdenim nächsten Kapitel beschrieben.

Aufgabenbereich 1: Analyse von Benutzern und Kontext

Am Anfang eines neuen Projekts steht das Team vor der Herausforde-rung, eine neue Lösung zu planen, von der er noch nicht genau wissenkann, wofür sie eingesetzt wird, was sie bieten soll und wer die Benutzersein werden.

In der Geschäftsprozessanalyse bzw. -modellierung (Business Ana-lysis, Business Modeling) werden die Prozesse des Unternehmens ana-lysiert, in welche die neue Lösung eingebettet werden soll. Dabei mussauch der Tatsache Rechnung getragen werden, dass sich diese Prozessein der Regel durch die Einführung der Lösung verändern. Abbildung 2.3illustriert einen Ausschnitt aus einem solchen Geschäftsprozess.

Es würde den Rahmen dieses Buches sprengen, die Tätigkeiten derAnalyse und Modellierung im Detail zu beschreiben. Wichtig ist an die-ser Stelle, dass die Geschäftsprozesse wesentliche Rahmenbedingungenfür die neue Lösung definieren, zum Beispiel, welche Stellen und Prozes-se im Unternehmen betroffen sind, welche Aufgaben und Tätigkeiten vondiesen Stellen ausgeführt werden und wie der offizielle Informationsfluss


Inves��ons-antrag erstellen

Uni

t Lei

ter

Mita

rbei

ter

Adm

in/F

inan

ceG

L Inves��on genehmigen

Inves��on genehmigen

[>= EUR

5000]

[< EUR 5000]

Bestellung erstellen

Bestellung freigeben

Bestellung freigeben

[< EUR 5000]

[>=

EUR

5000

]

Abb. 2.3 Modell eines Geschäftsprozesses am Beispiel einer Hardware-Beschaffung

und die Zusammenarbeit zwischen den verschiedenen Stellen stattfinden.Basierend auf diesen Informationen lässt sich aus Geschäftssicht definie-ren, für welche Aufgaben das neue System eingesetzt werden soll.

Neben den formellen Geschäftsprozessen ist ein fundiertes Verständ-nis über die Benutzer und die tatsächliche Anwendung der neuen Lösungim Geschäftsalltag eine notwendige Voraussetzung. Usability Enginee-ring komplettiert die formellen Prozesse aus der Geschäftsprozessmo-dellierung mit den konkreten Details der täglichen Arbeit und füllt dieabstrakten Unternehmens-Rollen mit den Eigenschaften und Möglich-keiten der Menschen dahinter.

Contextual Inquiry (siehe Abschn. 3.1) soll in diesem Buch alsstellvertretendes Beispiel für weitere Techniken stehen, die von Beob-achtungen über Interviews und moderierte Gesprächsgruppen (FocusGroups) bis zu strukturierten Aufgabenanalysen reichen. Das Ziel dieserMethoden ist es, die Bedürfnisse der Benutzer sowie die Hintergründezu verstehen. In Beobachtungen und Befragungen der Benutzer vor Ortwerden die konkreten Aufgaben, Abläufe und Verhaltensmuster sowiedie Umgebung der Anwendung analysiert, ausgewertet und dokumen-tiert. Die Resultate hält das Team in Form von grafischen Modellen odernatürlichsprachlichen Beschreibungen fest. Abbildung 2.4 zeigt das Er-gebnis einer solchen Untersuchung vor Ort zum Beschaffungsprozessaus Abb. 2.3.


FrankMitarbeiter

- bestellt Hardware

HansProjektleiter- macht das

Administra�ve

PhilippUnit Leiter

HannaGL Mitglied

- Unterschreibt Bestellung

1) Ich brauche Unterschri�

2) Es eilt!

3)

Lieferant

4) Bi�e liefern

in zwei TagenBestellung

Bestellung

Bestellung(unterschrieben)

Bestellung

(unterschrieben)

5) Das haben

wir bestellt ok?Kopie Bestellung

(unterschrieben)

Abb. 2.4 Darstellung als Informationsfluss (Flow Model) der im Kontext untersuch-ten Abläufe

Die Erarbeitung von Anforderungen der verschiedenen Interessen-gruppen ist eine zentrale Aufgabe im Requirements Engineering. DieAnalysetätigkeiten umfassen beispielsweise Interviews, moderierteWorkshops sowie die Analyse von Altsystemen und Dokumentatio-nen. Usability-Methoden dienen zur Erarbeitung von Anforderungenaus Benutzersicht und ergänzen damit die Techniken im RequirementsEngineering.

Im nächsten Kapitel werden diese Methoden und deren Einsatz zurErarbeitung und Prüfung der Benutzeranforderungen im Detail beschrie-ben.

Aufgabenbereich 2: Modellieren einer passenden Lösung

Selbst bei kleineren Anwendungen ist es praktisch unmöglich, auf An-hieb ein System zu entwerfen, das allen Anforderungen genügt. Es istnotwendig, das neue System aus verschiedenen Sichten zu modellie-ren und Schritt für Schritt zu präzisieren. In mehreren Zyklen werden


Entwürfe erstellt und Feedback eingeholt. Das Team modelliert bei-spielsweise die Einbettung in die Geschäftsprozesse, die Arbeitsweiseder Benutzer mit dem neuen System sowie die Funktionalität und dasVerhalten des Systems.

Die Erkenntnisse aus der Analyse von Benutzern und Kontext werdenin Personas und Szenarien umgesetzt (siehe Abschn. 3.2).

Personas stellen prototypische Benutzerprofile dar, während Szena-rien die Arbeit mit dem neuen System aus Benutzersicht beschreiben.Personas und Szenarien bringen die im Contextual Inquiry erarbeitetenErgebnisse auf den Punkt und dienen als Grundlage für die Entwicklung.

Personas und Szenarien liefern auch eine gute Basis für den Entwurfeines Use-Case-Modells oder User Stories (siehe Abschn. 3.5). Dabeiwird zuerst eine Übersicht über den funktionalen Umfang der neuen Lö-sung erarbeitet und in einem zweiten Schritt das Verhalten des Systemsgemäß den Qualitätsanforderungen und Rahmenbedingungen detailliert.Als Modellierungselemente dienen bei der Use-Case-Modellierung Ak-teure (Actors), die in Anwendungsfällen (Use Cases) mit dem Systeminteragieren.

Ein genaues Verständnis der Objekte und Daten des Fachbereichs,welche im System repräsentiert werden sollen, ist eine wichtige Voraus-setzung für die Erstellung der Benutzerschnittstelle. Diese Konzepte undZusammenhänge können in einem Domänenmodell abgebildet werden.Ein durchdachtes Domänenmodell ist hilfreich für die Erstellung der Be-nutzerschnittstelle. Es zeigt die angezeigten und einzugebenden Datenund deren Zusammenhänge auf. Abbildung 2.5 zeigt eine erste Versioneines solchen Domänenmodells sowie des entsprechenden GUIs.

Ein Glossar ist ein weiteres einfaches, aber wichtiges Hilfsmittel, umBegriffe zu definieren und ein gemeinsames Verständnis im Projekt zuerreichen.

Mit Storyboards (siehe Abschn. 3.3) hat ein Projektteam die Mög-lichkeit, Lösungsideen anschaulich darzustellen, um beispielsweiseFeedback von Benutzern und Führungskräften zu erhalten und neueTeammitglieder einzuführen. Storyboards visualisieren und detaillierendie Anwendung aus Benutzersicht, indem sie einen ersten Eindruck überdie Abläufe der Benutzerschnittstelle im vorgesehenen Kontext geben.

Um das Verhalten des Systems weiter zu verfeinern und die Ab-laufschritte aus Benutzersicht in Aktion darzustellen, werden im User


Bestellung

Antrag

Kostenstelle: Kostenstelle IDBezeichnung: TextGegenstand: TextBegründung: TextBudge�ert: Ja/NeinKosten (einmalig): BetragKosten (jährlich): Betrag

Ak�vität

Tä�gkeit: TextAusführender: PersonDatum erledigt: Datum

IT Equipment

Service Tag: Text

Workflow

*

ersetzt

betri�*

Antrag bearbeiten

Kostenstelle

Gegenstand

Begründung

Kosten

CHF

Bezeichnung

Budge�ert?

speichern abbrechen

Kosten / Jahr

CHF

Workflow:

Antrag einreichen

Inves��on freigeben

Genehmigung GL

Genehmigung Finance

*

*

Abb. 2.5 Ausschnitt eines Domänenmodells und entsprechendes GUI am Beispieleines Beschaffungsprozesses

Interface Prototyping (siehe Abschn. 3.4) erste Dialogschritte mit mög-lichst einfachen Mitteln umgesetzt und von ausgewählten Benutzernund weiteren Stakeholdern geprüft. Die so erstellten Prototypen vermit-teln den Beteiligten erstmals einen Eindruck der laufenden Anwendungund dienen als einfach verständliche und gemeinsame Sprache zwischenBenutzern, Auftraggebern und Entwicklern. Die in Anwendungsfällentextuell oder mit grafischen Modellen formulierten Anforderungen wer-den dadurch greifbar und vorstellbar. Dank der erhöhten Realitätsnähekommen bisher unentdeckte Anforderungen zum Vorschein. Ein wich-tiges Ergebnis ist das User-Interface-Konzept (siehe Abschn. 3.4 „DieBenutzerschnittstelle konzipieren“), das die Eckpunkte für das zu erstel-lende User Interface festlegt.

Aufgabenbereich 3: Spezifizieren für die Entwicklung

Wenn genügend Klarheit über die vorgesehene Lösung herrscht, wird daszu erstellende System für die Entwicklung spezifiziert. In sehr formellenProjekten legen Auftraggeber und Hersteller mit der Anforderungsspe-zifikation den fachlichen Inhalt für die Vertragserfüllung fest. Use-Case-


Spezifikationen beschreiben die funktionalen Abläufe des Systems (sieheAbschn. 3.5). Neben weiteren funktionalen Anforderungen werden auchalle Rahmenbedingungen aufgenommen (siehe Abschn. 3.5. „Funktio-nale und nicht-funktionale Anforderungen“). Die Anforderungen an dieneue Lösung werden üblicherweise in strukturierten Dokumenten oderauch in speziellen Werkzeugen festgehalten.

Zwischen den Tätigkeiten für das Modellieren der neuen Lösungund deren Spezifikation besteht ein fließender Übergang. Ausgewähl-te Ergebnisse aus der Modellierung dienen auch der Spezifikation. Sokönnen Szenarien, Storyboards oder UI-Prototypen auch Teil der An-forderungsspezifikation sein und wesentlich zur Verständlichkeit, Voll-ständigkeit und zur Präzisierung der Anforderungen für die Realisierungbeitragen. Die Spezifikation besteht schließlich aus einem Konglo-merat von formalen Anforderungsnotationen und natürlichsprachlichenBeschreibungen wie dem Use-Case-Modell, Use-Case-Spezifikationen,Ablaufdiagrammen, dem Domänenmodell, Anforderungssätzen, nicht-funktionalen Anforderungen und zusätzlichen Ergebnissen wie Story-boards und UI-Prototypen.

Agil geführte Projekte betonen die direkte Kommunikation. Die Spe-zifikation soll dabei das Resultat dieser Kommunikation sein und sozeitnah mit der Entwicklung wie möglich entstehen. Die Spezifikationkann also, so die Theorie, informeller ausfallen. Die anschaulichen Tech-niken des Usability Engineerings wie Mock-ups und Szenarien sind hierbesonders einfach einsetzbar (vgl. Abschn. 3.5 „User Stories“).

Aufgabenbereich 4: Unterstützung der Realisierung

Für die Realisierung der Lösung muss die Spezifikation in ein tech-nisches Design umgesetzt, eine Software-Architektur entworfen undimplementiert werden. Vorgehensmodelle in der Software- oder Produkt-entwicklung setzen oft hier ihren Schwerpunkt.

In der Realisierung unterstützen Usability Guidelines und Stylegui-des die Entwicklung und helfen, ein konsistentes und regelkonformesUser Interface Design zu erreichen (siehe Abschn. 3.6).

User-Interface-Prototypen bilden eine wertvolle Grundlage für dieEntwicklung (siehe Abschn. 3.4). Moderne Software-Entwicklungspro-


zesse und agile Vorgehensweisen unterstützen dabei einen iterativenProzess, bestehend aus der Erstellung von Lösungsvarianten und Ein-arbeiten von Feedback in kurzen Zyklen. Diese Denkhaltung lässt sichausgezeichnet mit benutzerorientierten Vorgehensweisen vereinbaren.

Aufgabenbereich 5: Evaluation der Resultate

Ein wesentlicher Aufgabenbereich einer benutzerorientierten Software-oder Produktentwicklung besteht darin, die erstellten Resultate mit Be-nutzern zu überprüfen und zu optimieren. Dabei kann es sich um bereitsrealisierte Teile des Systems oder um einen Prototypen handeln. Inter-essanterweise bieten die gängigen Software-Engineering-Vorgehensmo-delle hier relativ wenige Hilfsmittel an. Im Wesentlichen beschränken siesich auf formale Reviews, Stellungnahmen und Abnahmetests durch denAuftraggeber.

Hingegen gibt es zahlreiche Usability-Methoden zur Evaluation einesSystems. In einem formalen Usability-Test werden Benutzer in einemUsability Lab dabei beobachtet, wie sie mit einer neuen Anwendung odereinem Prototypen arbeiten (siehe Abschn. 3.7). Die Probleme werdendokumentiert und daraus Verbesserungsmaßnahmen erarbeitet. Usabil-ity-Tests können auch im Rahmen eines Abnahmetests zur Erfüllung derAnforderungen eingesetzt werden. Usability Walkthroughs sind weni-ger formal und eignen sich zur Überprüfung und Optimierung von erstenPrototypen früh im Prozess.

Mithilfe von Usability-Fragebögen (mehr dazu in Abschn. 3.8) kannvon einer größeren Anzahl von Benutzern Feedback zur Benutzbarkeiteiner neuen Lösung eingeholt werden.

Schließlich besteht die Möglichkeit, Benutzerschnittstellen anhandvon Checklisten oder durch Experten prüfen zu lassen.

Zusammenfassung der Methoden

Tabelle 2.2 zeigt die Integration der Methoden aus Software Enginee-ring und benutzerorientierten Prozessmodellen nochmals als Übersicht.


Die kursiv gedruckten Methoden werden im nächsten Kapitel näher be-schrieben.

Tab. 2.2 Gegenüberstellung gängiger Methoden aus Software Engineering und be-nutzerorientierten Vorgehensmodellen für jeden Aufgabenbereich

Aufgabenbereich SE-Vorgehensmodelle BenutzerorientierteProzessmodelle

Analyse Business Analysis Contextual Inquiry

Business Modeling Beobachtungen

Stakeholder-Interviews Interviews

Moderierte Workshops Focus Groups

Analyse von Altsystemen Aufgabenanalysen

Fragebögen

Modellieren Business Modeling Personas und Szenarien

Use-Case-Modell Storyboards

Use Cases UI Prototyping, Mock-ups

Domänenmodell User-Interface-Konzept

Glossar

User Stories

Spezifikation Use-Case-Modell Szenarien

Use-Case-Spezifikationen Storyboards

Nicht-funkt. Anforderungen UI-Prototypen

Ablaufdiagramme Styleguides

Domänenmodell

Anforderungssätze

User Stories

Realisierung Technisches Design Usability Guidelines

SW-Architektur Styleguides

Implementierung UI-Prototypen

Evaluation Formale Reviews Usability Testing

Stellungnahmen Walkthroughs

Funktionales Testen Fragebögen

Abnahmetests Checklisten und Heuristiken

Experten-Reviews

Documents

[IT kompakt] Usability Engineering kompakt || Usability Engineering im Entwicklungsprozess