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

Agile Toolbox
Produktentwicklung
Scrum
User Story
Simon Mau
January 19, 2023

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Warum macht ihr eigentlich kein SAFe?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Transformation

FRAGE: Was kostet eine agile Transformation?

Agile Management
Agile Organization
Agile Toolbox
Leadership
Agiles Lernen

FRAGE: Welche Rolle spielt Training?

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?

Agile Management
Agile Organization
Agile Tools
Agiles Management
Leadership

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Führung

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?

Agile Management
Agile Organization

FRAGE: Warum sollten wir mit borisgloger arbeiten?

Agile Management
Agile Organization
Agiles Management
Transformation

FRAGE: Wie viel kostet eine Beratung und ist es wirklich rentabel bei borisgloger?

Agile Prinzipien
Agile Toolbox
Projektmanagement

The Lie Behind the Parable of the Golf Balls and the Jar

Video
Change
Digitale Transformation
Hardware
Agile Organization

Agile in Industrial Automation: The Digital Transformation of Yokogawa

Versicherung
Neues Arbeiten
Führung
Agile Prinzipien
Kundenfokus

Kundenzentrierte Versicherung: Kann ein agiles Projekt die Organisation retten?

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

Agilität in den Vertrieb bringen – für Versicherer sinnvoll

Versicherung
Agile Prinzipien
Kundenfokus
Agile Toolbox
Produktentwicklung

BizDevOps in der Versicherungsbranche – Wie multidisziplinäre Teams wirklich besetzt sein sollten

Versicherung
Agile Prinzipien
Kundenfokus
Neues Arbeiten
Meetings

Undercover Agile für Versicherer: 5 agile Praktiken für Ihr klassisches IT-Projekt

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

IT-Projekte in der Versicherungsbranche – Das Rennen um die Time-to-Market

Team
Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills

Umgang mit Fehlern & Diversität – Erfolgreiche agile Teams #2

Team
Neues Arbeiten
Agile Toolbox
Produktentwicklung

Das Geheimrezept von High-Performance-Teams

Team
Arbeiten bei borisgloger consulting
Agile Prinzipien
Freiwilligkeit
Selbstorganisation

Konsent und offene Wahl: 2 Prinzipien aus der Soziokratie, die jedes agile Team gebrauchen kann

Team
Neues Arbeiten
Meetings
Social Skills

Der agile Adventkalender

Team
Agile Toolbox
Scrum
ScrumMaster-Praxistipps
Agile Prinzipien

Selbstorganisation der Teams fördern: Ask the team!

Team
Agile Toolbox
Design Thinking

Who Recognizes the Truly Good Ideas?

Team
Agile Organization
Transformation

Pizza Is Not Dead, and Neither Is Agility

Scrum4Schools
Neues Arbeiten
Führung
Life
Social Skills

Trauen wir unseren Kindern mehr zu – auch in der Schule!

Scrum4Schools
Change
Agiles Lernen
Neues Arbeiten
Remote Arbeiten

Eine Scrum4Schools-Projekt-Rückschau mit Physiklehrer Ivan Topic

Scrum4Schools
Mehr Formate
Interview
Nachhaltigkeit

Mit Scrum4Schools dem Weltraum auf der Spur

Scrum4Schools
Change
Agiles Lernen

Scrum4Schools - ein Projekt nimmt Fahrt auf

Scrum4Schools
Agile Schulentwicklung
Agile Toolbox

Technik im Alltag - Scrum4Schools zu Gast in Langenzersdorf

Projektmanagement
Agile Toolbox
Scrum
Scrum-Begriffe
ScrumMaster-Praxistipps

Sprechen Sie Agile? Den klassischen Projektplan in die agile Welt überführen

Projektmanagement
Agiles Management
Agile Toolbox
Scrum
Enterprise Scrum

Das Management in Scrum

Projektmanagement
Change
Digitale Transformation

Agilität in der Logistik oder: Liefern wie Amazon

Projektmanagement
Agile Toolbox
Scrum

Meilensteine und Scrum

Portfoliomanagement
Project management

Too many projects? Portfolio management simplified

Neues Arbeiten
Mehr Formate
Agile Toolbox
Scrum
Scrum Values

Wie agiles Arbeiten die Kommunikation aus der Selbstverständlichkeit holt

Neues Arbeiten
Change
Agiles Lernen
Mehr Formate
Audio

New Learning heute für das New Work von morgen – mit Angelika Weis

Neues Arbeiten
Change
Soziale Innovation

New Work Experience 2019 – ein Erfahrungsbericht

Neues Arbeiten
Audit
Change

Agil im Audit: das Starter-Kit

Neues Arbeiten
Agile Toolbox
Scrum
Scrum4Schools
Agile Prinzipien

Scrum4Schools: Lernen für die Zukunft

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Meetings
Retrospektive

Arbeiten wir uns gesund!

Neues Arbeiten
Agile Toolbox
Scrum
ScrumMaster-Praxistipps

Who should be in (agile) HR?

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Values

Glauben Sie an die Seele Ihrer Firma?

Neues Arbeiten
Agile Toolbox
Scrum
Product Owner
ScrumMaster-Praxistipps

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freiwilliges Teilen von Wissen – Erfolgreiche agile Teams #5

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Doing vs. Being Agile – Erfolgreiche agile Teams #1

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freude bei der Arbeit & Sustainable Pace – Erfolgreiche agile Teams #3

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Anpassungsfähigkeit & schonungslose Offenheit – Erfolgreiche agile Teams #4