Cockburn Use Cases

Details
Vollständiger Name

Cockburn Use Cases (Writing Effective Use Cases)

Auch bekannt als

Fully Dressed Use Cases, Goal-Level Use Cases, Cockburn-Format

Kernkonzepte:

Fully Dressed Format

Ein strukturiertes textuelles Template zur Beschreibung von Systemverhalten aus Sicht des Akteurs. Jeder Use Case enthält: Primary Actor, Stakeholders & Interests, Vorbedingungen, Trigger, Main Success Scenario (nummerierte Schritte), Extensions (alternative/Fehlerpfade mit Schrittverweisen), Nachbedingungen (Success Guarantee und Minimal Guarantee) sowie Technology & Data Variations.

Goal Levels

Drei Abstraktionsebenen, die Use Cases hierarchisch organisieren:

  • Summary (Kite/Cloud) — Geschäftsprozessziele über mehrere Sitzungen. Beispiel: "Kundenlebenszyklus verwalten."

  • User Goal (Sea Level) — der Idealfall: ein Akteur, eine Sitzung, ein messbares Ergebnis. Beispiel: "Bestellung aufgeben." Die meisten Use Cases leben hier.

  • Subfunction (Fish/Clam) — Schritte, die ein User Goal unterstützen, aber selbst keine eigenständigen Ziele sind. Beispiel: "Benutzer authentifizieren." Nur extrahieren, wenn sie in mehreren User-Goal-Use-Cases wiederverwendet werden.

Scope

Definiert die Systemgrenze — was innerhalb des "Design Scope" liegt und was externer Akteur ist. Cockburn verwendet Ikonen (ein Kasten für das System, eine Person für Akteure), um die Grenze visuell zu machen. Den richtigen Scope zu treffen verhindert, dass Use Cases entweder zu vage (organisatorischer Scope) oder zu detailliert (Komponenten-Scope) werden.

Actor-Goal-Liste

Die Discovery-Technik: jeden Akteur und jedes Ziel auflisten, das er gegenüber dem System hat. Das ergibt eine Kandidatenliste für Use Cases, bevor Prosa geschrieben wird. Der Goal-Level-Test: "Geht der Akteur zufrieden nach Hause, wenn dieses Ziel erreicht ist?" filtert Subfunctions heraus, die sich als User Goals tarnen.

Was Cockburn nicht vorschreibt

Cockburns Format ist bewusst prosabasiert und notationsagnostisch. Es verlangt keine Activity-Diagramme, kein Gherkin, kein EARS und keine formale Syntax. Das sind komplementäre Darstellungsformen, die darauf aufbauen können — Activity-Diagramme für visuellen Fluss, Gherkin für ausführbare Akzeptanzkriterien, EARS für strukturierte Anforderungsformulierungen.

Schlüsselvertreter

Alistair Cockburn (Writing Effective Use Cases, Addison-Wesley, 2001). Das Buch bleibt die kanonische Referenz; Cockburn ist auch Mitunterzeichner des Agilen Manifests und Begründer der Crystal-Methodologien.

Wann zu verwenden:

  • Herausfinden was ein System tun muss, bevor entschieden wird wie es gebaut wird — die Actor-Goal-Liste ist ein schneller, strukturierter Brainstorm

  • Requirements-Gespräche mit Stakeholdern strukturieren, die in Szenarien denken, nicht in Features

  • Ein großes System in handhabbare Verhaltenseinheiten auf der richtigen Granularität zerlegen (Goal-Level-Test)

  • Brownfield-Theorie-Rekonstruktion: aus beobachtetem Verhalten Use Cases schreiben

  • Downstream-Artefakte befüttern: jeder Use Case wird zur natürlichen Einheit für Activity-Diagramme, Gherkin-Szenarien und Testpläne

  • arc42 ergänzen: Use Cases füllen Abschnitt 6 (Laufzeitsicht) und informieren Abschnitt 3 (Kontextabgrenzung)

Verwandte Anker:

  • Gherkin - Ausführbare Akzeptanzkriterien, die aus jedem Extension-Pfad eines Use Cases abgeleitet werden können

  • BDD Given/When/Then - Formalisiert die Szenario-Schritte, die Cockburn in Prosa beschreibt

  • EARS Requirements - Strukturierte Syntax für einzelne Anforderungsformulierungen; ergänzt Cockburns szenariobasierte Struktur

  • arc42 - Use Cases füllen Abschnitt 6 (Laufzeitsicht) und informieren Abschnitt 3 (Kontextabgrenzung)

  • ISO 25010 - Qualitätsziele, die Use-Case-Extensions adressieren sollten (Fehlerbehandlung, Performance, Sicherheit)

Weiterführend:

  • Anchors and Training Data - warum dieser Anker Cockburns Handwerk abbildet und nicht Jacobsons spätere Use-Case 2.0/3.0, und was das über die Abhängigkeit von Ankern von den Trainingsdaten verrät.

Aktueller Stand:

  • Writing Effective Use Cases (2001) hat nie eine zweite Auflage bekommen und bleibt der kanonische Handwerkstext — und der dichteste, am zuverlässigsten aktivierte LLM-Prior für das Schreiben von Use Cases

  • Jacobsons Nachfolger existiert und trägt als eigener Anker: Use-Case 2.0 (Jacobson, Spence & Bittner, freies Ebook, 2011) passt Use Cases über Use-Case Slices an iterative Lieferung an

  • Use Case 3.0 (de Mendonca & Jacobson, v1.0, 2024) existiert tatsächlich — ist aber zu jung für einen Anker: LLMs halten dafür keinen dichten Prior (siehe Weiterführend oben); wer 3.0-Semantik will, liefert die Definition im Prompt mit. Jacobson und Cockburn haben ihr Handwerk in "Use Cases are Essential" (ACM Queue, 2023) neu zusammengeführt