Use Cases gibt es seit 1987. Im Mai 2024 haben Ivar Jacobson, Ian Spence und Keith de Mendonca einen überarbeiteten Leitfaden veröffentlicht: Use-Case 3.0. Wenn du meinen früheren Beitrag zu Use-Case 2.0 gelesen hast, ist das der nächste Schritt. Use-Case 3.0 behält die gleichen Kernideen und ergänzt sie mit Struktur, damit Use Cases in jeden modernen Prozess passen.

Dieser Beitrag erklärt, was in Use-Case 3.0 steckt und wie man Use Cases in der Praxis einsetzt.

Was ist Use-Case 3.0?

Use-Case 3.0 ist eine skalierbare, agile Practice Family. Sie nutzt Use Cases, um Anforderungen zu erfassen und die inkrementelle Entwicklung eines Systems zu steuern.

Der Name klingt nach einer neuen Version, ist aber kein UML-Update. Ein Use Case bleibt ein Use Case. Geändert hat sich die Art, wie wir Use Cases darstellen, verwalten und ausliefern. Die Änderungen beruhen auf mehr als 30 Jahren Praxis in vielen Branchen.

Der Leitfaden beschreibt Use-Case 3.0 als leichtgewichtig, skalierbar, vielseitig und einfach in der Anwendung. Es funktioniert für kleine Teams an einem Ort und für grosse verteilte Teams. Es funktioniert auch mit deinen bestehenden Practices. Es schreibt dir nicht vor, wie du planst, designst oder testest. Es gibt dir eine Struktur, in die sich deine gewählten Practices einklinken.

Ein wichtiger Punkt: Use-Case 3.0 ist voll kompatibel mit User Stories. Es ersetzt sie nicht. Es gibt ihnen Kontext und Struktur.

Die Kernkonzepte

Ein Use Case ist die Summe aller Arten, ein System zu nutzen, um ein Ziel eines bestimmten Nutzers zu erreichen.

Dieser eine Satz trägt viel in sich. Er umfasst den Happy Path, die Sonderfälle und die Fehler. Er ist unabhängig von Technologie und Plattform. Er kann als Text geschrieben oder als Diagramm gezeichnet werden.

Use-Case 3.0 baut auf einer kleinen Menge von Konzepten auf:

  • System of Interest. Das System, das du bauen, analysieren oder ändern willst.
  • Actor. Eine Rolle, die mit dem System interagiert. Ein Actor kann eine Person, eine Organisation oder ein anderes System sein. Der Actor, der den Use Case startet, ist der Primary Actor. Die Actors, die das System aufruft, sind Supporting Actors.
  • Ziel. Der Grund, warum der Nutzer das System verwendet, und der Wert, den er dabei erhält.
  • Flow of Events. Ein Use Case ist ein Netz aus Flows. Jeder Flow ist ein Weg zum Wert. Zusammen decken sie alle Arten ab, das Ziel zu erreichen.
  • Use Case. Der Behälter, der die Flows für ein Ziel bündelt.
  • Use-Case Model. Ein Modell, das alle sinnvollen Arten zeigt, das System zu nutzen. Ein Use-Case-Diagramm ist eine Sicht auf dieses Modell.
  • Use-Case Slice. Ein Teil eines Use Case, der für sich genommen klaren Wert liefert. Das ist die zentrale Idee, mehr dazu weiter unten.
  • Work Item. Ein kleines, umsetzbares Stück Arbeit. Häufige Formen sind User Stories, Features und Tasks.

Die zehn Prinzipien

