ANFORDERUNGSANALYSE-UND-– Kapitel)3 SPEZIFIKATION

Software Technik

Prof. Dr. Wolfgang Schramm

ANFORDERUNGSANALYSE UND –SPEZIFIKATION

Kapitel 3

1

¨ Sie verstehen, warum der Anforderungsprozess wichtig ist.

¨ Sie lernen die verschiedenen Arten von Anforderungen kennen.

¨ Sie lernen, welche Tätigkeiten zum Anforderungsprozess gehören.

¨ Sie lernen, welche Personen an der Anforderungsphase beteiligt sind.

¨ Ihnen sind Anforderungs-‐vokabeln geläufig.

2

1. Einführung2. Begriffe3. Erheben und Analysieren4. Dokumentieren5. Management von Anforderungen6. Qualitätssicherung von

Anforderungen

3

Weg der Anforderungen (vereinfacht)

Kunde

Entwickler

Anforderungs-sammlung

Spezifikation Entwurf

Code

4

Beispiele für Anforderungen

R1: Die Bedienungsschnittstelle für den Hausbesitzer muss einfach zu handhaben sein.

R2: Das Hausinformationssystem soll monatlich eine Aufstellung der erlaubten und verweigerten Zugänge zum Hausinneren generieren.

R3: Ist die an der Tastatur des Zugangssystems eingegebene PIN korrekt, hebt das System die Sperre der Zugangstür auf und protokolliert den Zugang mit Datum, Uhrzeit und eingegebener PIN.

R4: Das System soll spätestens am 1.Mai 2009 auf dem Markt verfügbar sein.

R5: Die Freigabe des Schließungsmechanismus soll bei korrekt eingegebener Pin spätestens nach 0,8 Sekunden erfolgen.

aus [Poh08]

5

Anforderung: Definition

Eine Anforderung (requirement) ist:1. Bedingung bzw. Fähigkeit, die ein Anwender stellt bzw.

benötigt, um ein Problem zu lösen oder ein Ziel zu erreichen

2. Bedingung oder Fähigkeit, die ein System erfüllen bzw. besitzen muss, um einem Vertrag, einem Standard, einer Spezifikation oder einem anderen formalen Dokument zu genügen

3. Eine dokumentierten Darstellung einer Bedingung oder Fähigkeit aus 1. oder 2.

IEEE-Std. 610-1993

6

Anforderungen -‐ Arten

o Funktionale Anforderung (auch: Verhaltensanforderung)¤ definiert eine vom System oder einer Systemkomponente

bereitzustellende Funktion bzw. Service. ¤ engl.: functional requirements, FR

o Qualitätsanforderung¤ definiert eine qualitative Eigenschaft des Systems, einer

Systemkomponente oder einer Funktion.¤ Synonym: nicht-‐funktionale Anforderung¤ engl.: non-‐functional requirements, NFR

o Randbedingung¤ ist eine organisatorische oder technologische Anforderung, die die Art

und Weise einschränkt, wie ein Produkt entwickelt wird.¤ engl.: constraint

Pohl, Rupp: Basiswissen Requirements-Engineering, 2009

7

Funktionale vs. nicht-‐funktionale Anforderungen

o Die Abgrenzung zwischen nicht-‐funktionalen und funktionalen Anforderungen ist nicht scharf.

o Aus einer nicht-‐funktionale Anforderung…¤ Das System muss den unautorisierten Zugriff auf die

Kundenstammdaten verhindern.

o … wird durch Verfeinerung eine funktionale Anforderung ¤ Der Zugriff auf die Kundenstammdaten muss über eine Login-‐Prozedur

mit Passworten geschützt werden.

8

Nicht-‐funktionale Anforderungen

Quelle: ISO FDIS 21010 (2010)

Qualitätsmodell der ISO 21020(Nachfolger der ISO 9126)

9

Randbedingungen

o Organisatorische Anforderungen¤ Zu berücksichtigende Abläufe beim Kunden (Produkteinsatz)¤ Entwicklungsvorgaben, z.B. Prozess, Programmiersprache¤ Einsatzvorgaben, z.B. Betriebssystem, Datenbank

kann der Kunden festgelegen

o Externe Anforderungen¤ Regularien, z.B. FDA, Basel¤ Gesetze¤ Ethische Regeln

sind vom Kunden und vom Entwickler zu berücksichtigen

10

Inhalt

1. Einführung2. Begriffe3. Dokumentation4. Erhebung von Anforderungen5. Management von Anforderungen6. Qualitätssicherung von

Anforderungen

11

Vision vs. Ziele

o Vision¤ Informell, oft sehr abstrakt

o Ziel¤ SMART

nS pezifisch

nM essbar

nA ttraktiv

nR ealistisch

nT erminbezogen

Ziele sind hilfreich, um die Absichten der Stakeholder zu verstehen(=Grundlage, umAnforderungen zu verstehen).

13

Inhalt

1. Einführung2. Begriffe3. Dokumentation

SystemkontextNatürliche SpracheSzenario/Use CaseDrei PerspektivenAtomare AnforderungenTemplates/Gliederungen

4. Erhebung von Anforderungen5. Management von Anforderungen6. Qualitätssicherung von

Anforderungen

14

Systemkontext (1)

nach Pohl, Rupp: BasiswissenRequirements-Engineering, 2009

KontextgrenzeIrrelevante Umgebung

Systemgrenze

15

Systemkontext (2)

o Systemkontext besteht aus¤ Geschäftsprozessen¤ Technischen Prozessen¤ Personen¤ Organisationsstrukturen¤ IT-‐Infrastruktur (z.B. Datenbanken)

o System | Quellen | Senkeno „Grauzone“ der Systemgrenze

¤ Die Systemgrenze ist zunächst nicht klarn „breiter grauer Strich“

¤ Im Verlauf des RE wird klar, welche Funktionen im SW-‐System realisiert werden sollen

16

Systemkontext (3)

o Darstellung des Kontext: Kontext-‐Diagramme

Glinz, Vorlesung RE, Uni Zürich

alternativ:use case

17

Bedeutung des Systemkontexts

o Anforderungen¤ werden für einen bestimmten Kontext definiert.¤ Erst die Kenntnis des Kontexts macht die Anforderungen

interpretierbar und bestimmt den Umfang.

o Beispiel¤ Anforderung: Das geplante Beförderungsmittel soll den Reisenden eine

sichere und schnelle Reise zum Ziel ermöglichen.¤ Kontext: Personen sollen vom Festland auf eine Insel transportiert

werden. Die Insel hat keinen Platz für einen Flughafen.

à die Dokumentation des Kontexts ist notwendig

Kontext?

18

Inhalt




Anforderungen

19

Art der Darstellung der Anforderungen

Darstellung mit unterschiedlichem Formalitätsgrad.

o Texte in natürlicher Spracheo Strukturmodelleo Interaktionsmodelleo Formale Modelle auf der Grundlage mathematisch-‐logischer

Formalismen.

Graphisch, angereichert mit natürlicher Sprache

20

Natürliche Sprache

Die Qualität natürlich-‐sprachiger Anforderungsspezifikation lässt sich systematisch verbessern durch:¤ geeignete Strukturierung des Dokuments

