ANFORDERUNGSANALYSE UND SPEZIFIKATION

Transkript

1 Kapitel 3 ANFORDERUNGSANALYSE UND SPEZIFIKATION Software Technik Prof. Dr. Wolfgang Schramm

2 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.

3 2 1. Einführung 2. Begriffe 3. Erheben und Analysieren 4. Dokumentieren 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

4 Weg der Anforderungen (vereinfacht) 3 Spezifikation Entwurf Anforderungssammlung Code Kunde Entwickler

5 Beispiele für Anforderungen 4 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]

6 Anforderung: Definition 5 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

7 Anforderungen - Arten 6 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

8 Funktionale vs. nicht- funktionale Anforderungen 7 o Die Abgrenzung zwischen nicht- funktionalen und funktionalen Anforderungen ist nicht scharf. o Aus einer nicht- funktionale Anforderung o Das System muss den unautorisierten Zugriff auf die Kundenstammdaten verhindern. wird durch Verfeinerung eine funktionale Anforderung Der Zugriff auf die Kundenstammdaten muss über eine Login- Prozedur mit Passworten geschützt werden.

9 Nicht- funktionale Anforderungen 8 Quelle: ISO FDIS (2010) Qualitätsmodell der ISO (Nachfolger der ISO 9126)

10 Randbedingungen 9 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

11 Inhalt Einführung 2. Begriffe 3. Dokumentation 4. Erhebung von Anforderungen 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

12 11 o Vision o Ziel Informell, oft sehr abstrakt SMART n S n M n A n R n T pezifisch essbar ttraktiv ealistisch erminbezogen Vision vs. Ziele Ziele sind hilfreich, um die Absichten der Stakeholder zu verstehen (=Grundlage, um Anforderungen zu verstehen).

13 Inhalt Einführung 2. Begriffe 3. Dokumentation Systemkontext Natürliche Sprache Szenario/Use Case Drei Perspektiven Atomare Anforderungen Templates/Gliederungen 4. Erhebung von Anforderungen 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

14 Systemkontext (1) 14 Systemgrenze Kontextgrenze Irrelevante Umgebung nach Pohl, Rupp: Basiswissen Requirements-Engineering, 2009

15 Systemkontext (2) 15 o Systemkontext besteht aus Geschäftsprozessen Technischen Prozessen Personen Organisationsstrukturen IT- Infrastruktur (z.b. Datenbanken) o System Quellen Senken o Grauzone der Systemgrenze Die Systemgrenze ist zunächst nicht klar n breiter grauer Strich Im Verlauf des RE wird klar, welche Funktionen im SW- System realisiert werden sollen

16 Systemkontext (3) 16 o Darstellung des Kontext: Kontext- Diagramme alternativ: use case Glinz, Vorlesung RE, Uni Zürich

17 Bedeutung des Systemkontexts 17 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. Kontext? à die Dokumentation des Kontexts ist notwendig

18 Inhalt Einführung 2. Begriffe 3. Dokumentation Systemkontext Natürliche Sprache Szenario/Use Case Drei Perspektiven Atomare Anforderungen Templates/Gliederungen 4. Erhebung von Anforderungen 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

19 Art der Darstellung der Anforderungen 19 Darstellung mit unterschiedlichem Formalitätsgrad. o Texte in natürlicher Sprache o Strukturmodelle o Interaktionsmodelle Graphisch, angereichert mit natürlicher Sprache o Formale Modelle auf der Grundlage mathematisch- logischer Formalismen.

20 Natürliche Sprache 20 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 Anforderungen n 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 21 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 22 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 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.

23 Anforderungsbeschreibung 23 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 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.

24 24 Kern der Anforderung: <Prozesswort> Satztemplate (1) Das System tut etwas selbständig Das System reagiert auf Benutzereingaben Verbindlichkeit: bindend/ empfohlen/ zukünftig Das System reagiert auf Daten oder Signale Pohl, Rupp: Basiswissen Requirements-Engineering, 2009

