IREB RE@Agile Primer

• Das RE beschäftigt sich mit der systematischen Ermittlung und Dokumentation von Anforderungen als eigenständigen Artefakten, während bei agilen Entwicklungsprozessen die funktionierende Software im Vordergrund steht und nicht eine umfassende Dokumentation; auch werden Personen und Kommunikation höher bewertet als Prozesse und Werkzeuge.
• Ein wichtiger Unterschied zwischen der Anwendung von RE in agilen Entwicklungsprozessen und anderen Entwicklungsmethoden ist die zeitliche Abstimmung und der angewandte Prozess. 
• Das Manifest für agile Softwareentwicklung hebt den Wert eines Inkrements funktionierender Software (oder eines funktionierenden Produkts) gegenüber einer umfassenden Dokumentation hervor.

• Das Ziel der Auslieferung von Software auf ein klar definiertem Qualitätsniveau
• Dank agiler Methode kann funktionierende Software effizient und schneller ausgeliefert werden (geringere Zykluslaufzeit)
• Da RE stellt geeignete Technikgen bereit, mit deren Hilfe ein Verständnis der Wünsche und Anforderungen von Stakeholdern erlangt und die Software mit dem grössten Gewinn (Zuwachs an Business-Wert oder Liderung akuter Probleme) entwickelt werden kann. 
• RE vereinfacht:

1. Bedürfnisserkennung und Verständnis der Stakeholder für die Softwareentwicklung
2. Marktveränderungen erkennen und für Stakeholder Wettbewerbsvorteile generieren
3. Förderung effizienter Stakeholder Zusammenarbeit durch passende Techniken und Werkzeuge
4. Unterstützung verbaler Kommunikation durch passsende Techniken und Werkezuge
5. Das Verständnis um Stakeholder Anforderungen auf das Minimum reduzieren zu können. 

Das Manifest für agile Softwareentwicklung hebt den Wert eines Inkrements funktionierender Software (oder eines funktionierenden Produkts) gegenüber einer umfassenden Dokumentation hervor. Eine übertriebene Interpretation hatte den falschen Eindruck zur Folge, dass agile Methoden gänzlich auf Dokumentation verzichten. Diese Interpretation ist falsch: Zweckmäßige Dokumentation ist in agilen Entwicklungsprozessen nach wie vor erwünscht und zu empfehlen, allerdings nur dann, wenn sie die Entwicklung unterstützt oder Bestandteil des Produkts ist. In der Vergangenheit wurde es als Problem empfunden, dass in vielen Projekten Dokumentation ohne klar definierten Zweck oder Mehrwert erstellt wurde - diese Art von Dokumentation ist nach den agilen Prinzipien zu vermeiden. 

• RE und Entwicklungskompetenzen im selben Team können den Aufwand für Übergaben verringern
• Wenn RE_ Aufgaben im Team ausgeführt werden, kann das den Bedarf an vorab erstellter, umfassender Anforderungsdokumentation verringern (direkte Klärung innerhalb des Teams)
• Dokumentation von Ergebnissen aus den geführten Gesprächen und die Bewahrung von Wissen
• Inkrementelle Entwicklung ermöglicht die Optimierung vorhandener Ideen (die Qualität der Artefakte und/oder Software wird kontinuierlich verbessert)
• Das Risiko das zwischen den Kundenerwartungen und der Entwicklung grosse Lücken entstehen wird minimiert
• Kontinuierliche Verfeinerung ist ein Prinzip zur Ausreifung und Validierung. In regelmässigen Verfeinerungsmeetings wird mit dem Entwicklungsteam und den Stakeholdern die Anforderungen wiederkehrend durchgesehen und detailliert
• Durch das Verfahren der "Definition of Ready" Als "Quality Gate" wird validiert, dass eine Anforderung einer nachfolgenden Iteration zur Implementierung bereit ist
• Das RE vereinfacht das definieren eines ersten «Product Backlogs». Das RE bietet verschiedene Techniken, um die Stakeholder Anforderungen für das gewünschte Produkt richtig zu verstehen.

Das RE ist lediglich eine vorab erstellte Analyse. Missverständnis, da RE als Disziplin prozessunabhängig ist und nicht zwingend eine umfassende Vorarbeit erfordert. RE kann in jede Iteration integrierte Aktivität darstellen.

Vorab ist schlecht. Missverständnis, da die Vorbereitung auf eine iterative Entwicklung ein wesentlicher Bestandteil jedes nicht alltäglichen Entwicklungsprojekts ist. Agile Verfahren, die den Wert von Überlegungen im Vorfeld berücksichtigen, sind Story Mapping, Prototyping und das sog. Test Driven Development (TDD).

RE ist gleich Dokumentation. Missverständnis, da Dokumente bei z.B. der Einhaltung rechtlicher Vorgaben (Compliance), Bewahrung nützlicher Informationen, Vereinfachung der Kommunikation und bei gedanklichen Vorgängen unterstützen.

User-Storys sind ausreichend. Missverständnis, da User-Storys eine Methode für die Erfassung der Stakeholder Bedürfnisse sind. Sie zielen jedoch darauf ab, die Kommunikation in Gang zu setzen und stellen nicht die vollständige Spezifikation dar. Ein weit umfassenderes Bild von Anforderungen lässt sich durch eine Kombination von User-Storys mit anderen anerkannten RE Techniken wie Kontextdiagrammen, Prototyping, Anwendungsfällen und User Journeys erreichen.

Dokumentation ist wertlos, nur Code ist von bleibendem Wert. Missverständnis, da die Anforderungsdokumentation ebenso wie die Design-, Test- oder Betriebsdokumentation in bestimmten Kontexten ihre Daseinsberechtigung hat. Die Dokumente sind alle gleichermassen gültige und notwendige Artefakte, die aus dem Entwicklungsprozess für jedes nachhaltige Softwareprodukt entstehen.

Funktionierende Software ist der einzige Weg zur Validierung von Anforderungen: Missverständnis, Software ist als Mittel zur Validierung von Anforderungen zu bevorzugen, wenn die mit einem solchen Validierungsansatz verbundenen Kosten und Risiken verglichen mit dem Ergebnis akzeptabel sind. Sind die Kosten und/oder Risiken hoch, stellt RE verschiedene Tools zur Verfügung, die ein schnelles Feedback und eine rasche Anforderungsvalidierung ermöglichen, bevor auch nur eine einzige Zeile Code geschrieben wurde, beispielsweise Modelle für Benutzeroberflächen oder Story Boards

Agile und kulturelle Veränderungen sind unvereinbar. Agile Werte verändern die Unternehmenskultur (erfordert Zeit und qualifizierte Mitarbeiter)