n Gliederung, kommt später…

¤ Regeln zur sprachlichen Formulierung von Anforderungenn Satztemplate (1-‐Satz-‐Anforderung, Begründung),n shall/should bzw. muss/sollte.

¤ kontrollierten Umgang mit Redundanz¤ konsequente Verwendung eines Glossars

n (Fach-‐)Termini erklären.n Im Glossar Software/Software-‐Engineering-‐Begriffe vermeiden.

21

Diskussion

¨ Was halten Sie von folgendem Text

¨ Beschreibt er klar und deutlich, was zu entwickeln ist?

¨ Begründen Sie Ihre Ansicht mit entsprechenden Textstellen.

22

Anforderungsbeschreibung

Der Bediener drückt eine Wahltaste und bezahlt dengeforderten Betrag. Sobald die Summe der eingeworfenenMünzen den geforderten Betrag übersteigt, wird das Getränkzubereitet und ausgegeben. Ferner wird das Wechselgeldberechnet und ausgegeben. Der Bedienvorgang endet, wenndas Getränk entnommen wird und wenn die Bedienung fürlänger als 45s unterbrochen wird. Mit einer Annulliertastekann der Bedienvorgang jederzeit abgebrochen werden.Bereits eingeworfenes Geld wird beim Drücken derAnnulliertaste zurückgegeben. Nach dem Drücken einerWahltaste kann entweder bezahlt oder eine andereWahltaste gedrückt werden. Die zuletzt getätigte Auswahlgilt.

23

Anforderungsbeschreibung

Der Bediener drückt eine Wahltaste und bezahlt dengeforderten Betrag. Sobald die Summe der eingeworfenenMünzen den geforderten Betrag übersteigt, wird das Getränkzubereitet und ausgegeben. Ferner wird das Wechselgeldberechnet und ausgegeben. Der Bedienvorgang endet, wenndas Getränk entnommen wird und wenn die Bedienung fürlänger als 45s unterbrochen wird. Mit einer Annulliertaste kannder Bedienvorgang jederzeit abgebrochen werden. Bereitseingeworfenes Geld wird beim Drücken der Annulliertastezurückgegeben. Nach dem Drücken einer Wahltaste kannentweder bezahlt oder eine andere Wahltaste gedrückt werden.Die zuletzt getätigte Auswahl gilt.

24

Satztemplate (1)

Verbindlichkeit:bindend/empfohlen/zukünftig

Kern der Anforderung:<Prozesswort>

Das Systemtut etwasselbständig

Das Systemreagiert aufBenutzer-eingaben

Das Systemreagiert aufDaten oderSignale

Pohl, Rupp: Basiswissen Requirements-Engineering, 2009

25

Satztemplate (2)

o Prozessworte¤ z.B. drucken, berechnen, speichern, übertragen

o Prozessworte benötigen i.d.R. Objekt und Ergänzung¤ z.B. übertrage Temperaturdaten vom Sensor zur Datenbank

n (3 Objekte)

¤ z.B. drucke Rechnungsdaten in formatierter Form (Vordruck 7b)n (1 Objekt, eine Ergänzung)

o Anforderungen können Bedingungen enthalten¤ z.B. falls die Temperatur unter 1°C fällt, …

n konditional: falls …n temporal: sobald …

vermeide „wenn“(kann konditionaloder temporal sein)

26

Diskussion

¨ Schreiben Sie zwei Anforderungen für Getränkeautomaten unter Verwendung des erweiterten Templates

27

Einleitung Begriffe Dokumentation Erheben Management Qualitätssicherung

Der Bediener drückt eine Wahltaste und bezahlt den geforderten Betrag. Sobald die Summe der eingeworfenen Münzen den geforderten Betrag übersteigt, wird das Getränk zubereitet und ausgegeben. Ferner wird das Wechselgeld berechnet und ausgegeben. Der Bedienvorgang endet, wenn das Getränk entnommen wird und wenn die Bedienung für länger als 45s unterbrochen wird. Mit einer Annulliertaste kann der Bedienvorgang jederzeit abgebrochen werden. Bereits eingeworfenes Geld wird beim Drücken der Annulliertastezurückgegeben. Nach dem Drücken einer Wahltaste kann entweder bezahlt oder eine andere Wahltaste gedrückt werden. Die zuletzt getätigte Auswahl gilt.

28

Inhalt




Anforderungen

29

Szenario

o Beschreibt ein konkretes Beispiel für die Erfüllung bzw. Nichterfüllung eines oder mehrerer Ziele.

o Enthält typischerweise eine Folge von Interaktionsschritten und setzt diese in Bezug zum Systemkontext.

o Meist in natürlicher Sprache.o Sind gut geeignet um Information über den Kontext zu

dokumentieren.¤ Personen oder andere Systeme, die mit dem System interagieren.¤ Vorbedingungen, die zu Beginn des Szenarios erfüllt sein müssen.¤ Reale oder imaginäre Örtlichkeiten, in der die Ausführung eines

Szenarios stattfindet¤ ….

30

Beispiel Szenario

Karl möchte mit seinem PKW zum Potsdamer Platz 1 nach Berlin fahren. Karl benutzt das Navigationssystem des Fahrzeugs, um die kürzeste Wegstrecke zu ermitteln. Er wählt „Ziel eingeben“. Das Navigationssystem zeigt im Display „Bitte Ort nennen oder manuell eingeben“ an. Karl wählt die Spracheingabe und spricht „Berlin“. Aufgrund von Hintergrundgeräuschen und der schlechten Aussprache erkennt das System das Wort nicht eindeutig. Es zeigt das wahrscheinlichste Wort an: „Schwerin“. Es zeigt zudem an „Ihre Eingabe konnte nicht eindeutig erkannt werden“ sowie die folgenden Interaktionsmöglichkeiten:¤ Zielort akzeptieren (ja/nein)¤ Neueingabe (neu)¤ Ähnliche Ort anzeigen (ähnlich)¤ Manuelle EingabeKarl spricht „ähnlich“, und das System listet die Orte „Schwerin“, „Berlin“ etc. auf. Karl spricht „Berlin“ und das System wählt Berlin als Zielort aus.

31

Arten von Szenarien

o Ist-‐Szenarien beschreiben die Situation mit dem gegenwärtigen System¤ zum Beispiel, um es gegen zukünftige Anforderungen abzugrenzen.

o Visionäre Szenarien beschreiben ein künftiges System¤ Kommunikationsmedium, "preiswerter Prototyp“.

o Bewertungsszenarien dienen der (späteren) Evaluierung des Systems¤ Status-‐Bewertung, Usability, Akzeptanztest,¤ Bewertung der Architektur.

32

Regeln zur Formulierung von Szenarien (1)

o Sprache/Grammatik1. Schreiben Sie Szenarien in der Gegenwartsform.2. Schreiben Sie Szenarien in der Aktivform.3. Schreiben Sie in einfachen Sätzen.4. Vermeiden Sie Modalverben (z.B. müssen, können, sollen, wollen,

mögen, dürfen).

o Struktur5. Trennen Sie jede Interaktion deutlich von anderen Interaktionen.