Use-Case 2.0 baute auf sechs Prinzipien auf. Use-Case 3.0 baut auf dem Use-Case Foundation von Ivar Jacobson und Alistair Cockburn auf und nennt zehn. Das zehnte, „build the system in slices“, ist die Ergänzung, die die Practice vollständig macht.

  1. Universell anwendbar. Use Cases funktionieren für Business, IT-Systeme, physische Systeme und jede Mischung davon.
  2. Mit dem grossen Bild starten. Verstehe den Zweck des Systems und wie es genutzt wird, bevor du ins Detail gehst.
  3. Auf Wert fokussieren. Schau auf die Ziele der Nutzer und den besten Weg dorthin, nicht auf eine lange Liste von Features.
  4. Deine Stakeholder einbinden. Bring alle zusammen, um sich über Absicht und Umfang des Systems zu einigen.
  5. Die ganze Geschichte erzählen. Beschreibe den Use Case als Geschichte, vom ersten Ereignis bis zum gelieferten Wert oder dem behandelten Fehler.
  6. Gespräche anstossen. Das Schreiben der Flows hilft dir, fehlende Schritte und fehlende Fälle zu finden, die andere übersehen würden.
  7. Lesbarkeit priorisieren. Das Ziel ist, alle Beteiligten zu erreichen. Halte Modell und Narrative deshalb einfach lesbar.
  8. Just enough, just in time. Starte mit einer Skizze des Flows und ergänze Details erst, wenn du sie brauchst.
  9. In Stufen umsetzen. Bring die wichtigen Flows früh ein. Ergänze die weniger kritischen Flows später.
  10. Das System in Slices bauen. Entwickle das System Slice für Slice. Jeder Slice ist ein oder mehrere Pfade durch einen Use Case, plus Design, Code und Tests, damit es funktioniert.

Wie man einen Use Case schreibt

Die Struktur eines Use Case macht ihn nützlich. Du beschreibst zwei Dinge.

Der Basic Flow ist der normale, glückliche Weg zum Wert. Schreib ihn als einfache Liste von Schritten. Jeder Schritt ist etwas, das das System oder ein Actor tut.

Die Alternate Flows sind die Sonderfälle, die optionalen Schritte und die Fehler. Schreib sie zuerst als Liste von Namen. Du brauchst den vollen Detailgrad nicht von Anfang an.

Hier ein kurzes Beispiel für einen Geldautomaten, den Use Case Withdraw Cash:

Basic Flow:

  1. Karte einführen
  2. Karte prüfen
  3. Bargeldbezug wählen
  4. Konto wählen
  5. Verfügbarkeit der Mittel bestätigen
  6. Karte zurückgeben
  7. Bargeld ausgeben

Alternate Flows:

  • Ungültige Karte
  • Nicht standardisierter Betrag
  • Beleg gewünscht
  • Nicht genug Bargeld im Automaten
  • Nicht genug Guthaben auf dem Konto
  • Karte klemmt

Du erfasst nicht alle Flows auf einmal. Schreib zuerst den Basic Flow. Dabei denkst du automatisch daran, was schiefgehen kann. Notiere das als Alternate Flows und komm später darauf zurück.

Wichtig ist die Genauigkeit des Flows, nicht wie viel du schreibst. Eine Liste mit Stichpunkten reicht oft. Details ergänzt du, wenn das Team sie braucht.

Zwei weitere Punkte zum Schreiben von Use Cases.

Erstens sind die Flows additiv. Der Basic Flow muss vorhanden sein, damit der Use Case gelingt. Die Alternates sind optional. Du kannst sie einzeln hinzufügen. Genau das erlaubt dir, auf Wert zu fokussieren und kleine Releases auszuliefern, die trotzdem funktionieren.

Zweitens sind die Test Cases der wichtigste Teil. Ein Use Case ist erst dann wirklich definiert, wenn du die Test Cases hast. Sie machen die Geschichte konkret. Sie sagen dem Entwickler, wann die Arbeit fertig ist.

Use-Case Slices: Das Herz von 3.0

Ein Use Case ist oft zu gross, um ihn in einem Zug zu bauen. Ein ganzer Use Case kann Tage oder Wochen dauern. Genau hier kommen Slices ins Spiel.

Ein Use-Case Slice ist ein Teil eines Use Case, der klaren Wert liefert. Meist erfasst er einen Weg zum Ziel.

Jeder Slice hat diese Eigenschaften:

  • Er ist end-to-end. Er startet am Anfang des Use Case und endet an seinem Ende.
  • Er durchläuft einen oder mehrere der Flows.
  • Er ist immer testbar. Er kommt mit seinen eigenen Test Cases.

Slices sind die beste Einheit für Umfang und Priorität. Du kannst ein Schema wie MoSCoW (Must, Should, Could, Won’t) auf sie anwenden. Du kannst sie so ordnen, dass die wertvollste Arbeit zuerst kommt.

