anforderungsanalyse-und-– kapitel)3 spezifikation
TRANSCRIPT
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
1. Einführung2. Begriffe3. Dokumentation
SystemkontextNatürliche SpracheSzenario/Use CaseDrei PerspektivenAtomare AnforderungenTemplates/Gliederungen
4. Erhebung von Anforderungen5. Management von Anforderungen6. Qualitätssicherung von
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
1. Einführung2. Begriffe3. Dokumentation
SystemkontextNatürliche SpracheSzenario/Use CaseDrei PerspektivenAtomare AnforderungenTemplates/Gliederungen
4. Erhebung von Anforderungen5. Management von Anforderungen6. Qualitätssicherung von
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
Anleitung für Use Cases (2)
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
Anleitung für Use Cases (3)
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
1. Einführung2. Begriffe3. Dokumentation
SystemkontextNatürliche SpracheSzenario/Use CaseDrei PerspektivenAtomare AnforderungenTemplates/Gliederungen
4. Erhebung von Anforderungen5. Management von Anforderungen6. Qualitätssicherung von
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
1. Einführung2. Begriffe3. Dokumentation
SystemkontextNatürliche SpracheSzenario/Use CaseDrei PerspektivenAtomare AnforderungenTemplates/Gliederungen
4. Erhebung von Anforderungen5. Management von Anforderungen6. Qualitätssicherung von
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
1. Einführung2. Begriffe3. Dokumentation
SystemkontextNatürliche SpracheSzenario/Use CaseDrei PerspektivenAtomare AnforderungenTemplates/Gliederungen
4. Erhebung von Anforderungen5. Management von Anforderungen6. Qualitätssicherung von
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
Geschäftsprozesse (2)
Notation: BPMN
77
Geschäftsprozesse (3)
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
1. Einführung2. Begriffe3. Dokumentation
SystemkontextNatürliche SpracheSzenario/Use CaseDrei PerspektivenAtomare AnforderungenTemplates/Gliederungen
4. Erhebung von Anforderungen5. Management von Anforderungen6. Qualitätssicherung von
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
Anforderungs-sammlung
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
Anforderungs-sammlung
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
1. Einführung2. Begriffe3. Dokumentation4. Erhebung von Anforderungen5. Management von Anforderungen6. Qualitätssicherung von
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
1. Einführung2. Begriffe3. Dokumentation4. Erhebung von Anforderungen5. Management von Anforderungen
1. Priorisierung2. Verfolgung3. Verwalten von Änderungen
6. Qualitätssicherung von Anforderungen
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
1. Einführung2. Begriffe3. Dokumentation4. Erhebung von Anforderungen5. Management von Anforderungen
1. Priorisierung2. Verfolgung3. Verwalten von Änderungen
6. Qualitätssicherung von Anforderungen
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
1. Einführung2. Begriffe3. Dokumentation4. Erhebung von Anforderungen5. Management von Anforderungen6. Qualitätssicherung von
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