Generelles
- Wird auch Anwendungsfalldiagramm genannt
- Zeigt funktionale Anforderung an das Gesamtsystem (Nutzerinteraktionen)
- Aufgaben: Visualisierung, Spezifizierung und Dokumentation
- Darstellung der Akteure eines Systems
- Zeigt Aktionen von System und Nutzern (Mensch/anderes System)
- Stellt Erfolge und Misserfolge dar
- Basis für die Verständigung von Entwicklern, Endanwendern und Fachleuten für den Anwendungsbereich
- Für die Requirements, für die Überprüfung der Architektur, und für den Test genutzt
- Werden von allen Stakeholdern definiert
- Zeigt keine Implementierung
- Use Cases sind keine vollständige Anforderungsanalyse, nur ein Bestandteil davon.
1. Anwendungsfälle analysieren
- Beginn mit Sunny-Day-Szenario
- Was will der Aktor (aus Vogelperspektive gesehen)?
- Verschiedene Use Cases bei versch. Aktoren
- Wer/Wo/Wann/Was Fragen stellen
- Welche Infos werden ausgetauscht?
- Welche Unregelmäßigkeiten können auftreten?
- Keine internen Abläufe aufführen, nur aus Sicht des Kunden
2. Textkarten erstellen
Alle Anwendungsfälle werden in Tabellenform aufgeschrieben. Beispielsweise so:
Use Case | ein Vorgang im System |
Connected Use Cases | verbundene Anwendungsfälle (via include) (Bezeichnung immer mit Subjekt + Verb; konkret und verständlich formulieren) |
System | enthält gesamte Software Systemname in Kasten darstellen |
Akteur |
|
Primary Actor | Auslöser von Case (Kunde etc.) |
Further Actors | spätere Akteure (Kundenbearbeiter etc.) |
Trigger |
|
Success Guarantees | Ziel der Aktion (laut Titel) |
Beispiel
| Use Case | Briefzustellung |
| Connected Use Cases | – Nachricht hinterlassen – Identität prüfen – Einschreiben zustellen |
| System | Post |
| Akteur | – Postbote – Empfänger |
| Primary Actor | Brief |
| Further Actors | Identitätsausweis, Handgerät, Benachrichtigungskarte |
| Trigger | Brief muss zugestellt werden (wurde dem Postbote zugeteilt) |
| Success Guarantees | Brief erfolgreich abgegeben oder Nachricht hinterlassen |
4. Diagramm erstellen
Ziel: Die verschiedenen Anwendungsfälle in einem oder mehreren Diagrammen übersichtlich modellieren.
Diagrammelemente
System
Der Systemkontext wird durch Systemgrenzen in Form von Rechtecken gekennzeichnet. Mehrere Subsysteme sind in einem Diagramm darstellbar. Oben wird im Rechteck der Name des Systems eingetragen.
Actor
Kann eine Person oder ein anderes System sein, welches interagiert. Darstellung als Strichmännchen mit Namen darunter. Steht überlicherweise außerhalb des Systems.
Use Case
Namen der einzelnen Anwendungsfälle, die einem oder mehreren Actors zugeordnet werden. Darstellung in Ellypsen, mit Kanten verbunden.
Kanten
Verbinden einen oder mehrere Actors mit Use-Cases. Erster Pfeil zeigt zu Hauptaktion (ohne Pfeil), restliches kann dann “included” werden (wenn aufeinander aufbauend, Pfeilrichtung beachten).
Beziehungen
include-Beziehung
- Importiert vorgesehenen Use Case in einen anderen (wird normalerweise genutzt)
- Nutzung bei selbem Verhalten von mehreren Use Cases
- Notation mit gestrichteltem Pfeil und Bezeichnung <<include>>
extend-Beziehung
- Erweiterung von Use Case um einen weiteren (unabhängig)
- enthält z. B. return-Point (kann auch Abbruch sein)
- Notation mit gestrichteltem Pfeil und Bezeichnung <<extend>>
Generalisierung
- Zeigt von Spezialisierung auf allgemeinen Anwendungsfall/Actor
- Darstellung mit Pfeil
Aufbau von Abzweigungen
- Trigger (Bedingung für Aufruf von Course)
- Alternative Course (Ablaufschritte)
- sog. Action-Steps (Aktionen von System/Nutzer)
- Rückkehr/Abbruch/Ausgabe
Beispiel
Begriffe erklärt
| Succcess Guarantees/Use Case-Business-Result/Main Success Scenario | Alle Bedingungen, die im Erfolgsfall erfüllt sein müssen |
| Minimal Guarantees | Bedingungen die immer erfüllt sein müssen (z. B. Pflichtfelder oder Abbruch, Meldung anzeigen, Karte ausgeben, Protokollierung…) |
| Alternative Course | Abzweigung (z.B. bei Fehlern) Werden als vollständige Use Cases beschrieben. |
Praxistipps
- Erst Textkarten erstellen
- Beginn mit dem Sunny Day Scenario
- Aktive Formulierungen (Subjekt, Prädikat, Objekt) nutzen
- Exakte, kurze Formulierung (kein sollte/müsste)
- Von außen gucken
- Kein Userinferface beschreiben, nur die Ziele fokussieren
- Lieber wenig Schritte, notfalls zusammenfassen (max. 9 Schritte, danach Auslagern/Zusammenfassen)