25 Satztemplate (2) 25 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 konditional oder temporal sein)

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

27 27 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 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. Einleitung Begriffe Dokumentation Erheben Management Qualitätssicherung

28 Inhalt Einführung 2. Begriffe 3. Dokumentation Systemkontext Natürliche Sprache Szenario/Use Case Drei Perspektiven Atomare Anforderungen Templates/Gliederungen 4. Erhebung von Anforderungen 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

29 Szenario 29 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 30 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 Eingabe Karl 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 31 o o o Ist- Szenarien beschreiben die Situation mit dem gegenwärtigen System zum Beispiel, um es gegen zukünftige Anforderungen abzugrenzen. Visionäre Szenarien beschreiben ein künftiges System Kommunikationsmedium, "preiswerter Prototyp. Bewertungsszenarien dienen der (späteren) Evaluierung des Systems Status- Bewertung, Usability, Akzeptanztest, Bewertung der Architektur.

32 Regeln zur Formulierung von Szenarien (1) 32 o Sprache/Grammatik 1. 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 Struktur 5. Trennen Sie jede Interaktion deutlich von anderen Interaktionen. Pohl, Requirements Engineering Grundlagen, Prinzipien, Techniken, 2008

33 Regeln zur Formulierung von Szenarien (2) 33 o Inhalt 6. 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 34 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 35 o Deutsch: Anwendungsfall o Zur strukturierten Dokumentation der Funktionalität existierender oder geplanter Systeme durch Interaktionsfolgen o Besteht aus Use Case- Diagramm Übersichtsbild Use Case- Spezifikation Tabelle

36 Beispiel: Use Case- Diagramm 36 o UML Use Case- Diagramme zeigen, welche Anwendungsfälle (= welche Funktionalität) ein System bietet und wer diese in Anspruch nehmen kann

37 37 Beispiel: Use Case HebeGeldAb (1) Anwendungsfallname Geld abheben Akteure Ziel Kunde Geld vom Konto abheben Hauptablauf 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 38 Beispiel: Use Case HebeGeldAb (2) Ausnahmeabläufe Anfangsbedingungen Abschlussbedingungen Qualitätsanforderungen Ausnahme in 2.: Kontonummer unbekannt 101. Das System gibt die Fehlermeldung Kto-Nr. unbekannt aus;; weiter mit 8. Ausnahme in 4.: Währung nicht verfügbar 201. Das System gibt die Fehlermeldung Währung nicht verfügbar aus;; weiter mit 3. Ausnahme in 4.: Konto hat keine ausreichende Deckung 301. 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. Kunde hat ein Konto bei dem Geldinstitut Der Kunde hat den gewünschten Betrag erhalten ODER er bekam eine Meldung, warum die Auszahlung nicht möglich war 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.

39 Elemente von Use Case- Diagrammen 39 Name Use Case Objekte «extend» A Beziehungen inkludiert B A Name Akteur (Person) erweitert B «include» A Akteur (System) generalisiert «system» Name B Name System mit Systemgrenze Name kommuniziert Name

40 Beispiel für include 40 Geld abheben Kunden authentif. «include» 1. Include: Kunden authentif. 2. Kunde gibt Währung und Betrag ein 3. System prüft Kunden authentif. 1. Kunde gibt Kontonummer an 2. Kunde authentifiziert sich per PIN authentif. per mtan authentif. 1. Kunde gibt Kontonummer an 2a. System generiert TAN und sendet SMS 2b. Kunde gibt TAN ein

41 Anleitung für Use Cases (1) 41 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 Anleitung für Use Cases (2) 42 o Bzgl. dem Ereignisfluss: Die Systemgrenzen sollen klar sein. n Arbeitsschritte des Akteurs und Arbeitsschritte des Systems sollen 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 vollzieht n z.b. Der Dienstleiter überprüft Der Außenbeamte hat... empfangen... Das System berechnet Einrücken der Systemarbeitsschritte Die ursächliche Beziehung zwischen aufeinander folgenden Schritten soll klar sein.

