Das Thema Requirements Engineering wird in der agilen Community durchaus immer noch kritisch gesehen. Es wird gerne gleichgesetzt mit einer „vollständigen“ Vorabspezifikation und einem Wasserfall-Vorgehen – kurz Waste. Requirements Engineering (RE) ist kein Selbstzweck. Sehen wir RE jedoch als eine Disziplin im Software- oder Systems-Engineering, die uns hilft die richtigen und qualitätiv hochwertige Produkte und Systeme zu entwicklen, verfolgen wir damit einen Großteil der Ziele von agilen Vorgehensweisen. In diesem Beitrag beleuchten wir, am Beispiel von Scrum wie Requirements Engineering in einer agilen Umgebung Value liefert. Hierzu betrachten wir den Product Owner, der eine zentrale und dennoch stiefmütterlich behandelte Rolle im Scrum Team spielt. Wir zeigen auf, wie RE-Methoden ihn und das Entwicklungsteam in seiner Arbeit da unterstützen, wo Scrum keine Antworten liefert. Abschliessend machen wir uns auf die Suche nach Ursachen, die dazu führen, dass Aktivitäten des RE in einem agilen Umfeld als Waste empfunden werden: Sind Erhebungstechniken, Spezifikation, Qualitätskriterien, Traceability oder auch Requirements Management tatsächlich Waste? Teams und Umfeld sind nicht alle gleich – ein „ideales“ Scrum-Umfeld, indem genau ein Team genau ein Produkt entwickelt ist nicht überall gegeben. Die Verwendung von RE in Organisationen, die z.B. mit vielen Teams ein Produkt entwickeln, wird notwendiger sein, als in dem oben beschrieben „idealisierten“ Scrum-Umfeld. Wie erreichen wir auch in solchen Konstellationen ein Umdenken zu einem Umgang mit Requirements Engineering, um echten Value aus agilem Vorgehen zu erzielen?

1. Requirements Engineering in einer agilen Umgebung –
Waste oder Value?
Susanne Mühlbauer, HOOD GmbH HOOD GmbH
Keltenring 7
November 2012 82041 Oberhaching
www.HOOD-Group.com

2. Unser Geschäftsfeld
Wir liefern unseren Kunden das Rüstzeug für die erfolgreiche Entwicklung komplexer
Produkte, Dienstleistungen und Systeme durch Training, Beratung und Coaching.
Unsere Kernkompetenz ist das Requirements Engineering mit all seinen
Schnittstellen im Systems und Software Engineering.
-2- © HOOD GmbH

3. HOOD- Excellence
Unsere Konferenzen, Publikationen, Expertentalk
REConf®
Im HOOD Blog diskutieren wir ständig
aktuelle Themen und Trends des
Requirements Engingeering. Wir freuen
uns darauf, Sie auf unserem Blog
begrüßen zu dürfen:
http://blog.hood-goup.com
HOOD ist der Veranstalter von
Europas größter RE-Konferenz
-3- © HOOD GmbH

4. HOOD Portfolio
-4- © HOOD GmbH

5. Was ist RE?
Was ist Agile?
Scrum und
der Product
Owner
Wasteful
und
valuable RE
Fazit
-5- © HOOD GmbH

6. Requirements Engineering
Verstehen Vereinbaren Sicherstellen
Was möchte der Kunde? Wie vereinbaren wir das? Wie stelle ich sicher, dass er das bekommt?
Copyright © 2012 HOOD Ltd. http://www.HOOD-Group.com Vertraulich. Alle Rechte
vorbehalten. Weitergabe oder Vervielfältigung ohne vorherige schriftliche Zustimmung der
HOOD Group verboten. -6- © HOOD GmbH

7. Agile Scrum Guide
Praktiken
z.B. Scrum, XP, Crystal,…
Agile Das
agile
Prinzipien Manifest
Agile Werte
-7-

8. Die Ideallinie für RE im agilen Umfeld finden!
„So wenig wie möglich, soviel wie nötig.“
„Konventionell“ „Agile“
Schriftlich Konversation
Spezifikation Just-in-Time
„Vollständig“ Requirements Engineering Value-Orientiert
Copyright © 2012 HOOD Ltd. http://www.HOOD-Group.com Vertraulich. Alle Rechte
vorbehalten. Weitergabe oder Vervielfältigung ohne vorherige schriftliche Zustimmung der
HOOD Group verboten. -8- © HOOD GmbH