Pohl, Requirements Engineering – Grundlagen, Prinzipien, Techniken, 2008

33

Regeln zur Formulierung von Szenarien (2)

o Inhalt6. Beschreiben Sie aus dem Blickwinkel eines Außenstehenden.7. Benennen Sie explizit die Akteure.8. Benennen Sie das Ziel des Szenarios explizit.9. Fokussieren Sie bei der Szenariobeschreibung auf die Erfüllung des

Ziels.

34

Fragen zur Erstellung (visionärer) Szenarien

o Welches Ziel verfolgt der Akteur?o Was sind die Aufgaben, die der Akteur vom System erwartet?o Auf welche Informationen greift der Akteur zu?

Wer generiert diese Informationen?o Über welche externen Änderungen muss der Akteur das

System informieren?o Über welche Ereignisse muss das System den Akteur

unterrichten?

35

Use Case

o Deutsch: Anwendungsfallo Zur strukturierten Dokumentation

der Funktionalität existierender oder geplanter Systemedurch Interaktionsfolgen

o Besteht aus¤ Use Case-‐Diagramm Übersichtsbild¤ Use Case-‐Spezifikation Tabelle

36

Beispiel: Use Case-‐Diagramm

o UML Use Case-‐Diagramme zeigen,¤ welche Anwendungsfälle

(= welche Funktionalität)ein System bietet und

¤ wer diese in Anspruch nehmen kann

37Beispiel: Use Case HebeGeldAb (1)

Anwendungs-fallname

Geld abheben

Akteure KundeZiel Geld vom Konto abhebenHauptablauf 1. Der Kunde meldet sich mit seiner Kontonummer/PIN am

Geldautomaten an.2. Das System überprüft die Identität.

3. Der Kunde gibt einen Betrag ein und wählt eine Währung aus.4. Das System überprüft, ob die Währung vorrätig und der Betrag

auf dem Konto verfügbar ist;; es zeigt den Auszahlungsbetrag sowie die Belastung des Kontos an

5. Der Kunde …5a. …bestätigt die Angaben.

6a. Das System bucht den Betrag ab und zahlt ihn aus.5b. …bricht den Vorgang ab

6b. Das System bestätigt den Abbruch.7. Der Kunde meldet sich ab.

8. Das System gibt eine Anmeldungsseite aus.

38

Ausnahme-abläufe

Ausnahme in 2.: Kontonummer unbekannt101. Das System gibt die Fehlermeldung „Kto-Nr. unbekannt“ aus;;weiter mit 8.

Ausnahme in 4.: Währung nicht verfügbar201. Das System gibt die Fehlermeldung „Währung nicht

verfügbar“ aus;;weiter mit 3.

Ausnahme in 4.: Konto hat keine ausreichende Deckung301. Das System gibt die Fehlermeldung „Betrag nicht verfügbar“

aus;;weiter mit 3.

Ausnahme in 3/5/7: längere Zeit keine Aktion durch Kunde (timeout)401. Das System meldet den Kunden ab.weiter mit 8.

Anfangs-bedingungen

Kunde hat ein Konto bei dem Geldinstitut

Abschluss-bedingungen

Der Kunde hat den gewünschten Betrag erhalten ODERer bekam eine Meldung, warum die Auszahlung nicht möglich war

Qualitäts-anforderungen

Ein Nutzer der häufiger am Automaten Geld abhebt soll von Beginn der Aktion bis zur erfolgreichen Auszahlung von Geldes nicht länger als 90 s benötigen.

Beispiel: Use Case HebeGeldAb (2)

39

Elemente von Use Case-‐Diagrammen

System mitSystemgrenze

Name

Akteur (Person)

Name Use Case

Name

Akteur (System)

Name

A

B A

B

Name

Name

erweitert

inkludiert

kommuniziert

Objekte Beziehungen

«extend»

«include»

«system»

A

B

generalisiert

40

Beispiel für „include“

Geldabheben

Kundenauthentif.

«include»1. Include: Kunden authentif.2. Kunde gibt Währung und Betrag ein3. System prüft …

Kundenauthentif.

per PINauthentif.

per mTANauthentif.

1. Kunde gibt Kontonummer an2. Kunde authentifiziert sich

1. Kunde gibt Kontonummer an2a. System generiert TAN und sendet SMS

2b. Kunde gibt TAN ein…

41

Anleitung für Use Cases (1)

o Use Cases sollen mit Verbalphrasen beschrieben werden. Der Name sollte anzeigen, was der Anwender bewirken möchte.¤ z.B. MeldeVorfall

EröffneVorfall

o Akteure sollen mit Nominalphrasen benannt werden.¤ z.B. Außenbeamter

Dienstleiter

42


o Bzgl. dem Ereignisfluss:¤ Die Systemgrenzen sollen klar sein.

n Arbeitsschritte des Akteurs und Arbeitsschritte des Systemssollen gekennzeichnet sein.

n z.B. Der Dienstleiter ….Das System …

¤ Die einzelnen Schritte im Ereignisfluss sollten im Aktivstil geschrieben sein, um deutlich zu machen, wer diese vollziehtn z.B. Der Dienstleiter überprüft…

Der Außenbeamte hat ... empfangen...Das System berechnet…

¤ Die ursächliche Beziehung zwischen aufeinander folgenden Schritten soll klar sein.

Einrücken derSystemarbeitsschritte

43


o Ein Anwendungsfall soll die vollständige Transaktion eines Anwenders schildern.

o Ein Anwendungsfall sollte im Idealfall nicht länger als eine Seite sein.

Use case vs. SzenarioRolle vs. Name

Akteur-initiiert/ vs. beliebiger (Teil-)AblaufTransaktion

vollst. Aufgabe vs. spezieller Ablaufeine Aufgabe vs. viele Aufgaben

44

Diskussion

¨ Schreiben Sie das Beispiel des Getränkeautomaten zu einem Use Case¤ „Getränk kaufen“

um!¨ Benutzen Sie das verteilte

Schema!

45

Der Bediener drückt eine Wahltaste und bezahlt den geforderten Betrag. Sobald die Summe der eingeworfenen Münzen den geforderten Betrag übersteigt, wird das Getränk zubereitet und ausgegeben. Ferner wird das Wechselgeld berechnet und ausgegeben. Der Bedienvorgang endet, wenn das Getränk entnommen wird und wenn die Bedienung für länger als 45s unterbrochen wird. Mit einer Annulliertastekann der Bedienvorgang jederzeit abgebrochen werden. Bereits eingeworfenes Geld wird beim Drücken der Annulliertaste zurückgegeben. Nach dem Drücken einer Wahltaste kann entweder bezahlt oder eine andere Wahltaste gedrückt werden. Die zuletzt getätigte Auswahl gilt.

46

Fragerunde

¨ Welche Unterschiede sehen sie zwischen Szenarien und UseCases?

¨ Wann setzen Sie Szenarien, wann Use Cases ein?

47

Szenario versus Use Case

o Ein Szenario ist kontextreicher:¤ Kann mehrere Anwendungsfälle in Beziehung setzen.¤ Kann aber auch eine konkrete Ausgestaltung eines Anwendungsfalls

