Anwendungsfaelle (Use Cases) - auf Matthias-Draeger.info
Anwendungsfaelle (Use Cases) - auf Matthias-Draeger.info Anwendungsfaelle (Use Cases) - auf Matthias-Draeger.info
Präzision der Form Nicht nur beim Inhalt, auch in der Form der Use Cases gilt die Regel "bitte gerade genau genug": • Informelle Use Cases sind eventuell reiner Fließtext • ganz ohne Abschnittsnamen und feste Struktur • Die wichtigsten Angaben (Hauptakteur, Ziel, wichtigste Schritte) müssen natürlich erkennbar sein • Meist ist etwas Struktur aber dermaßen hilfreich, dass sie sich empfiehlt Der umgekehrte Fall gilt ebenso: • Wenn die Anforderungen kritisch sind oder im Team keine hohe Kommunikation herrschen kann • z.B. weil es sehr groß oder örtlich verteilt ist • dann kann verstärkte Struktur nützlich sein • z.B. mehr feste Abschnitte oder rigidere Formulierungsweise Lutz Prechelt, prechelt@inf.fu-berlin.de [6] 24 / 44
Wichtigkeit von Zielen • Ein gutes Anforderungsdokument benennt Anforderungen nicht einfach, sondern begründet sie • damit man Mehrdeutigkeiten leichter ausräumen kann • damit man Prioritäten vernünftig setzen kann • In Use Cases werden die Begründungen durch die Ziele geliefert • Ein Ziel beantwortet zu den Schritten die Frage "Warum?" • Der Name eines Use Cases sollte ein Ziel bezeichnen • In einem umfassenderen Use Case tritt dieses Ziel als Schritt auf • Ziele-als-Schritte beschreibt eine hierarchische Zerlegung • so dass einzelne Use Cases übersichtlich/beherrschbar bleiben • Ein guter Use Case hat meistens 3 bis 9 Schritte Lutz Prechelt, prechelt@inf.fu-berlin.de [6] 25 / 44
- Seite 1 und 2: Vorlesung "Softwaretechnik" Kapitel
- Seite 3 und 4: Wo sind wir?: Anforderungsermittlun
- Seite 5 und 6: Welche Form hat ein Use Case? • N
- Seite 7 und 8: Bsp: Use Case "Über WWW Aktien kau
- Seite 9 und 10: Ein realer Use Case • Die Beschre
- Seite 11 und 12: Beispiel 2: Auto-Unfallschaden erse
- Seite 13 und 14: Zusätzliche Felder Je nach Projekt
- Seite 15 und 16: Arten von Use Cases Use Cases könn
- Seite 17 und 18: Arten von Use Cases (3) Anders ausg
- Seite 19 und 20: Feinkörnigere Use Cases sind mögl
- Seite 21 und 22: Präzisions-Gefahren bei Use Cases
- Seite 23: Konzentrieren Sie sich auf das Wese
- Seite 27 und 28: Beispiel: Gesund werden (2) • Use
- Seite 29 und 30: Beispiel: Gesund werden - Beobachtu
- Seite 31 und 32: Beispiel Wie? Warum? Lutz Prechelt,
- Seite 33 und 34: Schrittweises Modell für das Gesam
- Seite 35 und 36: Checkliste für Use-Case-Bestandtei
- Seite 37 und 38: Checkliste für Use-Case-Bestandtei
- Seite 39 und 40: Wie geht's dann weiter? • Use Cas
- Seite 41 und 42: Warnung: Use-Case-Diagramme • UML
- Seite 43 und 44: Quelle • Alistair Cockburn: "Writ
Wichtigkeit von Zielen<br />
• Ein gutes Anforderungsdokument benennt Anforderungen<br />
nicht einfach, sondern begründet sie<br />
• damit man Mehrdeutigkeiten leichter ausräumen kann<br />
• damit man Prioritäten vernünftig setzen kann<br />
• In <strong>Use</strong> <strong>Cases</strong> werden die Begründungen durch die Ziele<br />
geliefert<br />
• Ein Ziel beantwortet zu den Schritten die Frage "Warum?"<br />
• Der Name eines <strong>Use</strong> <strong>Cases</strong> sollte ein Ziel bezeichnen<br />
• In einem umfassenderen <strong>Use</strong> Case tritt dieses Ziel als Schritt <strong>auf</strong><br />
• Ziele-als-Schritte beschreibt eine hierarchische Zerlegung<br />
• so dass einzelne <strong>Use</strong> <strong>Cases</strong> übersichtlich/beherrschbar bleiben<br />
• Ein guter <strong>Use</strong> Case hat meistens 3 bis 9 Schritte<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [6] 25 / 44
Change language