43 Anleitung für Use Cases (3) 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. Szenario Rolle vs. Name Akteur-initiiert/ vs. beliebiger (Teil-)Ablauf Transaktion vollst. Aufgabe vs. spezieller Ablauf eine Aufgabe vs. viele Aufgaben

44 Diskussion 44 Schreiben Sie das Beispiel des Getränkeautomaten zu einem Use Case Getränk kaufen um! Benutzen Sie das verteilte Schema!

45 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 Annulliertaste kann 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 46 Welche Unterschiede sehen sie zwischen Szenarien und Use Cases? Wann setzen Sie Szenarien, wann Use Cases ein?

47 Szenario versus Use Case 47 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 Einführung 2. Begriffe 3. Dokumentation Systemkontext Natürliche Sprache Szenario/Use Case Drei Perspektiven Atomare Anforderungen Templates/Gliederungen 4. Erhebung von Anforderungen 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

49 49 Ein-/Ausgabe- Daten Nutzungsbeziehungen System/ Systemkontext Systemverhalten/ zustandsbasiert, z.b. Reaktion auf Signale von außen 3 Perspektiven Zweck: verfeinern von Use Cases Aufzeigen von Zusammenhängen zwischen Use Cases Anforderungen Funktion Informationsfluss zwischen System und Systemkontext

50 zur Funktion: Datenflussdiagramme (DFD) 50 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 51

52 Datenflussdiagramme - Notation 52 Name Input/Output (Terminator) Name Funktion (Prozess) Name Datenbank (File) Name Datenfluss

53 Diskussion 53 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 54 Blood Blood Sugar Sensor Blood Parameters Blood Sugar Analysis Blood Sugar Level Insulin Insulin Pump Pump Control Commands Insulin Delivery Controller Insulin Requirement Computation Insulin Requirement Sommerville, Software Engineering, 2010

55 Fragerunde 55 Welche Notationen kennen Sie, um Verhalten Struktur in der Anforderungsphase zu verdeutlichen?

56 56 Ein-/Ausgabe- Daten Nutzungsbeziehungen System/ Systemkontext Systemverhalten/ zustandsbasiert, z.b. Reaktion auf Signale von außen 3 Perspektiven Statecharts Zustandsdiagramm E/R-Diagramm Klassendiagramm Anforderungen Datenflussdiagramm Aktivitätsdiagramm Funktion Informationsfluss zwischen System und Systemkontext

57 Inhalt Einführung 2. Begriffe 3. Dokumentation Systemkontext Natürliche Sprache Szenario/Use Case Drei Perspektiven Atomare Anforderungen Templates/Gliederungen 4. Erhebung von Anforderungen 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

58 58 Beispiel: Atomare Anforderungen / Snow Card FR Anforderungsnummer: 75 o Typ der Anforderung: Funktionale Anforderung o 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üller o 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: Hoch o Konflikte: Keine o Andere Materialien: Herstelleranleitung der Wetterstation IN34.67 Robertson & Robertson, Mastering the Requirements Process, 2008

59 Atomare Anforderungen 59 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 60 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 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 62 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 63 Beispiel: Atomare Anforderungen / Snow Card NFR Anforderungsnummer: 43 o o o o o o o o o Typ der Anforderung: Nicht- Funktionale Anforderung Beschreibung: Das System ist von 10- jährigen Kindern zu bedienen Rational: das System ist für Kinder vorgesehen, die die Grundschule absolviert haben Quelle: Karl- Heinz Müller Fit Kriterium: 80% der Testgruppe von 10- jährigen können sich innerhalb 2 Minuten erfolgreich registrieren; 90% der Testgruppe Event/Use Case: UC 1/Registrierung; UC 3/ Priorität: Hoch Konflikte: Keine Andere Materialien: keine Robertson & Robertson, Mastering the Requirements Process, 2008

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

65 Inhalt Einführung 2. Begriffe 3. Dokumentation Systemkontext Natürliche Sprache Szenario/Use Case Drei Perspektiven Atomare Anforderungen Templates/Gliederungen 4. Erhebung von Anforderungen 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

