Jenseits der Debatte User Stories gegen Use Cases

Eine kurze Geschichte der Anforderungsbeschreibung

Software-Anforderungen waren schon immer ein Übersetzungsproblem. Stakeholder wissen, was sie in geschäftlichen Begriffen brauchen. Entwickler benötigen dieses Wissen in einer Form, mit der sie arbeiten können. Die Methoden für diese Übersetzung haben sich etwa einmal pro Jahrzehnt verändert, und jeder Übergang hat dasselbe Argument hervorgebracht: Der neue Ansatz macht den alten obsolet.

Use Cases tauchten in den 1990er Jahren auf, populär gemacht durch Ivar Jacobson und formalisiert von Alistair Cockburn. Sie ersetzten abstrakte „Das System soll“-Aussagen durch konkrete Szenarien: Ein Akteur führt eine Aktion aus, das System antwortet, und die Interaktion setzt sich fort, bis das Ziel erreicht oder aufgegeben wird. Use Cases machten Anforderungen lesbar und überprüfbar.

Dann kam Agile. User Stories entstanden aus dem Extreme Programming Anfang der 2000er Jahre und verbreiteten sich über Scrum in die gängige Praxis. Das Format war bewusst minimal: eine Rolle, ein Wunsch und ein Grund, auf eine Karteikarte geschrieben. Kent Beck und Ron Jeffries entwarfen Stories als Gesprächsstarter, nicht als fertige Spezifikationen.

Die Fehlinterpretation, die alles veränderte

Das Agile Manifest sagt „funktionierende Software über umfassende Dokumentation.“ Das Wort „umfassend“ trägt die Hauptlast dieses Satzes. Es zielt auf das 500-seitige Lastenheft, das sechs Monate zum Schreiben braucht und veraltet ist, bevor die erste Zeile Code geschrieben wird. Es zielt nicht auf einen zweiseitigen Use Case, der beschreibt, wie ein Kunde ein defektes Produkt zurückgibt.

Viele Praktiker lasen das Manifest als „keine Dokumentation“ und übernahmen User Stories als einziges Anforderungsartefakt. Für einfache Projekte mit engagierten Product Ownern und kleinen Teams funktionierte das. Für alles andere entstand eine Dokumentationslücke, die Teams mit Stammeswissen, Slack-Nachrichten und Annahmen füllten.

Was ohne Details verloren geht

User Stories sind hervorragend darin, Absichten zu erfassen. Sie beantworten die strategische Frage: Was braucht diese Person und warum ist es wichtig? Sie sind weniger effektiv bei der Erfassung von Verhalten: Was genau passiert, wenn Sie auf diesen Button klicken, und was passiert, wenn etwas schiefgeht?

Nehmen Sie einen E-Commerce-Checkout-Ablauf. Die Story ist klar: „Als Kunde möchte ich meinen Einkauf abschliessen, damit ich meine Bestellung erhalte.“ Hinter dieser Story verbirgt sich ein Labyrinth von Entscheidungen. Zahlungsvalidierung, Bestandsprüfung, Adressverifizierung, Steuerberechnung, Versandoptionen, Gutscheineinlösung und Fehlerbehandlung für jeden dieser Schritte. Eine einzelne Story kann diese Komplexität nicht fassen. Eine Reihe von Stories kann sie zerlegen, aber Zerlegung ohne eine verbindende Erzählung lässt Entwickler ein Puzzle zusammensetzen, ohne das Bild auf der Schachtel zu haben.

Use Cases liefern dieses Bild. Sie beschreiben den vollständigen Ablauf, einschliesslich der Ausnahmepfade, die Stories selten ansprechen, bis ein Tester sie im Sprint Review entdeckt.

Die eigentliche Frage

Die Debatte zwischen User Stories und Use Cases stellt das Problem falsch dar. Sie fragt „welches Artefakt sollten wir verwenden?“ wenn die produktive Frage lautet „welchen Detaillierungsgrad braucht diese Anforderung?“

Manche Anforderungen brauchen nur einen Satz. Eine kleine UI-Aenderung, eine Konfigurationsoption, eine einfache Datenanzeige. Eine User Story erledigt das effizient. Andere Anforderungen beschreiben komplexe Interaktionen mit mehreren Akteuren, Verzweigungslogik und Fehlerszenarien. Diese brauchen das strukturierte Detail, das Use Cases bieten.

Der BABOK Guide der IIBA vertritt diese pragmatische Sicht. Er führt sowohl User Stories als auch Use Cases als Elizitation- und Analysetechniken auf, ohne eine der anderen überlegen zu erklären. Ebenso behandelt das CPRE-Referenzwerk des IREB Use Cases als primäre Technik zur Spezifikation funktionaler Anforderungen und erkennt an, dass agile Praktiken das strukturierte Requirements Engineering ergänzen statt ersetzen. Beide Standards anerkennen, dass Anforderungen in verschiedenen Grössen und Formen existieren.

Wie moderne Teams beides kombinieren

Effektive agile Teams haben die Entweder-oder-Debatte hinter sich gelassen. Sie verwenden Stories im Product Backlog für Priorisierung und Sprint-Planung. Wenn eine Story während des Refinements verborgene Komplexität offenbart, dokumentieren sie die detaillierte Interaktion in einem Use Case oder einem ähnlichen strukturierten Format.

Ein typisches Szenario: Während des Backlog-Refinements diskutiert das Team eine Story zur Passwortzurücksetzung. Der Product Owner erwähnt, dass Unternehmenskunden Multi-Faktor-Authentifizierung, temporäre Sperrungen nach fehlgeschlagenen Versuchen und administrative Entsperrungsmöglichkeiten benötigen. Die BA erkennt, dass diese Story über das hinausgewachsen ist, was eine einzelne Karte vermitteln kann. Sie entwirft einen Use Case, der den Hauptablauf, drei alternative Pfade und zwei Ausnahmeszenarien erfasst. Die Story bleibt im Backlog als Planungseinheit. Der Use Case wird zur Spezifikation, mit der Entwickler und Tester arbeiten.

Dieser hybride Ansatz bewahrt die agile Betonung von Geschwindigkeit und Anpassungsfähigkeit und liefert gleichzeitig die Präzision, die komplexe Software verlangt. Der Business Analyst wird zur Brücke, die zwischen den Prioritäten des Product Owners und dem Klaerunsgbedarf des Entwicklungsteams übersetzt.

Anforderungen als Spektrum

Die Entwicklung der Anforderungspraktiken folgt einem Muster. Jede neue Methode adressiert die Exzesse ihrer Vorgängerin. Lastenhefte waren zu schwer, also machten Use Cases Anforderungen szenariobasiert. Use Cases konnten bürokratisch werden, also reduzierten User Stories Anforderungen auf ihr Wesentliches. Heute fehlt den reduzierten Stories manchmal das Detail, das Teams brauchen.

Die Antwort ist nicht, eine Seite zu wählen. Sie besteht darin zu erkennen, dass Anforderungsdokumentation auf einem Spektrum von leichtgewichtig bis detailliert existiert. Das angemessene Niveau hängt vom Projekt, dem Team, der Domäne und der spezifischen Anforderung ab. Ein kompetenter Business Analyst liest den Kontext und wählt entsprechend.

Agile hat Use Cases nicht getötet. Es hat die Annahme getötet, dass ein einziges Dokumentationsformat für alle Situationen passt. Das ist eine nützlichere Lektion, als jeder Methodenkrieg bieten könnte.

Weiterführend