Methoden, Notationen und Werkzeuge zur Übersetzung von Anforderungen in User Interface Spezifikationen

1 Methoden, Notationen und Werkzeuge zur Übersetzung von Anforderungen in User Interface Spezifikationen

Thomas Memmel

Mensch-Computer Interaktion Universität Konstanz Universitätsstrasse 10, Box 73 78457 Konstanz

memmel@inf.uni-konstanz.de http://hci.uni-konstanz.de

Thomas Geis ProContext GmbH Deutzer Freiheit 77-79 50679 Köln

thomas.geis@procontext.com www.procontext.com

Prof. Dr. Harald Reiterer Mensch-Computer Interaktion Universität Konstanz Universitätsstrasse 10, Box 73 78457 Konstanz

reiterer@inf.uni-konstanz.de http://hci.uni-konstanz.de

Abstract

In diesem Workshop wollen wir unter- schiedliche Methoden und Werkzeuge vorstellen und diskutieren, mit denen kreative Prozesse bei der Übersetzung von Anforderungen in benutzerfreundli- che und innovative Benutzungsschnitt- stellen angetrieben und unterstützt wer- den. Dabei betrachten wir auf Text

sierende Notationsformen und Werk- zeugketten ebenso wie spezielle Werkzeuge für Interaktionsdesigner.

Als neue und zukunftsweisende Un- terstützung von User Interface Ent- wicklungsprozessen stellen wir unsere Idee von interaktiven Spezifikationen vor.

Keywords

Anforderungsanalyse, Spezifikation, Usability Engineering, User Interface Design

1.0 Einleitung

Der aktuelle „Chaos Report“ der Standish Group aus dem Jahr 2007 zeigt auf, dass die Softwareentwicklung auch weiterhin vor großen Herausforde- rungen steht. Nur 35% der IT Projekte werden erfolgreich abgeschlossen in Hinblick auf Projektlaufzeit, Budget und Umsetzung definierter Anforderungen.

46% der Projekte haben dagegen die Zeit- und Budgetvorgaben signifikant überschritten und 19% der Projekte scheitern im Durchschnitt gänzlich ohne Projektergebnis. Als primäre Ursache sind dabei besonders die frühen Phasen des Entwicklungsprozesses zu sehen, in denen die „Richtung“ für das zu entwi- ckelnde Produkt festgelegt wird. Wer zu spät testet, muss mit in späteren Pro- jektphasen mit teuren Problemen und Rückschlägen rechnen. Das US-ameri- kanische National Institute of Standards and Technology hat in einer 2002¹ veröf- fentlichten Studie erhoben, dass etwa 70% der Mängel im Entwicklungspro- zess in der Phase der Anforderungs- erhebung entstehen. Entdeckt werden

1 http://www.nist.gov/public_affairs/

releases/n2-10.htm

diese meist erst während der Abnah- metests. Um einen Mangel während einer späteren Projektphase noch zu beheben muss das 50- bis 100-fache der ursprünglichen Kosten kalkuliert werden.

In diesem Workshop beleuchten wir diese Problematik in Hinblick auf die Entwicklung der Benutzungsschnitt- stelle (im Folgenden als User Interfa- ce, kurz „UI“ bezeichnet). Die UI Entwicklung nimmt in den meisten IT Organisationen inzwischen einen ho- hen Stellenwert ein und ist faktisch Teil des gesamten Entwicklungsprozesses.

Spätestens bei der UI Spezifikation und UI Visualisierung können noch übersehene oder missverstandene Anforderungen systematisch erkannt werden, wenn für die UI Spezifikation eine entsprechende Systematik zu- grunde gelegt wird.

Die Spezifikation des UI kann sowohl als Teil der Anforderungsspezifikation als auch als Teil der Softwarespezifi- kation verstanden werden. Wie jedoch gerade dieser sensible Teil einer Soft- wareanwendung spezifiziert werden muss, damit Entwickler das UI anfor-

derungskonform umsetzen, wird von den meisten bekannten Usability Enginee- ring (UE) Vorgehensmodellen offen ge- lassen. Doch gerade wenn der Auftrag- geber eine hohe UI Qualität sicherstellen will, muss der Entwicklungsprozess eine explizite Art der UI Spezifikation vorse- hen (Memmel et al., 2007a).