9. Scrum und
der Product
Owner
Wasteful
und
valuable RE
Fazit
-9- © HOOD GmbH

10. Scrum – kurz und knapp
Product Selected/
Backlog Sprint
Backlog
Potentiell lieferbares
Sprint Produktinkrement
Scrum Team
-10- © HOOD GmbH

11. Wo haben wir es mit Anforderungen zu tun?
Product
Vision/ Implementation
Scope Requirements
Requirements
Acceptance
Product Selected/
Backlog Sprint
Backlog
Potentiell lieferbares
Sprint Produktinkrement
Business/System
Requirements
Scrum Team
-11- © HOOD GmbH

12. Soruce: http://wallpapers-free.co.uk/backgrounds/cartoons/disney/The-Incredibles.jpg
Source: http://www.gamgea.com/wp-content/uploads/2009/04/the-incredibles-1-sized1.jpg
Verantwortung des Product Owner
• Product Backlog
• Fachliche Klärung der
Backlog Items
• Wert des Produkts/ der Arbeit
(ROI)
PO
• Priorisierung und
Reihenfolge der Backlog
Items
Product Owner ist ein • Abnahme der
Full-time Job Produktinkremente
• Release Planung
-12-

13. Soruce: http://wallpapers-free.co.uk/backgrounds/cartoons/disney/The-Incredibles.jpg
Soruce: http://wallpapers-free.co.uk/backgrounds/cartoons/disney/The-Incredibles.jpg
Source: http://www.gamgea.com/wp-content/uploads/2009/04/the-incredibles-1-sized1.jpg
PO
Product Owner ist
ein herausfordernder Job
-13-
• Project Management
• Product Management
• Fachliches Know How
Fähigkeiten des Product Owner
• Technisches Know How
© HOOD GmbH
• Requirements Engineering
• Kommunikationsfähigkeiten

14. PO
Scrum Team
-14- © HOOD GmbH

15. Dem Product Owner gehört das Produkt – Konflikte mit anderen
Rollen
Business Analyst Unternehmens-
führung
Projektleiter
Architekt
Produkt Manager Produkt/
System
UX-Spezialist Product
Marketing
Owner
Anforderungs-
The Product Owner is responsible for maximizing the value of the product
manager
Vertrieb
and the work of the Development Team.
-15- © HOOD GmbH

16. Eine Lösungsmöglichkeit: Die bestehenden Rollen als Stakeholder
betrachten
Requirements
Engineering Product
Owner
Scrum
Master Development Team
Scrum Team
Stakeholders
-16- © HOOD GmbH

17. „Grooming the Backlog“
Quelle: http://www.pfoten-und-co.de/fotos/pflegePferd.jpg
• Detaillierte
Requirements Analyse
• Grosse Anforderungen
splitten
• (Re-) Priorisieren
• (Re-) Schätzen
-17-
• Bearbeitungsreihenfolge
LAS Zürich
September 2012

18. Requirements Engineering innerhalb des Scrum Teams
Systemintegration
QM
Product Architektur
Owner Betrieb
Scrum
Master Development Team
Scrum Team
Stakeholders
© HOOD GmbH

19. Wasteful
und
valuable RE
Fazit Qualitäts-
Erhebung Spezifikation kriterien
Traceability
-19- © HOOD GmbH

20. Magic Backlog
Erhebungs-
techniken
Source: http://www.birgit-helfmann.de/pict/wunderlampe.jpg
LAS Zürich
September 2012

21. Beispiel: Von der Vision Vision
zur User Story
Business Business
Plan Drivers
Architektur-
vision
Minimum
Marketable
Product/
Feature Set
Feature Feature Feature Feature
Epic User User
Epic Story Epic
Story Epic
User User
Story Epic
Story
-21-

22. Product Vision - Beispiel Vision
„All my music is in my pocket“
Apple
Copyright © 2012 HOOD Ltd. http://www.HOOD-Group.com Vertraulich. Alle Rechte vorbehalten.
Weitergabe oder Vervielfältigung ohne vorherige schriftliche Zustimmung der HOOD Group verboten. -22- © HOOD GmbH

23. Requirements Engineering: Scope definieren
Stakeholder
Systemgrenze, -kontext
und Analyse
Schnittstellen
-23- © HOOD GmbH