sein.

o Ein Anwendungsfall ist allgemeiner.o Ein Anwendungsfall wird immer von einem Akteur initiiert.o Ein Szenario kann das Zusammenspiel mehrerer Akteure

darstellen.

48

Inhalt




Anforderungen

49

3 Perspektiven

Anforderungen

Funktion

• Ein-/Ausgabe-Daten

• Nutzungs-beziehungenSystem/ Systemkontext

Systemverhalten/ zustandsbasiert,z.B. Reaktion auf Signale von außen

Informationsflusszwischen Systemund Systemkontext

Zweck:• „verfeinern“ von UseCases

• Aufzeigen von Zusammenhängen zwischen Use Cases

50

zur Funktion: Datenflussdiagramme (DFD)

o ... zeigen den Datenfluss eines Prozesses oder einer Tätigkeit (z. B. die Datenverwendung und Veränderung bei der Angebotserstellung in einem Handelsunternehmen).

o ... geben eine funktionale Perspektive des Systems wieder.o ... sind nützlich um die Abfolge von Aktionen zu

verdeutlichen.¤ vom Input (Eingabe des Anwenders)¤ bis zum Output (Ausgabe des Systems)

51

Beispiel DFD

http://www.visualcase.com/tutorials/images

52

Datenflussdiagramme -‐ Notation

Name

Datenfluss

Input/Output (Terminator)

Funktion (Prozess)

Datenbank (File)

Name

Name

Name

53

Diskussion

¨ Zeichnen sie das Datenflussdiagramm einer Insulin-‐Pumpe. Sie enthält einen Sensor, der den Blutzucker bestimmen kann und injiziert automatisch die richtige Dosis Insulin.

54

Insulin-‐Pumpe

Blood Sugar Sensor

Insulin RequirementComputation

Blood SugarAnalysis

Insulin DeliveryControllerInsulin Pump

BloodBlood

Parameters Blood SugarLevel

InsulinRequirement

Pump ControlCommandsInsulin

Sommerville, Software Engineering, 2010

55

Fragerunde

¨ Welche Notationen kennen Sie, um¤ Verhalten¤ Struktur

in der Anforderungsphase zu verdeutlichen?

56

3 Perspektiven

Anforderungen

Funktion

• Ein-/Ausgabe-Daten

• Nutzungs-beziehungenSystem/ Systemkontext

Systemverhalten/ zustandsbasiert,z.B. Reaktion auf Signale von außen

Informationsflusszwischen Systemund Systemkontext

E/R-DiagrammKlassendiagramm

StatechartsZustandsdiagramm

DatenflussdiagrammAktivitätsdiagramm

57

Inhalt




Anforderungen

58

Beispiel: Atomare Anforderungen / Snow Card FR

Anforderungsnummer: 75o Typ der Anforderung: Funktionale Anforderungo Beschreibung: Das Produkt löst einen Alarm aus, wenn die

Wetterstation die eingelesenen Daten nicht übertragen kann. o Rational: Fehler bei der Übermittlung von Daten können ein

Hinweis auf einen Defekt in der Wetterstation sein, die evtl. Wartung benötigt. Die Daten zur Vorhersage des Straßenlage können aus diesem Grund unvollständig sein.

o Quelle: Karl-‐Heinz Müllero Fit Kriterium: Für mindestens eine Wetterstation soll die Anzahl der

pro Stunde übermittelten Daten unterhalb des durch den Hersteller definierten Wertebereiches liegen.

o Event/Use Case: UC 3.4 WerteÜbertragen o Priorität: Hocho Konflikte: Keineo Andere Materialien: Herstelleranleitung der Wetterstation IN34.67

Robertson & Robertson, Mastering the Requirements Process, 2008

59

Atomare Anforderungen

Sollten folgende Information beinhalten:o Anforderungsnummer: ein eindeutiger Identifier, zur

Zuordnung/Verfolgbarkeit über den gesamten Life-‐Cycle.o Typ der Anforderung: Constraint, Funktionale Anforderung, Nicht-‐

funktionale Anforderung.o Beschreibung: der Inhalt der Anforderung.o Rational: Die Motivation/Begründung hinter der Anforderung.o Quelle: Person, die die Anforderung zum ersten Mal erwähnt hat.o Fit Kriterium: Die messbare Beschreibung der Anforderung, die erlaubt zu

überprüfen, ob die Anforderung erfüllt ist.o Event/Use Case: Verweis auf den Geschäftsvorfall, aus dem die

Anforderung erwachsen ist.o Priorität: Wie wichtig ist die Anforderung im Hinblick auf das gesamte

Produkt?o Konflikte: Gibt es Anforderungen, denen die Anforderung widerspricht?o Andere Materialien: Verweis auf Dokumente oder andere Artefakte, die

für diese Anforderung von Bedeutung sind.

60

Beschreibung NFRs

Typisches Vorgehen: o Fragen stellen

¤ Wie fehlertolerant soll das System sein?

o Antworten quantifizieren mit Maßen und Abnahmebedingungen ¤ direkte Maße:

n Die Fehlertoleranz wird in MTTF gemessen und soll grösser als 106 Betriebsstunden sein.

¤ indirekte Maße: n Die Bedienung des System gilt als erlernbar, wenn pro Person nicht mehr als zwei Tage Schulung aufgewendet werden müssen.

n Für jede Hauptfunktion beträgt der Lernaufwand für ihre erfolgreiche Anwendung im Mittel weniger als eine Stunde.

61

Regeln zur Formulierung von NFRs

1. Formulieren Sie NFRs kurz und prägnant. 2. Verwenden Sie Aktivformulierung.3. Formulieren Sie überprüfbare NFRs.4. Verfeinern Sie nicht überprüfbare NFRs.5. Formulieren Sie den Mehrwert einer NFR.6. Geben Sie eine Begründung für die NFR an.7. Vermeiden sie Lösungsansätze.

62

Diskussion

¨ Welche Regel wird mit dem folgenden NFRs verletzt?

¨ Finden sie eine bessere Formulierung.

1. Das geplante System soll intuitiv benutzbar sein

2. Das geplante System soll besser sein als sein Vorgängersystem

3. Die Dauer für die Erstellung von Quartalsberichten soll im Vergleich zum Vorgängersystem halbiert werden.

4. Durch komplexe Datenübertragung soll das geplante System um 10% kürzere Antwortzeiten aufweisen als sein Vorgängersystem

63

Beispiel: Atomare Anforderungen / Snow Card NFR

Anforderungsnummer: 43o Typ der Anforderung: Nicht-‐Funktionale Anforderungo Beschreibung: Das System ist von 10-‐jährigen Kindern zu bedieneno Rational: das System ist für Kinder vorgesehen, die die Grundschule

absolviert habeno Quelle: Karl-‐Heinz Müllero Fit Kriterium: 80% der Testgruppe von 10-‐jährigen können sich

innerhalb 2 Minuten erfolgreich registrieren; 90% der Testgruppe… o Event/Use Case: UC 1/Registrierung; UC 3/…o Priorität: Hocho Konflikte: Keineo Andere Materialien: keine

Robertson & Robertson, Mastering the Requirements Process, 2008