Wir wollen daher Methoden, Notationen und Werkzeuge diskutieren, mit deren Hilfe kreative Prozesse entlang des UI Entwicklungsprozesses bis hin zur UI Spezifikation unterstützt werden können.

2.0 Struktur von UI Spezifikations- prozessen

Industrielle UI Entwicklungsprojekte starten in der Regel mit einer Anforde- rungsspezifikation. Vor und nach der Übersetzung in ein Fachkonzept werden die Anforderungen geprüft und gegebe- nenfalls modifiziert. Erst nach einer Ab- nahme der Anforderungen und des Kon- zepts wird eine Systemspezifikation er- zeugt. Diese ist meist die Grundlage für die Implementierung erster UI Proto- typen und des finalen UI.

Anforderungen und Anforderungen sind jedoch bereits „zwei paar Schuhe“. So Zuerst ersch. in: Usability Professionals 2008 / Henning Brau ... (Hrsg.). Stuttgart: Fraunhofer IRB Verlag, 2008, S. 45-48

Konstanzer Online-Publikations-System (KOPS) URN: http://nbn-resolving.de/urn:nbn:de:bsz:352-opus-75382

URL: http://kops.ub.uni-konstanz.de/volltexte/2009/7538/

2

gibt es immer die Anforderungen aus Sicht des Kunden („Stakeholder requi- rements“) und Anforderungen an das System zur Umsetzung der Anforderun- gen des Kunden („System require- ments“)².

Eine intensive Anforderungsphase wird dann problematisch, wenn sie nicht aus- reichend Spielraum für Prototyping und Evaluierung vorsieht, um so natürliche Unsicherheiten bei den Anforderungen durch das Ausprobieren passender Lösungen ausräumen zu können. Grade in Entwicklungsprojekten, bei denen ein IT Dienstleister ab der Anforderungs- spezifikation das Zepter übernimmt, sind interaktive Prototypen in der Regel vor- her nicht verfügbar. In einer rein durch Spezifikation getriebenen Entwicklungs- kultur kann viel Zeit vergehen, bis Fach- experten und Endbenutzer zum ersten Mal das Ergebnis ihrer textuell formulier- ten Anforderungen ausprobieren und beurteilen können. Je größer dann die Diskrepanz zwischen Qualität und Funk- tionalität von Entwürfen einerseits und den Erwartungen der „Stakeholder“ an- dererseits ist, umso wahrscheinlicher ist es, dass die Nutzung für alle Stake- holder unbefriedigend wird.

Probleme treten bereits dann auf, wenn beteiligte Personen ihre Anforderungen nicht ausreichend gut zum Ausdruck bringen können. Viele Arbeitsprozesse laufen unbewusst ab und deren Doku- mentation selbst fehlt häufig in der An- forderungserfassung. Später versuchen Experten, die lückenhaften und beliebig sortierten Anforderungen mit einem Ma- nagement-Werkzeug in eine Struktur zu bringen. Das Kommunikations- und Ver- ständnisproblem zwischen IT und Fach- abteilung verstärkt sich, wenn die Pro- jektbeteiligten sich in unterschiedlichen Sprachstilen und Abstraktionsniveaus

2 ISO IEC 15288 „Systems and software engineering - System life cycle processes“

ausdrücken. Anforderungsspezifikatio- nen werden dann nicht mehr verstan- den und Konflikte nicht transparent.

