Aus dem Requirements Engineering (RE) ist kein Projektfortschritt sichtbar, da damit nichts produziert wird. Trotzdem solltest du die Zeit investieren, um zu überlegen, welche Anforderungen an ein Produkt gestellt werden, um die Kundschaft zu begeistern. Doch wieviel solltest du hierfür investieren? Hier erhältst du die Antwort darauf und ich teile euch meine bisherigen Erfahrungen anhand eines Praxisbeispiels mit.
Wofür Requirements Engineering
Jeder, der an einem neuen Projekt beteiligt ist, kennt es: Du möchtest sofort damit starten, und zwar so schnell wie möglich. Aber halt! Lasst uns überlegen, was genau der Endkunde benötigt und wie das Ding funktionieren soll. In anderen Worten, lasst uns RE betreiben. Vom Gedanken sich Zeit zu nehmen, um bloss Anforderungen niederzuschreiben, ist insbesondere das obere Management nicht erfreut. Wenn Geld investiert wird, will man in Zeiten, wo alles agil geführt wird, unmittelbar Resultate sehen. Mit RE wird die Basis gestellt, damit es während dem Projektverlauf zu weniger Abklärungen kommt, weniger Unterbrüche, mehr Klarheit über die Funktionalität des Tools oder die Erwartungen der Kundschaft gegenüber einem neuen Service.
Welches Mass an Requirements Engineering ist richtig
Aus den Erfahrungen mit RE in den letzten 50 Jahren wissen wir, dass je nachdem wieviel Zeit in die Anforderungen investiert wird, ein Projekt deswegen ins Wasser fällt oder eben erfolgreich ist. Bedeutet das, dass blind in RE investiert werden sollte? Es ist klar, dass niemand daran interessiert ist ein Projekt zu führen, welches am Schluss nicht erfolgreich abgeschlossen werden kann. Jedoch möchte kein Investor mehr ausgeben als nötig. Doch wieviel darfst du denn für RE ausgeben, sodass du das Projektbudget nicht sprengst? Die Antwort ist einfach: 16% von den Projektkosten.
Gem. einer Studie von J. Bowen und M. Hinchey solltest du ungefähr 16% deiner Zeit und Geldes darin investieren, um Anforderungen zu ermitteln, diese z.B. anhand von Use Cases zu beschreiben und zu dokumentieren. Zudem solltest du auch die Anforderungen prüfen und mit den Stakeholdern abstimmen, um die Qualität zu wahren und die Anforderungen zu verwalten. Wenn du mehr als 16% investierst, riskierst du eine Kostenüberschreitung. Wenn du weniger für RE ausgibst, riskierst du aus den obenerwähnten Gründen den Projekterfolg.
Requirements Engineering deckt auf, was schiefläuft
Wer im Projektmanagement arbeitet, verbringt viel Zeit damit, Unklarheiten aus dem Weg zu schaffen, IT zu erklären, wie bestimmte Sachen funktionieren sollten und mitten im Projekt Anforderungen zu schreiben oder anzupassen. Das raubt nicht nur viel Zeit, sondern auch Nerven!
Das obere Management hat Zugriff auf die Informationen, welche über Erfolg und Misserfolg eines Projektes entscheiden. Trotzdem können wir beobachten, dass insbesondere bzgl. RE die Augen verschlossen werden und schnelle erste Projektresultate als wichtiger eingestuft werden.
Folgendes Praxisbeispiel zeigt auf, dass mit RE Zeit und Kosten gespart werden: Ein Unternehmen will ein neues Tool kreieren, welches über die neueste Technologie verfügt. Es handelt sich um ein Projekt, das über mehrere Jahre andauert und sich im zweistelligen Millionenbereich bewegt. Zudem werden Senior Developers eingestellt, um das Tool zu entwickeln. Das Projekt startet und schnell wir ein erstes GUI kreiert. Dieses wird erfolgreich getestet, während die Entwickler am Dashboard weiterarbeiten. Inzwischen sind anderthalb Jahre vergangen und das Go-Live steht vor der Tür. Dabei wird festgestellt, dass das Tool zwar funktional sich richtig verhält, jedoch die Performance nicht stimmt. Um die Root Cause des Problems zu finden, geht das Management mit dem System-Designer die Use Cases durch und sie eruieren, ob die Architektur in Ordnung ist. Nachdem sie die Requirements überprüft haben, wird festgestellt, dass die Skills der Entwickler ungenügend sind. Sie haben das System so aufgebaut, dass die Entwickler die Milestones schnell erreichen können, haben dabei aber nicht die Technologie verwendet, welche angedacht war. Nun steht das Projektteam mit einem Tool da, das nicht die Leistung erbringt, die zukünftig nötig ist.
RE ist nicht etwas, das nur anfangs im Fokus stehen sollte, sondern während des gesamten Projektes. Es sollte regelmässig überprüft werden, ob das was entwickelt wird, auch mit den Use Cases übereinstimmt.
