Viele Teams behandeln User Stories heute als einzige Methode, um Anforderungen zu erfassen. Aber es gibt eine ältere, bewährte Technik, die besser skaliert und etwas bietet, was User Stories fehlt: Kontext. Sie heisst Use-Case 2.0, und sie verdient einen zweiten Blick, besonders im Zeitalter der KI-gestützten Entwicklung.

Was ist Use-Case 2.0?

Use-Case 2.0 ist eine Praxis von Ivar Jacobson, Ian Spence und Kurt Bittner. Sie baut auf der ursprünglichen Use-Case-Technik auf, die Jacobson 1987 an der OOPSLA vorgestellt hat. Das „2.0“ ist kein UML-Versionsupdate. Es ist eine modernisierte Art, Use Cases anzuwenden, die mit agilen, Kanban- und sogar Wasserfall-Ansätzen funktioniert.

Im Kern erfasst ein Use Case alle Wege, ein System zu nutzen, um ein bestimmtes Ziel für einen bestimmten Benutzer zu erreichen. Das unterscheidet sich von einer User Story, die eine einzelne Wertaussage erfasst. Ein Use Case gruppiert verwandte Stories und gibt ihnen Struktur.

Die sechs Prinzipien

Use-Case 2.0 basiert auf sechs Prinzipien:

  1. Halte es einfach, indem du Geschichten erzählst. Man erkundet Use Cases durch Storytelling. Die Geschichten werden zu Flows (Basic und Alternative), und jeder Flow bekommt Testfälle. Die Testfälle sind wichtiger als die Narrative selbst, sie definieren, was „fertig“ bedeutet.
  2. Verstehe das grosse Bild. Ein Use-Case-Diagramm zeigt alle Ziele des Systems auf einen Blick. Man kann den Scope eines Releases in Minuten festlegen, indem man entscheidet, welche Use Cases drin sind und welche nicht.
  3. Fokussiere auf Wert. Der Basic Flow ist der einfachste Weg, das Ziel zu erreichen. Alternative Flows fügen Optionen und Fehlerbehandlung hinzu. Man kann den Basic Flow zuerst ausliefern und Alternativen später ergänzen. Das ist von Design her additiv.
  4. Baue das System in Slices. Das ist die zentrale Innovation. Ein Use-Case Slice ist ein Stück eines Use Case, das unabhängig implementierbar und testbar ist. Slices schneiden durch Anforderungen, Design, Implementierung und Test, nicht nur durch die Anforderungsebene.
  5. Liefere das System in Inkrementen. Slices werden zu Inkrementen zusammengesetzt, und Inkremente zu Releases. Jedes Inkrement baut auf dem vorherigen auf.
  6. Passe dich den Bedürfnissen des Teams an. Use-Case 2.0 skaliert von Karteikarten für kleine Teams bis zu ausführlichen Dokumenten für verteilte Teams. Man beginnt mit dem Nötigsten und fügt Details nur bei Bedarf hinzu.

Use Cases vs. User Stories

Eine User Story ist ein eigenständiges Element. Sie hat keine eingebaute Beziehung zu anderen Stories. Ein Product Backlog mit 200 User Stories ist ohne zusätzliche Gruppierungsmechanismen wie Epics oder Themes schwer zu navigieren.

Ein Use Case ist anders. Er gruppiert alle verwandten Stories unter einem Ziel. Er hat einen Basic Flow, Alternative Flows und Testfälle. Wenn man einen Use Case anschaut, sieht man das vollständige Bild, wie ein Benutzer ein bestimmtes Ziel erreicht, nicht nur ein einzelnes Fragment.

Use-Case 2.0 führt auch Use-Case Slices ein, um Use Cases in kleinere Arbeitspakete für die manuelle Entwicklung aufzuteilen. Ein Slice referenziert bestimmte Flows und Testfälle und kann auf die Grösse eines Sprints oder einer Kanban-Spalte zugeschnitten werden. Das war eine wichtige Idee für Teams, die Code von Hand schreiben und kleine, schätzbare Arbeitspakete brauchen.

Aber wie wir sehen werden, ändert KI diese Gleichung. Wenn KI die Implementierung generiert, muss man einen Use Case nicht mehr in kleine Stücke zerlegen. Man kann mit dem ganzen Use Case auf einmal arbeiten.

Warum das für die moderne Entwicklung wichtig ist

