Auf Erfolg getrimmt

Der Autor ist Business Unit Manager bei Logica Switzerland AG. Die Spezifikation von Anforderungen ist keine neue Erfindung. Auch in den klassischen Modellen zur Software-Entwicklung steht die Anforderungsanalyse am Anfang eines jeden Projekts. Warum wird dennoch neuerdings mehr Augenmerk auf das sogenannte Requirements Engineering gelenkt? Zwei Gründe führen dazu, dass sich Requirements Engineering mehr und mehr neben und ergänzend zur Business-Analyse als eigenständige Disziplin etabliert.

Zum einen entstehen die meisten IT-Projekte nicht mehr auf der grünen Wiese, sondern müssen sich in eine über Jahre gewachsene Infrastruktur integrieren lassen. Die daraus resultierende technische Komplexität zieht eine mindestens ebenso anspruchsvolle organisatorische nach sich, denn von einer Entwicklung sind zumeist mehrere andere System mit betroffen, die sich zum Teil während der Projektlaufzeit ebenfalls ändern, auf jeden Fall jedoch organisatorisch mit einbezogen werden müssen.

Der zweite Grund ist, dass in der Vergangenheit allzu häufig der Erfolg oder Misserfolg eines Software-Projekts erst gegen Ende, wenn nicht gar erst beim Akzeptanztest durch den Kunden festgestellt wurde. Agile und iterative Entwicklungsmethoden können dafür sorgen, dass Fehler früher entdeckt und mit höherer Frequenz korrigiert werden. Häufig zielen diese Prozesse in der Praxis aber nur auf die Entwicklung der Software aus den Anforderungen und vernachlässigen die kontinuierliche Verbesserung der Anforderungen selbst. Fehler in der Analyse und den Anforderungen gelten aber als Hauptursache für Fehlschläge in der Software- und Systementwicklung, das haben mehrere Studien ergeben. In Tests kann Qualität nur noch gemessen werden, generieren muss man diese dagegen fortlaufend.

Das Requirements Engineering sorgt für die erfolgreiche Durchführung von IT-Projekten. Es begleitet den gesamten Projektlebenszyklus und spart so von Beginn an und über die gesamte Projektlaufzeit Zeit und Kosten. Die wesentliche Aufgabe des Requirements Engineers ist es, die Anforderungen an ein System bei allen betroffenen Anspruchsgruppen zu erheben, die es zu Beginn eines Projekts erst noch zu identifizieren gilt. Dies geschieht beispielsweise durch Interview-, Beobachtungs- und Kreativtechniken. Der Requirements Engineer muss dafür auch über umfassendes Know-how zu den verschiedenen Techniken der Dokumentation verfügen – von der Formulierung in Prosa über Checklisten bis zur Modellierung mittels UML (Unified Modelling Language), wofür sich etwa Werkzeuge wie Enterprise Architect von SparxSystem bewährt haben. In einem nächsten Schritt sind die Anforderungen zu validieren, das heisst, es sind allfällige Widersprüche oder Spezifikationslücken aufzudecken und zu beseitigen. Als Ergebnis seiner Arbeit liefert der Requirements Engineer in klassischen Vorgehensmodellen die Systems Requirements Specification (ISO 15504) ab. In moderneren Umgebungen können es Use Cases, User Stories, Qualitäts­szenarien und dergleichen sein. Alle Prozess­modelle erwarten von den Anforderungen, dass sie selbst auch gewisse Qualitätskriterien erfüllen wie etwa Eindeutigkeit, Vollständigkeit, Machbarkeit, Prüfbarkeit und Notwendigkeit.

Es empfiehlt sich, die Requirements nach ihrer Wichtigkeit und dem Aufwand ihrer Umsetzung zu priorisieren, wobei diese Grössen nicht unabhängig voneinander sind. In der Praxis erlebt man häufig, dass Anforderungen, die sich als sehr aufwendig herausstellen, dann mitunter nicht mehr so wichtig sind wie zu Beginn. Für die Schätzung des Aufwands gibt es ebenfalls eine ganze Reihe von Methoden, die beherrscht werden wollen: etwa Delphi, Function Points oder Planning Poker. Ebenso wichtig wie alle bereits skizzierten Aufgaben des Requirements Engineers ist es letztendlich, die Anforderungen im Projektverlauf zu managen. Im Rahmen dessen müssen kontinuierlich der Status aller anforderungsbezogenen Aussagen und die wesent­lichen Abhängigkeiten zwischen diesen überwacht und aktuell gehalten werden. Diese komplexe Aufgabe ist alles andere als trivial angesichts des langen Lebenszyklus, die eine Anforderung vom mitunter recht unscharf formulierten Bedürfnis über ihr Design im System bis zu Implementierung, Test und Inbetriebnahme durchläuft.

Hinzu kommt, dass sich erfahrungsgemäss rund zwei bis fünf Prozent der Anforderungen pro Monat ändern. Insbesondere in der iterativen und agilen Software-Entwicklung, die Änderungen früh erkannt und aufgenommen haben will, ist das Management auf der Ebene der Requirements eine ausserordentliche He-rausforderung. Voraussetzung ist daher nicht zuletzt auch ein gewisses diplomatisches Geschick, da der Requirements Engineer im Laufe des Projekts häufig zwischen der Fachabteilung einerseits und dem Team aus Projekt- und Qualitäts­managern, Systemarchitekten und Entwicklern vermitteln muss.

Ein neues Berufsbild

Das Berufsbild Requirements Engineer ist bereits am Entstehen. In der Schweiz gibt es schon mehrere Anbieter von Ausbildungs- und Weiterbildungs-kursen, die mit einer Zertifizierungsprüfung durch die Swiss Association for Quality (SAQ) abgeschlossen werden. Die Qualitätsstandards in der Ausbildung zum Certified Professional for Requirements Engineering werden durch das International Requirements Engineering Board (IREB) kontrolliert.