Anwendungsfaelle (Use Cases) - auf Matthias-Draeger.info
Anwendungsfaelle (Use Cases) - auf Matthias-Draeger.info Anwendungsfaelle (Use Cases) - auf Matthias-Draeger.info
Und: Anforderungen müssen einleuchten • Gute, sinnvolle Anforderungen kann man immer in einleuchtender Form beschreiben • Evtl. fehlt nur ein Überblick • Hinterfragen Sie also uneinleuchtende! Lutz Prechelt, prechelt@inf.fu-berlin.de [6] 38 / 44
Wie geht's dann weiter? • Use Cases sind aus Benutzersicht wunderbar • klar, prüfbar, einleuchtend • Auch als Werkzeug für die Anforderungserhebung sind sie günstig • einfach zu schreiben, einfach mit Beteiligten abzugleichen • Aus Entwicklersicht lassen sie aber zu wünschen übrig • Sie beschreiben nicht, welche Funktionen die SW braucht • Und auch nicht, was für Daten im System vorhanden sind • Es ist unklar, wie man die Arbeit auf Personen verteilen kann • Deshalb müssen als nächstes Daten und Funktionen identifiziert werden • Anforderungsanalyse • Siehe nächste Vorlesungen Lutz Prechelt, prechelt@inf.fu-berlin.de [6] 39 / 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 und 24: Konzentrieren Sie sich auf das Wese
- Seite 25 und 26: Wichtigkeit von Zielen • Ein gute
- 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: Checkliste für Use-Case-Bestandtei
- Seite 41 und 42: Warnung: Use-Case-Diagramme • UML
- Seite 43 und 44: Quelle • Alistair Cockburn: "Writ
Und:<br />
Anforderungen müssen einleuchten<br />
• Gute, sinnvolle<br />
Anforderungen kann<br />
man immer in<br />
einleuchtender Form<br />
beschreiben<br />
• Evtl. fehlt nur ein<br />
Überblick<br />
• Hinterfragen Sie also<br />
uneinleuchtende!<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [6] 38 / 44
Change language