Embed Size (px)
Citation preview
„100 SEITEN SPEZIFIKATION -UND WAS IST DIEKONSEQUENZ FÜR UNS?”Anforderungen vorstellbar machen.
Geschäftsprozesse integriert und die Be-nutzer ihre Aufgaben nicht wie geplantoder gar nicht erfüllen können.
Wie aber soll Feedback von den Betei-ligten eingeholt werden, wenn diese dieAnforderungsdokumentation nicht nach-vollziehen können? Um Anforderungen mitBusiness Stakeholdern und Benutzern früh-zeitig validieren zu können, müssen diese inverständliche Form gebracht werden. Jekonkreter und vorstellbarer die Anfor-derungen wiedergegeben werden, umsofundierter werden die Beteiligten diese prü-fen und für ihre tägliche Praxis reflektierenkönnen. Die folgenden Abschnittebeschreiben einige in der Praxis bewährteMethoden, um genau dies zu erreichen.
Die Überprüfung der Richtigkeit und Vollständigkeit von Anforderungen ist eine zen-trale Aufgabe im Requirements Engineering. Für Business-Vertreter und Benutzersind die oft umfangreichen Spezifikationen aber nicht sehr verständlich. Die Konse-quenz sind spät entdeckte Fehler und aufwändige Änderungen. Wie aber sollFeedback von den Beteiligten eingeholt werden, wenn diese die Anforderungsdoku-mentation nicht nachvollziehen können? Dieser Artikel beschreibt einige einfacheund in der Praxis bewährte Methoden, wie Anforderungen in konkreter, vorstellba-rer Form wiedergegeben werden können, um sie mit Business Stakeholdern undBenutzern frühzeitig zu überprüfen.
m e h r z u m t h e m a :www.hcid.chwww.benutzbar.ch
Michael Richter
ist Berater bei der Zühlke Engineering AG
und Dozent an der HSR Hochschule für
Technik Rapperswil für das Master of
Advanced Studies in Human Computer
Interaction Design. Er ist Autor des
Buches „Usability Engineering kompakt”
[Ric07] und begleitet seit mehr als zehn
Jahren Projekte in benutzer-orientierter
Entwicklung.
Der Analyst steht dabei vor einer schwie-rigen Aufgabe. Formal korrekt dokumen-tierte, ausführliche Requirements sind alseindeutige, präzise Vorgaben für dieEntwicklung notwendig. Für die Business-Vertreter und Benutzer dagegen sind dieSpezifikationen mittels Use Cases,Ablaufdiagrammen und Modellen nichtsehr verständlich. Oft sind die Beschrei-bungen dermaßen abstrakt, dass deren tat-sächliche Bedeutung für die Praxis kaumvorstellbar ist. Fehlerhafte Anforderungenwerden dann erst spät im Entwicklungs-prozess aufgedeckt, wenn die implemen-tierte Anwendung erstmals sichtbar ist.Dies führt zu teuren Änderungen. DasRisiko ist zudem hoch, dass die entwickel-te Lösung sich schlussendlich nicht in die
Requirements Engineering gehört zu denwichtigsten Disziplinen moderner Software-und Produktentwicklung. Ohne das syste-matische Erarbeiten, Dokumentieren undVerwalten von Anforderungen der verschie-denen Interessensgruppen sind komplexeProjekte nicht in den Griff zu bekommen.
Ziel des Requirements Prozesses ist es,die Anforderungen und Rahmenbedingun-gen aufzunehmen, gegeneinander abzuwä-gen und im Verlauf des Projekts abzustim-men, so dass schließlich spezifizierteVorgaben für die Entwicklung der neuenLösung zur Verfügung stehen.
Wesentlich für den Projekterfolg ist einevon allen Interessensgruppen getragene undvereinbarte Zielvorstellung. Eine zentraleAufgabe im Requirements Engineering istdeshalb die Überprüfung (Validierung) deraufgenommenen Anforderungen mit denBeteiligten:
■ Wurden alle relevanten Anforderungenaus Geschäftssicht erfasst?
■ Können die Benutzer mit der spezifi-zierten Funktionalität ihre Aufgabeneffektiv und effizient erfüllen?
■ Wurden die technischen Rahmenbe-dingungen für die neue Lösung berück-sichtigt?
Das Aufnehmen, Dokumentieren undValidieren von Anforderungen ist ein itera-tiver Prozess. Dieser soll sicherstellen, dassdie dokumentierten Anforderungen dentatsächlichen Bedürfnissen und Notwen-digkeiten der verschiedenen Interessens-gruppen entsprechen. Auf das Wesentlichereduziert stellt dies Abbildung 1 dar:
der au toradver tor i a l
1 w w w. o b j e k t s p e k t r u m . d e
Abbildung 1: Requirements Engineering als iterativer Prozess
Personas repräsentierenBenutzeranforderungenPersonas stellen prototypische Benutzerdar und verkörpern deren Ziele undVerhaltensweisen. Abbildung 2 zeigt ein(vereinfachtes) Beispiel einer solchenPersona.
Personas werden aufgrund von Informa-tionen über die zukünftigen Benutzer einesSystems erarbeitet. Dazu dienen beispiels-weise Ergebnisse aus Workshops mitBenutzern, Beobachtungen am Arbeits-platz, Fragebögen oder Walkthroughs mitbestehenden Systemen. Im Rahmen einesProjekts entstehen meist mehrere Personas,die die Anforderungen unterschiedlicherBenutzergruppen repräsentieren. DieMethodik wurde vom InteraktionsdesignerAlan Cooper eingeführt und publik ge-macht [Coo03].
Eine Persona sollte über folgende Eigen-schaften Auskunft geben:
■ Ziele der Benutzer■ Beruf, Funktion, Verantwortlichkeiten
und Aufgaben■ Fachliche Ausbildung, Wissen und
Fähigkeiten ■ Verhaltensmuster und Vorgehensweisen■ Werte, Ängste, Sehnsüchte, Vorlieben■ Allgemeine Computerkenntnisse■ Kenntnisse über verwandte Produkte,
Vorgängersysteme, Konkurrenzprodukte■ Verbesserungspotenzial in der heutigen
Situation■ Erwartungen an eine neue Lösung
Der Analyst entwirft Vorschläge und vali-diert diese mit den Beteiligten, oder diePersonas werden in einem gemeinsamenWorkshop erstellt. Die Beschreibungen gebenletztendlich die für die Projektziele relevantenEigenschaften der Benutzer wieder. Personasbilden eine hervorragende Basis für das wei-tere Vorgehen, indem sie die implizitenAnnahmen des Projektteams explizit machenund objektive Kenntnisse über die zukünfti-gen Benutzer anschaulich darstellen.
Szenarien konkretisierenProzesseAnwendungsszenarien oder kurz Szenarienschlagen die Brücke zwischen denAnforderungen und dem Entwurf einerneuen Lösung. Ein Szenario beschreibt inForm eines realistischen Beispiels, wie einBenutzer mit dem geplanten System intera-gieren wird. Mittels einfacher Sätze wirdein konkreter Ablauf aus Benutzersicht imAnwendungskontext dargestellt. Dabeisollte wie auch bei Personas mehr aufinhaltlich richtige Aussagen als auf derenformale Korrektheit geachtet werden.Abbildung 3 zeigt ein Beispiel.
Das Szenario im obigen Beispiel be-schreibt in wenigen Sätzen, wie die Aufnah-me eines Schadensfalls in Zukunft mit einerneuen Versicherungsapplikation ablaufensoll. Es gibt eine Reihe von zusammenge-
hörigen Anforderungen aus Benutzersichtwieder:
■ Automatische Anzeige des Namens undAngaben des Anrufers
■ Darstellung aller bestehenden Versi-cherungspolicen eines Kunden
■ Kurze Antwortzeiten des Systems
Szenarien werden basierend auf denAnforderungen an ein neues System er-stellt. Sie können iterativ entwickelt oder inWorkshops, zum Beispiel zusammen mitBenutzern, erarbeitet werden. Ein großerVorteil von Szenarien ist ihre leichteVerständlichkeit. Sie können von verschie-denen Stellen wie Auftraggeber, Benutzerund Entwicklung schon zu einem frühenZeitpunkt überprüft, ergänzt oder korri-giert werden.
Die Durchgängigkeit über den gesamtenEntwicklungsprozess macht Szenarien zueinem äußerst effektiven Instrument in derEntwicklung von interaktiven Systemen:
■ Die Reflektion am konkreten Beispielerlaubt es Auftraggebern und Benut-zern, Anforderungen in der konkretenAnwendungssituation zu vergegenwär-tigen, zu überprüfen und zu ergänzen.Szenarien können als erste Prototypeneines neuen Systems betrachtet werden.
adver tor i a l
Requirements Engineering ist ein zentra-les Ausbildungsthema des Studiums zumMaster of Advanced Studies in HumanComputer Interaction Design(www.hcid.ch), einem Weiterbildungs-angebot der HSR Hochschule fürTechnik Rapperswil (FachhochschuleOstschweiz), der Universität Basel undder Hochschule für Gestaltung undKunst Basel (Fachhochschule Nord-westschweiz). In dem 3-jährigen berufs-begleitenden Studiengang hat das 1. Jahrdas Thema „Benutzerzentriertes Require-ments Engineering”, im 2. Jahr steht„Interaction Design” im Mittelpunkt,den Abschluss bildet die Master-Arbeitim 3. Jahr. Der Autor ist als Dozent aktivan dieser Ausbildung beteiligt.
o n l i n e - a u s g a b e R e q u i re m e n t s E n g i n e e r i n g 2 0 0 8
Abbildung 2: Personas geben Benutzeranforderungen wieder.
Abbildung 3: Szenarien beschreiben einen typischen Ablauf mit der vorgesehenen neu-en Lösung.
Aspekte der Anwendung bildlich dar unddient damit der Kommunikation zwischenallen Beteiligten.
Der Analyst setzt Storyboards in Situa-tionen ein, in denen Text alleine nicht aus-reicht. Zwei wichtige Gründe sprechen füreine solche Visualisierung:
■ In Bildern können Aspekte vermitteltwerden, die mit Text nicht oder nurschwer auszudrücken sind, beispiels-weise neuartige Konzepte, für die esnoch keine Begriffe gibt.
■ Mit der visuellen Umsetzung könnenErlebnisse, die für die Anwendung vonBedeutung sind, besser in die Welt desZielpublikums transportiert werden.
Storyboards können in verschiedenenSituationen und für unterschiedlicheZwecke eingesetzt werden:
■ Zur Diskussion einer Idee oder einerausgearbeiteten Lösung mit Benutzernund weiteren Stakeholdern.
■ Um das korrekte Verständnis derBedürfnisse und der fachlichen Zu-sammenhänge zu prüfen und Missver-ständnisse auszuräumen.
■ Zur Diskussion von Vor- undNachteilen verschiedener Varianten.
■ Um über Neuerungen zu informierenund damit beispielsweise Akzeptanz fürdas neue Werkzeug zu erzeugen.
■ Um neugierig auf das Neue zu machen. ■ Um Führungskräfte darüber zu infor-
mieren, wie ihre Vision durch die neueLösung Realität wird.
■ Um Entwicklern die relevantenAnforderungen der Benutzung näher-zubringen und zu zeigen, warum gewis-se Entscheidungen getroffen wurden.
■ Um Benutzern im Rahmen einer Aus-bildung einen Überblick über dasSystem zu geben.
■ Für Projektmarketing bei Auftragge-bern, Geschäftsleitung und Benutzern.
Storyboards sind ein ausgezeichnetesMittel, um die Realität der Anwendung ineinen Workshop einzubringen. DieTeilnehmer diskutieren über Annahmen,reflektieren Unterschiede zur heutigenSituation und klären Missverständnisse anrealen Beispielen. Es ist immer wieder ver-blüffend, wie Personen auf abstrakterEbene aneinander vorbei diskutieren undwelche Missverständnisse sich klären,
Benutzerschnittstelle im vorgesehenenKontext geben. Mit Storyboards hat derAnalyst die Möglichkeit, Lösungsideenanschaulich darzustellen, um beispielsweiseFeedback von Benutzern und Führungs-kräften zu erhalten.
Ein Storyboard zeigt mithilfe derBenutzerschnittstelle, wie ein System oderProdukt verwendet wird. Es stellt wichtige
■ Szenarien illustrieren die Anwendungim realen Kontext und dienen alsErgänzung der Use Cases. Sie vermit-teln den Entwicklern ein Verständnisder Abläufe und Zusammenhänge.
■ Szenarien dienen dazu, die Abläufe derBenutzerschnittstelle zu beschreiben.Damit kann die Interaktion modelliertund mit Benutzern optimiert werden.Die technischen Anforderungen wiede-rum können von den Entwicklern über-prüft werden.
■ Realistische Personas und Szenarienbilden eine gute Grundlage für denEntwurf von Use Cases. Im Verlauf desProjekts detailliert und komplettiert derAnalyst die Anwendungsfälle, so dassdas gesamte funktionale Verhalten desSystems, inklusive der Anbindungexterner Systeme, spezifiziert wird.
Für eine weiterführende Vertiefung der sze-nariobasierten Entwicklung sei an dieserStelle auf [Ros02] verwiesen.
User Interface Storyboardsvisualisieren die AnwendungUser Interface Storyboards visualisieren dieAnwendung aus Benutzersicht, indem sieeinen ersten Eindruck über die Abläufe der
adver tor i a l
3 w w w. o b j e k t s p e k t r u m . d e
Hintergrund: Die Macht des guten BeispielsEin Analyst achtet darauf, formal korrekt und präzise zu formulieren. Die Spezifikationeines neuen Systems darf letztendlich nur wenig Interpretationsspielraum zulassen. Umformal korrekt zu formulieren, muss zwangsläufig über verschiedene mögliche Fällegeneralisiert werden. Die Gefahr dabei ist, dass die konkrete Realität auf der Streckebleibt.
Der Sachbearbeiter nimmt eine Schadensmeldung eines Kunden auf ist eine formalkorrekte Formulierung des Sachverhalts im obigen Beispiel, sie sagt allerdings wenigüber die tatsächliche Situation aus. Natürlich wird im Beispiel nicht nur der BenutzerJakob S. mit dem neuen System arbeiten. Es sollen damit auch nicht nur Schadens-meldungen für kaputte Fensterscheiben erfasst werden. Eine zentrale Anforderung ist imvorliegenden Fall, dass der Benutzer aufgrund der Kundenanfrage (eine zerbrocheneFensterscheibe) schnell und eindeutig (denn der Kunde wartet am Telefon) die richtigeVersicherungspolice (z. B. eine Hausratversicherung) zuordnen kann. Diese Anforderungwird erst durch die Schilderung der konkreten Anwendungssituation ersichtlich undkommt in einer formal korrekten, generalisierten Darstellung nur schwer zum Ausdruck.
Ein Beispiel dagegen ist weder eindeutig noch vollständig. Interessanterweise ist dasmenschliche Gehirn hervorragend dafür geeignet, um aus Beispielen Regeln abzuleiten.Mittels weniger, guter Beispiele kann ein Sachverhalt oft schneller, umfassender undmanchmal sogar präziser dargestellt werden als mit einer formalen Spezifikation.Personas und Szenarien nutzen diese Tatsache aus. Indem sie wichtige, stimmige und rea-listische Beispiele wiedergeben, können sie die Anwendung eines geplanten Systemsschon früh im Entwicklungsprozess relativ genau umreißen, ohne dass die Details prä-zisiert werden müssen.
Buchauszug: Usability Engineering kompakt - Benutzbare Software gezielt entwi-ckeln. [Ric07]
Abbildung 4: User Interface Storyboardsvisualisieren Abläufe.
sobald jemand eine erste Skizze einerBenutzerschnittstelle auf ein Blatt Papierkritzelt. Die Visualisierung von Anfor-derungen durch User-Interface-Entwürfehilft, unterschiedliche Verständnisse zu ver-meiden.
Mock-ups decken versteckteAnforderungen aufUm das Verhalten des Systems weiter zuverfeinern und die Ablaufschritte ausBenutzersicht in Aktion darzustellen, wer-den mit User Interface Prototypen ersteDialogschritte mit möglichst einfachenMitteln umgesetzt und von ausgewähltenBenutzern und weiteren Stakeholderngeprüft. Man spricht bei solchen Attrappender Benutzerschnittstelle auch von Mock-ups.
Mit Mock-ups können bereits konkreteFälle durchgespielt und diskutiert werden.Dabei geht es nicht darum, das System zuentwerfen, sondern die Anforderungen miteinem einfachen Hilfsmittel erfahrbar zumachen. Der Analyst deckt dabei nebenfachlichen Missverständnissen weitere Be-dürfnisse auf:
■ Notwendiger Informationsgehalt■ Funktionalität und Abläufe■ Datenaustausch mit anderen Systemen
und Applikationen■ Darstellung von Tabellen, Grafiken,
Funktionen usw.■ Wichtige Details der Benutzerschnitt-
stelle
Im Rahmen der Spezifikation können Pro-totypen für folgende Zwecke eingesetztwerden:
■ Illustrieren des Funktionsumfangs■ Verdeutlichung der Funktionsweise■ Spezifizieren der User-Interface-Ele-
mente■ Aufzeigen der Navigation und Inter-
aktion■ Visualisieren der geplanten Lieferung ■ Abschätzen des Realisierungsaufwands
durch die Entwickler
Die erstellten Prototypen vermitteln denBeteiligten erstmals einen Eindruck der lau-fenden Anwendung und dienen als einfachverständliche und gemeinsame Sprache
zwischen Benutzern, Auftraggebern undEntwicklern. Die in Use Cases textuell odermit grafischen Modellen formuliertenAnforderungen werden dadurch greifbarund vorstellbar. Dank der erhöhtenRealitätsnähe kommen bisher unentdeckteAnforderungen zum Vorschein.
FazitAnforderungen von der Business- oderKundenseite, die vom Analysten erarbeitet,analysiert und in Spezifikationen übersetztwerden, stellen die Weichen für die Ent-wicklung eines neuen Systems.
Um die aufgenommenen Anforderungenzu validieren, müssen Benutzer, Business-Einheiten, Fachstellen und Entwickler eingemeinsames Verständnis erreichen. Diesist allein mit abstrakten Dokumentationennur schwer möglich.
Die Erarbeitung von konkreten, vorstell-baren Ergebnissen ist für die Validierungvon Requirements notwendig: Personas,Szenarien, Storyboards und Mock-ups die-nen als gemeinsame Sprache der verschie-denen Stellen und erlauben eine effizienteZusammenarbeit.
Es sollte ein iterativer Prozess aufgesetztwerden, in dem Anforderungen undSpezifikationen visualisiert, mit Benutzernund Geschäftseinheiten überprüft und fallsnotwendig angepasst werden können. ■
adver tor i a l
o n l i n e - a u s g a b e R e q u i re m e n t s E n g i n e e r i n g 2 0 0 8
Abbildung 5: Unterschiedliche Ausprägungen eines User Interface Prototypen (Mock-up): Einfache Papierskizze, Drahtmodell (Wireframe) und endgültiges Look&Feel.
Literatur[Coo03] Cooper, A. & Reimann, R., About
Face 2.0: The Essentials of Interaction
Design, Wiley, Indianapolis, 2003
[Ros07] Rosson, M. B. & Carroll, J. M.,
Usability Engineering: Scenario-Based Devel-
opment of Human Computer Interaction,
Morgan Kaufmann, San Francisco, 2002
[Ric07] Richter, M. & Flückiger, M., Usa-
bility Engineering kompakt - Benutzbare
Software gezielt entwickeln, Spektrum Aka-
demischer Verlag, Heidelberg, 2007