64

Fragerunde

¨ Wir haben über Use Cases, Perspektiven und atomare Anforderungen gesprochen… beschreiben wir alle Anforderungen mehrfach?

65

Inhalt




Anforderungen

66

Rahmenwerke für Anforderungsdokumente

o VDI/VDE Standard 3694: Referenzstruktur für Lasten-‐ und Pflichtenheft

o IEEE Standard 1233-‐1998: Referenzstruktur für Systems Requirements Spezifikationen

o IEEE Standard 830-‐1998 für Software Requirements Spezifikationen

o Volere Template von Robertson & Robertsonhttp://www.volere.co.uk/template.htm

o Template von Sören Lauesenhttp://www.itu.dk/people/slauesen/Papers/RequirementsSL-‐07.doc

67

Qualitätskriterien für Anforderungsartefakte

o eindeutig / verständlich „klar“ Clarityo vollständig „komplett“ Completenesso konsistent Consistencyo korrekt Correctness

o nachvollziehbaro überprüfbaro bewertet / abgestimmto modifizierbar / erweiterbar / verfolgbar

Gilt für• einzelne Anforderungen• das ganze Dokument!

+

70

Glossar

o Zweck¤ konsistente Terminologie aller

Beteiligten

o Inhalt¤ kontextspezifische Fachbegriffe

n ggf. Alltagsbegriffe mitspezieller Bedeutung

n Bsp.: „Medien“bei techn. Betriebsleitung

¤ Abkürzungen/Akronyme¤ Synonyme/Homonyme

71

Regeln für Glossar

o zentral verwalteto eine Person verantwortlicho projektbegleitend gepflegto allgemein zugänglicho verbindlich verwendeto Quelle der Begriffe angegebeno abgestimmt mit allen Stakeholderno einheitlich strukturiert

Glossar istzwingendnotwendig

72

Personas (1)

Zur Beschreibung der Zielgruppe/Nutzergruppe

73

Personas (2)

o Individualisierung¤ Foto, Name

o Biographie¤ Geographisch

n Region, Klima, Stadt/Land, …

¤ Demographischn Geschlecht, Alter, Familienstand, Generation, Ausbildung, Beruf, Einkommen, …

¤ Psychographischn Klasse, soziale Rolle, Herangehensweisen, Lifestyle, Hobbies, …

Persona enthält nurfür dasProjektrelevanteInformationen

74

Personas (3)

o Beziehung zum Produkt¤ Bedeutung (im Vergleich zu anderen Personas)¤ Ziele

n Motivation, versteckte Ziele, Einstellung zur Aufgabe, …

¤ Fähigkeitenn Anwendungsdomäne, Computernutzung, Internetnutzung, …

¤ Nutzungskontextn Nutzungsrolle, Umgebung, besondere Anforderungen (Sicherheit, Verfolgbarkeit, Genauigkeit)

¤ Einstellung/Stimmungn Aktiv/passiv, modern/traditionell, …

75

Geschäftsprozesse (1)

o Kunden möchten keine Software,sondern Lösungen.

o Lösungen helfen Kunden,ihre Aufgaben effektiver/effizienter zu erfüllen.

o Lösungen (hier: Software-‐Lösungen) werden mit Anforderungen beschrieben.

o Wie kommen wir von Aufgaben zu Anforderungen?(wie wir von Anforderungen zu Software-‐Lösungen kommen wissen Sie [demnächst])?

Geschäftsprozesse

76


Notation: BPMN

77


Geschäftsprozessmodellierung

• Übergang zuSystemanforderungsbestimmung und –analyse§ Aufgaben / Aktivitäten markieren,

die mit Systemunterstützung ablaufen sollen

Antragsdatenerfassen

Schufa-Ausk.einholen

Kontoeinrichten

«system support»Antragsdatenerfassen

Schufa-Ausk.einholen

«system support»Konto

einrichten

1. Antragsdateneingeben2. Datenprüfen

3. Zulässigkeitbestätigen4. Kontoeinrichten

Anforderung

78

Inhalt




Anforderungen

79

Inhalt

1. Einführung2. Begriffe3. Dokumentation4. Erhebung von Anforderungen

QuellenMethoden

5. Management von Anforderungen6. Qualitätssicherung von

Anforderungen

80

RE-‐Prozess: Anforderungsbestimmung

Durchführbar-keitsstudie

Bestimmung und Analyse der Anforderungen

Validierung der Anforderungen

Spezifikation der Anforderungen

Durchführbar-keitsbericht

Benutzer- undSystem-anforderungen

System-modelle

Pflichtenheft

nach [Som01]

81

Anforderungsbestimmung und –analyse – im Detail

Verstehen desAnwendungs-bereichs

Anforderungs-überprüfung(Validierung)

Setzen von Prioritäten

Konfliktlösung

Klassifizierung


Pflichtenheft

Anforderungs-spezifikation unddokumentation

Prozessbeginn

82

Anforderungsbestimmung: was ist zu beachten?

Es gibt keinen idealen RE-‐Prozess.à Zuschneiden auf konkrete Projektsituation.Zu berücksichtigende Faktoren:

¤ Zugrunde liegendes Prozessmodell (lineares oder inkrementelles Vorgehen)?

¤ Muss die Spezifikation wasserdicht sein (Vertrag; Realisierung durch Dritte)?

¤ Sind die Kunden/Benutzer bekannt und können sie in die Erstellung derSpezifikation einbezogen werden?

¤ Wird das zu spezifizierende System im Kundenauftrag oder für den Marktentwickelt?

¤ Soll Standardsoftware zum Einsatz kommen?

83

Erhebung von Anforderungen (1)

o Der schwierigste Schritt der Anforderungsphase.o Geht über das Abfragen von Wissen hinaus.o Die Quellen sind zu Beginn der Anforderungsphase oft nicht

bekannt.o Beinhaltet häufig auch die Generierung einer neuen Idee

(insbesondere bei innovativen/neuen Produkten).

84

Abbilden oder Gestalten?

o Weder¤ … dem Kunden genau das liefern, was er wünscht.

o Noch¤ „…wir wissen schon, was gut für den Kunden ist“.

Innovation initiieren!n Den Beteiligten innovative Lösungen vorschlagen.n Kreativität der Beteiligten anregen

n Zukunftsszenarien entwerfen und durchspielen.n Beschränkungen in Frage stellen und sich von „alten Zöpfen“ verabschieden.n Metaphern suchen und explorieren.

85

Erhebung von Anforderungen (2)

o Wissen sammeln über¤ Beteiligte Stakeholder und ihre Ziele¤ Nutzeraufgaben¤ Gegenwärtige Situation (Ist-‐Situation)¤ Erwartungen¤ Wissen über die Domäne

86Anforderungsquellen

o Stakeholder¤ Beobachten¤ Interviews¤ Workshops

o Dokumente¤ Allgemeine, z.B. Normen, Gesetze, Branchenstandards¤ Spezifische, z.B. „alte“ Anforderungsdokumente, Fehlerberichte

o Laufende Systeme¤ Alt-‐/Vorgängersystem¤ Konkurrenzsystem

87Probleme bei der Erhebung (1)

