Requirements Engineering in der agilen Produktentwicklung

In den letzten Jahren habe ich mich intensiv mit dem Thema Anforderungsmanagement beschäftigt. Dabei habe ich Softwaretools wie DOORS (Next), Enterprise Architect, Polarion, objectiF oder Windchill RV&S ausprobiert und verglichen, die aus der Automobil- und Luftfahrtindustrie nicht mehr wegzudenken sind. Auch in Methodiken wie SPICE und in klassischen Vorgehensmodellen, wie dem Wasserfall- oder V-Modell, ist das Requirements Engineering ein fester Bestandteil. Denn ohne vorher genau zu definieren, was geschaffen werden soll, kann der lineare Ansatz nicht verfolgt werden. Das Requirements Engineering ist hier ein befristeter erster Abschnitt in der Systementwicklung. 

Um dieser Linearität folgen zu können, müssten aber einige Voraussetzungen erfüllt sein: 

• Die ausführenden Personen brauchen viel Erfahrung in der zu entwickelnden Technologie.
• Sie sollten wissen, wie der User das Produkt anwenden wird.
• Es sollte entsprechendes Know-how zum Anforderungsmanagement und der Erhebung von Anforderungen  selbst vorhanden sein.

Leider sind diese Voraussetzungen meistens nicht gegeben, denn die Rahmenbedingungen eines Projekts ändern sich schnell. Bereits kurz nach dem Design Freeze hat der Kunde erste Änderungswünsche, eine Technologie steht nicht mehr zur Verfügung, die vorher erdachte Funktionalität kann nicht wie geplant umgesetzt werden bzw. es besteht keine Notwendigkeit, diese weiterhin zu integrieren. Genauso kann sich eine neue Funktionalität ergeben, die vorher nicht angedacht war. 

Eines der Prinzipien des agilen Manifestes lautet: 

„Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.” 

Mir stellt sich da die Frage: Wie passt die agile Welt mit dem klassischen, linearen Entwicklungssystem zusammen, das größtenteils im Maschinenbau, dem Automobil- und der Flugzeugindustrie zu finden ist? 

Agilität und Requirements Engineering: ein Widerspruch?

Nach genauerer Betrachtung kann ich eines vorab sagen: Es gibt es keinen Widerspruch. Tatsächlich gibt es sogar viele Synergien, die gut genutzt werden können und sich ergänzen. Welche sind aus meiner Sicht die wichtigsten? 

1.  Product Backlog Items haben viel mit Requirements in einem Lastenheft gemein

Im Lastenheft sind die Funktionalitäten bzw. Requirements eines zu entwickelnden Produktes definiert. Zulieferern werden die Lastenhefte häufig einfach übergeben und sollen umgesetzt werden. Wenn darin alle Anforderungen beschrieben sind, liegt es nahe, sie einfach in das Backlog zu importieren und Stück für Stück abzuarbeiten. Doch das kann zu einem unübersichtlichen Chaos führen, wie ich in einigen Projekten leider erleben musste. Diese scheinbar naheliegende Vorgehensweise half nicht, sondern führte zu mehr Verwirrung, da die Reihenfolge, Priorisierung und der Funktionsumfang entscheidend sind. 

Das bedeutet für die Praxis: Funktionalitäten sollten im Laufe der Entwicklung nach Priorität geordnet in das Backlog übernommen werden. Dabei müssen sie so granular strukturiert werden, dass sie innerhalb eines Sprints umgesetzt werden können.  Das ist zum Teil eine sehr komplexe Angelegenheit, denn am Ende eines Sprints soll ein konkretes Produkt geliefert werden können. Es ist aber möglich, wenn Schnittstellen gezielt definiert werden und kleine Inkremente – zum Beispiel einer Teilfunktion oder ein Versuchsaufbau – geschaffen werden. Durch ein strukturiertes Lastenheft kann die Priorisierung festgelegt und gezielt auf mögliche Engpässe reagiert werden.

•  Aus groben Funktionalitäten und Anforderungen werden konkrete User Stories

Obwohl es verlangt wird, werden Anforderungen oftmals nicht hinreichend beschrieben. In einem linearen Entwicklungsprozess kann schlicht auch noch nicht alles definiert werden. Während der Entwicklung führt das zu Schwierigkeiten, da eine Anpassung eine Welle von Prozessen im Änderungsmanagement auslöst. Zusätzlich wird das Produkt oft erst am Ende dem Kunden zur Validierung übergeben oder es wird nur an den Meilensteinen validiert. Den agilen Prinzipien gemäß müssen durchaus auch Rahmenparameter (Constraints) gesetzt werden. Es ist aber gewünscht, dass im Laufe der Entwicklung die Lösungen gemeinsam mit dem Kunden geschärft und angepasst werden. 

Das bedeutet für die Praxis: Es ist nicht notwendig, in der Konzeptphase alles zu definieren. Vielmehr wird gemeinsam justiert, um das ideale Ergebnis zu erzielen. Im besten Fall haben die Anwender:innen nach jedem Entwicklungszyklus die Chance, das Produkt zu erproben und Feedback zu geben, um so früh wie möglich eingreifen zu können und unnötige Entwicklungen zu vermeiden. Im Lastenheft sind weiterhin die Funktionalitäten beschrieben, die Detaillierung findet aber in Rückkopplung mit dem Backlog im Laufe der Entwicklung statt. 