24. Erhebung und Priorisierung mit MuSCoW
Product Backlog
Feature/ MuSCoW
EPIC
EpicEPIC
(ITEM)
EPIC
(ITEM)
(ITEM)
MuS CoW
Feature/ Feature/
EPIC
Epic EPIC
Epic
(ITEM) (ITEM)
MuSCoW MuSCoW
• Must Have – ohne das
funktioniert das System nicht
• Should Have
• Could Have
• Won‘t Have MuS CoW
User EPIC
Story
EPIC
(ITEM) User EPIC
Story
EPIC
(ITEM)
User EPIC
Story
(ITEM) (ITEM) (ITEM)
-24- © HOOD GmbH

25. Architekturrelevante Anforderungen Architektur-
vision
1. Architekturrelevante Anforderungen sind
Anforderungen, die implizit oder explizit
architekturrelevant sind.
2. Implizite Architekturanforderungen sind
Anforderungen, die über ihre Eigenschaften
als architekturrelevant eingeordnet werden.
 Alle Anforderungen mit hohem Risiko,
hoher Priorität oder geringer Stabilität
können als architekturrelevant betrachtet
werden.
3. Explizite Architekturanforderungen sind
meist nicht-funktionale Anforderungen.
Prinzip:
Deferred Decisions
-25- © HOOD GmbH

26. Evolving Architecture Architektur-
vision
Funktionalität
Funktionalität
validiert
Architektur
Quelle:
Architektur nicht Architektur Codecentric, OS
Information Days
ohne Funktionalität 2012
t
-26- © HOOD GmbH

27. Wasteful
und
valuable RE
Qualitäts-
Spezifikation kriterien
Traceability
Fazit
-27- © HOOD GmbH

28. Spezifikationen versus Product Backlog
Product Backlog
Copyright © 2012 HOOD Ltd. http://www.HOOD-Group.com Vertraulich. Alle Rechte
vorbehalten. Weitergabe oder Vervielfältigung ohne vorherige schriftliche Zustimmung der
HOOD Group verboten. -28- © HOOD GmbH

29. Was ist ein Backlog?
Der Begriff „Backlog“ wird zum Beispiel in der
Auftragsverwaltung verwendet und beinhaltet alle
Product Backlog
eingegangenen/ eingehenden Aufträge geordnet nach
ihrer Bearbeitungsreihenfolge.
Über diese Liste werden alle nachfolgenden
Prozessschritte, wie Beschaffung und Produktion, geplant
und gesteuert.
Das Backlog findet nun in der agilen Softwareentwicklung
analoge Anwendung. Es enthält alle potenziell
umzusetzenden Backlog Items, geordnet nach der
Reihenfolge ihrer Bearbeitung. Auf Basis dieser Liste
erfolgt die Planung und Steuerung der Umsetzung.
-29-

30. Aufbau eines Backlog
Bearbeitungsreihenfolge
Evolving Backlog
-30-

31. Was sind Backlog Items
Backlog Items sind solche Items, die geplant Ressourcen verbrauchen. Dazu zählen
zum Beispiel:
Features
Issue
Test Set (Test Run)
Needs
User Story
Technische Anforderungen Market Requirement Defect
Use Cases
Nicht-funktionale Anforderungen
-31-

32. Umdenken beim Requirements Engineering
Funktionale Dekomposition Inkrementell, nutzenorientiert
 Epic 1
Epic 

User Story 1

User Story 1 
User Story 2 
User Story 3
User Story 2
 Epic 2
Ergebnis sichern – Gewinne realisieren 
User Story 1
User Story 2
-32- © HOOD GmbH

33. „Wasserfallsprint“
Wasserfallsprínt
-33-

34. „Wasserfallsprint“
Sprint 1
Input für Sprint Planning
Realisation
Requirements Definition Review
t Wasserfallsprínt
Baseline Approval 
-34-

35. Iterativ und inkrementell
Sprint 1 Sprint 2 Sprint 3 Sprint 4
Input für Sprint Planning
Realisation
Requirements Definition Review
t  Baseline Approval
Copyright © 2012 HOOD Ltd. http://www.HOOD-Group.com Vertraulich. Alle Rechte
vorbehalten. Weitergabe oder Vervielfältigung ohne vorherige schriftliche Zustimmung der
-35- HOOD Group verboten.

36. „Gut genug für den Moment“
1. Minimum Marketable Product/
Feature Set
2. Walking Skeleton
3. Die einfachste Lösung, die
funktioniert
4. Nur das Notwendigste wird vom
System unterstützt
5. Was wäre, wenn wir heute liefern
müssten (potentiell lieferbar)
6. Akzeptanzkriterien streichen
7. Bereits während der Erhebung
priorisieren
-36- © HOOD GmbH

