Use Case 2.0: Requirements Engineering und agile Methoden vereint

Die Anforderungslücke in agilen Projekten

Agile Methoden haben die Softwareentwicklung grundlegend verändert. Kürzere Zyklen, engere Zusammenarbeit mit den Anwendern, funktionierende Software als wichtigstes Fortschrittsmass. Diese Prinzipien haben die Branche umgestaltet. Doch der Wechsel zu agilem Vorgehen liess eine praktische Frage offen: Was geschieht mit dem Requirements Engineering?

User Stories haben die Lücke für kleine Teams gefüllt. Sie sind leichtgewichtig, dialogorientiert und passen auf Karteikarten. Ron Jeffries hat dies 2001 mit seiner 3C-Formel formalisiert: Card (eine knappe Absichtserklärung), Conversation (fortlaufender Dialog mit Stakeholdern) und Confirmation (Akzeptanzkriterien). Das Format funktioniert für Teams, die Sprint für Sprint Funktionalität aufbauen.

Das Problem zeigt sich, wenn Projekte wachsen. Product Owner, die Hunderte von Stories verwalten, verlieren den Überblick. Welche Stories gehören zusammen? Welches Gesamtverhalten soll das System bieten? Das Backlog wird zu einer flachen Liste zusammenhangloser Einträge statt einer kohärenten Beschreibung der Systemfunktionalität. Teams berichten regelmässig die gleiche Frustration: User Stories allein vermitteln nicht das Gesamtbild.

Warum Jacobson die Use Cases überarbeitet hat

Ivar Jacobson führte Use Cases 1987 als Interaktionsfolgen zwischen einem Benutzer und einem System zur Erreichung eines bestimmten Ziels ein. Fast vier Jahrzehnte später ist das Konzept nach wie vor weit verbreitet. Eine Umfrage von 2013 ergab, dass 73% der deutschen Unternehmen und 51% der Schweizer Organisationen Use Cases weiterhin für die Anforderungsspezifikation einsetzen. Der Grund ist naheliegend: Use Cases beschreiben, was ein System aus der Perspektive seiner Benutzer tut.

Ein einzelner Use Case erfasst alle Möglichkeiten, wie eine Interaktion ablaufen kann, vom Haupterfolgsszenario über alternative Pfade bis zur Fehlerbehandlung. Das gibt Stakeholdern und Entwicklern ein vollständiges Bild einer Geschäftsfähigkeit. Doch Jacobson erkannte, dass traditionelle Use Cases eine wesentliche Einschränkung hatten. Sie waren monolithisch. Ein einzelner Use Case zur Beschreibung eines Bestellvorgangs konnte Dutzende Seiten umfassen. Kein agiles Team konnte das in einem zweiwöchigen Sprint umsetzen.

Use Case 2.0 war Jacobsons Antwort. Als frei verfügbares White Paper veröffentlicht, verpackt es die analytische Stärke von Use Cases in ein agil-kompatibles Format. Die zentrale Innovation ist der Use Case Slice.

Was ist ein Use Case Slice?

Ein Use Case Slice ist ein dünner, vertikaler Schnitt durch die Erzählung eines Use Cases. Er wählt bestimmte Szenarien aus dem vollständigen Use Case aus und bündelt sie als lieferbares Arbeitselement. Jeder Slice ist unabhängig implementierbar und innerhalb eines einzelnen Sprints testbar.

Nehmen Sie einen Use Case „Bestellung aufgeben“. Der Basisfluss, bei dem ein Kunde Artikel auswählt, Zahlungsdaten eingibt und eine Bestätigung erhält, wird zum ersten Slice. Der alternative Fluss für die Anwendung eines Rabattcodes wird zum zweiten. Die Behandlung von Zahlungsfehlern wird zum dritten. Jeder Slice liefert eine sinnvolle Funktionalität, während der übergeordnete Use Case das Gesamtbild des Bestellvorgangs bewahrt.

