Irrtum Nr. 9: Requirements Engineering in Projekten kostet nichts

Meine Kollegen Jens Donig und Frank Stöckel haben in ihrem Artikel Sieben Irrtümer bei der Einführung von Requirements Engineering die häufigsten Fehleinschätzungen bei der Einführung von RE beschrieben und haben dazu nochmals auf der REConf 2012 vorgetragen. Ein achter Irrtum in dem Vortrag war zu glauben, dass es nur sieben Irrtümer über die Einführung gäbe. Deshalb möchte ich daran anschließen und auf einen weiteren Irrtum Nr. 9 aufmerksam machen:

Requirements Engineering in Projekten kostet nichts!

Der Umgang mit Anforderungen gehört zu guter Projektmanagementpraxis, wie sie etwa von der GPM Deutsche Gesellschaft für Projektmanagement e.V. oder dem Project Management Institute vertreten wird. Unsere Erfahrung zeigt aber, dass in vielen Projekten Aktivitäten für den Umgang mit den Anforderungen kaum explizit oder nur sporadisch eingeplant werden. Dies hat zur Folge, dass die Arbeitsergebnisse in mangelhafter Qualität vorliegen. Dabei hat die Standish Group in ihrem Chaos Manifesto 2013 (S. 38) die Bedeutung guter Anforderungen für den Projekterfolg einmal mehr betont. Will man die Qualität dieser Arbeitsergebnisse erhöhen, muss man Ressourcen für systematisches Requirements Engineering einplanen. Im Ergebnis erhält man bspw. ein abgestimmtes Stakeholder-Register, systematisch erhobene und abgestimmte Anforderungen, nach fest definierten Qualitätskriterien geprüfte Anforderungen, etc.. Letztlich hilft all dies, einen für alle Beteiligten klar umrissenen Projektscope zu definieren.

Die Kehrseite ist, dass ich in das Projekt investieren muss, wenn ich von den Vorzügen profitieren möchte. All diese Aspekte generieren Aufwand während des Projektes, den ich bei der Projektplanung berücksichtigen muss. Den Return on Investment am Anfang erhalte ich in den nachfolgenden Projektphasen durch reduzierte Aufwände in der Entwicklung, einer höheren Produktqualität und in Form eines Produktes, was der Kunde wirklich benötigt und sich gewünscht hatte. Die Entscheidung in das Investment sollte nicht den Projekten allein überlassen werden, sondern sollte letztlich eine strategische Entscheidung des Managements sein (vergl. Abbildung).

Der erste entscheidende Aspekt für ein Investment in eine verbesserte Qualität der Anforderungen und deren Management ist nun, Mitarbeiter in das Projekt einzuplanen, die in der Lage sind, die entsprechenden Arbeitsergebnisse in der gewünschten Qualität zu liefern. Dabei ist nachrangig, ob diese von einem Requirements Engineer oder einer bereits existierenden Rolle mit den entsprechenden Kompetenzen erarbeitet werden.

Der zweite entscheidende Aspekt ist das Einplanen entsprechender Aktivitäten und der notwendigen Zeit dafür, denn: Nur das, was im Projektmanagement eingeplant wird, kann auch durchgeführt werden. D.h. konkret also, dass die Projekt- und Zeitpläne grundsätzlich überarbeitet werden müssen. Leider passiert das nicht immer und so müssen die Betroffenen teilweise die neuen Arbeitsergebnisse oder Arbeitsergebnisse mit erhöhter Qualitätsanforderung zu den früher definierten Meilensteinen abliefern. Dies ist natürlich nicht möglich und bedeutet für die Betroffenen, die ihre erlernten Techniken nicht anwenden können, ein unauflösbares Dilemma, da sie nicht die notwendige Zeit zur Verfügung gestellt bekommen.