Damit dies gelingt und letztlich auch eine vertragsbindende Anforderungs- spezifikation entsteht, sind mehrere Schritte notwendig. In Abschnitt 3 be- trachten wir dazu zunächst Notationen zur Erfassung und Dokumentation von Erfordernissen von Benutzern und deren Übertragung in Nutzungsanfor- derungen. Da es für die erfolgreiche UI Entwicklung entscheidend ist, dass Umsetzungsmöglichkeiten für erhobe- ne Anforderungen möglichst schnell visualisiert und getestet werden kön- nen, stellen wir in Abschnitt 4 spezielle und einfach zu nutzende Werkzeuge zum UI Prototyping vor. Mit deren Hilfe soll der IT Entwicklungsorganisation der Wandel vom rein Spezifikations- getriebenen Prototyping zur Prototy- ping-getriebenen Spezifikation gelin- gen. Dazu diskutieren wir die Möglich- keiten zu einer Verschmelzung von Anforderungsmodellen und UI Proto- typen zu sogenannten interaktiven UI Spezifikationen. In diesen sehen wir die Möglichkeit, textbasierte Spezifika- tionsdokumente durch erlebbare Arte- fakte zu ersetzen. Dazu stellen wir schließlich kurz ein experimentell ent- wickeltes Werkzeug vor.

3.0 Anforderungsgetriebenes Spe- zifizieren von UIs

Um Anforderungen an ein UI fest- legen zu können, müssen diese in Form von Nutzungsanforderungen expliziert werden. Nutzungsanforde- rungen sind nicht gleichzusetzen mit fachlichen Anforderungen, die primär Regeln darstellen, die ein fachlich kor- rekt erzieltes Arbeitsergebnis mit Hilfe des Software-Erzeugnisses / interakti- ven Systems vorsehen. Nutzungsan- forderungen sind auch keine „Nutzer- anforderungen“. Nutzungsanforderun-

gen sind Anforderungen an die effiziente Nutzung eines Systems, die primär aus dem Nutzungskontext in dem das inter- aktive System eingesetzt wird hergelei- tet werden müssen. Der Leitfaden Usa- bility³ der Deutschen Akkreditierungs- stelle Technik (DATech) liefert hierzu ein Schema zur Darlegung der Kontextda- ten selbst („Kontextszenario“), das auf der Basis von Kontextinterviews mit ech- ten Repräsentanten der Ziel-Nutzer- gruppe entsteht. Die Auswertung solcher Kontextszenarien in Hinblick auf implizi- te Erfordernisse und hieraus ableitbare Nutzungsanforderungen geschieht mit dem Schema des „ausgewerteten Kon- textszenarios“). Das Schema wurde zunächst für die Herleitung von Prüf- kriterien auf der Basis von DIN EN ISO 9241-11 und DIN EN ISO 9241-110 im Rahmen von Gebrauchstauglichkeits- prüfungen entwickelt, ist jedoch glei- chermaßen für die Herleitung von Nut- zungsanforderungen in frühen Projekt- phasen geeignet. Für die Nutzung des Schemas ist ein normales Textverarbei- tungssystem völlig ausreichend. Die eigentliche Herausforderung liegt im methodischen Erkennen und Darlegen von impliziten Erfordernissen im Nut- zungskontext. Dies erfordert einen geschulten Anforderungsanalytiker, der die Syntaxregeln für Erfordernisse und für Nutzungsanforderungen beherrscht, und die Empfehlungen der DIN EN ISO 9241-110 „Grundsätze der Dialoggestal- tung“ anwenden kann.

Auf der Basis einer ausreichenden An- zahl ausgewerteter Kontextszenarien wird im Anschluss mit Hilfe eines zwei- ten Schemas, des „Nutzungsszenarios“

die Ausführung der zu unterstützenden Aufgaben im Nutzungskontext aus Sicht des Nutzers spezifiziert.

Diese Form der Spezifikation kann man durchaus als „Interaktionsdesign“ auf

3 http://www.datech.de/share/files/

Leitfaden-Usability.pdf

3

der Basis von Nutzungsanforderungen verstehen, die die Brücke zwischen Anforderungsspezifikation und Proto- typing darstellt. Auch hierfür reicht ein Textverarbeitungssystem.

Wesentlich für den erfolgreichen Einsatz des Schemas für das Nutzungsszenario ist wiederum die Professionalität des menschlichen „Editors“, um die Interak- tion zwischen Nutzer und System in Hinblick auf zu erfüllende Nutzungsan- forderungen zu spezifizieren. Nutzungs- anforderungen und Nutzungsszenarien, die methodisch sauber hergeleitet und dokumentiert sind, bieten eine ideale Grundlage für das Prototyping, da wich- tige Fragen bereits vor dem Prototyping adressiert wurden und so „vorherseh- bare Überraschungen“ beim Prototyping und Entwicklungsbegleitenden Usability Testing bereits im Vorfeld ausgeräumt werden können.