Technisch gesehen ist dies einfach umzusetzen, denn die heutigen Tools (siehe oben) haben offene Schnittstellen. Das heißt: Lastenhefte können exportiert werden und als Backlog Items (partiell) importiert werden, zum Beispiel in Azure DevOps oder umgekehrt durch eine RequIF-Schnittstelle. Dadurch erhöht sich die Granularität des Lastenheftes mit jedem Schritt der Entwicklung. 

In der agilen Produktentwicklung ist es also zum einen notwendig, den Scope der Anforderungen in einem Requirements Tooling nachvollziehen zu können. Zum anderen wird eine Planung der konkreten Umsetzung in agiler Methodik gebraucht, die beispielweise durch ein Tickettrackingsystem wie Azure DevOps oder JIRA unterstützt wird. Dabei können je nach Granularität 1:n-Beziehungen zwischen Requirement und User Story entstehen (siehe Abbildung).

Leider hält sich das Gerücht, dass ein Lastenheft einfach als Backlog importiert werden kann und dann in Sprints abgearbeitet wird. Wie beschrieben, ist dies aber gar nicht gewünscht. Doch woher kommt diese Annahme? In der Tat gibt es zwischen Requirements und User Stories viele Gemeinsamkeiten, die das Zusammenspiel erleichtern, aber es gibt auch einige deutliche Unterschiede. 

In der Fachliteratur werden Requirements häufig als lösungsfrei, abgestimmt, eindeutig beschrieben sowie verständlich, gültig, realisier- und prüfbar definiert (Quelle: Basiswissen Requirements Engineering, 3. Auflage, S. 54 f.). Eine andere Variante ist die Erfassung in Form von Use Cases für eine bessere funktionale Darstellung. Mit Hilfe von Akteuren und Funktionalitäten wird der Kontext beschrieben.

User Stories sind ebenfalls lösungsfrei und haben klare Akzeptanzkriterien und Rahmenparameter, die bei der Umsetzung helfen. Erst durch die Definition von Action Items werden im Sprint Planning 2 konkrete Maßnahmen erarbeitet, wie die User Story umgesetzt werden kann. Was bei bei Use Cases und Requirements jedoch häufig fehlt, ist die Beschreibung des Nutzens – genau das ist der wohl größte Unterschied zu User Stories. Denn der Product Owner priorisiert sein Backlog nach dem Nutzen. Im Vergleich zu einer User Story stammen die Requirements meistens nicht vom entwickelnden Team, sondern vom Stakeholder oder dem technischen System. 

Das bedeutet für die Praxis: Es gibt also einige Synergien zwischen Requirements bzw. Use Cases und User Stories, die eine Integration einfach möglich machen. Es bedarf aber trotzdem eines gewissen Fingerspitzengefühls in der Umsetzung. So kann bei der Erstellung eines Lastenheftes schon auf die Funktionalität und den Grund geachtet werden. Im Umkehrschluss kann in der Verifizierung der User Story schon die Verifikationsmethodik beachtet werden, welche die Integration in das Requirementstooling erleichtert. 

•  Funktionierende Prototypen vor detaillierten Anforderungen  

In der Hardwareentwicklung durfte ich am Beispiel eines Schalters erleben, wie ein funktionaler Prototyp dem Kunden half, obwohl dieser noch nicht fertig entwickelt war. Der Kunde hatte klare Vorstellungen von der Helligkeit und Lichtfarbe der Hintergrundbeleuchtung, weil diese zu bestimmten Referenzprodukten passen musste. Durch einen variablen Prototyp war es möglich, das LED zu dimmen und in der Farbtemperatur zu steuern. Zusätzlich konnten aber auch die Diffusionslinsen gewechselt werden, was eine einheitliche Lichtstreuung gewährleistete und bei Bedarf angepasst werden konnte. Der Schalter an sich war noch nicht final entwickelt. Für die Validierung der Anforderung gemeinsam mit dem Kunden war das aber nicht entscheidend. 

Das bedeutet für die Praxis: Durch gezielte Schwerpunkte in der Wahl der Anforderungen kann frühzeitig auf die gewichtigsten Bedürfnisse des Kunden eingegangen werden. Zusätzlich wird es dadurch möglich, den Fortschritt der Entwicklung an konkreten Funktionen eines Inkrements zu messen statt auf Basis von Analysen und Dokumenten – ganz gemäß der agilen Sichtweise. 

Requirements und Use Cases sind in der physischen Produktentwicklung im agilen Kontext eng miteinander verbunden. Ich habe erlebt, wie in der Entwicklung der Fortschritt frühzeitig messbar gemacht werden kann, wenn die Gemeinsamkeiten und Unterschiede zwischen Requirements und User Stories entsprechend berücksichtigt werden. Wenn die Kunden in den Entwicklungsprozess integriert wurden, waren am Ende der Entwicklung weniger Anpassungen nötig, auch wenn sich die Anforderungen zwischendurch verändert hatten. Beide Methodiken, sowohl Requirements als auch User Stories, helfen dabei, in der Entwicklung effizient zu sein und den Entwicklungsstatus gegenüber dem Kunden zu reflektieren. Die Voraussetzung ist aber, die genannten Punkte zu beachten, um die beiden Methoden erfolgreich miteinander zu verbinden.

Wie seht ihr die aufgezeigte Verbindung? Welche Erfahrungen habt ihr damit in der agilen Entwicklung gemacht?

Bildquelle:  Martin Adams auf Unsplash