In meiner Erfahrung mit Spring Boot, Vaadin und jOOQ Projekten sehe ich, dass Teams mit denselben Problemen kämpfen:

  • User Stories verlieren den Kontext. Wenn man Story #147 liest, weiss man nicht, wie sie mit den Stories #23, #89 und #201 zusammenhängt. Mit Use Cases leben all diese Stories unter demselben Use Case und referenzieren dieselbe Narrative.
  • Testfälle kommen zu spät. Viele Teams schreiben Abnahmetests nach der Implementierung. Use-Case 2.0 erstellt Testfälle als Teil des Use Case, vor dem Programmieren. Das ist Test-First by Design.
  • Das grosse Bild fehlt. Teams springen direkt in Stories, ohne das System als Ganzes zu verstehen. Ein Use-Case-Modell mit 10-15 Use Cases gibt diesen Überblick in einem einzigen Diagramm.
  • Die Gruppierung fehlt. User Stories sind flach. Use Cases gruppieren verwandtes Verhalten unter einem einzigen Ziel. Man weiss immer, wohin eine Anforderung gehört und wie sie mit anderen Anforderungen zusammenhängt.

Von Use-Case 2.0 zum AI Unified Process

Hier wird es interessant. Use-Case 2.0 wurde 2011 geschrieben, lange bevor es KI-Coding-Assistenten gab. Aber die Prinzipien passen perfekt zur KI-gestützten Entwicklung. Tatsächlich ist Use-Case 2.0 eine der Grundlagen des AI Unified Process (AIUP), den ich entwickle.

AIUP ist eine anforderungs- und spezifikationsgetriebene Entwicklungsmethodik. Sie hält Anforderungen im Zentrum, während KI die Implementierung übernimmt. Die Verbindung zu Use-Case 2.0 ist direkt: AIUP verwendet Use Cases als primäres Spezifikationsformat, das die KI-Codegenerierung steuert.

Use Cases als KI-Spezifikationen

KI-Coding-Assistenten wie Claude Code arbeiten am besten mit klaren, strukturierten Spezifikationen. Eine Use-Case Narrative mit Flows und Testfällen ist genau das. Sie gibt der KI:

  • Ein klares Ziel (der Use Case)
  • Einen schrittweisen Ablauf (der Basic Flow)
  • Definierte Variationen (Alternative Flows)
  • Abnahmekriterien (Testfälle)

Das ist viel handlungsfähiger als eine einzeilige User Story. Die Narrative sagt der KI, was das System tun soll. Die Testfälle sagen ihr, wann es fertig ist. In AIUP ist das der Kernzyklus: eine System-Use-Case-Spezifikation schreiben, KI den Code generieren lassen, dann mit Tests verifizieren.

Die vier Phasen treffen auf die sechs Prinzipien

AIUP folgt vier agilen Phasen, Inception, Elaboration, Construction, Transition, inspiriert vom Rational Unified Process. Die sechs Prinzipien von Use-Case 2.0 lassen sich natürlich auf diese Phasen abbilden:

  • Inception ist, wo man „das grosse Bild versteht“ (Prinzip 2). Man erstellt einen Business-Anforderungskatalog und erste Use-Case-Diagramme. In Use-Case 2.0 Begriffen ist das die Aktivität „Find Actors and Use Cases“.
  • Elaboration ist, wo man „auf Wert fokussiert“ (Prinzip 3). Man schreibt System-Use-Case-Spezifikationen mit Basic und Alternative Flows, erstellt Entity-Modelle und validiert mit Stakeholdern.
  • Construction ist, wo man „das System in Slices baut“ (Prinzip 4), aber mit einem Unterschied. In AIUP ist die Arbeitseinheit der ganze Use Case, nicht ein Slice. KI generiert die komplette Implementierung für eine Use-Case-Spezifikation, inklusive aller Flows. Tests schützen das Verhalten. Jede Iteration verbessert Spezifikationen, Code und Tests zusammen.
  • Transition ist, wo man „das System in Inkrementen liefert“ (Prinzip 5). Benutzerabnahmetests bestätigen, dass die Use Cases die Bedürfnisse der Stakeholder erfüllen.

Warum Slices mit KI optional werden

Use-Case 2.0 hat Slices eingeführt, weil menschliche Entwickler kleine, handhabbare Arbeitspakete brauchen. Den Code für einen kompletten Use Case mit allen Flows zu schreiben, kann Tage oder Wochen dauern. Slicing macht die Arbeit vorhersagbar.

Mit KI-Codegenerierung fällt diese Einschränkung weg. KI kann die Implementierung für eine gesamte Use-Case-Spezifikation auf einmal generieren, Basic Flow, Alternative Flows, Fehlerbehandlung und alles andere. Der Use Case selbst wird zur Arbeitseinheit. Man schreibt die Spezifikation, KI generiert den Code, und Tests prüfen, ob das Verhalten stimmt. Kein Slicing nötig.

