Der Umsetzungsteil eines IT-Projektes, soll sich an real existierenden Anforderungen orientieren und nicht an schnell getroffenen Annahmen, welche nicht überprüft wurden.
Sie sind die berüchtigten Evergreens der Branche: IT-Projekte, die gut beginnen, zu umfangreich werden, aus dem Ruder laufen und scheitern. Die ursprünglichen Kosten werden dabei oft um ein Vielfaches überstiegen. Solche Projekte haben zwei Gemeinsamkeiten: Sie beginnen mit den besten Absichten, und sie verwenden von Beginn an Methoden, die nicht funktionieren. In einem neuen Artikel sieht Jared M. Spool das Hauptproblem bei der traditionellen Anforderungsanalyse. Um Abhilfe zu schaffen, schlägt er deshalb vor, diese durch etwas zu ersetzen, was auch tatsächlich funktioniert. Dazu gehören die Methoden, die auch wir im User-Centered Design bei Zeix für unsere Kunden seit bald 13 Jahren erfolgreich einsetzen.
Testen und diskutieren als Teile der Lösung
- Formulierung von Hypothesen
Die technischen und fachlichen Anforderungen können durchaus korrekt sein, aber sie sind nicht immer relevant, vollständig oder richtig priorisiert. Werden die getroffenen Annahmen als Hypothesen formuliert, stellt man diese Annahmen damit zur Diskussion. - Durchführung von Usability-Tests
Hier wird geprüft, welche Hypothesen richtig waren – und welche falsch. Mit der Beobachtung des Benutzerverhaltens anhand von Prototypen kann in Tests herausgefunden werden, welche Ansätze dem Benutzer am besten dienen. Tests dienen auch dazu, verschiedene Varianten auszuprobieren und die Beste davon auszuwählen. - Anforderungen in Szenarien einbetten
Statt Anforderungen trocken und ohne Kontext zu erfassen, werden sie in Szenarien eingebettet. Dabei wird nicht nur betrachtet, was der Benutzer tut, sondern auch wieso er es tut. So fliessen alle Bedürfnisse und Probleme des Benutzers in die Anforderungen ein, mit dem Resultat, am Ende eine erstklassige User Experience für alle Szenarien garantieren zu können. - Kritisches Überprüfen der Anforderungen
Wenn nun alle Anforderungen kritisch hinterfragt und diskutiert werden, zeigt sich schnell, welche davon noch gültig sind und welche nicht mehr. So wird vermieden, dass wertvolle Anforderungen untergehen, während unnötige Anforderungen weiterbestehen.
Besser machen ist auch billiger
Diese iterativen Schritte nehmen nur auf den ersten Blick mehr Zeit in Anspruch als eine traditionelle, oft zu kurze Anforderungsanalyse zu Beginn eines Projektes. Denn sie sorgen im Gegenzug dafür, dass sich der Umsetzungsteil des Projektes an real existierenden Anforderungen orientiert und nicht an schnell getroffenen Annahmen, welche nicht überprüft wurden. Genau die Lücken zwischen den realen und den angenommenen Anforderungen sind es nämlich, die später im Projekt zu teuren und teils gefährlichen Änderungen führen können.
Links
Replacing „Requirements Gathering“ with Something That Works, Jared M. Spool, 25.6.2013
«Ursachenforschung bei Informatik-Flops» oder «Sind wirklich die armen Projektleiter schuld?», Zeix-Blog, Gregor Urech, 16.7.2012,
Vortrag: The End of Prose – Developing Unambiguous Requirements with User-Centered Design, Zeix Veranstaltung vom 20.6.2012