4.0 Protoyping-getriebenes Spezifizie- ren von UI’s

Nachdem Nutzungsszenarien und Nutzungsanforderungen erzeugt worden sind, können erste Prototypen erzeugt werden. Prototyping ist eine essentielle Methode im UE Prozess, um Anforde- rungen zu simulieren und ein UI Design bereits sehr früh im Entwicklungspro- zess mit Nutzern evaluieren zu können.

In Projektsituationen mit einer hohen Beteiligung von Stakeholdern, die keine IT Experten sind, muss das Erzeugen von Prototypen einfach möglich sein.

Dies ist eine Voraussetzung für einen kollaborativen Prozess. Umgekehrt erzeugen innovative Prototypen, die eine magnetisierende Wirkung haben und Enthusiasmus verbreiten können, auch innovative Teams (Schrage, 1999).

Paper Prototyping reicht jedoch in vielen Situationen dazu nicht aus, da Stake- holder sehr häufig alle Ergebnisse (auch in frühen Phasen) bereits in einem „er- lebbaren“ Format kennen lernen möch-

ten. Es besteht daher eine enorme Nachfrage nach Prototyping-Werkzeu- gen, die detaillierte Simulationen er- zeugen können, aber dennoch für alle Stakeholder zu benutzen sind (Mem- mel et al., 2007a/b).

Wir stellen das sehr neue und im eu- ropäischen Raum noch weniger be- kannte Werkzeug iRise vor. iRise Stu- dio knüpft an die Erfahrungen der meisten Stakeholder mit Office-An- wendungen wie PowerPoint an. Dem Nutzer stehen alle gängigen UI Ele- mente zur Verfügung. Diese können leicht auf der „UI Zeichenfläche“ zu- sammengestellt werden. Auch ActiveX Komponenten wie z.B. Flash Filme, können zum Bau visuell ansprechen- der Prototypen integriert werden. Mit Hilfe von Templates und Master- Komponenten sind generische Ände- rungen leicht möglich. Durch die Ver- bindung mehrerer kreierter UIs ent- steht ein Storyboard. Per Knopfdruck wird hieraus eine UI Simulation er- zeugt, die in einem Feedback-Ver- fahren mit Annotationen versehen werden kann. Das iRise Datenformat erlaubt das gepackte Weiterleiten der erzeugten Prototypen an Dritte und bietet sich damit auch als nützliche Beigabe zu jeder textuell ausgearbei- teten Spezifikation an.

Zusätzlich integriert iRise auch selbst die Möglichkeit, Texte zu hinterlegen.

Dadurch können einzelne UI Elemente mit den ihnen zugrunde liegenden Use Case Narrationen oder auch Anforde- rungen für Designentscheidungen ver- bunden werden. Im Unterschied zu Styleguides stellen iRise Simulationen daher eine erlebbare Dokumentation der UI Design Rationale dar. UI- Standards sowie der Look einer An- wendung werden nicht nur textuell beschrieben, sondern auch als erleb- bares Artefakt bereitgestellt. Damit kann auch das Feel einer Anwendung besser weitervermittelt werden.

Die mit Prototypen erzielten Ergebnisse werden oft in Styleguides dokumentiert und treiben den weiteren UI Entwick- lungsprozess an (Mayhew 1999). Style- guides stellen keine UI Spezifikationen dar, da sie in der Regel keine Kontext- spezifischen Abbildungen oder Interakti- onsbeschreibungen enthalten. Vor allem wenn die Implementierung eines UI durch eine dritte Partei vorgenommen wird, muss zusätzlich zum Styleguide eine Spezifikation angefertigt werden.

