1.
Anforderungen haben
immer Schuld
Komplexität mit gutem Anforderungsmanagement
beherrschen
Frank Düsterbeck
@fduesterbeck

2.
DAS AGILE QUIZ
Warum haben Anforderungen oft Schuld?
DAS
AGILE
QUIZ
???Weil sie schlecht sind (wenn sie da sind) und
sich andauernd ändern!

3.
WAS BISHER GESCHAH

4.
IT ODER DIENSTLEISTER?
FACHBEREICH, BA UND IT?
ANFORDERUNGEN
LASTEN
LASTENHEFT
JETZT GEHT’S
(ENDLICH)
LOS???
(ER-)LÖSUNG
DER LASTEN
(PFLICHTEN)
PFLICHTENHEFT

5.
DAS GROSSE HEFT
DER LASTEN
(1602 SEITEN)
UNDURCHSUCHBAR
UNAKTUELL
UNNÜTZ

6.
DAS GROSSE HEFT
DER LASTEN
(1602 SEITEN)

7.
WIE MAN ES BESSER
MACHEN KANN
(SOLLTE, MUSS)

8.
Was ist die Grundlage
für gutes Anforderungs-
management?

9.
PO
ENTREPRENEUR
Repräsentiert die Endkundenbedürfnisse
VEREINT PRODUKT- UND PROJEKTMANAGEMENT

10.
Und was ist noch
Grundlage für gutes
Anforderungs-
management?

11.
VisionZiel des Projektes
Erstellung eines Produktes
Ergebnis des Produktes
Welche Veränderung soll erzielt werden?
Nutzen des Produktes
Welche Verbesserung soll aus dem
Ergebnis resultieren?
Zielgruppe
Wer soll mit dem Produkt arbeiten?
Business
Case

12.
Personas
Persona erstellen
Zielgruppen
erkennen und
gruppieren

13.
> 60 Jahre
> 1.000.000 Gehalt
Verheiratet
> 1 Kind
Lebt in einer
Großstadt
Personas

14.
Personas
Jetzt weiß ich auch wer das
System nutzt und welche
Bedürfnisse und Probleme
er hat

15.
Probleme
Wesentliche
Informationen
Ziele
Bedürfnisse
DAS SUPER
PERSONAS
POSTER
Alternativen

16.
Produkt-
planung

17.
Gemeinsames Verständnis
Das ist
eine
Schlange
Das ist
ein Baum
Das ist eine
Höhle
Das ist
ein Berg

18.
Ein Satz zu
meiner Vision
Meine
neuen Stärken
Wer möchte
was und wozu
Die
„messbaren“
Ziele
Meine
Stakeholder
Risiken und
Chancen
Als wer
Möchte ich was
ganz großes
Damit wozu
Als wer
Möchte ich was
ganz großes
Damit wozu
DAS SUPER
PRODUKT
VISION
POSTER

19.
Stakeholder
Freunde, Feinde und Neutrale
Einfluss auf das Projekt
Interessen und Hintergründe
Weitere Treiber und Bremser
Gesetze, Projekte
Risiken und Chancen
Eintrittswahrscheinlichkeit, Auswirkung
Vorbeugen, reduzieren, übertragen, akzeptieren
Ergreifen, steigern, teilen, ablehnen
Historie
Ursprung des Projektes
Probleme in der Vergangenheit

20.
Produktvision
Textmuster
Elevator Pitch

21.
Muster anwenden

22.
Produktvision
Was
Tolles!
Karton

23.
Und wie beschreibe ich
Anforderungen?

24.
USER STORIES
Als Rolle (wer)
Möchte ich Ziel (was)
Damit Nutzen (wozu)

25.
Independent (von anderen unabhängig)
Negotiable (kein Gesetz)
Valuable (haben (Mehr-)Wert)
Estimable (überschau- und damit schätzbar)
Small (passen in eine Iteration)
Testable (ohne Test kein Erfolg)

26.
Sollten denn alle
Stories möglichst klein
sein? Was sind
überhaupt Epics?