88

Probleme bei der Erhebung (2)

o Kommunikation ¤ Stakeholder sind oft nicht in der Lage genau zu beschreiben, was sie

tun, warum sie es tun oder was sie gerne tun würden .

o Berücksichtigung aller Stakeholder

o Aufzeigen neuer Möglichkeiten¤ Stakeholder verhaften gerne an alten Gewohnheiten und Vorgängen.

o Konflikte¤ Zwischen Stakeholdern mit unterschiedlichen Interessen.

¤ Widerstand gegen Veränderungen.

o Prioritäten & Veränderungen¤ Stakeholder wollen zu viel.

¤ Stakeholder ergänzen ständig.

89Stakeholders …

Stakeholder sind alle,die ein Interesse an dem Produkt haben.

¤ Sie bezahlen es.¤ Sie bauen es.¤ Sie nutzen es (heute, morgen).¤ Sie verwalten es.¤ Sie sind durch das Produkt in irgendeiner Weise betroffen.

90

Alle Stakeholder berücksichtigen

o Wer verwendet die Services, die das System zur Verfügung stellt?

o Wer stellt Services zur Verfügung, die im System benötigt werden?

o Welche Systeme haben direkte Schnittstellen zum zu spezifizierenden System?

o Welche Personen sind an der Entwicklung und Wartung beteiligt?

o Wer kennt die Marktbedürfnisse?o Wer kennt/verantwortet das externe Image der Organisation?

91

Fragerunde

¨ Denken Sie an den Getränkeautomaten:Wer sind Stakeholder?

92

Inhalt

1. Einführung2. Begriffe3. Dokumentation4. Erhebung von Anforderungen

QuellenMethoden

5. Management von Anforderungen6. Qualitätssicherung von

Anforderungen

94

Erheben von Anforderungen

o Interview

o Fokus-‐Gruppe

o Beobachtung

95

Weg der Anforderungen (vereinfacht)

Kunde

Entwickler


Spezifikation Entwurf

Code

96

Kommunikation

Objektive Realität Persönliche Realität

Wahrnehmung

Linguistischer Ausdruck

Darstellung Interpretation

Ergebnis

Kunde / Anwender Requirements Engineer

97

Arten von Interviews: Grad der Formalität (1)

¤ Offenes Interview

n Offene Fragen.

n Analyse der Daten ist schwierig.

n Erfordert gute Interview-‐Fähigkeiten.

n Persönlichkeit hat Einfluss auf das Ergebnis.

¤ Halb-‐strukturiertes Interview

n Wird durch vorformulierte Interviewfragen

geleitet.

n Wird an Hand von Themen gegliedert.

n Lässt Raum für spontane Abschweifungen

/Ergänzungen.

98

Arten von Interviews: Grad der Formalität (2)

¤ Strukturiertes Interview

n Hohes Maß an Objektivität.

n Erlaubt den einfachen Vergleich zwischen

verschiedenen Interviews.

n Erlaubt quantitative Auswertung.

n Keine Freiheiten in der Interviewführung, enge

Führung.

99

Interview Durchführung

1. VorbereitungVorliegende Dokumente studieren.Fragen vorbereiten.

2. DurchführungWenn möglich mit zwei Interviewenden.Evtl. Aufnahme des Interviews auf Band.

3. Eröffnung des InterviewsWofür ist das Interview. Was passiert mit den Antworten.

4. Die FragenAm Anfang eher allgemein, später spezifischer.Eine Mischung aus offenen und geschlossenen FragenAktives Zuhören.Achtung: Auch nonverbale Kommunikation ist von Bedeutung.

5. AbschlussWie geht es weiter.Die interviewte Person hat das letzte Wort.

100

Beispiel: Nach dem „WARUM“ fragen (1)

Neurologische Diagnostik -‐ Interviewo Das System soll ein Mini-‐Keyboard haben mit Start und Stop

Knopf….o WARUM?o Man soll es mit der linken Hand bedienen könneno WARUM?o Beide Hände sind in der Nähe des Patienteno WARUM?o Schmerzhaft für den Patienten, Elektroden, …..o …

101Beispiel: Nach dem „WARUM“ fragen (2)

Neurologische Diagnostik -‐ Anforderungsdokumento Kontext: Neurologische Messungen sind schmerzhaft für den

Patienten. Die Elektroden müssen während der Messung fixiert bleiben. Beide Hände müssen während der Messung in der Nähe des Patienten sein .

o WAS -‐ Anforderung: Beginn und Ende der Messung müssen bedient werden können, während beide Hände in der Nähe des Patienten sind.

o WIE -‐ Anforderung: Start und Stopp werden mit einem Fußpedal oder mittels Sprachsteuerung angesteuert.

102Interview-‐Effekte

Wechselwirkung zwischen Befragtem und Fragendem.

103

Interview-‐Effekte – Soziale Erwünschtheit

o Soziale Erwünschtheit liegt vor, wenn Befragte Antworten geben, von denen sie glauben, sie träfen eher auf Zustimmung als die korrekte Antwort, bei der sie soziale Ablehnung befürchten.

Wie oft trinken sieAlkohol?

Durchschnitt-lich viel!

Ähm... 2 x pro Woche ein

Glas!

.

104Interview-‐Effekte – Halo Effekt

o Beim Halo-‐Effekt erzeugen einzelne Eigenschaften einer Person einen Gesamteindruck, der die weitere Wahrnehmung der Person "überstrahlt".

Attraktiv

= reich

= intelligent

105Recency-‐ Effekt

o Der Recency-‐Effekt ist ein psychologisches Gedächtnisphänomen, welches dazu führt, dass später (recency) erfasste Information gegenüber anderer eingehender Information bevorteilt wird.

106

Fokus Gruppe (1)

Quelle: Krueger & Mary, 2003, „Focus Groups“, Sage Publ., London

hier:Stakeholder(insbesondere

Nutzer)

Krueger & Mary,, „Focus Groups“, Sage Publ., London, 2003

107

Fokus-‐Gruppe (2)

o Mit Problemen beginnen¤ Flipchart, Kartenabfrage¤ Gründe sammeln

o Dann auf Lösung fokussieren¤ Gruppierung der gesammelten Punkte

n ca. 40 Punkte

¤ Priorisierungn Bspw. 10 Punkte klebenn Bspw. in Gruppen je nach Stakeholder-‐Rolle

o Abschluss mit einer Zusammenfassung der Ergebnisse

108

Fokus-‐Gruppe (3)

o Geeignete Methode, wenn: ¤ noch zu wenig Informationen über die Nutzer, deren Aufgaben, den

Kontext und die Domäne vorhanden ist.¤ sehr viele Ideen vorhanden sind und diese bewertet werden müssten. ¤ verschiedene Perspektiven und Standpunkte besser verstanden

werden sollen. ¤ weitere Eigenschaften einer Fokus-‐Gruppe genutzt werden sollen, z.B.

Vertrauensbildung, Kundenorientierung

o Mögliche Nachteile¤ Diskussionen schwer zu analysieren/leicht fehl-‐zu-‐interpretieren.¤ Teilnehmer „zu freundlich“/nicht realistisch.

109Beobachtung (1)

