In agilen Projekten ist funktionierende Software wichtiger als ausufernde Dokumentation. Durch kurze Entwicklungszyklen (Iterationen) werden den Anwendern schon während der Entwicklung Teilpakete der geplanten Softwarelösung mit einem sinnvollen Funktionsumfang bereit gestellt. In agilen Projekten ist die flexible Reaktion auf Änderungen der Anforderungen wichtiger als ein starrer Projektplan. Agilität bei der Entwicklung erfordert aber auch Agilität bei der Beschreibung der funktionalen Anforderungen (Requirements Engineering). Use Case-Modelle eignen sich hervorragend für diese Aufgabe. Durch dieses Vorgehen ist es möglich, Wünsche der Anwender, geänderte Rahmenbedingungen und Erfahrungen aus der bisherigen Entwicklung in der Realisierung zu berücksichtigen. Reinhard Brüggemeyer, Dozent dieses "Treffpunkt Semicolon", zeigt, warum in agilen Projekten der Anwender und seine Aufgaben im Mittelpunkt stehen. Pro und Contra des agilen Vorgehens gegenüber dem klassischen Requirements Engineering werden diskutiert.

1. Requirements Engineering in agilen
Projekten
Flexibilität ist gefordert
Treffpunkt Semicolon, 31.08.2010
Reinhard Brüggemeyer, GEDOPLAN GmbH

2. Entwicklung von Informationssystemen
30+ Jahre am Markt
~35 Mitarbeiter
Beratung und Entwicklung
Maßgeschneiderte Lösungen GEDOPLAN
Standardsoftware
Archi- Entwick-
Analyse
tektur lung
SAP®
Java

3. Seit 1998 im Bereich Java:
80+ Beratungs- und Entwicklungsprojekte
Konzeption und Entwicklung
30+ Seminartitel
Java / Java EE GEDOPLAN
Diverse App.-Server
Glassfish Archi- Entwick-
IBM WebSphere Analyse
tektur lung
JBoss
Oracle WebLogic SAP®
SAP NetWeaver
Java

4. IT-Systeme und Prozesse
Beratung, Schulung, Entwicklung
80+ Mitarbeiter
www.involva-gruppe.de

5. Agenda
Prinzipien des Agilen Manifestes
Requirements Engineering, einige Fachbegriffe
Agiles Vorgehen in den Projektphasen
Vorteile der agilen Vorgehensweise

6. Agiles Manifest
Funktionierende Software ist wichtiger als umfangreiche
Dokumentation
Gute Kommunikation ersetzt Dokumentation
In kurzen Abständen übergebene Software ist Basis der
Kommunikation
Schnelle Rückkopplung durch feste Iterationen
Nur notwendige Dokumentation wird erstellt
Reaktion auf Änderungen ist wichtiger als starrer Projektplan
Änderungen an Anforderungen werden bei der Realisierung
berücksichtigt
6

7. Sinn und Zweck von Business Spezifikationen
Gemeinsames Verständnis der Anforderungen
Kommunikation zwischen Projektteam und Auftraggeber
Basis für …
Aufwandsschätzungen
Projektplanung
Realisierung
Test
Die Informationen sind so detailliert, wie sie in jeder
Projektphase benötigt werden
Klassisches Vorgehen: Vollständiges Pflichtenheft vor Start
der Realisierung
7

8. Wer erstellt / nutzt Dokumentation ?
Requirements Engineer -> beschreiben
Projektleiter -> schätzen
-> planen
-> entscheiden
Entwickler -> realisieren
-> System warten
Qualitätskontrolle -> testen
Anwender -> System nutzen

9. Fachbegriffe des Requirements Engineering
Funktionale Nicht funktionale
Anforderungen Anforderungen
Analyse Story verbale
Beschreibung
Use Case
Planung Timeboxing
Iteration
Produktfeature
Iterationsfeature
Release
9

10. Phasen in Agilen Projekten
Vorstudie
Konzeption
Iterationsplanung
Iterationsdurchführung
Projektabschluss
10

11. Vorstudie
Betrachtung des gesamten Projektes
Realisierungsalternativen ermitteln
Technische Machbarkeit prüfen
Grobplanung für …
Zeitbedarf
Personalbedarf
Kosten
Entscheidungsvorlage für das Management
Die Vorstudie betrachtet das gesamte Projekt
Hier unterscheidet sich agiles Vorgehen nicht von klassischen
Projekten
11

12. Phasen in agilen Projekten
Vorstudie
Konzeption
Iterationsplanung
Iterationsdurchführung
Projektabschluss
12

13. Bestandteile der Konzeption
Systemabgrenzung
Gesamtmodell der funktionalen Anforderungen
Prioritäten der Anforderungen
Aufwandsschätzungen für die Anforderungen
Klassenmodell der Objekte
Systemarchitektur
Klärung neuer technischer Anforderungen durch Prototypen
Beschreibung der nicht funktionalen Anforderungen
13