27.
Als wer
Möchte ich was
großes
Damit wozu
Als wer
Möchte ich was
Damit wozu
Als wer
Möchte ich was
großes
Damit wozu
Als wer
Möchte ich was
großes
Damit wozu
Als wer
Möchte ich was
Damit wozu
Als wer
Möchte ich was
Damit wozu
Als wer
Möchte ich was
Damit wozu
Das muss
ich tun
Das muss
ich tun
Das muss
ich tun
Das muss
ich tun
Das muss
ich tun
PO
Als wer
Möchte ich was
ganz großes
Damit wozu
PO
TD

28.
Muss die Summe der
Schätzung der
zerlegten Stories
eigentlich gleich der
original Story sein?

29.
Als wer
Möchte ich was
großes
Damit wozu
Als wer
Möchte ich was
Damit wozu
Als wer
Möchte ich was
Damit wozu
Als wer
Möchte ich was
Damit wozu
Als wer
Möchte ich was
Damit wozu≠∑

30.
Und wie sichere ich die
Qualität der User
Stories?

31.
Conversation
Definition of Ready
Qualitätssicherung
für
User Stories

32.
*Haben nicht den Anspruch Anforderungen umfassend zu dokumentieren
Card
Conversation
Confirmation
Als Benutzer
möchte ich Zahlen addieren können
damit ich Zeit beim Rechnen spare
*

33.
Confirmation
Akzeptanzkriterien (Testbasis)
Herstellung der Messbarkeit
Ready (DoR)  Bereit zur Umsetzung
Fertig (DoD)  Bereit zur Inspektion

34.
Schlüssel-
wörter
identifizieren
Fragen-
katalog
verwenden
Fragen im
Team
diskutieren
Akzeptanz-
kriterien
ableiten
Testfälle
spezifizieren
Confirmation

35.
Schlüssel-
wörter
identifizieren
Confirmation
Als Benutzer
möchte ich mein Profil speichern können,
damit ich meine Daten nicht immer wieder
neu eingeben muss.

36.
 Wer muss speichern?
 Wann speichern stattfinden?
 Wann ist speichern komplett abgeschlossen?
 Wie kann speichern genau durchgeführt werden?
 Wie häufig / oft / groß / schnell soll speichern sein?
 Wo / Wie kann geprüftwerden, ob speichern durchgeführt wurde?
 Wurde sichergestellt, dass speichern alle Daten / Aspekte berücksichtigt?
 Was geschieht, wenn man nicht speichern kann?
 Was könnte speichern verhindern und was wird dann erwartet?
 Welche möglichen Fehleingaben müssen beim speichern abgefangen werden?
 Welche Inhalte kommen in Profil vor?
 Welche optionalen / verpflichtende Aspekte gelten für Profil ?
 Welche Inhalte von Profil und nach welchen Regeln soll überprüft werden?
 Wie sieht das Layout für Profil aus?

37.
Und was ist wenn ich
jetzt total viel
Akzeptanzkriterien
habe?

38.
Akzeptanzkriterien
• Der Premium-Kunde soll bei einer Buchung auswählen können, ob die Buchung als Abo laufen soll
• Der ausgewählte Termin ist der Starttermin
• Er kann verschiedene Intervalle für sein Abo auswählen
– Täglich
• Er kann zwischen bestimmten Wochentagen oder allen Arbeitstagen auswählen
– Wöchtlich
• Rhythmus von jeder, zweiter, dritter…Woche
– Monatlich
• Bestimmter Wochentag (letzter Freitag im Monat)
• Bestimmter Tag, wie der 1. eines Monats
• Er kann einen Endtermin für sein Abo bestimmen
– Bestimmtes Datum
– Nach einer bestimmten Anzahl an Wochen
• Er kann in seinem Kundenkonto die ausgewählten Abos einsehen, ändern und löschen
• Er kann in seinem Kundenkonto die Kosten anzeigen
• Er kann einen Zahlungsrhythmus für das Abo auswählen
– Im Voraus
– Je Termin
– monatlich

39.
Man soll also viel
reden!
Gibt‘s da noch mehr?

40.
Conversation
BDD

41.
VERHALTEN
TREIBT
ENTWICKLUNG
BEHAVIOR
DRIVEN
DEVELOPMENT

