Haben Sie alle relevanten User bei der Erhebung der Anforderungen einbezogen und trotzdem sind diese sind am Schluss unzfrieden mit dem Resultat? Meistens liegt es daran, dass die Anwender ihre Anforderungen selbst formulieren, sei es in Workshops oder in Textdokumenten. Genau das aber fällt Anwendern schwer: Sie verstehen sich zwar ausgezeichnet auf ihre Arbeit, aber sie können nur unzureichend erklären, was sie tun und was sie benötigen. Die Methode der Contextual inquiry nimmt sich genau dieses Problems an: Statt Mitarbeiter zu befragen, werden diese bei ihrer Arbeit beobachtet. Wir führen in die Methode ein und zeigen anhand von Beispielen aus dem Projektalltag, wie damit vollständige Anforderungen erhoben werden und die Falle des «Wunschkonzerts» von Anforderungen vermieden wird.

1. © by Zeix 2014
Contextual Inquiry:
Weshalb beobachten besser ist als fragen.

2. © by Zeix 2014 2
Software …
> Nervt.
> Ist unintuitiv.
> Ist mühsam zu bedienen.
> Zwingt die Nutzer zu unnötigen Schritten.
> Führt dauernd zu Fehlern und stürzt laufend ab.
> Unterstützt die Nutzer beim Erledigen ihrer täglichen Arbeit.
> Vereinfacht den Nutzern die Arbeit.
> Hilft beim Vermeiden von Fehlern.
> Steigert die Effizienz.
> Macht Freude.
> Hilft.
Leider oftmals die Realität

3. © by Zeix 2014 3
Um benutzerfreundliche
Software zu entwickeln …
… müssen die Benutzer in den Entwicklungsprozess
mit einbezogen werden.

4. © by Zeix 2014 4
User einbeziehen im Projektverlauf
Anforderungs-
erhebung /
Analyse
Konzeption/
Design/
Prototyping
Umsetzung
Betrieb &
Optimierung
Heute Fokus auf die
Anforderungserhebung

5. © by Zeix 2014 5
Die User fragen
a) schriftlich

6. © by Zeix 2014 6
Die User fragen
b) In Bedürfnisworkshops
?

7. © by Zeix 2014 7
User im Arbeitsalltag beobachten

8. © by Zeix 2014 8
Erfahrungen mit
den Methoden
Die User fragen
a) schriftlich
Die User
beobachten
Die User fragen
b) Bedürfnisworkshops

9. © by Zeix 2014 9
> … können oftmals ihre Bedürfnisse nur
ungenügend formulieren.
> … formulieren ihre Anforderungen so, dass sie
von anderen Personen (z.B. den Requirements
Engineers oder UX Architects)
> falsch verstanden werden oder
> unterschiedlich verstanden werden.
> … priorisieren eigennützig.
Einzelne User …

10. © by Zeix 2014 10
> … sind oft politisch ausgewählt.
> … sind selber nicht oder nur begrenzt Nutzer der Software.
> … verwechseln «Anforderungen» mit «Beschreiben der IST-
Situation»
> Meist dominieren einzelne Individuen die Meinung in der
Gruppe.
Die Teilnehmer von Bedürfnisworkshops …

11. © by Zeix 2014 11
> Andere Menschen
> Arbeitsteilung, Unterstützung, Kommunikation, Hierarchien
> Die Arbeitskultur
> Gesamte Arbeitsabläufe
> Für eine Aufgabe zwischen Personen, für alle Aufgaben einer Person
> Einbezug von Hilfsmitteln
> Arbeitsumgebung
> Äussere Bedingungen, Lichtverhältnisse, Platz, Lärm
Der Kontext ist relevant
Deshalb heisst die Methode «Beobachten am Arbeitsplatz» auch
«Contextual Inquiry»

12. © by Zeix 2014 12
> Wieso der gesamte Arbeitsprozess relevant ist für das
Applikationsdesign.
Projektbeispiel

13. © by Zeix 2014 13
Projektbeispiel
> Vereinheitlichung der Geschäftsprozesse nach Integration
eines neuen Unternehmens
Ausgangslage

14. © by Zeix 2014 14
Projektbeispiel
> Portal mit benutzerfreundlicher Darstellung der
Geschäftsprozesse und Links auf Zusatzinformationen.
> Beschaffung einer Software für die Abbildung und Verwaltung
der Geschäftsprozesse.
Projektziele

15. © by Zeix 2014 15
Projektbeispiel
> «Remote-Beobachtung» mit 7 Personen.
> Mit Screen-Übertragung und per Telefon wegen räumlicher Distanz.
> Befragung zur Art der Arbeit, Zusammenarbeit, Stärken und
Schwächen der aktuellen Prozesse und Tools.
> Details zu den verwendeten Tools und Systemen.
Erhebung der Anforderungen

16. © by Zeix 2014 16
Projektbeispiel
> Erfahrung ist zentral für die Erledigung der Arbeit.
> Information ist schwer auffindbar und oft nicht aktuell.
> Regelmässiger Austausch und persönlicher Kontakt sind die
wichtigsten Arbeitsinstrumente.
> Workflow-Funktionalitäten sind eher sekundär.
> Empfehlung: Ein zentraler Zugang zu den Systemen,
Weisungen etc. , visualisiert gemäss dem Geschäftsprozess.
Ergebnisse Anforderungsanalyse

17. © by Zeix 2014 17
Projektbeispiel
> Umsetzung der Systemanforderungen in einem klickbaren
Prototyp.
> Usability Tests (remote) mit 6 Personen.
Überprüfung der Anforderungen

18. © by Zeix 2014 18
Visualisierung macht urteilsfähig …
… und vereinfacht die Kommunikation.

19. © by Zeix 2014 19
Projektbeispiel
> Anforderungen waren richtig verstanden und umgesetzt.
> Erfüllung der Anforderungen konnte besser gewichtet werden.
> Eine Anforderung, die in den Interviews als eher nebensächlich
bewertet worden war, wurde durchgehend als sehr wichtig eingestuft.
> Viele Details können optimiert werden, z.B.
> Benötigte Tiefe der Information.
> Unterschiedliches Verständnis von Prozessen und Definitionen.
> Viele wichtige Zusatzinformationen am Ende des Nachinterviews.
> Gewisse Diskrepanz zwischen Stärken des eingesetzten Tools
und Benutzerbedürfnissen.
Ergebnisse Usability Test

20. © by Zeix 2014 20
Die User fragen
a) schriftlich
+ Kostengünstig
+ Hoher Abdeckungsgrad
unterschiedlicher User
− Heterogenität von Qualität
und Detaillierungsgrad der
Anforderungen
− Missverständnisse &
Fehlinterpretationen
− Führt zu Wunschkonzert
Der Vergleich
Die User
beobachten
+ Arbeitskontext fliesst in die
Anforderungen mit ein
+ Bessere Erfassung
individueller Bedürfnisse
+ Bessere Gesamtprozess-
betrachtung und –
optimierung
+ Sehr gute Kooperation
− Im Vergleich aufwändiger
− Allenfalls die Arbeit
störend
Die User fragen
b) Bedürfnisworkshops
+ Relativ kostengünstig
− Einbezug der falschen
Personen
− Dominanz einzelner
Personen
− Falsche Priorisierung der
Anforderungen
− Häufig Kompromiss-
Anforderungen
− Führt zu Wunschkonzert

21. © by Zeix 2014 21
Danke.
Fragen können Sie nicht nur jetzt.
Gregor Urech
gregor.urech@zeix.com
Andrea Rosenbusch
andrea.rosenbusch@zeix.com