37. Wasteful
und
valuable RE
Qualitäts-
kriterien
Traceability
Fazit
-37- © HOOD GmbH

38. Die Säulen der Qualität
User Story
I ndependent
N egotiable
Akzeptankriterien
INVEST (Bill Wake)
V aluable
E stimable
S mall
T estable
Card Conversation Confirmation
-38-

39. Beispiel für Akzeptanzkriterien
User Story: User Story
„Als Marketing-MA will ich einen
I ndependent Webseite
Text auf der
publizieren können.“
N egotiable
Akzeptankriterien
Akzeptanzkriterien:
V 1. Das System muss ein
aluable
Review des Textes
ermöglichen
E stimable
2. Das System muss eine
Freigabe des Textes
S mall
ermöglichen
3. …
T estable
Card Conversation Confirmation
-39-

40. Qualität von Akzeptanzkriterien
Verständlich User Story
Atomar
I ndependent
Eindeutig
N egotiable
Akzeptankriterien
Nachweisbar
V aluable
Widerspruchsfrei
E stimable
Notwendig
Realisierbar
S mall
Lösungsneutral
T estable
Card Conversation Confirmation
-40-

41. „Als Marketing-MA will ich einen Text auf der Webseite publizieren
können.“
Akzeptanzkriterien
Text erstellen
Review
Aufgabe:
Machen Sie daraus 3-4 User Stories
Freigabe
Publizieren
-41-

42. Lösung:
„Als Marketing-MA will ich einen Text auf der Webseite publizieren
können.“
Text erstellen 1. „Als Marketing-MA will ich einen Text
erstellen können.“
Review Reihenfolge 2. „Als Marketing-MA will ich ein Review für
einen Text durchführen können.“
Freigabe 3. „Als Marketing-MA will ich eine Freigabe für
einen Text erhalten.“
Publizieren 4. „Als Marketing-MA will ich einen Text auf der
Webseite publizieren können.“
-42-

43. Lösung 2:
„Als Marketing-MA will ich einen Text auf der Webseite publizieren
können.“
Text erstellen 1. „Als Marketing-MA will ich einen Text
erstellen und publizieren können.“
2. „Als Marketing-MA will ich eine Freigabe für
Review Reihenfolge einen Text erhalten.“
3. „Als Marketing-MA will ich ein Review für
einen Text durchführen können.“
Freigabe
Publizieren
-43-

44. Wasteful
und
valuable RE
Traceability
Fazit
-45- © HOOD GmbH

45. Bestehende Spezifikationen: Needs, Epics und Stories extrahieren
Product Backlog
Anforderungen
„Miteinander reden statt
- Verstehen
- Gruppieren
gegeneinander
- Konsolidieren
- Priorisieren
schreiben“
- Abstimmen
- Verlinken
Quelle: mir leider unbekannt
-46-

46. Traceability
SW-Design
dokumentiert
Epic Benutzerdoku/
Fachliche
Doku
beinhaltet testet
Testfall Testlauf
User
Story
realisiert
User Source
Story Code
-47- © HOOD GmbH

47. Fazit
-48- © HOOD GmbH

48. Requirements Engineering im agilen Umfeld
Sprint
Verstehen Vereinbaren Sicherstellen
Was möchte der Kunde? Wie vereinbaren wir das? Wie stelle ich sicher, dass er das bekommt?
Erheben Sprintziel Retro
Scope Handschlag Automatisierung
Vision MMP
Doku Review
Ziel Visualisieren DoD Akzeptanzkriterien
Commitment frühes Feedback
Konversation
Fokus auf Value Traceability
Stakeholder potentially Shippable Akzeptanzkriterien
User Stories
-49-

49. Nutzen Sie agile Werte und Prinzipien und werden Sie zu:
http://www.drooglab.com/
-50- © HOOD GmbH

50. Fragen/ Diskussion

51. Kontakt
Susanne Mühlbauer
Susanne.Muehlbauer@HOOD-Group.com
HOOD GmbH
Büro München
Keltenring 7
82041 Oberhaching
Germany
http://blog.hood-goup.com
Tel: 0049 89 4512 53 0
www.HOOD-Group.com
-52- © HOOD GmbH

52. Quellen/ Links/ Zusatzinformation
1. www.agilemanifesto.org
2. www.scrum.org/Scrum-Guides
3. Innovation Games: Creating Breakthrough Products Through Collaborative
Play [Paperback], Luke Hohmann
-53- © HOOD GmbH