Requirements Engineering in der agilen Softwareentwicklung

Wenn man von Requirements Engineering spricht, dann meint man damit eine bestimmte Verfahrensweise innerhalb von Projekten. Mit diesem Beitrag möchte ich mich mit der Herausforderung beschäftigen, die entsteht wenn man Requirements Engineering und agile Methoden in der Softwareentwicklung zusammenbringt. Da dies ein sehr komplexes Thema ist und von vielen Seiten betrachtet werden muss, werde ich den Beitrag in mehrere Teile aufbrechen.

Zu Beginn die Grundlagen des Requirements Engineering:

Requirements, auch unter dem Begriff Anforderungen bekannt, definieren was ein System können muss und wie man dieses Ziel erreicht. Das Requirements Engineering ist eine disziplinierte und systematische Verfahrensweise, um Anforderungen zu ermitteln, zu dokumentieren, zu prüfen sowie zu analysieren und dann zu verwalten. Es ist die fachübergreifende Disziplin und beinhaltet den gesamten Prozess der Anforderungsanalyse sowie des Anforderungsmanagements.

Gerade die Analyse, d.h. das Identifizieren, Verstehen und Modellieren von Anforderungen ist zu Beginn eines jeden Projektes enorm wichtig und sichert bei guter Umsetzung den späteren Projekterfolg. Das Managen der Anforderungen stellt sicher, dass Requirements verfolgbar sind, überwacht werden können sowie in eventuellen Change- oder Risiko-Management-Situationen angepasst werden können.

Das Ziel des RE ist es, fehlende oder unklare Anforderungen zu finden und zu verbessern. Außerdem gilt es Anforderungen zu priorisieren, Konflikte aufzuspüren und dann auch zu lösen. Als Disziplin ist es die Aufgabe des RE eine zentrale Anforderungsverwaltung aufzubauen und zu unterhalten.

Viele Unternehmen müssen auf schmerzliche Art und Weise die Bedeutung des RE erkennen. Wenn nämlich Projekte an ungenügend aufbereiteten und definierten Spezifikationen scheitern oder Kosten zur Behebung der entstandenen Fehler entstehen. Diese sind häufig sehr hoch bzw. steigen exponentiell je weiter der Entwicklungsprozess bereits mit unentdeckten Fehlern fortgeschritten ist.

Nun könnte man meinen, dass die Erarbeitung von Requirements, d.h. die Analyse, mit ein paar kurzen Gesprächen erledigt ist und dass man die dadurch entstandenen Anforderungen dann leicht überwachen kann.

Weit gefehlt.

Denn innerhalb eines Projektes gibt es immer mehrere Stakeholder. Häufig werden nicht alle Beteiligten nach Ihren Bedürfnissen und Ideen gefragt, z.B. die operativen Bereiche, die für die Umsetzung verschiedener Prozessschritte zuständig sind. Zudem wird nicht nach wichtigen und unwichtigen Anforderungen unterschieden bzw. werden Veränderungen nicht berücksichtig. Denn eine Systemanforderungen, die zu Beginn des Projektes noch höchste Priorität hatte, kann im Laufe der Zeit durch andere Lösungsansätze an Bedeutung verlieren. Anforderungen verändern sich ständig. Man braucht eine Methode, um diese eindeutig und verständlich zu beschreiben. Und, man muss Anforderungen ganz klar von passenden Lösungen trennen, denn sonst vermischen sich Ergebnisse und weitere Entwicklungsschritte. Und das wiederum wird immer dann zum Problem, wenn verschiedene Beteiligte Anforderungen für selbstverständlich halten bzw. diese Requirements nicht explizit erwähnt werden, da man nur noch das Ziel im Auge hat.

In der Praxis aber, ist eine der größten Herausforderungen für Requirementsverantwortliche die Kommunikation. Denn Kommunikation braucht Zeit und Offenheit. Wer kennt das nicht? Es gibt eine Idee, ein Projekt, eine Aufgabe und alle wollen das es los geht. Möglichst schnell und fehlerfrei. Das Ziel immer vor Augen. Jede neue Software verspricht die Lösung zu einem Problem.

Als Requirementsverantwortlicher ist man häufig erst einmal die Bremse. Derjenige, der die Euphorie auf ein rationales Level bringen muss. Requirements-Ingenieure müssen mit viel Geduld und Sorgfalt Stakeholder befragen. Denn nur wenn die Details besprochen, verstanden und festgehalten wurden, können die entstandene Lösung und der Weg dorthin die richtigen sein. Die Stakeholder wiederum haben oft keine Zeit bzw. arbeiten unter Druck und müssen die Kosten im Auge behalten. Schnelle Lösungen sind hier gefragt.

Das Requirementsengineering hat die Aufgabe die Anliegen der Stakeholder herauszuarbeiten und dadurch Anforderungen zu erheben, zu sammeln und zu definieren sowie die unterschiedlichsten Informationsquellen zu konsolidieren. Erarbeitete Anforderungen müssen geprüft und priorisiert werden, sowie nicht stimmige Anforderungen oder Lücken ausgemacht und beseitigt werden. Es müssen Dokumente erzeugt und gepflegt werden und Prozesse im Sinne des Requirements Engineering optimiert werden. Dabei darf man nie das große Ganze aus den Augen verlieren und muss die Details herausarbeiten.

Keine einfache Aufgabe sondern ein komplexer Prozess.

Nimmt man diese Grundlagen und vergleicht sie mit den aktuell häufig diskutierten, empfohlenen und auch bereits praktizierten agilen Herangehensweisen innerhalb eines Softwareentwicklungsprojektes, dann wird schnell klar, dass es sich lohnt genauer hinzuschauen. Denn Agilität ist ein iterativer Prozess und kein linearer. Das bedeutet, man entwickelt von Phase zu Phase und der Prozess wird fortlaufend verbessert. Die Stakeholder haben konstant Einfluss im Projekt und die Anforderungen werden kontinuierlich erfasst.

Im agilen Projektmanagement werden Rollen, Prozesse und Projektpläne aus der klassischen Vorgehensweise komplett hinterfragt. Stattdessen wird Wert darauf gelegt, Stakeholder während des gesamten Projekts intensiv einzubeziehen und ihnen regelmäßig Ergebnisse zu liefern. Das bedeutet, Änderungen sind willkommen, weil sich nur so die besten Resultate liefern lassen. So die Aussage. Die Grundsätze der agilen Methode sind im 2001 veröffentlichten agilen Manifest festgehalten worden.

Im zweiten Teil meines Beitrages möchte ich auf die Herausforderungen eingehen, die sich für Requirements-Ingenieure dadurch ergeben.