Agilität ist weiterhin in aller Munde und viele Unternehmen bedienen sich agiler Frameworks und Best Practices zur Entwicklung ihrer Software – Tendenz steigend. Während für das Requirements Engineering (RE) in klassischen Vorgehensmodellen wie dem V-Modell oder RUP (Rational Unified Process) ein klarer Platz innerhalb des Entwicklungsprozesses vorgesehen ist, ist die Rolle des RE im agilen Umfeld nicht gleich auf den ersten Blick ersichtlich.

Requirements Engineering in klassischen Vorgehensmodellen

Das wesentliche Merkmal klassischer Vorgehensmodelle in der Software-Entwicklung ist die Aufteilung des Entwicklungsprozesses in genau definierte, zeitlich begrenzte Phasen. Das Vorgehensmodell gibt vor, in welcher Reihenfolge welche Aktivität stattfindet und wer diese Aktivität durchführt und verantwortet. Die Anforderungsanalyse findet ihren Platz typischerweise am Anfang des Prozesses. Das heißt, schon vor Beginn der eigentlichen Implementierung werden die Anforderungen an das System vollumfänglich ermittelt, abgestimmt und dokumentiert. Erst mit dem Abschluss dieser Phase folgen danach die weiteren Phasen wie Systemdesign, Implementierung und Test.

Requirements Engineering im agilen Umfeld

Im agilen Umfeld wird meistens zunächst ein sogenanntes MVP (Minimal Viable Product) entwickelt und veröffentlicht. Ein MVP ist das Produkt mit dem minimalst notwendigen Funktionsumfang, welches entwickelt werden muss, um einen Kundenbedarf zu decken. Weitere Anforderungen des Kunden an das Produkt werden danach in weiteren Iterationen nach und nach ermittelt und je nach Priorität umgesetzt. Somit wird es ermöglicht flexibel und schnell auf Kundenwünsche oder geänderte Randbedingungen zu reagieren.

Obwohl es in der Praxis gerade bei komplexen Projekten ratsam sein kann, bereits vor dem ersten Inkrement ein Grobkonzept des Projektes zu erstellen, um einen groben Überblick über die Anforderungen zu erhalten, ist eine eigene Phase zur Anforderungsanalyse zu Beginn des Projekts im agilen Umfeld nicht vorgesehen. Doch wo finden die Hauptaktivitäten des Requirements Engineerings Ermittlung, Dokumentation, Prüfung & Abstimmung und Verwaltung statt, wenn es im Gegensatz zu klassischen Vorgehensmodellen keine klar definierte Phase dafür gibt?

Deutlich wird dies anhand des Beispiels Scrum:

Ermittlung der Anforderungen

Die Ermittlung der Anforderungen erfolgt durch den Product Owner (PO). Dieser kommuniziert mit den relevanten Stakeholdern und erfasst deren Anforderungen meist als User Stories im Product Backlog. Diese Aktivität findet bei Bedarf kontinuierlich über den gesamten Produktentwicklungszeitraum statt. Im Zuge des Refinements werden diese Stories mit dem Team besprochen und bei Bedarf angepasst und weiter konkretisiert. Ist die Story ausreichend hoch priorisiert und für den kommenden Sprint vorgesehen, präsentiert der PO diese dem Entwicklungsteam im Sprint Planning Meeting. Auch hier können weitere Anforderungen identifiziert oder konkretisiert werden.

Doch nicht nur vor einer Iteration kann eine Anforderungsermittlung stattfinden. Ein wesentlicher Vorteil von Scrum sind die schnellen Feedback-Schleifen. Um die Anforderungen der Stakeholder zu validieren, präsentiert das Team diesen daher im Sprint Review die Arbeitsergebnisse des vergangenen Sprints. Hier können die Teilnehmer fehlende Anforderungen oder neue Erkenntnisse äußern, welche dann gegebenenfalls ebenfalls Änderungen auf das Product Backlog haben können.

Dokumentation der Anforderungen

Eine erste Dokumentation der Anforderungen stellt bereits das Anlegen einer User Story im Product Backlog und die Ergänzung der zugehörigen Akzeptanzkriterien dar. Außerdem kann es zum besseren Verständnis im Zuge des Refinements oder des Sprint Plannings sinnvoll sein, eine strukturierte Dokumentation wie beispielsweise Kontextdiagramme, Aktivitätsdiagramme, Klassendiagramme oder andere UML Diagramme anzufertigen.

Oftmals ist es aufgrund gesetzlicher Anforderungen notwendig eine detaillierte Dokumentation des Systems anzufertigen. Dafür empfiehlt es sich während des Sprints die umgesetzten Features in der Dokumentation des Systems zu ergänzen.

Übergreifende nicht-funktionale Anforderungen können in der Defintion of Done festgehalten werden. Somit muss jede User Story für deren Fertigstellung die definierten nicht-funktionalen Anforderungen erfüllen.

Abstimmung und Prüfung der Anforderungen

Das Abstimmen und das Prüfen der Anforderungen sind essenziell, um ein gemeinsames Verständnis über die Anforderungen zu erlangen. Eine erste Abstimmung der erhobenen Anforderungen mit allen relevanten Stakeholdern findet im Zuge der Erstellung der User Stories für das Product Backlog statt. Darüber hinaus muss im Refinement eine Prüfung mit den Mitgliedern des Entwicklungsteams erfolgen, sodass diese die Inhalte verstanden haben und die notwendige Klarheit für die Umsetzung der Anforderungen herrscht.

Verwaltung der Anforderungen

Da Anforderungen kontinuierlich erhoben werden, ist das Product Backlog einer ständigen Veränderung unterworfen. Die Liste muss kontinuierlich verwaltet und priorisiert werden, um somit das Backlog stets aktuell zu halten. Dies gilt auch für das Sprint Backlog, welches nach der Erledigung von Aufgaben und Stories aktuell gehalten werden muss, um den tatsächlichen Bearbeitungsstand abzubilden.

Fazit

Das Ziel der Analysephase im klassischen Umfeld ist es, ein vollständiges Spezifikationsdokument zu erstellen (z. B. Lastenheft), welches im weiteren Verlauf des Entwicklungsprozesses stabil bleibt.

Die Anforderungen im agilen Umfeld hingegen können sich ständig ändern und müssen erst dann vollständig sein, wenn deren Umsetzung unmittelbar bevorsteht. Das Requirements Engineering findet daher iterativ, während des gesamten Entwicklungsprozesses statt.