- Zunächst wird eine kurze Beschreibung der nur für den normalen Ablauf des Anwendungsfalls erforderlichen Schritte verfasst (d. h. welche Funktion der Anwendungsfall bereitstellt).
- Im Verlauf der Analyse werden diese Schritte mit mehr Details ausgearbeitet.
- Schließlich werden alternative und Ausnahmeabläufe zum Anwendungsfall hinzugefügt.
- Jedes Projekt kann eine standardisierte Anwendungsfallvorlage verwenden, um Anwendungsfallspezifikationen zu erstellen.
Anwendungsfall im Vergleich zu Anwendungsfallspezifikation
Ein Anwendungsfall beschreibt eine Aufgabe, die von einem Akteur ausgeführt wird und geschäftlichen Wert liefert. Ein Anwendungsfall kann als Anwendungsfalldiagramm und/oder in einer strukturierten textuellen Spezifikationsform dargestellt werden:

- Interaktion — Systemanwendungsfälle beschreiben, wie ein Akteur mit dem System interagiert, um ein festgelegtes geschäftliches Ziel zu erreichen.
- Manuell — Eine Folge von Aktionen, die vom Akteur ausgeführt werden.
- Automatisiert — Eine Folge von Schritten, die von einem Programm oder Skript ausgeführt werden.
Eigenschaften eines Anwendungsfalls
Ein Anwendungsfall hat:
- Nur ein Ziel
- Ein Startpunkt
- Ein Endpunkt
- Mehrere Wege vom Start zum Ende
- Das heißt, es legt das Verhalten für verschiedene mögliche Bedingungen fest
- Jede Bedingung kann spezifische Aktionen erfordern

Zum Beispiel — Kunde zahlt eine Rechnung:

Es gibt mehrere Wege, umdas Ziel zu erreichen:
- Per Telefon
- Per Post
- Persönlich
- Per Scheck
- In bar, usw.
Pfade, die nicht zum Ziel führen:
- Kreditkarte abgelehnt
Agiler Use-Case-Ansatz
Das Use-Case-Modell und seine einzelnen Use-Cases entwickeln sich im Laufe der Zeit schrittweise weiter. Es ist nicht erforderlich, dass alle Use-Cases im Modell auf der gleichen Detailstufe spezifiziert werden.
Just-in-Time und Just-Enough
Use-Cases können auf unterschiedlichen Detail- und Umfangsebenen verfasst werden, wobei jeder eine bestimmte Funktion erfüllt:
- Zusammenfassung: Eine allgemeine Beschreibung und Übersicht auf hoher Ebene einer Systemfunktion oder eines Geschäftsprozesses.
- Benutzer-Ziel-Ebene: Aufgabenbezogene Beschreibungen von den BenutzerZiele und deren Interaktion mit dem System; Beschreibungen spezifischer Geschäftsprozesse. Use-Cases auf Benutzer-Zielebene gelten typischerweise als auf der Ebene der primären Arbeitsaufgaben des Benutzers.
Beispiel: Das Abheben von Bargeld von einem Geldautomaten ist eine sinnvolle Aufgabe und wäre ein Use-Case auf Kern-Ebene, aber das Eingeben Ihrer PIN wäre nicht auf dieser Ebene, da es die Hauptaufgabe unterstützt.
- Unterfunktion: Beschreibungen von Aktivitäten auf niedrigerer Ebene, die Teile eines Kern-Use-Cases abschließen.

Hinweis: Einige Use-Cases können vollständig auf Ebene II spezifiziert werden. Sie hören auf, sobald Sie genau die notwendige Detailtiefe erreicht haben, die zeitnah und ausreichend ermittelt wurde.
Detaillierte Use-Case-Spezifikation
Ein detaillierter Use-Case ist eine textuelle Darstellung, die eine Ereignisfolge sowie weitere relevante Use-Case-Informationen in einem bestimmten Format beschreibt. Menschen verwenden typischerweise eine Standard-Use-Case-Vorlage, um detaillierte Use-Case-Informationen zu dokumentieren.

Use-Case-Vorlage – Beispiel: Bargeldabhebung am Geldautomaten
Wie bereits erwähnt, haben Use-Cases verschiedene Notationsformen (z. B. diagrammatisch, UML, Textformat). Unabhängig von der verwendeten Notation sollte sie leicht verständlich sein. Sie können eine Vorlage wie die von Alistair Cockburn, oder wählen Sie die Vorlage, die am besten zu Ihrem Team passt.
| Use-Case-Spezifikation | ||
|---|---|---|
| Anwendungsfalld Name: | Geld abheben | |
| Akteure: | Kunde (primär), Bankensystem (sekundär) | |
| Kurzbeschreibung: | Ermöglicht jedem Bankkunden, Geld von seinem Bankkonto abzuheben. | |
| Priorität: | Muss haben | |
| Status: | Mittlerer Detailgrad | |
| Voraussetzungen: | Der Bankkunde verfügt über eine Karte, die in den Geldautomaten eingelegt werden kann Der Geldautomat ist online und funktioniert normal |
|
| Nachbedingungen: |
|
|
| Grundablauf: |
|
|
| Alternative Abläufe: | 2a. Ungültige Karte 2b. Karte falsch herum eingelegt 5a. Gestohlene Karte 5b. Ungültiges PIN 10a. Unzureichendes Bargeld im Gerät 10b. Falscher Bargeldbetrag im Gerät 11a. Abhebung überschreitet die Abhebegrenze 12a. Unzureichende Mittel auf dem Bankkonto des Kunden 14a. Bankkarte steckt im Gerät 15a. Der Kunde nimmt die Bankkarte nicht 16a. Bargeld steckt im Gerät 17a. Der Kunde nimmt das Bargeld nicht
|
|
| Geschäftsregeln: | B1: PIN-Format B2: Anzahl der PIN-Versuche B3: Dienstleistungsangebote B4: Betragsauswahl B5: Abhebegrenzen B6: Die Karte muss vor der Bargeldausgabe entnommen werden |
|
| Nicht-funktionale Anforderungen: | NF1: Zeit zur Abwicklung der Transaktion NF2: Sicherheit der PIN-Eingabe NF3: Zeit zur Abholung der Karte und des Bargelds NF4: Sprachunterstützung NF5: Unterstützung für blinde und teilweise sehbehinderte Benutzer |
|