o Anwender im Kontext beobachten.o Arbeitsumgebung, Kommunikationswege, Geräte.o Arbeitsartefakte.

110

Beobachtung (2) Site Visits

o Idee¤ Site Visits¤ Beobachtung der Stakeholder in ihrer realen Umgebung

(evtl. auch Kamera, Computer Monitoring)

o Ziele¤ Erfassen von implizitem Wissen¤ Identifikation versteckter Anforderungen¤ Besseres Verständnis des Kontextes

o Geeignete Methode¤ für die Entwicklung neuer Produkte oder

in neuen Marktsegmenten

111

Inhalt


Anforderungen

112

Management

o Attributierung / Sichten¤ Attribute: Nr, Id, Name, Version, Quelle, Verantwortlicher, Stabilität,

Priorität, Validierungsstatus, Abstimmungsstatus, Release¤ Sichten: Auswahl von Anforderungen nach Attribut-‐Wert

o Priorisierung à im Folgendeno Verfolgung à im Folgendeno Versionierung

¤ Version einzelner Anforderungen¤ Konfiguration aller Anforderungen

n „zusammenpassende Versionen“ der Anforderungen

o Verwaltung von Änderungen à im Folgenden

„Verwalten von Attributen“

113

Inhalt

1. Einführung2. Begriffe3. Dokumentation4. Erhebung von Anforderungen5. Management von Anforderungen

1. Priorisierung2. Verfolgung3. Verwalten von Änderungen

6. Qualitätssicherung von Anforderungen

114Priorisierung

Ist nötig bei …o harten Terminen.o harten Preisobergrenzen.o Beschaffung.o Festlegen von Inhalt und Umfang der Inkremente bei inkrementeller

Entwicklung.o Releaseplanung bei der Weiterentwicklung bestehender Systeme.

Zeitliche und finanzielle Restriktionenerlauben es meist nicht,alle Anforderungen

mit der gleichen Intensität zu beachten.

117

Techniken zur Priorisierung: IEEE 830-‐1998

o Eine Kriterien-‐Klassifikation¤ Mandatory

n Anforderungen müssen umgesetzt werden, um den Erfolg zu gewährleisten.

¤ Optionaln Anforderungen, die zwar wichtig sind, deren vereinzeltes Fehlen im System den Erfolg nicht gefährdet.

¤ Nice-‐to-‐haven Anforderungen, deren Fehlen im System den Erfolg des Systems nicht gefährdet.

Beobachtung: Meist starke Häufung in der Klasse „Mandatory“

118

Inhalt




119

Nachvollziehbarkeit von Anforderungen (1)

o Ziel¤ Beherrschen der Evolution der Anforderungen.

n Anforderungen stabil halten.n Veränderung kontrolliert zulassen.

o Maßnahme¤ „Konfigurationsmanagement“ für Anforderungen

n Anforderungen einzeln identifizierbar machen.n Geordneter Änderungsprozess.n Klare Zuständigkeiten und Verantwortlichkeiten.n Rückverfolgbarkeit aller Entscheidungen und Änderungen.

engl.: Traceability

120Nachvollziehbarkeit von Anforderungen (2)

o Im Entwicklungsprozess nachvollziehen ¤ des Ursprungs der Anforderungen¤ der Verwendung der Anforderung

Vorgelagerte Artefakte Anforderungen Nachgelagerte

Artefakte

Pre-Traceability Post-Traceability

In-Traceability

121

Nachvollziehbarkeit von Anforderungen (3)

Vertikale Verfolgbarkeit(zwischen gleichartigen Obj.)

Horizontale Verfolgbarkeit(zwischen verschiedenen Obj.)

Quelle: Robert Brcina: Arbeiten zur Ver-folgbarkeit und Aspekte des Verfolgbar-keitsprozesses, 2006 (vereinfacht)

123

Nachvollziehbarkeitsmatrizen

U: uses, benutztR: relates, bezieht sich auf

124

Inhalt




125

Bearbeitung von Änderungsanträgen / Change Request

Auswirkungsanalyse

Beurteilung der Änderung

Kommunikation derAblehnung

Priorisierung derAnforderungsänderung

[Annahme der Änderung] [Ablehnung der Änderung]

Zuordnungder Änderung zu Änderungsprojekt

Auslöser: CR(change request)

Aufwands-ermittlung

Kosten/Nutzen-Analyse

Changecontrol board

Projektmanager

Folgeaktivität:Umsetzung(oder nichts!)Pohl, Rupp: Basiswissen Requirements-Engineering, 2009

126

Inhalt


Anforderungen

127

Qualitätssicherung von Anforderungen

o Abweichungen von der geforderten Qualität der Spezifikation feststellen.

o Möglichst viele Fehler, Lücken, Unklarheiten, Mehrdeutigkeiten etc. finden und beheben.

o Konflikte zwischen den Wünschen / Forderungen verschiedener beteiligter Personen erkennen und lösen.

o Verdeckte Wünsche / Erwartungen / Befürchtungen erkennen und thematisieren.

128

Anforderungsprüfung

o Einbeziehen aller Stakeholdero Zeitpunkt(e):

¤ Fortlaufend, d.h. begleitend zur Erstellung der Spezifikation, z. B. Autor-‐Kritiker-‐Zyklus.

¤ Wenn die Spezifikation fertig ist(aber noch genug Zeit bleibt, die gefundenen Mängel zu beheben).

129Anforderungsprüfung

o Review¤ Stellungnahme: Expertise einer 3. Person.¤ Walkthrough: Autor führt durch das Review.¤ Inspektion: Gutachter prüfen eigenständig, tragen in Sitzung Befunde

zusammen.¤ Autor-‐Kritiker-‐Zyklus: Kunde liest und kritisiert, bespricht Befunde mit Autor.

o Prototyp¤ Kunden wird Ablauf (grafisch) vorgeführt.

o Prüf-‐ und Analysemittel in Werkzeugen¤ Einsatz bei werkzeuggestützter Erstellung der Spezifikation

n Auffinden von Lücken und Widersprüchen.

Das Mittel der Wahlzur Prüfung von Spezifikationen

130

Prototyping

o Wofür?¤ …bei interaktiven Systemen

o Wie?¤ Horizontaler Prototyp

o Warum?¤ Fördert die Kommunikation

mit dem Benutzer¤ Fehlende Anforderungen werden identifiziert¤ Missverständnisse werden entdeckt¤ Reduziert Entwicklungsrisiko

131

Paper Prototyping – Low Fidelity

o Eingabemasken auf Papier¤ Keine/Wenig Ähnlichkeit zum fertigen Produkt

o Vorteile¤ Preiswert, schnell, technisch einfaches Verfahren¤ Kommunikativ¤ Änderungsvorschläge können direkt umgesetzt werden

o Nachteile¤ Ohne Funktionalität¤ Nicht weiter nutzbar¤ Nicht alle Ideen technisch umsetzbar

132

Computer-‐gestütztes Prototyping – High Fidelity

o Hohe Ähnlichkeit zum fertigen Produkt¤ z.B. pidoco.com

o Vorteile¤ Mehr Funktionalität¤ User kann mit Prototyp interagieren