66 Rahmenwerke für Anforderungsdokumente 66 o VDI/VDE Standard 3694: Referenzstruktur für Lasten- und Pflichtenheft o IEEE Standard : Referenzstruktur für Systems Requirements Spezifikationen o IEEE Standard für Software Requirements Spezifikationen o Volere Template von Robertson & Robertson o Template von Sören Lauesen 07.doc

67 Qualitätskriterien für Anforderungsartefakte 67 o eindeutig / verständlich klar o vollständig komplett o konsistent o korrekt Clarity Completeness Consistency Correctness + o nachvollziehbar o überprüfbar o bewertet / abgestimmt o modifizierbar / erweiterbar / verfolgbar Gilt für einzelne Anforderungen das ganze Dokument!

68 Glossar 70 o Zweck o Inhalt konsistente Terminologie aller Beteiligten kontextspezifische Fachbegriffe n ggf. Alltagsbegriffe mit spezieller Bedeutung n Bsp.: Medien bei techn. Betriebsleitung Abkürzungen/Akronyme Synonyme/Homonyme

69 Regeln für Glossar 71 o zentral verwaltet o eine Person verantwortlich o projektbegleitend gepflegt o allgemein zugänglich o verbindlich verwendet o Quelle der Begriffe angegeben o abgestimmt mit allen Stakeholdern o einheitlich strukturiert Glossar ist zwingend notwendig

70 Personas (1) 72 Zur Beschreibung der Zielgruppe/Nutzergruppe

71 Personas (2) 73 o Individualisierung Foto, Name o Biographie Geographisch n Region, Klima, Stadt/Land, Demographisch n Geschlecht, Alter, Familienstand, Generation, Ausbildung, Beruf, Einkommen, Psychographisch Persona enthält nur für das Projekt relevante Informationen n Klasse, soziale Rolle, Herangehensweisen, Lifestyle, Hobbies,

72 Personas (3) 74 o Beziehung zum Produkt Bedeutung (im Vergleich zu anderen Personas) Ziele n Motivation, versteckte Ziele, Einstellung zur Aufgabe, Fähigkeiten n Anwendungsdomäne, Computernutzung, Internetnutzung, Nutzungskontext n Nutzungsrolle, Umgebung, besondere Anforderungen (Sicherheit, Verfolgbarkeit, Genauigkeit) Einstellung/Stimmung n Aktiv/passiv, modern/traditionell,

73 Geschäftsprozesse (1) 75 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

74 Geschäftsprozesse (2) 76 Notation: BPMN

75 Geschäftsprozesse (3) 77 Übergang zu Systemanforderungsbestimmung und analyse Aufgaben / Aktivitäten markieren, die mit Systemunterstützung ablaufen sollen Geschäftsprozessmodellierung Anforderung Antragsdaten erfassen Schufa-Ausk. einholen Konto einrichten «system support» Antragsdaten erfassen Schufa-Ausk. einholen «system support» Konto einrichten 1. Antragsdaten eingeben 2. Daten prüfen 3. Zulässigkeit bestätigen 4. Konto einrichten

76 Inhalt Einführung 2. Begriffe 3. Dokumentation Systemkontext Natürliche Sprache Szenario/Use Case Drei Perspektiven Atomare Anforderungen Templates/Gliederungen 4. Erhebung von Anforderungen 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

77 Inhalt Einführung 2. Begriffe 3. Dokumentation 4. Erhebung von Anforderungen Quellen Methoden 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

78 RE- Prozess: Anforderungsbestimmung 80 Durchführbarkeitsstudie Bestimmung und Analyse der Anforderungen Spezifikation der Anforderungen Durchführbarkeitsbericht Benutzer- und Systemanforderungen Systemmodelle Validierung der Anforderungen Pflichtenheft nach [Som01]

79 Anforderungsbestimmung und analyse im Detail 81 Anforderungssammlung Anforderungsspezifikation und dokumentation Verstehen des Anwendungsbereichs Anforderungsüberprüfung (Validierung) Prozessbeginn Setzen von Prioritäten Konfliktlösung Pflichtenheft Klassifizierung

