Agiles Requirements-Engineering

supported by

sponsored by

Inhaltliche Entwicklung: Prof. Dr. Gerd Beneken, Hochschule Rosenheim Prof. Dr. Ulrike Hammerschall, Hochschule für angewandte Wissenschaften München

Autoren des Buches ‚Software Requirements‘, Pearson

User Story (Vorderseite)

User Story (Rückseite)

Vorgehen1. Finde Benutzer-Typen mit ähnlichem Verhalten

und ähnlichen Zielen! Beginne mit Überblick über die wichtigsten Aktivitäten/Schritte (Tasks) zur Erreichung ihrer Ziele.

2. Verfeinere/Schneide die Schritte zu detaillier-teren User Storys. Plausibilisiere den Ablauf, komplettiere die User Storys.

3. Ausbauplan erstellen: Gruppiere User Storys so, dass die Software iterativ ausgebaut werden kann. Beginnend bei dem wichtigsten Benutzer-Typ oder bei den wichtigsten Zielen.

4. Baue die User Storys entlang des Ablaufs aus.

„Gute“ User StorysEigenschaften nach B. Wake:

Independent (untereinander unabhängig)

Negotiable (verhandelbar)

Valuable (haben Geschäftswert)

Estimable (schätzbar)

Small (klein genug)

Testable (testbar)

http://xp123.com/articles/invest-in-good- stories-and-smart-tasks

Story Maps nach J. Patton

User Storys und Akzeptanzkriterien

Arbeiten mit User Storys

Anforderungen variabel, Budget und Termin fest

Agiles Requirements Engineering

Product Backlog

Stakeholder

Product Owner Verantwortlich für den

Produkterfolg

Scrum Master Verantwortlich für

den Prozess

Ermittlung (Elicitation) Entdecken von Anforderungen

KonsolidierungAnforderungen prüfen

und abstimmen

AnalyseEinordnen, Strukturieren,

Priorisieren

SpezifikationAnforderungen schriftlich,

strukturiert festhalten

Klassischer Requirements Engineering

Zyklus

Inkrement mit Funktionalität in neuer Produktversion

Tasks zur Realisierung der Anforderung

Sprint-Backlog mit User-Stories

Team

Sprint < 30 Tage

Entdecken von Anforderungen: Interviews, Workshops, Stakeholder Management, ...

Analyse von Anforderungen: Strukturieren nach Workflows, Priorisieren, Finden von größeren Features / Themen, Einordnen

Spezifikation von Anforderungen (light) Fachlicher Überblick, Datenmodelle, Workflows, Wireframes, … Zusätzlich zu den User Storys, Constraints

Konsolidierung von Anforderungen Product Owner muss Anforderungen mit anderen Stakeholdern abstimmen

„Guter“ Product Backlog:Eigenschaften nach R. Pichler

D etailed Appropriately Anforderungen erst kurz vor der Realisierung detailliert

E stimated Aufwand (ideale Personenstunden) oder Umfang (Story Points) geschätzt

E mergent wird ständig überarbeitet

P rioritized sortiert nach Priorität (Geschäftswert für den Kunden) Hohe Priorität = baldige Realisierung

http://www.romanpichler.com/blog/making-the-product-backlog-deep/

Änderungswünsche und neue Anforderungen aus Fragen und Feedback.

Erstellung eines Produktes mithilfe von Scrum

Techniken des klassischen Requirements Engineering leichtgewichtig anwendbar

Anforderungen zur Realisierung im nächsten Sprint

Prioritäten

Analysieren, verfeinern, schätzen, = Grooming

Validierte Anforderungen formuliert z.B. als User Storys,Constraints, ...

Just-In-Time Anforderungen vage festgelegt genau festgelegtReden, Diskutieren, Prototypen bauen

Schn

elle

s Fe

edba

ck

Klassisches RE Agiles RE

Epic Große User Story

Laufendes Skelett Minimale Menge an User Storys, sodass der Benutzer sein Ziel gerade eben erreicht

http://www.agileproduct-design.com/presentations/user_story_mapping/

Vollausbau Usability, Performance, Sexappeal

Epic Große User Story

User Story

User Story kurz vor Umsetzung

Ziele

hoch

Laufende Software niedrig

Theme

Schn

eide

n/ve

rfei

nern

Dri

nglic

hkei

t

Det

ails

, Tei

lsch

ritt

e

(Sub

-Tas

ks)

Benutzer erreicht Ziel(e) Schritt für Schritt mithilfe der Software

Aktivität

Task

User Story

User Story

User Story

Aktivität

Task

User Story

User Story

User Story

Task

User Story

User Story

Task

User Story

User Story

User Story

Aktivität

Task

User Story

User Story

User Story

User Story

Release 1

Release 2

Release 3

Release 4

Eindeutige Identifikation der User Story

Beispiel: Als Autor will ich einen geänderten Text speichern, sodass ich diesen später weiter bearbeiten kann.

Aufwand für die Realisierung

Priorität nach Geschäftswert: z.B. MUst, Should, COuld, Won’t

Als [Benutzerrolle] will ich [eine Aktivität ausführen], sodass [ein best. Ziel erreicht wird].

Titel der User Story

Größe: 5 Story Points Priorität: Must

# 4711

Beispiel: Datei des Autors ist schreibgeschützt → Fehlermeldung #3. Programm erkennt, dass Dokument geändert wurde ...

Beispiele, Testfälle, Szenarien, Sonderfälle ...

Akzeptanzkriterien

Anforderungen

Anforderungen

Termin

Termin

Budget

Budget

fest

variabel

Planung Kurz vor Realisierung

Sprint Planung zusammen mit Product Owner

24 h

Daily Scrum