Anforderungen als einheitliche Art von Informationen behandeln. Der benötigte Detailierungsgrad und unterschiedlichen Abstraktionsebene pro Anforderungen muss berücksichtigt werden. Z.B. Vision = hohe Abstraktionsebene und lange Gültigkeitsdauer.  Andere Anforderungen sind schnelllebiger – es müssen nicht alle Anforderungen einheitlich spezifiziert werden.

Den Zusammenhang aus den Augen verlieren. Bei agilen Methoden wird der Fokus nur auf Themen gelegt, die unmittelbar umgesetzt werden. Dadurch gerät der Gesamtzusammenhang aus dem Blickfeld. Lang- und mittelfristige Perspektiven schaffen (z. B. Verfeinerungs-Meetings).

Es wird sofort in Lösungen gedacht und spezifiziert. Noch bevor das Problem analysiert und der Nutzen/Bedarf des Stakeholders festgestellt wurde.

Stakeholder mit Informationen überladen. RE-Artefakte weisen eine hohe Informationsdichte auf, die einen grossen Review-Aufwand für Stakeholder darstellt.

Inkrementelle und iterative Ausarbeitung aller Themen. Nicht jedes Anforderungsthema muss detailliert und inkrementell entwickelt werden. Inkrementelle Entwicklungen eignen sich für komplexe Themen (z.B. Einkaufsprozess Onlineshop). Hochkomplexe Themen sind für inkrementelle Entwicklung nicht geeignet, da jede neue Erkenntnis zu einem völlig neuen Verständnis der bereits bekannten Informationen führt (z.B. Berechnungen von Versicherungspolicen).

Inkrementelle Entwicklung unterstützt möglicherweise keine radikalen oder bahnbrechenden Innovationen. Agile Entwicklungen mit inkrementellen Prozessen führen zu kontinuierlichen Innovationen. Radikale Innovationen entstehen, wenn unterschiedliche Ideen berücksichtigt und vorhandene Ideen neu kombiniert werden. Gemäss dem Prinzip «10. Prinzip - Maximieren nicht getaner Arbeit» werden keine alternativen Ideen in agilen Umgebungen entwickelt. Radikale Innovationen benötigt z.B. Lean-Startup-Ideen oder Design-Thinking-Ansätze.

Agilität beinhaltet mehr als Scrum. Besonders geeignete Ansätze für Innovationen sind: Design Thinking, Design-Sprint und Lean Startup

Diese Techniken zeigen, dass es Ansätze für konzeptuelle Arbeit in RE@Agile gibt, welche die Denkweise agiler Methoden teilen und daher gänzlich mit agilen, Softwareentwickelnden Unternehmen kompatibel sind. Diese Herangehensweisen sollten als eine neue Form des Wasserfall-Ansatzes berücksichtigt werden.

Sie können als Frameworks von agiler Entwicklung für das Design dedizierter Aspekte eines Systems verwendet werden. Alternativ können sie als Aktivitäten genutzt werden, die der agilen Entwicklung vorangehen. So helfen diese Ansätze, das begrenzte Potenzial für Innovationen in agilen Entwicklungsprozessen zu überwinden. 

3 Ansätze für Agilität in konzeptueller Arbeit (Kombinationen aus RE Ermittlungs- und Validierungstechniken).

Design Thinking  