42.
UBIQUITÄRE SPRACHE
GHERKIN
ALLE VERSTEHEN ES
SZENARIEN MIT
GIVEN WHEN THEN
ANGENOMMEN WENN DANN

43.
Akzeptanzkriterien
Szenario: Marmelade abonnieren monatlicher Rhythmus
Angenommen ein Kunde Max
Und Max ist Premium Kunde
Und Max aktiviert den Aboservice
Wenn Max als Intervall monatlich auswählt
Dann bekommt Max eine Nachricht
Und die Marmelade wird monatlich versendet
Und er bekommt 10% Rabatt
Szenario: Marmelade abonnieren wöchentlicher Rhythmus
Angenommen ein Kunde Max
Und Max ist Premium Kunde
Und Max aktiviert den Aboservice
Wenn Max als Intervall wöchentlich auswählt
Dann bekommt Max eine Nachricht
Und die Marmelade wird wöchentlich versendet
Und er bekommt 5% Rabatt

44.
Akzeptanzkriterien
Szenario: Marmelade abonnieren
Angenommen ein Kunde Max
Und Max ist Premium Kunde
Und Max aktiviert den Aboservice
Wenn Max ein als Intervall <intervall> auswählt
Dann bekommt Max eine Nachricht
Und die Marmelade wird <intervall> versendet
Und er bekommt <rabatt> Rabatt
Beispiele:
|intervall |rabatt |
|wöchentlich |5% |
|monatlich |10% |

45.
… und das geht auch
automatisiert?
Wie denn?

46.
Client
View
Model
Businesslogik
Controller
Ressourcen
Request
Response
Select
?
?

47.
Als Benutzer
möchte ich Zahlen addieren können
damit ich Zeit beim Rechnen spare
User Story schreiben
Akzeptanzkriterien ausarbeiten
Glue Code schreiben
Unittest Code schreiben
Code schreiben
Ready
Done
[Then(@"the result should be (.*) on the screen")]
public void ThenTheResultShouldBeOnTheScreen(decimal p0)
{
Assert.AreEqual(p0, result);
}
Assert.AreEqual(130, calculator.result);

48.
User Story schreiben
Akzeptanzkriterien ausarbeiten
Glue Code schreiben
Unittest Code schreiben
Code schreiben
Fachbereich und
Anforderungsmanager haben eine
einfache Sprache, ...
… Anforderungsmanager, Entwickler
und Tester müssen jetzt eng
zusammenarbeiten, …
… die Entwickler können dann
direkt gegen das erwartete
Verhalten (den Test) entwickeln, …
… alle kriegen sofort eine
Rückmeldung, ob sie alles richtig
gemacht haben, …
… am Ende braucht man
nicht mehr soviel testen, …
… und wir haben eine
lebende Dokumentation!!!

49.
Das ist ja alles ganz
toll aber wie werde
ich damit den
Anforderungen an
moderne
Softwareentwicklung
gerecht?

50.
K O M P L E X I TÄT R E D U Z I E R E N
R I S I K O M I N I M I E R E N

51.
Epos 31
Epos 19
Epos 12
Epos 9
Epos 4
Epos 7
Epos 2
User Story 4 User Story 33
User Story 14User Story 13User Story 3
User Story 1
User Story 6
User Story 2
User Story 5



Status Ready
K O M P L E X I TÄT R E D U Z I E R E N

52.
Detailed Appropriatly (angemessen Ausdetailliert)
Emergent (sich entwickelnd / dynamisch)
Estimated (geschätzt)
Prioritized (in „Reihenfolge“ gebracht)

53.
Und wie mache ich
das Projectscoping?
Wie weiß ich was ich
zuerst bauen soll?

54.
Das minimale Set an Funktionen...
...die für uns den maximalen…
...Lerneffekt herstellen.
Schick
Benutzbar
Wertvoll
Funktional

55.
REICHT DAS?
K O M P L E X I TÄT R E D U Z I E R E N
R I S I K O M I N I M I E R E N

56.
Das Unbekannte kennen...
...über den ganzen Geschäftsprozess(e)...
...über alle Hauptkomponenten.