Du musst nicht den ganzen Use Case auf einmal in Slices zerlegen. Zieh die Slices heraus, die du jetzt brauchst, und lass den Rest liegen. Du kannst Entwickler sogar einen neuen Slice anfordern lassen, wenn sie Kapazität haben.

Ein Slice kann so dünn sein, wie du willst. Der kleinste Slice ist ein einzelner Test Case durch einen einzelnen Pfad. Du könntest mit einem end-to-end Pfad starten, mit fest verdrahteten Werten und ohne Fehlerbehandlung, nur um zu beweisen, dass das System funktioniert.

Eine Idee wird leicht übersehen. Ein Slice schneidet durch mehr als die Anforderungen. Er schneidet auch durch Design, Code und Tests. Das gibt dir Traceability von einer Anforderung bis zum Code und zu den Tests, die sie belegen. Es zwingt dich auch, die Auswirkung eines Slice auf das System zu bedenken, bevor du ihn baust.

Von Slices zu Work Items

Slices sind noch nicht das, was du einem Entwickler in die Hand gibst. Du machst aus einem Slice Work Items, die in das Backlog deines Teams passen.

Die zwei üblichen Formen sind User Stories und Tasks.

Bei User Stories kommt das Team zusammen und sammelt die Stories, die für einen Slice nötig sind. Vielleicht ergänzt du ein paar technische Stories, zum Beispiel einen Spike, um ein Supporting System anzubinden, oder eine Story für das End-to-End-Testing des ganzen Slice.

Bei Tasks erstellst du eine Reihe von Tasks pro Slice, etwa Screen-Design, Interface-Code, Unit Test, Integration Test und System Test.

In beiden Fällen gilt das gleiche Prinzip. Der Slice ist das Team-Ziel. Die Work Items sind die Schritte dorthin. Use-Case 3.0 unterstützt jeden Planungs- und Arbeitsstil, den dein Team bereits nutzt.

Die Lifecycle States

Use-Case 3.0 gibt dir einfache States, um Fortschritt zu verfolgen. Du brauchst kein schweres Tool. Haftnotizen oder eine Tabelle reichen.

Ein Use Case durchläuft diese States:

  1. Goal Established
  2. Flow Structure Understood
  3. Basic Flow Enabled
  4. Sufficient Flows Fulfilled
  5. All Flows Fulfilled

Ein Use-Case Slice durchläuft diese States:

  1. Identified
  2. Defined
  3. Analyzed
  4. Prepared
  5. Implemented
  6. Verified

Das kann nach Wasserfall aussehen, ist es aber nicht. Du verfolgst jeden Slice für sich. Über die Menge der Slices hinweg kann die ganze Arbeit parallel laufen. Ein Slice wird verifiziert, während ein anderer implementiert und ein dritter vorbereitet wird.

Die Aktivitäten: Wie die Arbeit fliesst

Use-Case 3.0 teilt die Arbeit in eine Menge von Aktivitäten. Manche entdecken und ordnen die Anforderungen. Andere formen, bauen und testen das System. Du wiederholst sie nach Bedarf, nicht einmal in fester Reihenfolge.

  • Find Actors and Use Cases. Führe einen Workshop mit deinen Stakeholdern durch. Versuch nicht, jeden Use Case zu finden. Fokussiere auf die, die den nötigen Wert liefern. Ordne sie so, dass sie deinen Release-Plan stützen.
  • Discuss and Slice a Use Case. Bau ein gemeinsames Verständnis des Use Case auf und zieh die ersten Slices heraus. Mach das mit deinen Stakeholdern, damit jeder Slice den Bau wert ist. Zerlege nicht alles auf einmal.
  • Analyze a Use-Case Slice. Bevor du codest, kläre, wie der Slice das System betrifft. Was muss sich ändern, was ist neu? Das Ergebnis heisst Use-Case Realization.
  • Prepare a Use-Case Slice. Mach ihn baubereit. Kläre das Narrative, definiere die Test Cases und teile ihn in Work Items. Hat ein Slice keine Test Cases, ist er nicht prepared.
  • Implement Software for a Slice. Design, Code, Unit Test und Integration der Teile, die den Slice funktionieren lassen.
  • Test the System for a Slice. Führe die Test Cases des Slice aus, um zu bestätigen, dass er funktioniert. Weil Slices unabhängig sind, bekommst du schnelles Feedback.
  • Test the System as a Whole. Prüfe, ob die neuen Slices zusammenspielen und nichts kaputt gemacht haben, das schon funktioniert hat.
  • Inspect and Adapt the Use Cases. Halte das Modell aktuell. Behandle Änderungen, verfolge Fortschritt und justiere die Grösse deiner Slices.

