Erfolgskritische Faktoren für das Requirements Engineering in agilen Projekten

Inhaltsverzeichnis

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.

Mehr Infos

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.

Spezifische Faktoren

Spezifische Faktoren in agilen Projekten

Um den Fertigstellungsgrad der Anforderungserhebung bei agilen Projekten messen zu können, empfiehlt sich ein auf Checklisten basierendes und fragenorientiertes Fortschritts-Tracking. Hierbei hilft eine einfache Vorgehensweise: Zunächst sollte man einen Katalog mit generellen, immer wiederkehrenden Aufgaben und Fragen erstellen, der einen groben Überblick über den Aufwand gibt. Das sind beispielsweise Aktivitätsdiagramme und Fehlerlisten, die jedes Requirements-Projekt benötigt. Während der Beschäftigung mit den Punkten kommen immer konkretere Fragen ("Open Issues") auf, die sich dokumentieren und später abarbeiten lassen. Der Vorgang lässt sich analog zum Bug-Tracking in der Softwareentwicklung verstehen, das anstelle einer Fehlerübersicht die Open Issues in den Fokus rückt.

Der Überblick gewährleistet in agilen Vorgehensweisen, etwa bei Scrum, eine wertvolle Planungssicherheit, indem der Product Owner die offenen Punkte nach ihrer Relevanz ordnet und sie sich entsprechend abarbeiten lassen. Beispielsweise lässt sich feststellen, zu welchem Zeitpunkt ein Punkt wirklich relevant wird und bearbeitet werden sollte, nämlich erst kurz bevor sich das Entwicklungsteam damit befasst. Konkret bedeutet das, dass die eigentliche Klärung einer offenen Frage erst wenige Sprints vorher notwendig wird, weil die Entwickler erfahrungsgemäß weitere Punkte identifizieren, die es zu berücksichtigen gilt. Damit entgeht man der Gefahr, sich abermals mit ein und derselben Aufgabe zu befassen.

Die technische Umsetzung und Darstellung des "Open-Issue-Trackings" kann beispielsweise über das Tool JIRA erfolgen, das nicht nur die offenen Punkte, sondern auch den Bearbeitungsstatus einfach abbildet. Dadurch herrscht während des Projekts jederzeit Transparenz darüber, wie weit das Requirements Engineering fortgeschritten ist.

Bei agilen Vorgehensweisen steht zudem die verstärkte Zusammenarbeit zwischen Entwickler und Kunde im Mittelpunkt, um möglichst schnell eine funktionierende Software entwickeln zu können. Statt einen strengen, zu Projektbeginn detailliert ausgearbeiteten Plan zu verfolgen, setzt man auf Flexibilität und den engen Dialog mit den Stakeholdern. Änderungen im Projektverlauf sind erwünscht, da man sich dadurch Software verspricht, die genau den Kundenwünschen entspricht.

Mehr noch als in konventionellen Vorgehensweisen muss der Business-Analyst in agilen Projekten die Nähe zum Kunden und die direkte Kommunikation suchen. Denn zum Projektstart verfügt er nur selten über Expertenwissen, wie es etwa in den Fachbereichen vorhanden ist. Ohne das kann der Analyst nur schwer einschätzen, was die wirklich wichtigen Aspekte sind. Genau über das Wissen sollte er verfügen, wenn er schnell und flexibel Entscheidungen treffen möchte. Will der Business-Analyst herausfinden, über welche Funktionen die Software zukünftig verfügen sollte, muss er sich an den jeweiligen Fachbereich wenden und diese mit ihm diskutieren. Erst dann kann er ein objektives Bild über die Prioritäten entwerfen. Daher sollte der Analyst anhand einer Checkliste konkrete Fragen, etwa nach der Häufigkeit der Nutzung, dem Datendurchsatz und dem Geschäftswert der Funktionen stellen.

Durch den engen Dialog mit dem Kunden kann er priorisieren und ein Gefühl für dessen Problemstellungen und Arbeitsweise entwickeln – eine zentrale Voraussetzung für den Erfolg agiler Projekte. Denn im weiteren Projektverlauf ist der Business-Analyst auch in die Entwicklung mit eingebunden und kann sein erworbenes Wissen dort einbringen, indem er als Schnittstelle zu den Fachbereichen agiert. Er gleicht die Wünsche des Kunden permanent mit der zuvor entworfenen Prozesslandschaft ab, instruiert das Entwicklerteam und stellt sicher, dass jederzeit der Fokus auf aktuell wichtigen Aspekten liegt.

In einem flexiblen Projekt sollte nicht nur der Business-Analyst einen umfassenden Überblick über den Stand der Arbeit behalten können, sondern jeder der Beteiligten. Seitenlange Dokumente sind hierfür jedoch kaum dienlich, da sie meist zu umfangreich und komplex erscheinen. Stattdessen sollte sich das Projektteam auf ein Set einfacher Dokumentationskonzepte einigen, die eine leicht zu verstehende Grundlage für die Aufzeichnung der Anforderungen darstellen. Die Erfahrung zeigt, dass selbst bei Großprojekten nur wenige Notationselemente ausreichen, um Prozesse oder Datenflüsse grafisch und für alle verständlich abzubilden. Die überschaubare Anzahl verwendeter Elemente stellt sicher, dass auch Personen mit nichttechnischem Hintergrund in der Lage sind, die Korrektheit der Anforderungen nachzuvollziehen.

