Requirements Engineering in agilen Projekten einfach erklärt

Scrum als eine der bekanntesten agilen Methoden ist ein Framework, das sich bei der Entwicklung von komplexen Produkten bewährt hat. Eines der Hauptprinzipien «Inspect & Adapt» wird durch verschiedene Events und durch kurze Feedback-Zyklen gelebt.

Arbeitsergebnisse werden in regelmässigen Abständen inspiziert. Wenn nötig und sinnvoll, gibt es Anpassungen am Produkt oder am Arbeitsprozess. Beides wird kontinuierlich verbessert und entsprechend neuer Erkenntnisse oder geänderten Bedingungen angepasst.

Bei der erfolgreichen Entwicklung von immer komplexer werdenden Produkten spielen die Erhebung und Konsolidierung von Anforderungen jedoch auch weiterhin eine zentrale Rolle.

Wie genau passen nun agile Methoden und Requirements Engineering (RE) zusammen? Wo braucht es dort Requirements Engineering und wie genau sieht das aus?

Um diese Fragen zu beantworten, betrachten wir das Thema Requirements Engineering zunächst in klassischen Vorgehensmodellen, bevor wir in den agilen Kontext übergehen.

Requirements Engineering in klassischen Vorgehensmodellen

In klassischen Vorgehensmodellen ist der Entwicklungsprozess in genau definierte, zeitlich begrenzte Phasen aufgeteilt. Das Vorgehensmodell selbst gibt vor, in welcher Reihenfolge diese Phasen ablaufen, welche Aktivitäten sie beinhalten, und wer sie durchführt und verantwortet.

Requirements Engineering findet typischerweise am Anfang des Entwicklungsprozesses statt. Bereits vor Beginn der Implementierung werden die Anforderungen an das zu bauende System vollumfänglich ermittelt, abgestimmt und dokumentiert. Erst im Anschluss folgen weitere Phasen, wie Design des Systems, Implementierung und Test.

Das bedeutet, dass alle Anforderungen bereits bis ins Detail spezifiziert sind, bevor die Implementierung begonnen hat.

Lesen Sie auch: Warum sich Requirements Engineering lohnt

Requirements Engineering in agilen Projekten

In agilen Projekten wird hingegen zunächst ein Minimum Viable Product (MVP) gebaut. Ein MVP ist eine erste Version des geplanten Produkts mit dem minimalsten Funktionsumfang, um ein Kundenbedürfnis abzudecken. Weitere Anforderungen werden in darauffolgenden Iterationen ermittelt und anhand der zugeordneten Priorität umgesetzt. Somit kann man flexibel und schnell auf neue Kundenwünsche und geänderte Rahmenbedingungen reagieren.

Eine eigene Phase zur Analyse von Anforderungen ist im agilen Umfeld nicht vorgesehen.

Ein grobes Konzept kann zu Beginn eines agilen Projekts jedoch durchaus ratsam sein. Eine eigene Phase zur Analyse von Anforderungen ist im agilen Umfeld nicht vorgesehen.

Doch wo und wann genau finden die Hauptaktivitäten des Requirements Engineers in Form von Ermittlung, Dokumentation, Prüfung, Abstimmung und Verwaltung von Anforderungen statt?

1 Ermittlung von Anforderungen

Der Product Owner (PO) ist für die Ermittlung von Anforderungen zuständig. Er kommuniziert mit den relevanten Stakeholdern und erfasst deren Anforderungen. Diese werden meist als User Stories im Product Backlog hinterlegt. Das Ermitteln ist eine kontinuierliche Aktivität, die sich über den gesamten Entwicklungszeitraum des Produkts erstreckt.

In Refinement Meetings werden die User Stories mit dem Team besprochen, gegebenenfalls angepasst und weiter verfeinert. Ist eine User Story ausreichend hoch priorisiert und für den kommenden Sprint vorgesehen, stellt sie der PO im Sprint Planning Meeting dem gesamten Team vor. Hierbei können weitere Anforderungen identifiziert oder konkretisiert werden.

2 Dokumentation von Anforderungen

Mit dem Anlegen einer User Story im Product Backlog beginnt bereits die Dokumentation einer Anforderung. Ergänzt wird sie durch Akzeptanzkriterien.

Daneben gibt es übergreifende Akzeptanzkriterien, die für alle Anforderungen gelten und bspw. einen gewissen Qualitätsstandard des Teams darstellen. Diese werden in einer separaten, allgemein gültigen Definition of Done (DoD) des Teams hinterlegt.

Je nach Komplexität einer Anforderung kann es sich während eines Refinements oder Sprint Plannings herausstellen, dass zusätzlich eine strukturierte Dokumentation sinnvoll ist in Form von Kontext- oder Zustandsdiagrammen, Aktivitätsdiagrammen, Klassendiagramme, usw.

Das Product Backlog besteht aus Anforderungen auf hoher Abstraktionsebene in Form von User Stories. Sie werden erst verfeinert und weiter detailliert, wenn sie Kandidaten für die nächste Iteration sind.

Die Verantwortung für das Product Backlog liegt beim PO. Er kann jedoch von Business Analysten und Entwicklern aus dem interdisziplinären Team beim Erstellen und Verfeinern von User Stories unterstützt werden.

3 Prüfung und Abstimmung

Das Prüfen und Abstimmen von Anforderungen ist wichtig, um ein gemeinsames Verständnis zu erreichen. Im Zuge der Erstellung von User Stories findet bereits eine erste Abstimmung der ermittelten Anforderungen mit allen relevanten Stakeholdern statt.

Dasselbe wird mit dem Team in Refinements und Sprint Plannings gemacht, um ein gemeinsames Verständnis der Inhalte und die notwendige Klarheit für die Umsetzung der Anforderungen zu erreichen.

4 Verwaltung von Anforderungen

In einem agilen Projekt werden Anforderungen kontinuierlich erhoben und verfeinert. Das bedeutet, dass das Produkt Backlog sich ständig ändert. Um es auf dem aktuellen Stand zu halten, muss es ebenso kontinuierlich gepflegt und verwaltet werden.

Backlog Management ist die fortlaufende Aktivität, das Backlog zu pflegen
Für das Sprint Backlog gilt dasselbe, da es den tatsächlichen Stand der Arbeiten im Sprint widerspiegeln soll. Im Gegensatz zum Product Backlog liegt die Verantwortung für das Sprint Backlog jedoch beim Team.

Fazit

Requirements Engineering ist in agilen Umgebungen genauso wichtig wie in traditionellen Vorgehensmodellen. Da sich die Anforderungen im agilen Umfeld ständig ändern können, findet das Requirements Engineering iterativ und während des gesamten Entwicklungsprozesses statt.

Anstelle von schwerfälligen Anforderungsspezifikationen in verschiedenen Ausprägungen treten leichtgewichtigere Formen wie Backlogs, User Stories, Story Maps.

Agilität und Flexibilität sind somit keine gültigen Entschuldigungen für fehlendes Requirements Engineering oder einen unsystematischen Ad-hoc-Stil der Requirements Engineers.