80 Anforderungsbestimmung: was ist zu beachten? 82 Es gibt keinen idealen RE- Prozess. à Zuschneidenauf konkrete Projektsituation. Zuberücksichtigende Faktoren: Zugrunde liegendesprozessmodell (linearesoderinkrementellesvorgehen)? Muss die Spezifikation wasserdicht sein (Vertrag; Realisierung durch Dritte)? Sind die Kunden/Benutzer bekannt und können sie in die Erstellung der Spezifikation einbezogen werden? Wird das zu spezifizierende System im Kundenauftrag oder für den Markt entwickelt? Soll Standardsoftware zum Einsatz kommen?

81 Erhebung von Anforderungen (1) 83 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).

82 Abbilden oder Gestalten? 84 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 n n Zukunftsszenarien entwerfen und durchspielen. Beschränkungen in Frage stellen und sich von alten Zöpfen verabschieden. Metaphern suchen und explorieren.

83 Erhebung von Anforderungen (2) 85 o Wissen sammeln über Beteiligte Stakeholder und ihre Ziele Nutzeraufgaben Gegenwärtige Situation (Ist- Situation) Erwartungen Wissen über die Domäne

84 86 Anforderungsquellen 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

85 87 Probleme bei der Erhebung (1)

86 Probleme bei der Erhebung (2) 88 o o o o 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. Berücksichtigung aller Stakeholder Aufzeigen neuer Möglichkeiten Stakeholder verhaften gerne an alten Gewohnheiten und Vorgängen. Konflikte Zwischen Stakeholdern mit unterschiedlichen Interessen. Widerstand gegen Veränderungen. Prioritäten & Veränderungen Stakeholder wollen zu viel. Stakeholder ergänzen ständig.

87 89 Stakeholders 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.

88 Alle Stakeholder berücksichtigen 90 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?

89 Fragerunde 91 Denken Sie an den Getränkeautomaten: Wer sind Stakeholder?

90 Inhalt Einführung 2. Begriffe 3. Dokumentation 4. Erhebung von Anforderungen Quellen Methoden 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

91 Erheben von Anforderungen 94 o Interview o Fokus- Gruppe o Beobachtung

92 Weg der Anforderungen (vereinfacht) 95 Spezifikation Entwurf Anforderungssammlung Code Kunde Entwickler

93 Kommunikation 96 Kunde / Anwender Requirements Engineer Wahrnehmung Darstellung Interpretation Objektive Realität Persönliche Realität Linguistischer Ausdruck Ergebnis

94 Arten von Interviews: Grad der Formalität (1) 97 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.

95 Arten von Interviews: Grad der Formalität (2) 98 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.

96 Interview Durchführung Vorbereitung Vorliegende Dokumente studieren. Fragen vorbereiten. 2. Durchführung Wenn möglich mit zwei Interviewenden. Evtl. Aufnahme des Interviews auf Band. 3. Eröffnung des Interviews Wofür ist das Interview. Was passiert mit den Antworten. 4. Die Fragen Am Anfang eher allgemein, später spezifischer. Eine Mischung aus offenen und geschlossenen Fragen Aktives Zuhören. Achtung: Auch nonverbale Kommunikation ist von Bedeutung. 5. Abschluss Wie geht es weiter. Die interviewte Person hat das letzte Wort.

97 Beispiel: Nach dem WARUM fragen (1) 100 Neurologische Diagnostik - Interview o Das System soll ein Mini- Keyboard haben mit Start und Stop Knopf. o WARUM? o Man soll es mit der linken Hand bedienen können o WARUM? o Beide Hände sind in der Nähe des Patienten o WARUM? o Schmerzhaft für den Patienten, Elektroden,.. o

98 101 Beispiel: Nach dem WARUM fragen (2) Neurologische Diagnostik - Anforderungsdokument o 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.

99 102 Interview- Effekte Wechselwirkung zwischen Befragtem und Fragendem.