14. Systemabgrenzung durch In-/Outmatrix
Projekt Betriebsdatenerfassung
Funktionalität
Zeiterfassung IN
Schichtbericht IN
Urlaubserfassung OUT
Leistungslohn IN
Gehaltsabrechnung OUT
14

15. Ermittlung der funktionalen Anforderungen
Betrachtung des Systems als Black Box
Wer ist von den System in irgendeiner Weise betroffen
(Stakeholder) ?
Welche Akteure nutzen das System?
Welche Use Cases benötigen die jeweiligen Akteure?
Welches primäre Ziel haben die Akteure (Geldabheben oder
Pineingabe) ?
15

16. Use Case Diagramm
Projekt Betriebsdatenerfassung
Kommen
buchen
Bericht
anzeigen
Gehen
buchen
Mitarbeiter Bericht Vorgesetzter
korrigiere
n
Pause
erfassen
16

17. Anforderungen an Use Cases (INVEST)
Independent sind unabhängig voneinander
Negotiable sind verhandelbar
Valuable haben einen Geschäftswert
Estimatable sind schätzbar
Small sind möglichst in einer Timebox umsetzbar
Testable sind testbar

18. Strukturierung der funktionalen Anforderungen
Welche Use Cases sind konkrete Use Cases auf
Anwenderebene?
Welche Use Cases unterstützen Use Cases auf
Anwenderebene?
Welche abstrakten Use Cases gruppieren konkrete Use
Cases?
Ebenenkonzept der Use Cases (nach Cockburn)
Gesamtprojekt (Level 1)
Bereich (Level 2)
Anwendersicht (Level 3)
Supportsicht (Level 4)
Level 2 und 3 liefern eine vollständige Beschreibung des
Systems 18

19. Gesamtmodel der funktionalen Anforderungen
Projekt Betriebsdatenerfassung
Betriebsdaten Gesamt –
- erfassung projekt
Zeit Schicht - Bereich
- erfassung bericht
Kommen Gehen Pause Bericht Bericht Anwender
buchen buchen erfassen anzeigen korrigieren –
ebene
Mitarbeiter Mitarbeiter Support –
authentifizieren identifizieren ebene
19

20. Use Case Attribute für die Konzeption
Primärer Akteur: Hauptanwender
Ziel und Inhalt: Kurze textliche Inhaltsangabe
Ebene: Beschreibungsebene
Akteure und Interessen: Wer verfolgt welche Ziele?
Vorbedingung: Welche Bedingungen müssen vor
dem Start eines Use Case erfüllt
sein?
Minimal Garantie: Was ist das Minimalergebnis?
Auslöser: auslösendes Ereignis
Hauptobjekt: Überwiegend bearbeitetes
Objekt
Business Priorität: Priorität der Anwender
20

21. Beispiel: Use Case in Konzeptionsphase
21

22. Bewertung der Anforderungen
Bewertung der Anforderungen nach „Business Priorität“ und
„Entwicklungskomplexität“
Use Case Priorität Komplexität
Gesamtpriorität
Kommt buchen 5 1 5,1
Geht buchen 5 1
5,1
Leistungslohn berechnen 4 3 5,0
Leistungslohn simulieren 2 5 5,4
Schichtbericht erzeugen 4 3 5,0
22

23. Schätzung der Anforderungen
„Wetter von gestern“ Prinzip
Use Case Point Methode
Use Cases auf Anwenderebene schätzen
Schätzung durch mehrere Personen und Mittelwert bilden
Abstrakte Use Case Points in konkreten Aufwand umrechnen
23

24. Hierarchisches Schätzen
Zeiterfassung Schichtbericht
abstrakte
2 3 Use Cases
Komme Gehen Pause Bericht Bericht konkrete
n buchen erfasse anzeigen korrigiere Use Cases
buchen 4 n n
2 2
Bewertung der abstrakten Use Cases
Bewertung der konkreten Use Cases für einen Bereich
Umrechnung der Bewertungen in Aufwand (1 Punkt = 2 MT)
Aufwand Zeiterfassung = (2 + 4 + 2) * 2 MT = 16 MT
Aufwand Schichtbericht = 16 MT / 2 * 3 = 24 MT
24

25. Klassenmodel der Objekte
Strukturierung aller Objekte des Systems
Beschreibung der Begriffe und ihrer Beziehungen
Beschreibung der Objekteigenschaften durch Attribute
Schichtbericht
Bemerkung
Freigabedatum
Pausenzeitraum Aufgabenzeitrau Aufgabe
Startzeitpunkt m Bezeichnung
Endezeitpunkt Startzeitpunkt
Endezeitpunkt
25