Damit entfällt der umständliche Übersetzungsschritt, mit dem viele Teams kämpfen: die Umwandlung von Use Cases in User Stories. Slices sind keine eigenständigen Artefakte, die von ihrem Ursprung losgelöst sind. Sie behalten eine explizite Verbindung zum übergeordneten Use Case. Wenn ein Team einen Slice abschliesst, wird die Use-Case-Erzählung aktualisiert, um das Gebaute widerzuspiegeln. Der Use Case wird zu einem lebenden Dokument, das den Fortschritt über einzelne Sprints hinaus verfolgt.

Sechs Praktiken zur Strukturierung der Arbeit

Use Case 2.0 organisiert die Arbeit um sechs Praktiken, aufgeteilt zwischen Produkt- und Sprint-Ebene:

• Akteure und Use Cases identifizieren, um die Systemgrenzen festzulegen und zu bestimmen, wer mit dem System interagiert
• Use Cases in Slices schneiden, indem Sie spezifische Flüsse oder Szenarien als sprintgerechte Arbeitspakete auswählen
• Einen Slice vorbereiten, indem Sie die ausgewählten Flüsse gerade genug für die Implementierung detaillieren
• Einen Slice analysieren, um seine Auswirkungen auf die Systemarchitektur und bestehende Komponenten zu verstehen
• Den Slice implementieren als funktionierende Software innerhalb des Sprints
• Den Slice testen anhand der aus der Use-Case-Erzählung abgeleiteten Akzeptanzkriterien

Die ersten beiden Praktiken wirken auf Produktebene. Sie geben die strategische Richtung vor, indem sie den Systemumfang kartieren und in lieferbare Inkremente zerlegen. Die übrigen vier wirken auf Sprint-Ebene und spiegeln wider, wie Scrum die Backlog-Verfeinerung von der Sprint-Durchführung trennt.

Was das für Business-Analysten bedeutet

Für Business-Analysten löst Use Case 2.0 ein hartnäckiges Dilemma. In traditionellen Projekten erstellte man detaillierte Spezifikationen, die Entwickler manchmal ignorierten. In agilen Projekten moderierte man Gespräche, hatte aber kein strukturiertes Mittel, um Vollständigkeit sicherzustellen. Use Case 2.0 bietet einen pragmatischen Mittelweg.

Das Use-Case-Modell liefert den analytischen Rahmen, den Business-Analysten zu bauen gelernt haben. Es verknüpft Akteure mit Zielen, Ziele mit Interaktionsflüssen, Flüsse mit Geschäftsregeln. Dieser systematische Ansatz hilft, Lücken zu erkennen, die story-basierte Methoden übersehen. Wenn sich ein Team ausschliesslich auf User Stories verlässt, übersieht man leicht alternative Pfade für Ausnahmen, Grenzfälle und Fehlerbedingungen. Use Cases erzwingen durch ihre Struktur die Frage: Was könnte hier noch passieren?

Gleichzeitig stellt das Slicing sicher, dass die Analyse der Implementierung nur knapp voraus ist. Man verbringt keine Monate mit dem Verfassen von Spezifikationen für Funktionen, die möglicherweise nie gebaut werden. Man arbeitet jeden Slice kurz vor seinem Eintritt in den Sprint aus und hält so die Feedback-Schleife kurz und die Dokumentation relevant.

Wo Use Case 2.0 am besten passt

Nicht jedes Projekt braucht diesen Ansatz. Kleine Teams, die einfache Anwendungen bauen, werden User Stories möglicherweise als völlig ausreichend empfinden. Use Case 2.0 zeigt seinen Wert in spezifischen Kontexten: Systeme mit komplexer Geschäftslogik, regulierte Umgebungen mit Anforderungen an die Rückverfolgbarkeit, Grossprojekte, in denen mehrere Teams ihre Arbeit koordinieren müssen, und Organisationen im Übergang von traditionellen zu agilen Methoden.

Für Teams, die bereits mit Use Cases vertraut sind, ist der Übergang natürlich. Die Methodik verlangt nicht, die bestehende Praxis aufzugeben. Sie verlangt, anders zu schneiden.