100 Interview- Effekte Soziale Erwünschtheit 103 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. Ähm... 2 x pro Woche ein Glas! Durchschnittlich viel! Wie oft trinken sie Alkohol?

101 104 Interview- Effekte Halo Effekt o Beim Halo- Effekt erzeugen einzelne Eigenschaften einer Person einen Gesamteindruck, der die weitere Wahrnehmung der Person "überstrahlt". Attraktiv = reich = intelligent

102 105 Recency- 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.

103 Fokus Gruppe (1) 106 hier: Stakeholder (insbesondere Nutzer) Quelle: Krueger & Mary, 2003, Focus Groups, Sage Publ., London Krueger & Mary,, Focus Groups, Sage Publ., London, 2003

104 Fokus- Gruppe (2) 107 o Mit Problemen beginnen Flipchart, Kartenabfrage Gründe sammeln o Dann auf Lösung fokussieren Gruppierung der gesammelten Punkte n ca. 40 Punkte Priorisierung n Bspw. 10 Punkte kleben n Bspw. in Gruppen je nach Stakeholder- Rolle o Abschluss mit einer Zusammenfassung der Ergebnisse

105 Fokus- Gruppe (3) 108 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.

106 109 o Anwender im Kontext beobachten. o Arbeitsumgebung, Kommunikationswege, Geräte. o Arbeitsartefakte. Beobachtung (1)

107 Beobachtung (2) Site Visits 110 o Idee o Ziele Site Visits Beobachtung der Stakeholder in ihrer realen Umgebung (evtl. auch Kamera, Computer Monitoring) 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

108 Inhalt Einführung 2. Begriffe 3. Dokumentation 4. Erhebung von Anforderungen 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

109 112 Verwalten von Attributen o Attributierung / Sichten Management Attribute: Nr, Id, Name, Version, Quelle, Verantwortlicher, Stabilität, Priorität, Validierungsstatus, Abstimmungsstatus, Release Sichten: Auswahl von Anforderungen nach Attribut- Wert o Priorisierung o Verfolgung o Versionierung Version einzelner Anforderungen Konfiguration aller Anforderungen à im Folgenden à im Folgenden n zusammenpassende Versionen der Anforderungen o Verwaltung von Änderungen à im Folgenden

110 Inhalt Einführung 2. Begriffe 3. Dokumentation 4. Erhebung von Anforderungen 5. Management von Anforderungen 1. Priorisierung 2. Verfolgung 3. Verwalten von Änderungen 6. Qualitätssicherung von Anforderungen

111 114 Priorisierung Ist nötig bei o o o o o harten Terminen. harten Preisobergrenzen. Beschaffung. Zeitliche und finanzielle Restriktionen erlauben es meist nicht, alle Anforderungen mit der gleichen Intensität zu beachten. Festlegen von Inhalt und Umfang der Inkremente bei inkrementeller Entwicklung. Releaseplanung bei der Weiterentwicklung bestehender Systeme.

112 Techniken zur Priorisierung: IEEE o Eine Kriterien- Klassifikation Mandatory n Anforderungen müssen umgesetzt werden, um den Erfolg zu gewährleisten. Optional n Anforderungen, die zwar wichtig sind, deren vereinzeltes Fehlen im System den Erfolg nicht gefährdet. Nice- to- have n Anforderungen, deren Fehlen im System den Erfolg des Systems nicht gefährdet. Beobachtung: Meist starke Häufung in der Klasse Mandatory

113 Inhalt Einführung 2. Begriffe 3. Dokumentation 4. Erhebung von Anforderungen 5. Management von Anforderungen 1. Priorisierung 2. Verfolgung 3. Verwalten von Änderungen 6. Qualitätssicherung von Anforderungen

114 Nachvollziehbarkeit von Anforderungen (1) 119 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

115 120 Nachvollziehbarkeit von Anforderungen (2) o Im Entwicklungsprozess nachvollziehen des Ursprungs der Anforderungen der Verwendung der Anforderung In- Traceability Vorgelagerte Artefakte Anforderungen Nachgelagerte Artefakte Pre-Traceability Post-Traceability