26. Phasen in agilen Projekten
Vorstudie
Konzeption
Iterationsplanung
Iterationsdurchführung
Projektabschluss
26

27. Agiles, iteratives Vorgehen
Gesamtplanun
g Iterations-
- planung
Anforderungen
- Aufwand
- Reihenfolge
Anwender- Detail
präsentation Spezifikation
Iterations- Systementwu
test rf für Iteration
Realisierung
27

28. Iterationsplanung - Wann wird eine Anforderung
realisiert?
Anforderungen mit hoher „Business Priorität“ möglichst früh
realisieren (Easy Wins)
Komplexe Anforderungen früh einplanen, um Risiken zu
minimieren
Abhängigkeiten zwischen den Anforderungen berücksichtigen
(Trigger, Vorbedingungen)
Anforderungen, die dasselbe Hauptobjekt bearbeiten, evtl.
gemeinsam umsetzen
Umfangreiche Anforderungen auf Iterationen aufteilen
Mit Minimalergebnis beginnen
Varianten weglassen
Auf Komfort verzichten
28

29. Use Case / Iterations Matrix
Aufteilung eines Use Case (Rapportschein verwalten)
Funktion 1.Iteration 2.Iteration 3.Iteration
Anwesenheit anzeigen x
Pausen anzeigen x
Auftragsdaten anzeigen x
Zeiträume modifizieren x
29

30. Phasen in agilen Projekten
Vorstudie
Konzeption
Iterationsplanung
Iterationsdurchführung
Projektabschluss
30

31. Detailspezifikation der Anforderungen / Use Cases
Haupt-Erfolgsszenario: Schritte die im Erfolgsszenario –
dem Normalfall – durchlaufen
werden
Erweiterungen: Die Varianten des Normalfalls
werden mit ihren einzelnen Schritten
beschrieben
Fehlerbeschreibungen: Im Fehlerfall wird jeder Schritt
beschrieben, der durchlaufen
werden soll
31

32. Beispiel eines Use Case mit erweiterten
Informationen

33. Gründe für die späte Detailspezifikation
Aktuelle Rahmenbedingungen – Gesetze / Verordnungen
Technische Weiterentwicklungen
Bisherige Erfahrungen aus dem Projekt
Zusätzliche / geänderte Wünsche der Anwender
33

34. Vorteile der Beschreibung mit Use Cases
Die Sicht des Anwenders steht im Mittelpunkt
Planungs – und Analyseinformationen werden abgebildet
Komplexe Sachverhalte können beschrieben werden
Es gibt ein einheitliches Abstraktionsniveau
Abhängigkeiten werden erkannt
Es werden keine Informationen auf Vorrat erfasst

35. Systementwurf auf Basis der Spezifikation
Abbildung des Use Case Model auf ein Objektmodel
Sequenzdiagramme: In welcher Reihenfolge werden
Nachrichten zwischen den Objekten gesendet?
Tracebility:
Welche Use Cases werden in welchen
Designkomponenten abgebildet?
Wo wirken sich Änderungen von Use Cases aus?
Gibt es Designelemente, die keinem Use Case zugeordnet
sind?
Welche Use Cases beziehen sich auf ein Hauptobjekt?
Welche Use Cases werden von demselben Akteur in
demselben Arbeitsumfeld genutzt?
35

36. Realisierung in agilen Projekten
Product Sprint
Backlog Backlog
Gemeinsamer Programmcode des Teams
Feature-Burndown-Grafik
Kurze Buildzeiten (Smoke-Build)
Automatische Tests

37. Phasen in agilen Projekten
Vorstudie
Konzeption
Iterationsplanung
Iterationsdurchführung
Projektabschluss
37

38. Projektabschluss / Releaseabschluss
Gesamttest des Systems gegen das Gesamtmodel
Anwenderdokumentation erstellen
Auslieferung des Gesamtsystems
Inbetriebnahme des Systems
Abnahme des Systems
38

39. Requirements Engineering in agilen Projekten
Vorstudie Entscheidungsvorlage für
das Management
Konzeption Use Case Model
Objektmodel
Iterationsplanung Funktionsumfang der
nächsten Iteration
Iterationsdurchführung Detailspezifikation der
Use Cases und Klassen,
Systementwurf, Software
Abschlussphase Anwenderdokumentation
39

40. Vorteile des agilen Vorgehens
Iterationen beziehen die Realisierung der Software ein
Der Projektfortschritt ist transparent
Gleichmäßige Auslastung des Projektteams
Kontinuierliches Lernen durch Retrospektiven nach jeder
Iteration

41. Vielen Dank für Ihre Aufmerksamkeit!
Kontakt:
reinhard.brueggemeyer@gedoplan.de
www.gedoplan.de