Mayhew (1999) erläutert, dass eine sol- che UI Spezifikation in erster Linie aus Abbildungen besteht und nur an solchen Stellen Text enthält, an denen eine Ab- bildung alleine nicht ausreicht. Aus un- serer Erfahrung heraus trifft dies vor allem dann zu, wenn das interaktive Verhalten eines UI im Detail beschrei- ben werden soll. Wir stellen im Work- shop daher unsere Idee interaktiver UI Spezifikationen vor.

5.0 Interaktive UI Spezifikationen Eine interaktive UI Spezifikation verbindet die Grundidee von Styleguides mit dem Zweck einer Spezifikation. Sie speichert wichtige Designvisionen sowie -entscheidungen und dokumentiert Standards und Testergebnisse. Die tex- tuelle Information wird durch UI Prototy- pen unterschiedlichen Detailgrads (low-, medium-, high-fidelity) angereichert.

Zusätzlich enthält diese interaktive UI Spezifikation auch die am Beginn des Prozesses hergeleiteten Nutzungsanfor- derungen und -szenarien. Darauf auf- bauend werden unterschiedliche (agile) Anforderungsmodelle als visuelle Nota- tionen integriert, darunter z.B. Use Ca- ses oder Aktivitätsdiagramme (Memmel et al., 2007c). Die interaktive UI Spezifi- kation, die in einem XML-basierten For- mat gespeichert und mit Dritten ausge- tauscht werden kann, erlaubt somit den einfachen Wechsel von abstrakten Be- schreibungen (Text), graphischen Nota-

4

tionen (Modelle) und UI Prototypen (De- sign).

Mit einem experimentellen Werkzeug namens INSPECTOR (Memmel et al., 2008a/b/c/d) bauen wir auf vielverspre- chenden Werkzeugen wie iRise auf und ergänzen diese um eine Unterstützung von Anforderungsermittlung und UI Mo- dellierung. Durch die Integration von Text, Modellen und Design können alle für eine UI Spezifikation notwendigen Informationen mit einem innovativen Zoom-Konzept zusammengeführt wer- den. Dies sorgt für eine leichte Nach- vollziehbarkeit und starke Transparenz sowohl hinsichtlich der Topologie des Spezifikationsraums, als auch hinsich- tlich der Entwicklungsaufgabe selbst.

6.0 Zusammenfassung

In unserem Workshop zeigen und diskutieren wir ausgewählte Papier- basierte und interaktive UI Spezifikati- onstechniken. Diese unterstützen den Usability Professional bei der Identifika- tion von Erfordernissen und Anforderun- gen. Darüber hinaus helfen sie bei der Übersetzung von Anforderungen in gra- phische Notationen und UI Prototypen.

Mit interaktiven UI Spezifikationen stel- len wir eine Herangehensweise vor, die in Verbindung mit textuell ausgearbeite- ten Anforderungs- und Interaktionsspezi- fikationen eine frühzeitige Veranschauli- chung und Validierung von Lösungskon- zepten fördern und so das Risiko mini- mieren, das wichtige textuell dargelegte Sachverhalte mangels Veranschauli- chung schlichtweg übersehen werden.

7.0 Literaturverzeichnis

DIN EN ISO 9241-11: Anforderungen an die Gebrauchstauglichkeit; Leitsätze, Beuth Ver- lag, Berlin 1998.

DIN EN ISO 9241-110: Grundsätze der Dia- loggestaltung, Beuth Verlag, Berlin 2006.

ISO IEC 15288: Systems and software engineering - System life cycle processes, Beuth Verlag, Berlin 2008.

Deutsche Akkreditierungsstelle Technik in der TGA GmbH (2007): Leitfaden Usability.

http://www.datech.de/share/files/Leitfaden- Usability.pdf [01.08.2008].

Deutsche Informatik-Akademie 2003 - 2008, Seminar „Nutzungsanforderungen an Anwendungssoftware identifizieren und spezifizieren”, http://www.dia-

bonn.de/seminare/nutzungsanforderungen.

html [01.08.2008].

Deutsche Informatik-Akademie 2003 - 2008, Seminar „User Interfaces für Anwen- dungssoftware - Entwurf und Prototyping”, http://www.diabonn.de/seminare/user_interf ace.html [01.08.2008]..