o Nachteile¤ Teuer, aufwändig¤ Änderungen nur mit größerem Aufwand¤ mögliche Verwechslung mit Zielsystem

133

7 Sünden der Anforderungsspezifikation nach Myers

o Irrelevante Informationo Unvollständigkeito Über-‐Spezifikation (≠ Design-‐Entscheidungen)o Inkonsistenzeno Mehrdeutigkeito Vorwärts-‐Referenzeno Nicht testbare Anforderungen

134

135

User Stories

o Funktionale Beschreibung was für den Benutzer/Auftraggeber des (Software) Systems nützlich ist.

o Eine Schilderung, wie die Benutzer mit der Software interagieren, die erstellt werden soll.¤ Beschreibung aus der Sicht des Kunden.¤ Beschreibt, was die Software für den Kunden tut.

o User Stories setzen sich aus 3 Aspekten zusammen:¤ Beschreibung der Story für die Planung und als Erinnerung.¤ Gespräche über die Story, um die Details der Story herauszuarbeiten.¤ Tests, welche Details beschreiben und dokumentieren und die

hergenommen werden können, um entscheiden, on die Story vollständig ist.

Card

Conversation

Confirmation

136

User-‐Stories: Was sollten sie sein und was nicht.

o Sie sollten... genau eine Sache beschreiben, die die Software für den Kunden

erledigen soll.... in einer für den Kunden verständlichen Sprache geschrieben sein.... vom Kunden selbst formuliert werden.... kurz sein (max. 3 Sätze)

o Sie sollten nicht... in lange Erläuterungen ausarten.... Fachbegriffe enthalten , mit denen der Kunde nichts anfangen kann... Bezug nahmen auf spezifische Technologien.

137

User Story: Beispiele

o BigMoneyJobs: Eine Web-‐Seit zum Anbieten und Suchen von Jobs.

Titel: Lebenslauf veröffentlichen.Beschreibung: Der Benutzer kann seinen Lebenslauf über die Web-Site veröffentlichen.

Titel: Job suchen.Beschreibung: Der Benutzer kann über die Web-Site nach einem Job suchen.

Titel: Jobs anbieten.Beschreibung: Ein Unternehmen kann über die Web-Site einen Stelle anbieten.

Titel: Lebenslauf veröffentlichen.Beschreibung: Der Benutzer kann über die Web-Site festlegen, wer seinen Lebenslauf einsehen darf.

138

User Stories: zu wenige Details?

o Der Benutzer kann über die Web-‐Site nach einem Job suchen.¤ Kann man allein damit beginnen zu programmieren und zu testen?¤ Wo sind die Details?¤ Was ist mit den folgenden Fragen:

n Nach welchen Werten kann der Benutzer suchen?n Region? Stadt? Berufsbezeichnung? Schlüsselwörter?

n Muss sich der Benutzer auf der Web-‐Site registrieren?n Können Suchparameter gespeichert werden?n Welche Informationen werden bei passenden Job-‐Angeboten angezeigt?

¤ Viele dieser Details lassen sich durch weitere User Stories beschreiben: Mehr User Stories sind zu langen User Stories vorzuziehen.

¤ Beispiel: Die gesamte BigMoneyJobs-‐Seite kann man die 2 Stories zerlegen:n Ein Benutzer kann nach einem Job suchen.n Ein Unternehmen kann ein Jobangebot veröffentlichen.

139

User Stories: wie umfangreich?

o Faustregel: User Stories sollten sich in ½ Tag bis 2 Wochen von einem Programmierer (-‐paar) programmieren und testen lassen.

o Zu große Stories werden als Monumentalwerke (epics) bezeichnet und lassen sich leicht aufteilen:

o Beispiel:¤ Ein Benutzer kann nach einem Job suchen.

n Ein Benutzer kann nach Jobs suchen über Attribute wie Ort, Angabe eines Gehaltsbereichs, Firmenname und Datum, zu dem das Stellenangebot veröffentlicht wurde.

n Ein Benutzer kann Informationen zu jeder Stelle, die zu den angegeben Kriterien passt, ansehen.

n Ein Benutzer kann zu jedem Unternehmen, das ein Stellenangebot veröffentlicht hat, detaillierte Informationen ansehen.

140

User Stories: wie detailliert?

o Stories werden nicht bis ins letzte Detail verfeinert.o Ein Benutzer kann Informationen zu jeder Stelle, die zu den

angegeben Kriterien passt, ansehen.o Das ist eine vernünftige und realistische Story, die nicht weiter

zerlegt wird.o Weitere Informationen ergeben sich durch die Kommunikation mit

dem Kunden.o Wie umfangreich muss eine Story sein? è Ergibt sich aus

Hinweisen zu (Akzeptanz-‐)Tests (à Rückseite der Story-‐Card)o Versuch mit leerer Job-‐Beschreibung.o Versuch mit ganz langer Job-‐Beschreibung.o Versuch ohne Gehaltsangabe.o Versuch mit sechsstelliger Gehaltsangabe.

o Die Tests können jederzeit ergänzt oder entfernt werden. Sie sind ein ergänzender Hinweis auf die Erwartungen des Kunden.

141

Customer Team

o Idealfall: Der Product Owner (ein Mitarbeiter des Auftraggebers) ist während der gesamten Projektlaufzeit mit dabei und erledigt die folgenden Aufgaben:¤ Priorisiert die Aufgaben für die Entwickler (Sprint Backlog).¤ Beantwortet allwissend alle Fragen der Entwickler.¤ Verwendet (quasi als Tester ) den jeweiligen Stand der Software.¤ Schreibt alle User Stories.

o Realität (auch im SEP): Customer Team¤ Dazu gehören alle, die sicherstellen, dass die Software die

beabsichtigten Benutzeranforderungen erfüllt.¤ Tester + Produkt Manager + (echte) Anwender + Interaktions-‐Designer

Paradies

142

Customer Team: Aufgabe

o Schreibt die Stories, weil¤ die Sprache der Story die Domänen-‐Sprache ist und kein

Technikjargon.¤ das Customer-‐Team am besten das Produktverhalten beschreiben

kann.

143

Priorisierung von Stories

o Für Customer-‐Team¤ Wichtigkeit eines Features für eine breite Basis von

Benutzern/Kunden.¤ Wichtigkeit eines Features für eine schmale Basis von wichtigen

Benutzern/Kunden.¤ Zusammenhang der Story mit anderen Stories

o Für Entwickler¤ Technisches Risiko.¤ Ergänzung einer anderen Story.

è Das Customer-‐Team entscheidet nach Rücksprache mit den Entwicklern und unter Berücksichtigung der Kosten.

144

Story-‐Points

o Kosten einer Story werden von den Entwicklern geschätzt.o Die Schätzung wird in Story-‐Points gemessen.o Story-‐Point: beschreibt die Größe und die Komplexität einer

Story im Vergleich zu anderen Stories – also keine absolute Angabe in beispielsweise einem Geldbetrag.

o Maß der Entwicklungsgeschwindgkeit = Story-‐Points

Documents

ANFORDERUNGSANALYSE-UND-– Kapitel)3 SPEZIFIKATION