• ein multidisziplinäres Team, das an dem Problem arbeitet; dieses Team bringt ein breit gefächertes Wissen mit, das für die Problemlösung benötigt wird;
• eine Arbeitsumgebung, in der das Team an Ideen arbeiten kann; und
• ein iterativer Prozess, der sich aus folgenden Phasen zusammensetzt: Hineinversetzen („Empathize") / Definieren („Define") / Ideen finden („Ideate as many as possible and choose one» / Prototypen entwickeln („Prototype") / Testen („Test")

Die Phasen des Design Thinking sind skalierbar und im Ablauf. Diese Methode entspricht dem agilen Wert „das Reagieren auf Veränderungen bewerten wir höher als das Befolgen eines Plans", «multidisziplinäre Team und die Arbeitsumgebung sind zentrale Elemente des Prozesses» sind und durch die Entwicklung von kostengünstigen und schlanken Prototyps, dem agilen Prinzip der «Einfachheit».

Der Design-Sprint ist ein 5-tägiger Entwicklungsworkshop mit Endkunden. Gearbeitet wird mit klar definierten «Timeboxes»;

• Wissen des Teams freisetzen / Ideen skizzieren / entscheiden, für welche Ideen Prototypen erstellt werden sollen / die ausgewählten Prototypen erstellen / die Ideen mit realen Kunden testen.
• Der entscheidende Unterschied im Vergleich zu agiler Entwicklung ist, dass der Prototyp keine Software sein muss

Lean Startup ist ein Ansatz zur Entwicklung von Geschäftsideen und zum Managen von Startups.

• Produktentwicklungsansatz „Build - Measure - Learn" führt zu kontinuierlichem Lernen über die Kundenbedürfnisse
• Mit dem Minimum Viable Product ist eine Version eines neuen Produkts gemeint, mit mimalem Aufwand das maximale Kundenfeedback ermöglicht.

Bei Lean Startup wird ein Kurswechsel, d. h. „eine strukturierte Kurskorrektur, um eine neue grundlegende Hypothese über das Produkt, die Strategie und den Wachstumsmotor» aufzustellen. Anstelle einer Ermittlung und Validierung der Anforderungen basierend auf Konzepten oder Dokumenten, werden diese Methoden anhand des realen Produkts durchgeführt. Das MVP muss nicht zwingend eine voll funktionsfähige, vollständige Software sein muss.

• Bei den Crystal Methoden wird für jedes Projekt ein eigens zugeschnittenes Prozessmodell benötigt. Abhängig von Größe, Komplexität und Kritikalität werden verschiedene Rollen, Aktivitäten und Artefakte angewendet. Crystal Clear, eine Methode für kleine und weniger kritische Projekte. Crystal Orange und Crystal Red wurden um einige Formalismen erweitert, um größere Projekte abwickeln zu können. Aus Anforderungsperspektive werden mit wenig formellen Anwendungsfallmodellen und Mock-ups gearbeitet.
• Lean Development und Kanban beruhen auf Prinzipien aus den 1940erJahren. Ziel dieser Ansätze ist es, sieben Arten von Verschwendung im Produktionsprozess aufzudecken (unfertige Vorprodukte, Überproduktion, Mängel,...) und diese bis zur endgültigen Lieferung schrittweise zu beseitigen.
• Scrum ist ein Framework zum Entwickeln und Erhalten komplexer Produkte. Das Framework ist auf eine iterative, inkrementelle Entwicklung ausgerichtet. Es gibt drei Schlüsselrollen: einen Product Owner (zum Managen des Product Backlog), ein Entwicklungsteam, das diese Anforderungen in kurzen Sprints implementiert und einen Scrum Master, der den Prozess überwacht und als Vermittler zwischen den anderen Rollen fungiert.
• TDD (Test Driven Development) beruht auf der Idee, dass vor dem Codieren eines Features zunächst der entsprechende Test verfasst wird. Die Testfälle sind sowohl eine exakte, als auch eine detaillierte Spezifikation der Anforderungen, die das Produkt erfüllen soll.
• XP (eXtreme Programming) Beim XP liegt der Schwerpunkt auf der direkten Kommunikation zwischen einem Kunden und einem Programmierer (der sog. On-Site Customer, der direkt neben dem Programmierer sitzt, ständig Anforderungen bespricht und unmittelbares Feedback in Form von implementierten Features erhält).  

Scrum ist ein schlankes Framework zur Entwicklung von Produkten in komplexen Umgebungen. Es gibt 3 Rollen (Scrum Master, Product Owner und Entwicklungsteam), 4 Ereignisse (Sprint-Planung, Daily-Scrum-Meeting, Sprint Review und Sprint-Retrospektive) und Artefakte (Product Backlog, Sprint Backlog, Sprint Goal/Sprint-Ziel und Definition of Done). Scrum empfiehlt keinerlei Engineering-Verfahren.

Scrum entwickelt Produkte iterativ und inkrementell in einer Folge von Sprints (max. 1 Monat). Jeder Sprint resultiert in einem Produktinkrement: Das ist ein Teilprodukt, das Endkunden in einer Produktionsumgebung potenziell verwenden können.

Der Sprint ist ein iterativer 'Plan-Do-Check-Act' Prozess. Jeder Sprint beginnt mit der Sprint-Planung, einem Ereignis, bei dem das Scrum-Team gemeinsam definiert, was im nächsten Produktinkrement ausgeliefert und wie das erreicht werden kann (Zerlegung).

Der Plan basiert auf dem Product Backlog (eine priorisierte und dynamische Liste aller Bedarfe für das Produkt). In der Sprint-Planung wird das Sprint-Ziel und Sprint Backlog (Auswahl der Items und deren Zerlegung für den Sprint) erstellt. Anschliessend beginnt das Scrum-Team mit der Implementierung des Produktinkrements.

Das Entwicklungsteam ist für die Umsetzung der ausgewählten Items in konkrete Ergebnisse verantwortlich, arbeitet mit dem Product Owner an der Verfeinerung der Product Backlog Items zusammen und gibt sein Feedback zur aktuellen Implementierung ab.

Die Mitglieder des Entwicklungsteams bringen sich jeden Tag in den Daily-Scrum-Meetings auf denselben Stand, um den Fortschritt zu beurteilen und das Sprint Backlog zu aktualisieren.

In der „Definition of Done" wird vereinbart, welche Teile einer Anforderung vom Entwicklungsteam erfüllt werden müssen. Wenn die Sprint Timebox vorüber ist, inspiziert das Scrum-Team in einem Sprint Review das Produktinkrement, und die wichtigsten Stakeholder bewerten die Ergebnisse des Sprints und besprechen die weiteren Schritte. Das Product Backlog wird entsprechend aktualisiert.

Der Sprint endet mit der Sprint-Retrospektive, in der das Scrum-Team bespricht, wie der letzte Sprint verlaufen ist, und wie es effizienter werden kann.

Im Scrum werden keine Requirements-Engineering-Techniken eingesetzt. Trotzdem ist es für RE relevant. Denn im «Product Backlog» werden die aufgeführten Items resp. Anforderungen gebündelt.

Das Backlog sollte „DEEP" (Detailed appropriately, Estimated, Emergent, Prioritized, d. h. angemessen detailliert, geschätzt, dynamisch, priorisiert) sein.

Alternativ gilt die «INVEST»-Regel:

I: „Independent of each other" - unabhängig voneinander

N: „Negotiable" - verhandelbar

V: „Valuable" - wertvoll, nützlich

E: „Estimable" - schätzbar

S: „Small enough to fit into one sprint" - klein genug für einen Sprint

T: „Testable" - testbar

Im RE werden ähnliche Kriterien für gute Anforderungen genannt:

• abgestimmt
• Eindeutig
• Notwendig
• Konsistent
• Prüfbar
• Realisierbar
• Verfolgbar
• Vollständig
• Verständlich

Die wichtigsten Verantwortlichkeiten eines Product Owners sind:

• Sicherstellen, dass das Entwicklungsteam konstanten betriebswirtschaftlichen Wert liefert: Das bedeutet, dass der Product Owner die längerfristige Vision für das Produkt und kurzfristige Bedürfnisse ins Gleichgewicht bringen muss, und er das Product Backlog aus betriebswirtschaftlicher Sicht priorisieren und die Ergebnisse des Entwicklungsteams zusammen mit den Stakeholdern am Ende jedes Sprints prüfen muss.
• Managen aller Stakeholder: Der Product Owner ist dafür verantwortlich, konsistente Anforderungen an das Team weiterzuleiten. Er muss Anforderungen aller Stakeholder erfassen und sicherstellen, dass sich die Anforderungen nicht widersprechen. Es muss etwaige Meinungsverschiedenheiten zwischen Stakeholdern lösen, um das Entwicklungsteam davon zu entlasten.
• Kontinuierliche Versorgung des Entwicklungsteams mit den hochrangigen Einträgen aus dem Backlog: Die Granularität dieser Anforderungen muss klein genug sein, damit sie sich für einen Sprint eignet. Für alle Fragen, die nach dem Sprint-Planungsmeeting entstehen, muss der Product Owner zur zügigen Klärung zur Verfügung stehen.

Im «Product Backlog» werden die aufgeführten Items resp. Anforderungen gebündelt.

• Je nach Granularität werden die Anforderungen in «Epics», «Features» und «User-Storys» zerlegt.  
• Es wird unterschieden zwischen funktionalen Anforderungen (Fähigkeit), Qualitätsanforderungen (Verhalten) und Randbedingungen (Umgebung)
• Und nach Anforderungsthemen gruppiert.

Innerhalb des Sprints gibt es das Backlog Refinement bei dem Anforderungen besprochen und verfeinert werden.

Mit der «Definition of Done» (DoD) entwickelt das Team ein gemeinsames Verständnis davon, wann ein Product Backlog Item vollständig und bereit für die Produktionsfreigabe ist.

Vergleicht man diese beiden Rollen, so zeigt sich, dass sowohl der Requirements Engineer als auch der Product Owner (gemeinsam mit allen Stakeholdern) die zentralen Aufgaben Ermitteln, Dokumentieren, Validieren und Managen von Anforderungen durchführen muss.

Die Notationen und Werkzeuge, die dabei zum Einsatz kommen, sind in agilen Entwicklungsprozessen jedoch in der Regel weniger formell:

• Story-Cards anstelle von Anforderungsdokumenten
• mehr Gespräche und weniger Schreibarbeit
• stärkere Betonung von aktuellen Statusanforderungen, weniger Betonung auf Versionierung und Verlauf

Es ist zwar wichtig, eine Gesamtverantwortung für Anforderungen von hoher Qualität kontinuierlich aufrechtzuerhalten, dabei ist die Rolle des Product Owners breiter gefächert als die eines herkömmlichen Requirements Engineers: Ein Product Owner ist für den Erfolg des Produkts insgesamt, das fortwährende Einholen von Feedback von den Stakeholdern sowie für das entsprechende Aktualisieren und Priorisieren des Backlogs verantwortlich.

Gute Gründe dafür kennen, weshalb das Requirements Engineering Teil eines kontinuierlichen Prozesses sein sollte:

• Das Requirements Engineering in agilen Entwicklungsprozessen ist keine klar abgegrenzte Phase während der Entwicklung, sondern eine iterative und laufende Aktivität.
• Die Ermittlung und Analyse sämtlicher Anforderungen, bevor das Design und die Implementierung beginnen können, ist nicht das Ziel; Anforderungen und Produkte werden gleichermaßen iterativ und inkrementell erstellt.

Das Requirements Engineering ist daher eine fortlaufende Aktivität, die so lange dauert wie die gesamte Entwicklung des Produkts.

• Gleichwohl hat dieser Prozess gut definierte Zwischenergebnisse: die vorausgesagten Anforderungen, welche den grössten betriebswirtschaftlichen Wert versprechen, sollten „bereit für die Implementierung" sein (Definition of Ready).
• Andere, aus betriebswirtschaftlicher Perspektive weniger dringende Anforderungen werden erst dann verfeinert, wenn die dringenden Anforderungen abgeschlossen sind.

Der „kontinuierliche Prozess" schließt einige wichtige Vorabaktivitäten nicht aus. Selbst wenn für Anforderungen jeweils rechtzeitig auf Basis des Need-to-Know Prinzips geklärt werden, so gibt es einige Aspekte, die dennoch frühzeitig im Projektlebenszyklus behandelt werden müssen. Als Beispiele seien das Definieren von Visionen oder Zielen, das Kennen der Stakeholder und das Erarbeiten des Produktumfangs genannt. Beginnt man die Implementierung ohne diese Aktivitäten, so erhöht sich das Risikolevel erheblich.

Mit agilen Methoden wird das Ziel verfolgt, dem Endbenutzer kontinuierlich betriebswirtschaftlichen Wert zu liefern. Betriebswirtschaftlicher Wert lässt sich in finanzieller Hinsicht, in einem höheren Marktanteil oder in Bezug auf die Kundenzufriedenheit direkt ausdrücken.

Die Anforderungen, welche den größten betriebswirtschaftlichen Wert versprechen, sollten „bereit für die Implementierung" sein (Definition of Ready). Andere, aus betriebswirtschaftlicher Perspektive weniger dringende Anforderungen werde erst dann verfeinert, wenn die dringenden Anforderungen abgeschlossen sind.

Eine andere Art von Wert ist die Risikoreduktion. Gute agile Ansätze versuchen, ein Gleichgewicht zwischen betriebswirtschaftlichem Wert und Risikominderung für die Iterationen herzustellen. Um die Anforderungen mit dem optimalen Wert zu ermitteln, streben agile Methoden häufig Minimum Viable Products (MVPs).

Der Ansatz dem Endbenutzer kontinuierlich betriebswirtschaftlichen Wert zu liefern, wird häufig in gewinnorientierten Organisationen verfolgt. Aber für Non-Profit-Organisation lässt sich der Wert nicht ganz so klar definieren. Für diese können Kennzahlen wie Nutzungsquoten oder der Zufriedenheitsindex für ein Produkt (d. h. Klickraten auf Websites oder Spenden für eine Non-Profit-Organisation) relevanter sein.

Der Produktdefinitionsprozess kann wie folgt vereinfacht werden:

• Erarbeiten einer einfachen, potenziell unvollständigen Lösung für ein Problem, wodurch ein kleines Wertinkrement geschaffen wird
• Entwickeln der Fähigkeit, basierend auf Praxiserfahrungen mehr über den Kontext zu erfahren
• Anpassen und Erstellen von Iterationen zur Schaffung und Auslieferung von Werten in einem kontinuierlichen Tempo
• Einsparen von Ressourcen von einer nicht gewinnorientierten Idee, um diese einer neuen Idee zuzuweisen - durch schnelles Scheitern und Lernen.

«Einfachheit» steht in gewisser Weise im Gegensatz zu „Perfektion". Einfachheit bedeutet nicht „schlechte Qualität" sondern „minimaler Umfang" oder „minimaler Service" - jedoch immer mit hoher Qualität. In Bezug auf Qualität gibt es keine Kompromisse.

Zwei Arten „einfacherer" Produkte:

Ein Minimum Viable Product (MVP) ist ein Konzept des Lean-Startups. Es wird als das kleinste Produkt definiert, das eine Endbenutzererfahrung und damit dem Team Feedback bieten kann. Dieses Feedback ist für die Weiterentwicklung des Produkts wichtig. Diese Arbeitsweise bietet eine rasche Investitionsrendite bei einem geringen Risikolevel.

Der Zweck eines Minimum Marketable Products (MMP) geht einen Schritt weiter. Es geht hierbei nicht nur darum, frühzeitig Feedback bereitzustellen und damit die nächsten Anforderungsschritte voranzubringen, sondern um die sofortige Schaffung von Wert. Viele Produkte können bereits in einer einfachen „Version 1" genutzt werden, ohne dass diese Version alle gewünschten Funktionalitäten und Qualitäten umfasst; so erzielt das Produkt bereits Umsatz, mit dem die kontinuierliche Verbesserung des Produkts finanziert werden kann.

Agile Methoden setzten auf häufiges und schnelles Feedback. Nach jeder Iteration bespricht das Team, ob der Entwicklungsprozess funktioniert oder verbessert werden muss. Dabei werden die eingesetzten Methoden, die Werkzeuge, die Zusammenarbeit im Team, usw. hinterfragt. Der aktuellen Entwicklungsprozess wird inspizieren („inspect").

Zudem wird vom Team das Arbeitstempo besprochen und die geplante Implementierungsgeschwindigkeit für die nächste Iteration oder der Anforderungsprozess entsprechend geändert oder angepasst. Die Konsequenz aus diesen Erkenntnissen ergibt kurzfristige Anpassung von Prozessverbesserungsschritten. Die Erkenntnisse werden umgesetzt („adapt").

Im Requirements Engineering werden Anforderungen als Artefakte oder als Ergebnis des Ermittlungsprozesses (z.B. Benutzeranforderungsspezifikation oder Systemanforderungsspezifikation) bezeichnet, abhängig vom Autor und Detaillierungsgrad. Die Anforderungssammlung ist nicht notwendigerweise dokumentenbasiert, sondern einfach eine Sammlung von Anforderungen in jeglicher physischen Form (Papier, Repository-basiert, usw.).

Bei agilen Methoden wird der Begriff Product Backlog als zu implementierende Anforderungssammlung verwendet. Der Begriff Sprint Backlog wird für Anforderungen verwendet, die für die nächste Iteration/Sprint ausgewählt wurden. Auch hier ist die physische Erscheinungsform der Backlogs nicht relevant. Sie können aus Karteikarten oder Haftnotizen an einer Wand bestehen. Das Product Backlog muss angemessen detailliert, geschätzt, emergent und priorisiert wird. Für den Product Owner als Wertoptimierer ist die Priorisierung des Produkts das Wertvollste und Wichtigste.

Auch wenn die Bezeichnungen und die Behandlung unterschiedlich sind, beruhen alle Artefakte auf denselben Ideen und bieten eine Basis für die Ermittlung, die Dokumentation, die Abstimmung, die Validierung und das Management von Anforderungen. Die folgenden Elemente müssen unabhängig von der Dokumentationsform erfasst werden:

• Ziele und Visionen
• die Definition des Umfangs eines Systems
• funktionale Anforderungen
• Qualitätsanforderungen und Randbedingungen
• ein Glossar (d. h. Definitionen relevanter Begriffe und Abkürzungen).

Die Ansätze für Anforderungsspezifikationen können in Notationen, in der Syntax und im Detaillierungsgrad variieren. Gar keine Spezifikation zu erstellen (d. h. ohne schriftlich erfasste Anforderungen, ausschließlich auf verbale Kommunikation zwischen Stakeholdern zu setzen), bildet keine Alternative, da schriftliche Dokumente häufig als Basis für Abstimmungen und Akzeptanztests sowie zur rechtlichen Absicherung dienen.

Je mehr alle Stakeholder miteinander kommunizieren, umso weniger Schreibarbeit ist erforderlich, doch die Ergebnisse = Anforderungen, sollten schriftlich oder grafisch erfasst werden.

Die Darlegung der Vision und die Ziele der Stakeholder beschreiben sämtliche Bedürfnisse, die das System befriedigen soll, um seinen Zweck zu erfüllen. 

Jeder Entwicklungsprozess sollte von Visionen oder Zielen geprägt sein, über die sich alle Stakeholder einig sind und welche die Produktfunktionen definieren. Wenn die Visionen und Ziele erfolgreich implementiert wurden, gilt die Lösung als erfolgreich.

Die Ziele verschiedener Stakeholder können im Widerspruch zueinander stehen. Somit müssen sich die Stakeholder abstimmen und eine gemeinsame Vision/Ziele vereinbaren.

Da in der agilen Welt die Ergebnisse des Entwicklungsprozesses einen klaren betriebswirtschaftlichen Wert haben, sollten sie sich immer auf die Produktvision bezieht. Es wird häufig mit Zielen von unterschiedlicher Granularität gearbeitet. Z.B. gibt es Ziele für unterschiedliche Zeithorizonte oder Planungsintervalle. Es kann beispielsweise ein Jahres-Ziele geben, um Abstimmungen über Auslieferungen (Zeitpunkt und Inhalt) zu ermöglichen, Drei-Monats-Ziele für die Release-Planung und Sprint-Ziele für die nächste Iteration/den nächsten Sprint.

Langfristige Produktvisionen und kurzfristige Sprint-Ziele sind hilfreich, um die wichtigsten Leistungen hervorzuheben, die innerhalb eines bestimmten Zeitrahmens erreicht werden sollen. Zudem helfen sie die Interessen aller Stakeholder auf eine „gemeinsame Mission" einzustimmen. Diese Ziele lassen sich auf einer Roadmap visualisieren.

Die Produktvision oder -ziele sind die abstrakteste Form von Anforderungen, die nicht ohne weitere Verfeinerung in die Entwicklung übernommen werden können. Sie dienen als leicht verständliche und umfassende Orientierungshilfe für den gesamten agilen Entwicklungsprozess. Jede Anforderung sollte auf die Ziele hin überprüft werden, um den Beitrag zu verifizieren, den sie für die unterschiedlichen Ziele leistet. Wenn eine Anforderung keine Beziehung zu den Zielen hat, kann das auf mangelnden betriebswirtschaftlichen Wert hindeuten. Folglich sind die Ausarbeitung der Produktvision und die abgestimmten Ziele der Stakeholder sehr wichtige Artefakte für den Erfolg agiler Entwicklungsprozesse, da sie den Rahmen für alle Entwicklungsaktivitäten vorgeben, ohne die Entwickler unnötig in ihrer Kreativität einzuschränken.

Herkömmlichen Spezifikationsdokumenten und Backlogs unterscheiden sich in folgenden Punkten:

Im Requirements Engineering werden Anforderungen als Artefakte oder als Ergebnis des Ermittlungsprozesses (z.B. Benutzeranforderungsspezifikation oder Systemanforderungsspezifikation) bezeichnet, abhängig vom Autor und Detaillierungsgrad. Die Anforderungssammlung ist nicht notwendigerweise dokumentenbasiert, sondern einfach eine Sammlung von Anforderungen in jeglicher physischen Form (Papier, Repository-basiert, usw.).

Bei agilen Methoden wird der Begriff Product Backlog als zu implementierende Anforderungssammlung verwendet. Der Begriff Sprint Backlog wird für Anforderungen verwendet, die für die nächste Iteration/Sprint ausgewählt wurden. Auch hier ist die physische Erscheinungsform der Backlogs nicht relevant. Sie können aus Karteikarten oder Haftnotizen an einer Wand bestehen. Das Product Backlog muss angemessen detailliert, geschätzt, emergent und priorisiert wird. Für den Product Owner als Wertoptimierer ist die Priorisierung des Produkts das Wertvollste und Wichtigste.

Auch wenn die Bezeichnungen und die Behandlung unterschiedlich sind, beruhen alle Artefakte auf denselben Ideen und bieten eine Basis für die Ermittlung, die Dokumentation, die Abstimmung, die Validierung und das Management von Anforderungen. Die folgenden Elemente müssen unabhängig von der Dokumentationsform erfasst werden:

• Ziele und Visionen
• die Definition des Umfangs eines Systems
• funktionale Anforderungen
• Qualitätsanforderungen und Randbedingungen
• ein Glossar (d. h. Definitionen relevanter Begriffe und Abkürzungen).

Die Ansätze für Anforderungsspezifikaionen können in Notationen, in der Syntax und im Detaillierungsgrad variieren. Gar keine Spezifikation zu erstellen (d. h. ohne schriftlich erfasste Anforderungen, ausschließlich auf verbale Kommunikation zwischen Stakeholdern zu setzen), bildet keine Alternative, da schriftliche Dokumente häufig als Basis für Abstimmungen und Akzeptanztests sowie zur rechtlichen Absicherung dienen.

Je mehr alle Stakeholder miteinander kommunizieren, umso weniger Schreibarbeit ist erforderlich, doch die Ergebnisse = Anforderungen, sollten schriftlich oder grafisch erfasst werden.

Kontextmodelle bieten folgenden Mehrwert im RE:

• Kontextmodelle haben zum Ziel bestimmte Eigenschaften der Umgebung (des Kontextes), in dem das System funktionieren sollte, zu beschreiben.
• In einem Kontextmodelle werden relevante Annahmen in strukturierter Weise dokumentiert. Dies bietet den Vorteil eine gemeinsame Sicht der operativen Systemumgebung für das Entwicklungsteam/Stakeholder zu etablieren, mit der alle einverstanden sind.
• Kontextmodelle sind leistungsstarke Artefakte, da sie klar zwischen dem zu entwickelnden System und dessen Kontext (z.B. Nachbarsystemen und menschlichen Benutzern) unterscheiden. Dadurch kann zwischen den Verantwortlichkeiten des Systems und den Verantwortlichkeiten von Nachbarsystemen oder menschlichen Benutzern unterschieden werden, die bei einem Vorgang zusammenarbeiten. Daher eignen sich Kontextmodelle auch zur Klärung und Spezifizierung der externen Schnittstellen des zu entwickelnden Systems.
• Ein Kontextmodell ist ein nützliches Artefakt, das in einem agilen Entwicklungsprozess zu empfehlen ist. Es grenzt den Bereich/Umfangs ab, in dem Analysten freie Entscheidungen treffen können, während die externen Schnittstellen (d. h. die Grenze zwischen Umfang und Kontext) mit den Nachbarsystemen abgestimmt werden müssen.
• Für Kontextmodelle sind alle Notationen geeignet, welche eindeutig zwischen dem zu entwickelnden System und externen Schnittstellen oder Personen/Systemen in der Umgebung differenzieren. Zudem muss die Beziehung zwischen diesen Elementen und dem zu entwickelnden System in einem angemessenen Detaillierungsgrad dokumentiert sein.
• Beispiel von Kontextmodellen: Kontextdiagramme für strukturierte Systemanalysen, Grafiken für Anwendungsfälle, UML-Komponentengrafiken oder UML-Klassendiagramme. Selbst einfache, von Hand gezeichnete Kastengrafikdiagramme können pragmatisch und nützlich sein.

Anforderungen müssen auf der Basis der Vision und der Ziele erfasst werden; sie sind durch das Kontextmodell begrenzt. Typischerweise unterscheidet man zwischen drei Arten von Anforderungen:

• funktionale Anforderungen
• Qualitätsanforderungen
• Randbedingungen

Stakeholder kommunizieren ihre Bedürfnisse in unterschiedlichen Granularitätsstufen: von groben Anforderungen (z.B. Geschäftszielen), bis hin zu detaillierteren Systemanforderungen. Funktionale und Qualitätsanforderungen sollten daher auf unterschiedlichen Abstraktionsebenen besprochen und dokumentiert werden.

Bei nicht-agilen Methoden werden in einem Top-down- oder Bottom-up-Prozess die Visionen und Ziele (1. Ebene) in Use Cases (Anwendungsfälle) verfeinert (2. Ebene) und anschliessend gruppiert. Diese Unterteilung kann aufgrund der Systemfunktionalitäten, nach betriebswirtschaftlichen Objekten, Datenflüssen oder Komponenten bestehender Lösungen erfolgen. Auf der nächsten Granularitätsstufe wird für jeden Use Case die für die Fertigstellung der Funktion benötigten Schritte beschreiben (3. Ebene). Je nach Komplexität sind kann diese Beschreibung erfolgen in:

1. Verbale Beschreibung (reiner Text)
2. Anwendungsfallvorlagen (teilweise strukturiertes Format)
3. UML-Aktivitätsdiagramm, Datenflussdiagramm, BPMN, Kontextdiagramm, Zustandsdiagramm, usw.
    

Bei sehr komplexen Problemen können weitere Granularitätsstufen hinzukommen. Z.B. Zerlegung von Aktivitäten in Teilaktivitäten oder durch textuelle Anforderungsspezifikationen einzelner Aktivitäten. Auf diese Weise werden grobe Kundenanforderungen schrittweise in detailliertere Spezifikationen der erwarteten Lösungsfunktionalität verfeinert.

Bei agilen Methoden werden für die folgenden Granularitätsstufen verwendet:

1. Epics
2. Themes
3. Features
4. User-Storys

Übergeordnete Geschäftsziele (1. Ebene) und komplexe Funktionalitäten werden in Form von Epics oder Features (2. Ebene) erfasst und nach Themen gruppiert. Komplexe Themen werden in detailliertere User-Storys zerlegt (3. Ebene).

Ob ein Projekt dem Top-down-Prozess der Verfeinerung von Epics in Features und dann in User-Storys folgt, oder ob zuerst einzelne User-Storys mit allgemeinen Themen und Epics erfasst werden, die dann in einem Bottom-up-Prozess bearbeitet werden, hängt von Art des Projekts und den beteiligten Stakeholdern ab. In jedem Fall bieten agile Entwicklungsprozesse Artefakte, um das Gesamtbild und die entwicklungsbereiten Anforderungen zu besprechen und zu priorisieren.

Funktionale Anforderungen können in folgenden Spezifikationsnotationen erfasst werden:

Textuelle Spezifikationsformate

• Textuelle Anforderungen werden zwar von vielen Stakeholdern leichter verstanden, sie können aber auch von denselben Lesern leicht fehlinterpretiert werden.
• Die natürliche Sprache ist nicht so präzise und eindeutig

Vorlagenorientierte Spezifikationsformate

• Verringert Mehrdeutigkeit und stellt wechselseitige Abhängigkeiten dar (u.A. zwischen Daten und Prozessen)
• Beispiele: UML-Aktivitätsdiagramme, BPMN-Diagramme, Flussdiagramme, Zustandsdiagramme, Sequenzdiagramme usw.

Grafische Spezifikationsformate

• Grafische Modelle weisen ein höheres Maß an Formalität auf, wodurch unterschiedliche Interpretationen oder Missverständnisse vermieden werden.
• Je nach Perspektive/Aspekt eigenen sich unterschiedliche grafische Notationen
• Aktivitätsdiagramme oder BPMN-Diagramme = lineare Prozesse, die aufeinanderfolgende Schritte, Alternativen oder Wiederholungen aufweisen.
• Zustandsdiagramme = Zeigt auf, wie ein Ablauf durch asynchrone Ereignisse beeinflusst werden könnte.
• Sequenzdiagramme = „Spezifikationen nach Beispiel" (Szenarios ohne einen Anspruch auf Vollständigkeit)

Mit welcher Spezifikationsform ein gemeinsames Verständnis bei allen Stakeholdern sichergestellt und Unvollständigkeiten/Missverständnisse reduziert werden kann, hängt von den definierten RE Ziele ab. Je nachdem auf welche Wechselbeziehung fokussiert werden sollte (Modellierung von Prozessen und Daten, Daten und Interaktionen oder Prozessen und Schnittstellen) kristallisiert sich das anzuwendende Spezifikationsformat heraus.

Funktionale Anforderungen sind ohne ein klares Verständnis der verwendeten Begriffe unvollständig. Aus diesem Grund müssen alle relevanten betriebswirtschaftlichen Begriffe, die in einem Anforderungsartefakt verwendet werden, definiert werden. Die Mindestform ist eine Liste von Geschäftsbegriffen und Abkürzungen in alphabetischer Reihenfolge (= Glossar).

Bei sehr komplexen Geschäftsfeld, kann das Glossar z.B. in Klassen gruppiert oder grafisch Darstellung werden (= Informationsmodell). Solche Artefakte werden dann als Datenmodelle, Entity-Relationship-Diagramme oder UML-Klassendiagramme bezeichnet. Neben der Begriffsdefinition enthalten diese Modelle auch relevante Assoziationen zwischen den Entitäten, d. h. statische Beziehungen zwischen den Begriffen (= Mehrwert eines Informationsmodelles).

Auf der Definitionen von Geschäftsbegriffen basiert auch bei agilen Ansätzen das gemeinsames und abgestimmtes Verständnis der in Artefakten wie Epics und User-Storys verwendeten Begriffe.

Qualitätsanforderungen und Randbedingungen werden unter dem Sammelbegriff „nicht-funktionale Anforderungen" zusammengefasst.

• Qualitätsanforderungen:
  • Qualitätsanforderungen beziehen sich auf bestimmte Qualitäten, die ein System aufweisen muss (z.B. Performance, Sicherheit, Benutzbarkeit).
  • Da beim agilen Entwicklungsprozess der Fokus auf funktionalen Kundenanforderungen liegt, besteht die Gefahr, dass Qualitätsanforderungen nicht explizit festgehalten werden.
  • Qualitätsanforderungen können nicht als User-Storys definiert werden, die innerhalb eines Sprints entwickelt werden können: Sie beschreiben vielmehr ein aus dem entwickelten Produkt entstehendes Attribut und müssen daher für alle User-Storys kontinuierlich getestet werden.
  • Es ist schwierig, durch Refactoring Qualitätsanforderungen in vorhandene Systeme zu integrieren. Daher ist es essentiell, Qualitätsanforderungen frühzeitig im Prozess zu berücksichtigen.

• Randbedingungen:
  • Randbedingungen schränken die Umsetzungsvarianten ein
  • Es gibt folgende Formen von Randbedingungen: organisatorische Randbedingungen (Budgetbegrenzungen, ein vorgegebener Entwicklungsprozess, usw.), technische Randbedingungen (erforderliche Systeme, Programmiersprachen, usw.) oder Einschränkungen der Umgebung (Regulatorien, Standards, Nomen, usw.)
  • Viele Randbedingungen können nicht inkrementell hinzugefügt werden und müssen daher schon früh im Prozess resp. bei Planungs- und Designentscheidungen berücksichtigt werden.

Ähnlich wie funktionale Anforderungen, treten Qualitätsanforderungen und Randbedingungen auf verschiedenen Abstraktionsebenen auf und sollten im Product Backlog dokumentiert, dem Team zugänglich gemacht und in jedem Sprint getestet werden. Daher kann es nützlich sein, diese zur Definition of Done hinzuzufügen und deren Validierung in Form von automatisierten Regressionstests zu implementieren.

Alle Arten von Anforderungen müssen validiert, geprüft oder getestet werden können. Deshalb müssen für alle Anforderungen eine Reihe von testbaren Kriterien vorhanden sein. Solche Kriterien erleichtern in der Regel zusätzlich das Verständnis, indem sie konkret die Erwartungen beschreiben.

Die Art der verwendeten Kriterien sollte der Granularitätsstufe der Anforderung entsprechen:

• Auf höheren Abstraktionsebenen (Vision, Ziele, Funktionen und Epics) werden gewöhnlich Erfolgskriterien definiert (es ist «messbar» ob eine benötigte Funktionalität/Fähigkeit bereitgestellt wird oder nicht).
• Auf niedrigeren Abstraktionsebenen können Akzeptanzkriterien definiert werden, die bei der Anforderungsabnahme erfüllt sein müssen.

Bei agilen und Nicht-agilen Methoden müssen Anforderungen prüfbar sein. Bei Nicht-agilen Methoden werden häufig Begriffe wie „Qualitätskriterien", „Abnahmekriterien" oder „Testfälle" verwendet; in agilen Prozessen trifft man häufiger auf Begriffe wie „Akzeptanzkriterien" (für User-Storys) oder „Erfolgskriterien" (für Epics oder Themen).

Unter Akzeptanz- und Abnahmekriterien werden folgende zusammengefasst:

• Geschäftsanforderungen
• Artefakte
• „Definition of Ready" (DoR)
• „Definition of Done" (DoD)

Sie stellen die Qualität von Anforderungen und Produktinkrementen sicher.

„Definition of Done" (DoD) ist ein offizielles Scrum Artefakt und dient als Quality Gate für den agilen Entwicklungsprozess, während die „Definition of Ready" (DoR) ein bewährtes Verfahren ist, das die Erstellung nützlicher Anforderungen unterstützt und verhindern soll, dass das Team mit unqualifizierten Anforderungen überladen wird.

Die DoR ist hilfreich, um die Anforderungen im richtigen Detaillierungsgrad zu erstellen und ausreichend Informationen für die Abstimmung zwischen Product Owner/Requirements Engineer und dem Entwicklungsteam bereitzustellen.

Viele Stakeholder wollen keine Dokumente schreiben oder lesen, sie wollen sofortige Erfolge sehen. Die beste Möglichkeit, um die Stakeholder Bedürfnisse zu verstehen und Feedback zu erhalten, ist die Demonstration von Systemfunktionalitäten oder -Merkmalen in Form eines laufenden Systems. Dies kann durch minimale, inkrementelle Produkte erreicht werden. Im RE gibt es dafür zwei Arten:

• „Horizontale" Produktinkremente, durch die sich mehr Varianten für die Validierung präsentieren lassen („mehr von den richtigen Dingen tun")
• „Vertikale" Produktinkremente, mit denen geprüft werden kann, ob der Entwicklungsansatz richtig ist („das Richtige tun").

Durch Prototypen kann Feedback gefördert werden, da sie eine direkte Interaktion mit einem funktionierenden System ermöglichen. Merkmale der Benutzbarkeit, etwa die Reaktionszeit, sind sehr schwer zu spezifizieren, aber ganz leicht zu identifizieren, wenn man funktionierende Software nutzt. Prototypen können jedoch auch eine Frustrationsquelle darstellen - für Benutzer, wenn sie glauben, dass die Entwicklung bereits abgeschlossen ist, und für Entwickler, da sie häufig verworfen und später durch eine bessere Technologie ersetzt werden.

Bei agilen Methoden werden keine Prototypen, sondern Inkremente des „realen" Systems mit einer guten Qualität entwickelt und in kurzen Iterationen ausgeliefert. Basierend auf dem Benutzerfeedback kann durch Refactoring der entwickelte Code angepasst werden. Dies ist ein bewährtes agiles Verfahren, um auf sich ändernde funktionale oder Qualitätsanforderungen zu reagieren.

Im agilen Entwicklungsprozess wird der Begriff „Spike" für eine Entwicklungsiteration verwendet, die den expliziten Zweck hat, einen Komplexitätsbereich (z. B. die Systemarchitektur) zu verstehen und so das Risiko zu verringern. Das Prototyping ist eine valide Technik innerhalb von Spikes, bei der - anders als bei anderen agilen Iterationen - das primäre Ziel im Sammeln von Wissen besteht, und nicht im Entwickeln von funktionierendem Code.

Für eine erfolgreiche Entwicklung sind einige Artefakte sehr wichtig:

• Es ist ein bewährtes Verfahren, mit Visionen oder Zielen zu beginnen.
• Es ist ein bewährtes Verfahren, die wichtigsten Stakeholder immer zu identifizieren und zu kennen.
• Es ist ein bewährtes Verfahren, den Umfang explizit festzulegen und ihn vom Kontext abzugrenzen.

Auch wenn im nicht-agilen und im agilen RE unterschiedliche Begriffe verwendet werden, stimmt man in beiden Richtungen darin überein, dass ein Verständnis der Funktionalitäten ebenso wie der Geschäftsbegriffe notwendig ist, um funktionale Anforderungen zu erfassen.

Zudem sollten agile und nicht-agile Methoden Qualitätsanforderungen und Randbedingungen aufzeigen, da sie Designentscheidungen stark beeinflussen und viel Überarbeitungsaufwand resp. ein Produkt zur Folge haben, das den Erwartungen des Kunden nicht entspricht.

Um sicherzustellen, dass keinerlei relevante Aspekte vergessen gehen, werden bei nicht-agilen Methoden Systemanforderungen dokumentiert. In agilen Ansätzen wird die fehlende Dokumentation durch direkte Kommunikation ersetzt und rasche Feedbackschleifen werden durch   inkrementelle Produktentwicklung oder Prototypen ermöglicht (=zweites Prinzip des agilen Manifests).

In der agilen Welt wird empfohlen zu überlegen, was schriftlich erfasst werden muss, was besprochen und was in Form von Prototypen oder Inkrementen gezeigt werden kann. Die besten Ergebnisse werden erzielt, wenn Dokumentation, Kommunikation und Prototyping/inkrementelle Entwicklung gemäss den Randbedingungen und der Unternehmenskultur in einem ausgewogenen Verhältnis zueinander stehen.

Im agilen Entwicklungsprozess beruht das Ermitteln der Anforderungen auf einem intensiven Austausch der Stakeholder (inkl. Entwicklungsteam). Für die informelle, direkte Kommunikation kann eine Mischung aus Befragungen und Brainstorming angewendet werden. Für die Verfeinerung der Backlog Items können die XP Techniken wie «On-Site Customer» ebenfalls erfolgreich sein. Das Ziel ist ein eingehenderes Verständnis davon zu gewinnen, was tatsächlich benötigt wird.

Prototypen und Produktinkremente sind weitere Möglichkeit, um mehr über Anforderungen zu erfahren. Sobald ein Produktinkrement im Sprint Review oder in einem Demo-Meeting präsentiert wird, können neue Ideen entstehen, die direkt in das Product Backlog übernommen und vom Product Owner priorisiert werden können.

Das RE bietet zusätzliche Techniken zur Erkennung und Ermittlung von Anforderungen, als im Kontext der agilen Entwicklung angewendet werden. Dazu zählen Frage/Antwort-Techniken (z.B.  Fragebögen), Beobachtungstechniken, Artefakt-basierte Techniken (Wiederverwendung, Systemarchäologie usw.) oder Kreativitätstechniken wie Design Thinking. Diese Techniken unterstützen das Erfassen von Anforderungen im User-Story-Format. Sie dienen aber mehr als Basis für strukturierte Gespräche als eine Vorgabe für die Implementierung.

Somit können agile Entwicklungsprozesse in hohem Masse von nichtagilem RE profitieren, indem die verschiedenen RE Ermittlungstechniken angewendet werden. Intensive Kommunikation zwischen den Stakeholdern und schnelles Feedback durch Produktinkremente sind zwar hervorragende Ideen, doch hinter der Ermittlung von Anforderungen steckt noch mehr. Falls es z.B. extrem viele Stakeholder gibt, ist die verbale Kommunikation nicht ausreichend. Oder um innovative unterbewusste Anforderungen ans Tageslicht zu bringen, ist unter Umständen der Einsatz von Kreativitätstechniken erforderlich. Beim Erschliessen neuer Technologien sind Spikes (einfache Inkremente in Timeboxes zum Erschliessen potenzieller Lösungen) eine hervorragende Option.