Zurück
Philipp Murkowsky
12. October 2012

Requirements Engineering by Prototyping

Wenn grosse IT-Projekte wie Insieme floppen, taucht regelmässig die Frage auf, wie es dazu kommen konnte dass Millionen in den Sand gesetzt wurden, ohne dass brauchbare Resultate geliefert wurden.

Als Ursachen werden dabei typischerweise drei Dinge genannt:

Wir sind der Meinung dass schlechtes Anforderungsmanagement die wichtigste Ursache von Kostenüberschreitungen und Fehlenwicklungen ist. Fehler beim Projektmanagement und die falsche Einschätzung der Realisierungskosten sind oft eine direkte Folge von unklaren und unvollständigen Anforderungen.

Ein gemeinsames Verständnis der Anforderungen tut not

Gutes Anforderungsmanagement ist sehr schwierig und benötigt viel Wissen aus verschiedenen Domänen. Es braucht eine genaue Kenntnis der fachlichen Aspekte, der Arbeitsabläufe, der Vorgaben aus dem Business und der technischen Rahmenbedingungen. Nur so lassen sich die verschiedenen Anforderungen in ein vollständiges und mit vernünftigem Aufwand realisierbares Konzept überführen.

Ob die Anforderungen vollständig, notwendig und klar sind, lässt sich aber nur schwer überprüfen. Die verschiedenen Stakeholder kennen nur einen Teil des Ganzen und die Anforderungskataloge sind meistens sehr umfangreich, z.T. abstrakt formuliert und lassen einen grossen Interpretationsspielraum zu. Ein gemeinsames Verständnis der Anforderungen ist aber eine wichtige, wenn nicht gar die wichtigste Voraussetzung für ein erfolgreiches Projekt.

Prototypen sind unseres Erachtens die beste Methode, um ein gemeinsames Verständnis der Anforderungen herzustellen. Ein Prototyp simuliert das fertige Produkt und visualisiert die Anforderungen auf eine Weise, die für alle Beteiligten nachvollziehbar ist. Ob Business Analystin, Anwendervertreter, Entwickler, Projektleiter oder Auftraggeberin: alle sehen das Gleiche, sprechen über das Gleiche und können nun effektiv prüfen, ob das Produkt dem gewünschten Umfang entspricht oder nicht.

Prototyping reduziert Projektrisiken

Nicht-funktionale Protoypen können vergleichsweise kostengünstig erstellt werden, da dabei nur die Benutzeroberfläche einer Software simuliert wird. Die ganzen Backend-Prozesse, Schnittstellen, Datenbanken und Systemlandschaften müssen erst später entwickelt werden. Anpassungen sind daher in diesem Stadium noch ohne grossen Aufwand möglich, so dass man in mehreren Iterationen auf die richtige Lösung hinarbeiten kann. Protoypen können auch für Usability-Tests mit Anwendern benutzt werden. Dadurch lassen sich Probleme bei der Benutzerführung bereits lösen, bevor sie überhaupt entstehen.

Die Implementationsrisiken lassen sich jedoch mit nicht-funktionalen Prototypen nur zum Teil reduzieren. Es ist zwar unserer Erfahrung nach auch für Entwickler und Systemtechniker deutlich einfacher, anhand von Prototypen die technischen Rahmenbedingungen richtig einzuschätzen. Aber letzlich sieht man erst bei der konkreten Entwicklung, ob sich ein technisches Problem so lösen lässt, wie es ursprünglich vorgesehen war. Daher empfiehlt es sich, den eigentlichen Entwicklungsprozess agil zu gestalten und auf bewährte Vorgehensweisen wie Scrum zurückzugreifen, um auch diese Risiken zu vermindern.