Komplexe Systeme lassen sich jedoch meist nicht in allen Belangen durch eine einheitliche Beschreibung darstellen. In diesen Fällen sollte man pragmatisch agieren und gegebenenfalls mit der vereinbarten Notation brechen. Es sind jedoch die folgenden Punkte zu beachten:

1. Die Ausnahmen müssen deutlich als solche gekennzeichnet werden.
2. Es ist nur in Ausnahmefällen von der vereinbarten Notation abzuweichen. Werden diese zur Regel, sollte man die bisher gesetzten Standards überdenken.

Denn schließlich zählt, dass die Fachbereichsmitglieder und später auch die Entwickler und Tester die Darstellung verstehen, um den jeweiligen Schritt auf seine Korrektheit hin prüfen zu können. Erst dann lässt sich das zentrale Anliegen agiler Methoden erfüllen, dem Kunden zeitnah eine funktionierende Software zu liefern, die wirklich seinen Wünschen entspricht.

Ein weiteres Erfolgskriterium für das Gelingen agiler Projekte ist die nahtlose Integration des Business-Analysten in das Team, damit man schnell und einfach offene Punkte klären kann. Er sollte daher allen Beteiligten persönlich bekannt und idealerweise Teil des Entwicklungsteams sein. Dadurch lassen sich Hemmschwellen auf menschlicher Ebene von vornherein minimieren. Kennen die Entwickler ihren Ansprechpartner, kommen offene Punkte schneller als üblich zur Diskussion und lassen sich umgehend über das "Open-Issue-Tracking" aufnehmen und klären. Das stellt sicher, dass die Entwickler stets auf dem neuesten Stand sind, die wichtigsten Punkte verstehen und sich auf diese konzentrieren können.

Parallel erhält der Business-Analyst Rückmeldung über technische Schwierigkeiten und kann diese in seiner Planung berücksichtigen. Denn auch der Punkt ist – trotz aller Konzentration auf die Kundenwünsche – nicht zu vernachlässigen: die Bedürfnisse der Entwickler. Das ist insbesondere wichtig, wenn man in einem System kundenspezifische Anpassungen vornimmt und technische Einschränkungen zu beachten sind.

Die Integration des Business-Analysten in das Team hat zur Folge, dass er enger in die Realisierung und damit in den Teamerfolg eingebunden wird. Folglich kann und wird er viel stärker auf umsetzungsspezifische Punkte eingehen und die auf Kundenseite eher zur Sprache bringen. Mit dem Vorgehen ist letztlich allen Beteiligten gedient, da jeder das Ziel verfolgt, so schnell wie möglich eine funktionierende und den Anforderungen des Kunden entsprechende Software auf den Weg zu bringen.

Fazit

Fazit

Unabhängig von der gewählten Vorgehensweise ist das Requirements Engineering von zentraler Bedeutung für den Erfolg der Softwareentwicklung. Im Gegensatz zu konventionellen Methoden liegt der Fokus in agilen Projekten jedoch stärker auf einer schnellen und flexibleren Umsetzung. Dementsprechend bedarf es einer vergleichsweise engen Zusammenarbeit mit dem Kunden und schlanken Prozessen zur Entscheidungsfindung, bei der die Beteiligten im ständigen Dialog wichtige Aspekte identifizieren, diskutieren und auf ihre Korrektheit prüfen.

Insbesondere bei einer agilen Vorgehensweise müssen alle Beteiligten einen umfassenden Überblick über das Gesamtprojekt besitzen, um Notwendigkeiten und Schwierigkeiten besser einschätzen und berücksichtigen zu können. Andernfalls läuft man Gefahr, sich in Details zu verlieren, falsche Prioritäten zu setzen und schließlich wertvolle Zeit zu verschenken. Deshalb sollte der Business-Analyst nicht nur nahe am Kunden, sondern auch nahe am Entwicklerteam arbeiten, um dessen Feedback direkt in seine Arbeit und somit in die Projektplanung mit einfließen zu lassen. Den für die Planung nötigen Überblick muss er sich zu Projektbeginn durch eine umfassende Prozessanalyse erarbeiten und im weiteren Verlauf durch transparentes Fortschritts-Tracking sichern. Nur so kann er in agilen Projekten schnelle und fundierte Entscheidungen treffen, die alle umgehend umsetzen und damit zum gewünschten Erfolg führen können.

Martin Hilgers
ist IT-Berater bei MaibornWolff et al und wird seit mehreren Jahren mit der Entwicklung und Leitung von Softwareentwicklungsprojekten betraut. Sein derzeitiger Schwerpunkt liegt im Bereich des Requirements Engineerings.

Literatur

1. Karl E. Wiegers; Software Requirements; Microsoft Press, 2003 (2. Aufl.)
2. Suzanne Robertson, James Robertson; Mastering the Requirements Process; Addison-Wesley Longman, 2006 (2. Aufl.)
3. Mike Cohn; Succeeding with Agile: Software Development Using Scrum; Addison-Wesley Longman, 2009
4. Bernd Oestereich; Gedanken über agiles Requirements Engineering, Blog-Eintrag auf heise Developer
5. Chris Rupp, Rainer Joppich; Dokumentenberge oder Bierdeckel – Requirements Engineering in Zeiten der Agilität; Artikel auf heise Developer
   

(ane)