Die Practice Family

Die grösste Änderung in Use-Case 3.0 ist die Verpackung. Es ist keine grosse Methode mehr. Es ist eine Familie von Practices, die du mischst und kombinierst.

Du startest mit einer oder beiden der zwei essenziellen Practices:

  • Use-Case Storytelling. Nutze einfache Narratives, um das Team darauf zu fokussieren, ein nutzbares System mit klarem Wert zu liefern.
  • Light Use-Case Modeling. Erstelle ein einfaches visuelles Modell, das den Wert des Systems zeigt und wie Nutzer ihre Ziele erreichen.

Kombiniere die beiden, und du erhältst Use-Case Essentials. Das ist der übliche Startpunkt für alle, die neu bei Use Cases sind.

Wenn du mehr brauchst, ergänzt du Practices:

  • Use-Case Authoring für detaillierte, formale Narratives. Nutze es für komplexe oder sicherheitskritische Systeme, oder wenn ein Vertrag eine volle Spezifikation braucht.
  • Structured Use-Case Modeling, um die volle Systemgrenze zu erfassen und Releases und Optionen zu modellieren.
  • Use-Case Realization, um mit UML die Auswirkung eines Use Case auf dein Design zu analysieren.

Du kannst Use-Case 3.0 auch vollständig nutzen, aber das ist auf einmal viel. Der Sinn der Familie ist, dass du nur nimmst, was du brauchst, und Struktur später ergänzt.

Was sich von 2.0 zu 3.0 geändert hat

Wenn du Use-Case 2.0 kennst, hier das Neue.

  • Use-Case 3.0 baut auf dem Use-Case Foundation von Jacobson und Cockburn auf, veröffentlicht 2024.
  • Es ergänzt das zehnte Prinzip, „build the system in slices“.
  • Es ist als modulare Practice Family verpackt, sodass du es in kleinen Schritten einführen kannst.
  • Es ergänzt das Konzept Work Item. Damit kannst du Use Cases mit Scrum, Kanban und grösseren Frameworks wie SAFe und Nexus kombinieren, oder mit einfacher task-basierter Planung.
  • Es sagt klar, dass Use Cases und User Stories zusammenarbeiten.

Die Struktur, die du aus 2.0 kennst, ist weiterhin da. Der Refresh macht sie leichter einführbar und leichter mit modernen Arbeitsweisen kombinierbar.

Wie man startet

Du musst die ganze Practice nicht am ersten Tag einführen. Starte klein.

  1. Zeichne ein Use-Case-Diagramm. Finde die Actors und die Use Cases für dein System. Das dauert etwa 30 Minuten und gibt dir das grosse Bild.
  2. Schreib ein Use-Case Narrative. Wähle den wichtigsten Use Case. Schreib den Basic Flow als Liste mit Stichpunkten. Liste die Alternate Flows nur mit Namen.
  3. Zerlege ihn und bau den ersten Slice. Zieh den zentralsten Slice heraus, den, der end-to-end geht. Definiere seine Test Cases. Mach daraus Work Items und bau ihn.

Verfolge deine Use Cases und Slices auf einer Tabelle oder auf Haftnotizen. Für den Start braucht es kein spezielles Tooling.

Fazit

Use Cases geben dir das grosse Bild und die Struktur. Slices geben dir richtig grosse, testbare Einheiten von Wert. Test Cases geben dir eine klare Definition of Done. Work Items fügen das Ganze in die Arbeitsweise ein, die dein Team schon nutzt.

Use-Case 3.0 ersetzt weder User Stories noch deinen Prozess. Es gibt ihnen ein Zuhause. In einer Zeit, in der klare Spezifikationen wichtiger sind denn je, ist diese Struktur einen zweiten Blick wert.

Referenzen