Projektkosten besser im Griff mit Requirements Engineering

*Alain Hofer ist Business Analyst sowie IREB Kurstrainer und leitet das Berner Büro von SwissQ. Noch vor vier Jahren konnten im Schnitt nur gut 20 Prozent der IT-Projekte erfolgreich innerhalb der gegebenen Frist und des Kostenrahmens abgeschlossen werden. Gemäss der aktuellen Studie «Trends & Benchmarks» (T&B 2014, vgl. Kasten auf der letzten Seite) ist dieser Wert inzwischen auf knapp 40 Prozent gestiegen. Eine gute Projektplanung alleine ist jedoch noch keine Garantie dafür, dass ein Vorhaben erfolgreich abgeschlossen werden kann. Gerade in hektischen Zeiten ist es wichtig, einen kühlen Kopf zu bewahren und von Anfang an sicherzustellen, dass die richtigen Aufgaben in Angriff genommen werden. Dafür sorgt ein solides Requirements Engineering. Von Anfang an richtig Investieren in Requirements Engineering macht sich langfristig bezahlt. Folgende drei Gründe sind dafür ausschlaggebend:

Requirements Engineering hilft, Denkfehler in frühen Projektphasen zu erkennen und zu beheben. Mit einfachen Methoden werden Konflikte zwischen unterschiedlichen Anforderungen sichtbar gemacht. 2014 haben mehr als die Hälfte der Projekte und Firmen die Anforderungen in natürlicher Sprache erhoben (Quelle: T&B Report 2014). Bekanntlich lässt die Sprache einen erheblichen Interpretationsspielraum zu, sodass unter Umständen eine Lösung entwickelt wird, welche die Bedürfnisse und Wünsche der Kunden nur unvollständig oder gar ungenügend abdeckt. Ein ausgebildeter Requirements Engineer wird hier an die sogenannten Transformationseffekte (Quelle: IREB.de) denken und kann solche Ungenauigkeiten in den Sätzen systematisch aufdecken. Dadurch wird der Interpretationsraum eingeschränkt und die Lösung auf eine präzisere Basis gestellt.

Gemäss Umfrageergebnissen der Standish Group (Chaos Report) werden in fertigen Produkten unglaubliche 80 Prozent der Funk­tionen nie oder nur sehr selten gebraucht. Im Umkehrschluss heisst das, nur gut 20 Prozent der Funktionen werden oft oder zumindest ab und zu angewendet. Ein solides Requirements Engineering hilft, bereits in der Entwicklungsphase festzustellen, welche Funktionen in einem System zentral sind, und welche mit gutem Gewissen nicht umgesetzt werden müssen. So lassen sich Umfang bzw. Scope der Lösung so einschränken, dass nur die wirklich relevanten und aus einer Business-Sicht wertschöpfenden Funktionen realisiert werden. Das  setzt Ressourcen für die Umsetzung und das Testen der relevanten Funktionalitäten frei.

Ob agil unterwegs oder eher in klassischer Manier nach einem Wasserfallmodell: Eine Anforderung ist nur dann durchsetzbar, wenn sie testbar ist. Wie soll sonst überprüft werden können, ob sie wirklich umgesetzt worden ist? Deshalb sollte jede Anforderung von Anfang an mit einer Testidee oder einem Testfall hinterlegt werden. Dies hilft sicherzustellen, dass die Entwickler wissen, woran die Lösung gemessen werden wird. Die Methode ist in der Software-Entwicklung nicht neu: So werden im Test Driven Design und in der testbasierten Software-Entwicklung zuerst die Tests geschrieben und danach der Code bzw. das Design dazu entwickelt. In der Praxis zeigt sich, dass die verpflichtende Testbarkeit einer Anforderung wesentlich dazu beiträgt, eine stabile Basis für die Folgeaktivitäten wie Codierung und Testing zu schaffen. Dadurch nimmt die Anzahl der Änderungsanträge (Changes) merklich ab. Die Entwicklung kann die Planung besser einhalten und das Projektmanagement hat Zeit und Kosten besser im Griff. Auf der nächsten Seite: Effizient investieren, aber wo?

Dass sich ein gezieltes und sinnvoll eingesetztes Requirements Engineering lohnt, kann also nicht wegdiskutiert werden. Doch wo genau soll nun ins Requirements Engineering investiert werden? Welche Investitionen lohnen sich auch finanziell und auf längere Zeit? Sicher ist diese Frage individuell und je nach Gegebenheiten für jedes Unternehmen und Projekt verschieden zu beantworten. Trotzdem lässt sich auf Basis der aktuellen Trends und Benchmarks generell sagen, in welchen drei Bereichen sich Investitionen auf jeden Fall rechnen:

Gemäss T&B 2014 ist die – mehrheitlich zwischenmenschliche – Kommunikation immer noch Stolperstein Nr. 1 im Requirements Engineering. In mehr als 50 Prozent der Fälle sind Missverständnisse in der Kommunikation der Grund für mangelhafte Anforderungen. Der Requirements Engineer muss Stakeholder mit verschiedenen Interessen zusammenbringen, Workshops moderieren, Interviews führen, die Ergebnisse dem Management verkaufen und Konflikte zwischen Anforderungen auf­lösen können. Die Basis all dieser Aktivitäten ist eine professionelle und empathische Kommunikationsfähigkeit. Hier ist es also wichtig, dass die Mitarbeitenden, die mit dem Erheben von Anforderungen zu tun haben, entsprechende Soft Skills trainieren, zum Beispiel Moderation, Feedback geben oder Paraphrasieren. Die Kommunikation kann methodisch mit einfachen Mitteln unterstützt werden. Ein zentral verwaltetes und verpflichtendes Glossar hilft, Missinterpretationen einzelner Wörter und Begriffe zu reduzieren. Checklisten unterstützen die Requirements Engineers, in einem Workshop an wesentliche Elemente zu denken.

In mehr als der Hälfte aller IT-Projekte werden für das Erheben und Verwalten von Anforderungen immer noch Office-Programme eingesetzt. Die Anforderungen sind dabei mehrheitlich in natürlicher Sprache (Prosa) festgehalten. Auch wenn also kein eigentliches Requirements-Management-Werkzeug ein­gesetzt wird, lohnt es sich, die Anforderungen so genau und präzise wie möglich zu formulieren. Ein methodisches Vorgehen im Analysieren der Anforderungen kann die Qualität enorm beeinflussen. Zentrale Fragen lauten etwa: Sind alle Anforderungen atomar (nicht zerlegbar)? Sind sprachliche Ungenauigkeiten entdeckt und behoben? Dazu gehören zum Beispiel die sogenannten Universalquantoren wie «alle», «immer» und «jederzeit». Anforderungen wie «Alle Funktionalitäten sollen jedem Benutzer jederzeit zur Verfügung stehen», oder «Alles, was das System heute anbietet, soll auch in Zukunft möglich sein» müssen auf jeden Fall möglichst früh so umformuliert werden, dass sie testbar und realisierbar werden. Die in den Projekten gesammelten Erfahrungen können konsolidiert und in Checklisten festgehalten werden, damit sie späteren Projekten als Hilfe zur Selbsthilfe zur Verfügung gestellt werden können. Checklisten sind einfach in der Anwendung und trotzdem äusserst effektiv. Wer einen Schritt weiter gehen kann, ist gut damit beraten, auf erprobte und verbreitete Beschreibungssprachen wie UML und BPMN zu setzen. Die als Modell festgehaltenen Anfor­derungen sind dort präzise, eindeutig und verständlich – und zwar auch für Mitarbeitende mit einer fremden Muttersprache.

Bauchgefühl und präzises Requirements Engineering – passt das zusammen? Ja, und wie! Bevor irgendeine Methode oder ein anderer Indikator klar darauf hinweist, dass Anforderungen ungenügend präzise bzw. unvollständig sind oder das Projekt aus dem Ruder läuft, macht sich oft schon eine Vorahnung oder ein entsprechendes Bauchgefühl breit. Wir müssen wieder lernen, unserem Bauchgefühl mehr zu vertrauen und diesen intrinsischen Hinweisen nachzugehen. Sicher muss dann das eigene Bauchgefühl für andere fass- und sichtbar gemacht werden. Hier ist dann ein fundiertes Methodenwissen im Requirements Engineering und solides Fachwissen notwendig, um vom Bauchgefühl ausgehend die Problemen in den Anforderungen und im Lösungskonzept nachweislich sichtbar zu machen. Eine zielgerichtete Investition ins Requirements Engineering hilft also, die Projektkosten besser im Griff zu behalten, indem von Anfang an das Richtige gemacht wird und zwar richtig und rasch.

Software Development 2014: Wo steht die Schweiz? Der aktuelle Report «Trends & Benchmarks» deckt die Bereiche Requirements Engineering, Testing und Agil ab. Befragt wurden über 500 Personen und Organisationen. Die Auswertung erfolgte in Kooperation mit der Universität St. Gallen. Der Vergleich mit den Vorjahren zeigt Trends auf und dient als Basis für das kritische Hinterfragen eigener Investitionen. Zum Report: http://report.swissq.it