Nun stellt sich natürlich die Frage, was die Investition in systematisches Requirements Engineering in einem Projekt kostet. In der Luft- und Raumfahrt Industrie, hat sich gezeigt, dass durchschnittlich 3% der (vorgesehenen) Projektkosten auf das Requirements Engineering entfallen. Auswertungen der NASA haben sogar gezeigt, dass Investition von 8% bis 14% der (vorgesehenen) Projektkosten in den Requirements-Engineering-Prozess die Wahrscheinlichkeit signifikant erhöhen, dass Projektkosten gesenkt und Zeitpläne positiv beeinflusst werden können (Young, Ralph R.: Twelve Requirements Basics for Project Success. 2006. In: CROSSTALK – The Journal of Defense Software Engineering.). In der Softwareentwicklung können Aufwände auf Grundlage des mit der Function-Point-Methode (ISO/IEC 20926) bestimmten funktionalen Umfangs der zu entwickelnden Software abgeschätzt werden. Untersuchungen haben gezeigt, dass sich je nach Anwendungsbereich pro Funtion Point (FP) folgender Aufwand in Personenstunden des Requirements Engineering abschätzen lässt (Auszug aus Tabelle von Yong Xia: Seminar on Software Cost Estimation. Requirements Engineering Research Group, Department of Computer Science, University of Zurich, Switzerland):

Nehmen wir nun eine mittelgroße, kommerzielle Software mit 1500 FP an (siehe Jones, Caspers: Function Points as a Universal Software Metric. 2013.: zum Vergleich MS Word wird mit 1431 FP angegeben). Dann wären nach o.g. Tabelle 960 Personenstunden für das Requirements Engineering einzuplanen. Bei effektiven 128 Personenstunden pro Monat wären das 7.5 Personenmonate. Eine erfahrene Firma wie IBM rechnet für 1500 FP mit einem Aufwand von 194,6 Personenmonaten (Grechenig, T.: Softwaretechnik. 2010. S. 424). Dann würden demnach etwa 3.85% des Entwicklungsaufwandes auf das Requirements Engineering entfallen. Andere Autoren nennen generell einen Ansatz von ca. 10% der (vorgesehenen) Projektkosten als notwendigen Investition in das Requirements Engineering (Ebert, Ch.: Systematisches Requirements Engineering: Anforderungen ermitteln, spezifizieren, analysieren und verwalten. 2010. S.350ff).

Allgemeingültige Abschätzungen über die Aufwände von systematischem Requirements Enginee-ring lassen sich also nicht treffen. Dazu hängen diese zu sehr von Faktoren ab, wie Branche – in der Luft- und Raumfahrtindustrie werden sehr viel höhere Anforderungen aufgrund von Nachweispflichten an den Requirements Engineering Prozess gelegt, als in anderen Branchen – , wie Prozess – gibt es einen Requirements Engineering Prozess und wie wird dieser gelebt – etc.. Der wahre Aufwand wird wohl irgendwo zwischen 10% und 15% der vorgesehenen Projektkosten liegen. Dabei ist noch unklar, welche Aktivitäten nun dem Projektmanagement und welche dem Requirements Engineering zuzuordnen sind, da es Aspekte, wie das Stakeholder Management gibt, die für beide Disziplinen kritisch sind.

Deshalb empfehlen wir in einem ersten Schritt systematisches Requirements Engineering in ein Projekt einplanen und dabei sicherstellen, dass die Betroffenen die notwendige Zeit für die vereinbarten Ziele bekommen und natürlich in den neuen Techniken geschult werden. Wer also Requirements Engineering konkret leben möchte, muss die existierenden Projektpläne überarbeiten. Alleine wenn wir diesen Change konkret in Unternehmen erreichen können, wäre das in jedem Fall ein erster großer Schritt.

Christian Patschke

Kontaktieren Sie Christian Patschke

Herr Christian Patschke ist bei der HOOD GmbH als Consultant tätig. Sein Schwerpunkt liegt an der Schnittstelle zwischen Projektmanagement und Requirements Engineering. Er unterstützt unsere Kunden bei der Einführung eines nachhaltigen Requirements Engineerings & Management und dessen Integration in das Projektmanagement durch Begleitung der Prozessentwicklung, coachen von Projektleiter und Projektmitarbeiter, sowie durch Weiterbildung des Personals. Er setzt dabei Akzente in interdisziplinären Entwicklungsprojekten mit Bezug zur Informationstechnologie.