Das vereinfacht den Prozess. Statt eines Backlogs von Slices verwaltet man eine Liste von Use Cases. Jeder Use Case durchläuft den AIUP-Zyklus: spezifizieren, generieren, testen, verbessern.

Testgeschützte KI-Generierung

Use-Case 2.0 sagt, dass Testfälle wichtiger sind als die Narrative. AIUP geht noch weiter. Tests sind das Sicherheitsnetz, das KI-Codegenerierung zuverlässig macht. Wenn man Code aus einer verbesserten Spezifikation neu generiert, stellen Tests sicher, dass bestehendes Verhalten nicht bricht. Das nennt AIUP „testgeschützte Entwicklung“.

Die Testfälle jedes Use Case werden zur Regressionssuite, die das System während der KI-Neugenerierung schützt. Man kann eine Spezifikation sicher verbessern, den Code neu generieren und darauf vertrauen, dass die Tests Regressionen erkennen.

Tooling: Von der Theorie zur Praxis

Use-Case 2.0 ist werkzeugunabhängig. Man kann Post-it-Zettel oder Tabellen verwenden. AIUP fügt konkretes Tooling hinzu: Claude-Code-Plugins, die den Workflow automatisieren. Das aiup-core Plugin bietet Slash-Commands zum Erstellen von Anforderungskatalogen, Entity-Modellen, Use-Case-Diagrammen und Spezifikationen. Das aiup-vaadin-jooq Plugin fügt technologiespezifische Skills für Datenbankmigrationen, UI-Implementierung mit Vaadin und automatisiertes Testen mit Karibu und Playwright hinzu.

Das bedeutet, dass die Use-Case-Spezifikationen das System nicht nur dokumentieren, sie treiben aktiv seine Generierung. Die Spezifikation ist die Source of Truth, und der Code ist ein abgeleitetes Artefakt.

Wie man anfängt

Man muss nicht die gesamte Use-Case 2.0 Praxis oder AIUP auf einmal übernehmen. Man beginnt mit drei Dingen:

  1. Ein Use-Case-Diagramm zeichnen. Die Akteure und Use Cases des Systems identifizieren. Das dauert 30 Minuten und gibt das grosse Bild.
  2. Eine Use-Case Narrative schreiben. Den wichtigsten Use Case auswählen. Den Basic Flow als Aufzählung schreiben. Die Alternative Flows nur als Namen auflisten, noch nicht im Detail beschreiben.
  3. Den ersten Use Case implementieren. Wenn man den KI-gestützten Weg ausprobieren will, verwendet man das AIUP-Tooling, um die komplette Implementierung aus der Spezifikation zu generieren. Wenn man manuelle Entwicklung bevorzugt, kann man den Use Case wie von Use-Case 2.0 vorgeschlagen in kleinere Arbeitspakete aufteilen.

Man kann Use Cases in einer einfachen Tabelle oder auf Post-it-Zetteln verfolgen. Kein spezielles Tooling ist nötig, um mit Use-Case 2.0 zu starten. Wenn man bereit ist für KI-Generierung, bietet AIUP die Werkzeuge und den Prozess.

Das Fazit

Use-Case 2.0 ist kein Ersatz für User Stories. Es ist eine Ergänzung. Use Cases geben das grosse Bild und die Struktur. Testfälle geben eine klare Definition von „fertig“. Für die manuelle Entwicklung liefern Slices passend grosse Arbeitspakete.

AIUP baut auf dieser Grundlage auf und fügt die KI-Dimension hinzu. Es nimmt den Use Case , nicht den Slice. als Arbeitseinheit. Spezifikationen werden zum Input für die Codegenerierung. Tests werden zum Sicherheitsnetz für die Neugenerierung. Der Zyklus wird: spezifizieren, generieren, testen, verbessern.

In einer Welt, in der KI-Werkzeuge Code aus Spezifikationen generieren können, sind gut strukturierte Spezifikationen wichtiger denn je. Use-Case 2.0 liefert die bewährte Struktur. AIUP liefert das moderne Tooling. Zusammen zeigen sie, dass die besten Ideen aus der Vergangenheit des Software Engineering relevanter sind denn je.

Das Use-Case 2.0 E-Book von Ivar Jacobson, Ian Spence und Kurt Bittner ist kostenlos erhältlich auf ivarjacobson.com. Mehr über den AI Unified Process auf unifiedprocess.ai.