Dzida, W.; Freitag, R. (1998): Making use of scenarios for validating analysis and design, in IEEE Transactions on Software- Engineering, 0098-5589, 24(1998)12, S.

1182–1196.

Dzida, W.; Hofmann, B.; Freitag, R.; Red- tenbacher, W.; Baggen, R.; Zurheiden, C.;

Geis, T.; Beimel, J.; Hartwig, R.; Hampe- Neteler, W.; Peters, H. (2000): Gebrauchs- tauglichkeit von Software. ErgoNorm: Ein Verfahren zur Konformitätsprüfung von Software auf der Grundlage von DIN EN ISO 9241 Teile 10 und 11. Bremerhaven:

Wirtschaftsverlag NW.

Dzida, W.; Freitag, R. (2001): Usability Testing – The DATech Standard, in M.

Wieczorek, D. Meyerhoff (Hrsg.): Software Quality – State of the Art in Management, Testing And Tools. Berlin: Springer, 3-540- 41441-X, S. 160–177.

Geis, T.; Dzida, W.; Redtenbacher, W.

(2004): Specifying usability requirements and test criteria for interactive systems.

Consequences for new releases of soft- ware-related standards within the ISO 9241 series. Bremerhaven: Wirtschaftsverl. NW.

Mayhew, D. J. (1999): The usability engi- neering lifecycle - A Practicioners Hand- book for User Interface Design, San Fran- cisco: Morgan Kaufmann.

Memmel, T.; Vanderdonckt, J.; Reiterer, H.

(2008a): Multi-fidelity User Interface Speci- fications. In Proc. of the 15th International

Workshop on the Design, Verification and Specification of Interactive Systems (DSV-IS 2008), S. 43-57. Springer: Kingston, Canada.

Memmel, T.; Geyer, F.; Rinn, J.; Reiterer, H.

(2008b): Tool-Support for Interdisciplinary and Collaborative User Interface Specifica- tion. In Proc. of the IADIS International Confe- rence on Interfaces and Human Computer Interaction (IHCI 2008), Amsterdam, Nieder- lande, S. 51-60

Memmel, T.; Geyer, F.; Rinn, J.; Reiterer, H.

(2008c): A Zoom-Based Specification Tool for Corporate User Interface Development. In Proc. of the IADIS International Conference on Interfaces and Human Computer Interac- tion (IHCI 2008), Amsterdam, Niederlande, S.

368-370

Memmel, T.; Reiterer, H. (2008d): Inspector:

Interactive UI Specification Tool. In Proc. of the 7th International Conference On Comput- er Aided Design of User Interfaces (CADUI) 2008, Albacete, Spanien, S. 161 - 174 Memmel, T.; Reiterer, H.; Ziegler, H.; Oed, R.

(2007a): Visuelle Spezifikation zur Stärkung der Auftraggeberkompetenz bei der Gestal- tung interaktiver Systeme. In Proceedings of 5th Workshop of the German Chapter of the Usability Professionals Association e.V., in:

Kerstin Roese, Henning Brau, Frauenhofer IRB Verlag, Stuttgart, S. 99-104.

Memmel, T.; Heilig, M.; Schwarz, T.; Reiterer, H. (2007b): Visuelle Spezifikation interaktiver Softwaresysteme. In Proceedings of the 7th Mensch & Computer conference (MCI 2007, Weimar, Germany), in: Tom Gross: Mensch &

Computer 2007, Oldenbourg Verlag, S. 307- 310.

Memmel, T.; Gundelsweiler, F.; Reiterer, H.

(2007c): Agile Human-Centered Software Engineering. In Proc. of 21st BCS HCI Group conference (HCI 2007, UK), in: Linden J. Ball, M. Angela Sasse, Corina Sas, Thomas C.

Ormerod, Alan Dix, Peter Bagnall and Tom Mc Ewan: "HCI...but as we know it", British Computer Society, S. 167-175.

Schrage, M. (1999): Serious Play - How the World's Best Companies Simulate to Innovate Harvard Business School Press.

The Standish Group International (2007):

CHAOS Report 2007: The Laws of CHAOS.

The Standish Group International Inc, Boston.