Erfolgskritische Faktoren für das Requirements Engineering in agilen Projekten
Im Rahmen eines Requirements Engineering spielt der Business-Analyst eine zentrale Rolle. Er soll mit einer umfassenden Prozessanalyse und durch das Einführen eines transparenten Fortschritts-Trackings das Projekt zum Erfolg führen.
- Martin Hilgers
Schnell und flexibel agieren, den Überblick behalten und jederzeit fundierte Entscheidungen treffen können – das scheint kaum realisierbar zu sein. Im Rahmen eines Requirements Engineering spielt zur Bewältigung dieser Wünsche der Business-Analyst eine zentrale Rolle, der mit einer umfassenden Prozessanalyse und durch das Einführen eines transparenten Fortschritts-Trackings das Projekt zum Erfolg führen soll.
Die Bedeutung des Requirements Engineering für den Erfolg von Softwareentwicklungsprojekten ist unumstritten. Das gilt nicht nur für konventionelle Vorgehensweisen wie Wasserfall- oder V-Modell, sondern auch für agile Projekte. Egal für welches Vorgehensmodell man sich letztlich entscheidet, allen muss bekannt sein, was das Ziel der Entwicklung sein soll. Die Basis dafür, einen solchen Überblick zu gewähren, bildet eine Prozessanalyse, anhand derer sich die Anforderungen dokumentieren lassen, sodass sie für die Beteiligten klar verständlich und nachvollziehbar sind. Dadurch können Teams die Entscheidungen jederzeit gegenüber den Stakeholdern begründen. Es gibt zahlreiche zu berücksichtigende Faktoren, um etwa fundierte Aussagen über den Fortschritt und die Qualität der Spezifikation treffen zu können. Dazu zählt man vor allem ein übersichtliches Prozessdesign, das im Projektverlauf den Verantwortlichen als nützlicher Fahrplan dienen kann. Zudem bedarf es immer eines Fortschritts-Trackings für eine solide Planungssicherheit.
Die Brisanz des Requirements Engineering ist nicht neu, aber immer noch hochaktuell
Die drei größten Faktoren, die zu Abbruch oder Problemen in Softwareprojekten geführt haben:
- fehlender Anwender-Input
- unvollständige Requirements und Spezifikationen
- Änderungen an Requirements und Spezifikationen
(CHAOS Report, Standish, 1995)
Gleichzeitig ist die enge Zusammenarbeit mit dem Kunden sicherzustellen, damit sich jederzeit für ihn wichtige Punkte thematisieren und auf ihre Korrektheit prüfen lassen. Doch auch das Team rückt weiter in den Mittelpunkt. Um Anforderungen "agil" erheben zu können, sollte der Business-Analyst Teil des Entwicklerteams sein, da sich die Klärung offener Punkte auf persönlicher Ebene meist schneller und unproblematischer vornehmen lässt. Dadurch gewinnt er ein besseres Verständnis für die Bedürfnisse der Kollegen und kann von vornherein genauer auf umsetzungsspezifische Punkte eingehen.
Vom Vorgehensmodell unabhängige Faktoren
Gleichgültig, ob man ein konventionelles oder agiles Vorgehensmodell gewählt hat, gilt es immer, dass ein klares Prozessdesign die Basis eines Requirements-Engineering-Ansatzes darstellen sollte. Dennoch wird das aufgrund des zeitlichen Aufwands häufig nur unzureichend betrieben. Ein Fehler, der sich meist erst im späteren Verlauf des Projekts herausstellt: Denn soll man Anforderungen vollständig erheben, bedarf es immer des Gesamtüberblicks über die übergreifenden Abläufe. Es muss klar sein, was die relevanten Geschäftsfälle sind, die der Kunde berücksichtigt haben will, und wie diese miteinander verknüpft sind. Denn nur mit einem "Big Picture" lässt sich gewährleisten, dass sich das Projekt nicht zu schnell in Details verliert. Investiert man hingegen nur ungenügend Zeit in ein abstraktes Prozessmodell, gestaltet es sich erfahrungsgemäß umso schwieriger, mit steigender Systemkomplexität die entscheidenden Punkte im Fokus zu behalten.
Dementsprechend wäre zunächst eine klare Entscheidung zu fällen, was die generelle Intention des Projekts ist: Soll es Prozesse komplett neu aufnehmen oder bestehende "nur" erfassen oder marginal verbessern? Steht die Neudefinition, Erfassung oder die Optimierung von Prozessen im Mittelpunkt? Die Antwort auf diese Fragen ist entscheidend für den zu leistenden Projektaufwand.
Unabhängig davon sollten die Prozesse anhand einer Top-down-Modellierung erfasst werden: Die Vorgehensweise vom Abstrakten zum Konkreten gewährleistet, dass man alle wichtigen und übergreifenden Anforderungen erhebt, die nötige fachliche Tiefe auf Seiten des Projektteams entwickelt wird und es im Nachhinein nicht zu unerwünschten Überraschungen kommt.
Zudem bewegt man sich ohne High-Level-Sicht nur selten auf Augenhöhe mit dem Fachbereich. Das genau aber ist entscheidend: Es sollte jederzeit möglich sein, umfassend darüber Auskunft geben zu können, wo sich das Projekt im übergeordneten Prozess gerade befindet und weshalb es einen Aspekt überhaupt als relevant erachtet. Ansonsten ist eine kompetente Auseinandersetzung mit dem Fachbereich nur schwer zu realisieren. Konsequentes Prozessdesign stellt daher sicher, dass das erforderliche Verständnis zum Projekt besteht und alle relevanten Punkte Beachtung finden. Die Prozessmodellierung sollte sich auf die Erkenntnisse aus Workshops mit den jeweiligen Fachbereichen sowie auf eine weitreichende Analyse der Systemlandschaft stützen. Der initiale Aufwand für die konsequente Prozessanalyse lohnt sich immer, denn neben dem generellen Wissen über das Projekt stellt der menschliche Aspekt eine weitere, nicht zu unterschätzende Komponente dar.
Erst die detaillierte Auseinandersetzung mit den Fachbereichen und die genaue Dokumentation der Anforderungen demonstrieren den Mitarbeitern, dass man ihr Anliegen versteht und berücksichtigt. Insbesondere eine End-to-end-Prozessanalyse hilft, also die Beschreibung von fachbereichsübergreifenden Prozessen. Somit sensibilisiert man die Wissensträger aus den Fachbereichen für die Belange der jeweils anderen. Folglich entwickeln alle Beteiligten ein besseres Verständnis für die Ausgangssituation und rücken von ihrer teilweise zu punktuellen Betrachtung ab.
Durch die End-to-end-Betrachtung vermeidet man unnötige und vor allem aufwendige Nachbesserungen aufgrund widersprüchlicher Anforderungen unterschiedlicher fachlicher Bereiche. Deshalb ist im Rahmen der Prozessanalyse auf einem hohen Abstraktionslevel zu hinterfragen, welche Rolle die Datenflüsse innerhalb des Softwaresystems spielen: Welche Informationen sind an welcher Stelle notwendig? Woher kommen sie und wo lassen sie sich wiederverwenden? Nur mit der End-to-end-Betrachtung lassen sich Abhängigkeiten von Prozessen identifizieren, Schnittstellen einwandfrei entwerfen und letztlich ein umfassendes Gesamtbild entwickeln, das eventuellen Zusatzaufwand von vornherein eindämmt.
Erfahrungsgemäß bietet es sich an, beispielsweise auf BPMN-Basis (Business Process Modeling Notation) ein grafisches Tool zur abstrakten Darstellung der Prozesse zu verwenden. Damit können sämtliche Beteiligte, insbesondere auch die bei der Analyse nicht direkt involvierten Stakeholder, den Projektüberblick behalten und sämtliche Schritte nachvollziehen. Wichtig ist, auf eine Kombination aus Grafiken und Prosa zu setzen, die die Prozesse sowohl darstellen als auch kurz beschreiben. Erst dann lässt sich ein wirkliches "Big Picture" zum Projekt und den damit verbundenen Anforderungen entwerfen.