116 Nachvollziehbarkeit von Anforderungen (3) 121 Quelle: Robert Brcina: Arbeiten zur Verfolgbarkeit und Aspekte des Verfolgbarkeitsprozesses, 2006 (vereinfacht) Horizontale Verfolgbarkeit (zwischen verschiedenen Obj.) Vertikale Verfolgbarkeit (zwischen gleichartigen Obj.)

117 Nachvollziehbarkeitsmatrizen 123 U: uses, benutzt R: relates, bezieht sich auf

118 Inhalt Einführung 2. Begriffe 3. Dokumentation 4. Erhebung von Anforderungen 5. Management von Anforderungen 1. Priorisierung 2. Verfolgung 3. Verwalten von Änderungen 6. Qualitätssicherung von Anforderungen

119 125 Bearbeitung von Änderungsanträgen / Change Request Change control board Projekt manager Auswirkungsanalyse Auslöser: CR (change request) Aufwandsermittlung Beurteilung der Änderung Kosten/Nutzen- Analyse [Annahme der Änderung] [Ablehnung der Änderung] Priorisierung der Anforderungsänderung Zuordnung der Änderung zu Änderungsprojekt Kommunikation der Ablehnung Pohl, Rupp: Basiswissen Requirements-Engineering, 2009 Folgeaktivität: Umsetzung (oder nichts!)

120 Inhalt Einführung 2. Begriffe 3. Dokumentation 4. Erhebung von Anforderungen 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

121 Qualitätssicherung von Anforderungen 127 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.

122 Anforderungsprüfung 128 o Einbeziehen aller Stakeholder o 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).

123 129 Anforderungsprüfung o Review Stellungnahme: Expertise einer3. Person. Walkthrough: Autor führtdurch dasreview. Inspektion: Gutachter prüfen eigenständig, tragen in Sitzung Befunde zusammen. Autor- Kritiker- Zyklus: Kunde liestund kritisiert, bespricht Befunde mit Autor. o Prototyp Kunden wirdablauf (grafisch) vorgeführt. o Prüf- und Analysemittel in Werkzeugen Einsatz bei werkzeuggestützter Erstellung der Spezifikation n Auffinden von Lücken undwidersprüchen. Das Mittel der Wahl zur Prüfung von Spezifikationen

124 Prototyping 130 o Wofür? o Wie? bei interaktiven Systemen Horizontaler Prototyp o Warum? Fördert die Kommunikation mit dem Benutzer Fehlende Anforderungen werden identifiziert Missverständnisse werden entdeckt Reduziert Entwicklungsrisiko

125 Paper Prototyping Low Fidelity 131 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

126 Computer- gestütztes Prototyping High Fidelity 132 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

127 7 Sünden der Anforderungsspezifikation nach Myers 133 o Irrelevante Information o Unvollständigkeit o Über- Spezifikation ( Design- Entscheidungen) o Inkonsistenzen o Mehrdeutigkeit o Vorwärts- Referenzen o Nicht testbare Anforderungen

128 134

129 User Stories 135 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. Confirmation Card Conversation

130 User- Stories: Was sollten sie sein und was nicht. 136 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.

131 User Story: Beispiele 137 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.

132 User Stories: zu wenige Details? 138 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.

133 User Stories: wie umfangreich? 139 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.

134 User Stories: wie detailliert? 140 o o o o Stories werden nicht bis ins letzte Detail verfeinert. o Ein Benutzer kann Informationen zu jeder Stelle, die zu den angegeben Kriterien passt, ansehen. Das ist eine vernünftige und realistische Story, die nicht weiter zerlegt wird. Weitere Informationen ergeben sich durch die Kommunikation mit dem Kunden. 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.

135 Customer Team 141 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. Paradies 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

136 Customer Team: Aufgabe 142 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.

137 Priorisierung von Stories 143 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.

138 Story- Points 144 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