57.
Das ist mir irgendwie
noch zu unkonkret!

58.
Pre-Suche
Einloggen
Account anlegen
Suchen
Passwort ändern
Filtern Details ansehen
Anzahl im
Warenkorb
ändern
In den Warenkorb
legen
Aus dem
Warenkorb
löschen
Bestellen
Bewerten
Eigene
Marmelade
zusammenstellen
Detaillierte
Inhaltsliste
anzeigen
Abo anlegen
Versandservice
auswählen
Einfache
Einkaufs-
möglichkeit

59.
Pre-Suche
Einloggen
Account anlegen
Suchen
Passwort ändern Filtern
Details ansehen
In den Warenkorb
legen
Aus dem
Warenkorb
löschen
Versandservice
auswählen
Bewerten
Eigene
Marmelade
zusammenstellen
Detaillierte
Inhaltsliste
anzeigen
Abo anlegen
Anzahl im
Warenkorb
ändern
BestellungWarenkorbSucheLogin
Bestellen
Bewertung
Einfache
Einkaufs-
möglichkeit

60.
Warenkorb
Story Mapping
SucheLogin Bestellung ...
*


Jeff Patton
Benutzer-
verwaltung
Bestellprozess

61.
RELEASE 1:
MINISHOP
RELEASE 2:
AUKTIONEN
RELEASE 3:
MARKTPLATZ

62.
DAS GROSSE HEFT
DER LASTEN
(1602 SEITEN)
UNDURCHSUCHBAR
UNAKTUELL
UNNÜTZ

63.
DURCHSUCHBAR
AKTUELL
NÜTZLICH

64.
Und was ist mit den
nicht funktionalen
Anforderungen?

65.
reliability
availability
portability
scalability
usability
maintainability
security
performance
correctness
…
robustness

66.
Unsere
Story Map
Unsere
Rahmenbedingungen
DoD
Als Kunde
möchte ich, dass das System 99,99%
Erreichbarkeit hat
Als Administrator
möchte ich, dass das System in einem
Fail-Over Cluster läuft
Als Kunde
möchte ich, dass das System mobile
Endgeräte unterstützt
Als ausländischer Kunde
möchte ich, dass das System meine
Sprache anbietet
Aufbau der
Testinfra-
struktur

67.
Epos 31
Epos 19
Epos 12
Epos 9
Epos 4
Epos 7
Epos 2
Funktion Test
FunktionSpikeDesign
Tools
Infrastruktur
Technische
Unterstützung
Funktion

68.
Gibt‘s noch was?

69.
DON‘T WANT STORIES
Als Rolle
Möchte ich nicht, dass...
Weil / Damit ich sonst...

70.
Und wie sieht der
Prozess für Stories bzw.
Anforderungen aus?

71.
DAILY
SCRUM
SPRINT
PLANNING
Product
Backlog
Product
Backlog
SPRINT
BACKLOG
PRODUCT
BACKLOG
PRODUCT
BACKLOG
PRODUCT
BACKLOG
PRODUCT
BACKLOG
PRODUCT
BACKLOG
PRODUCT
BACKLOG
PRODUCT
REVIEW
RETROSPECTIVE
STORY TODO
IN
PROGRESS DONE
SCRUM BOARD (VISUALISIERUNG)
REFINEMENT

72.
REFINEMENT
SPRINT PLANNING

73.
TICKETSYSTEM
Offen
Bereit zur
Umsetzung
(Ready)
In
Bearbeitung
WIKI
Fertig
(Done)
DIE GROSSE
SYSTEMDOKUMENTATION
Das muss
ich tun

74.
DAS FAZIT

75.
Anforderungen haben
immer Schuld
Komplexität mit gutem Anforderungsmanagement
beherrschen
Frank Düsterbeck
@fduesterbeck

76.
Anforderungen haben
nimmer Schuld
Komplexität mit gutem Anforderungsmanagement
gerecht werden
Frank Düsterbeck
@fduesterbeck

77.
Frank Düsterbeck
frank.duesterbeck@HEC.de
@fduesterbeck
de.slideshare.net/fduesterbeck