Wie ordnet der IREB-Lehrplan Use Cases und User Stories ein?
Im IREB-Lehrplan gehören beide Formen zu den schablonenbasierten Arbeitsprodukten. User Stories werden mit einer Satzschablone formuliert, die auf Mike Cohn zurückgeht; Use Cases mit Formularschablonen, wie sie Alistair Cockburn beschrieben hat [1]. Der Lehrplan ordnet User Stories den Arbeitsprodukten für einzelne Anforderungen zu, Use Cases dagegen den Arbeitsprodukten für eine zusammenhängende Menge von Anforderungen. Dieser Unterschied erklärt bereits einen grossen Teil der praktischen Unterschiede.
Use Cases modellieren laut Lehrplan die dynamische Interaktion zwischen einem Akteur im Systemkontext und dem System aus Sicht des Akteurs. Sie werden meist mit Formularschablonen in natürlicher Sprache oder mit UML-Aktivitätsdiagrammen beschrieben; in UML zeigen Use-Case-Diagramme zudem das System, seine Use Cases und die beteiligten Akteure im Überblick. User Stories sind dagegen kurze Beschreibungen eines Wunsches, die erst im Gespräch zwischen Fachleuten und Team konkretisiert werden.
Was sind die Unterschiede im Überblick?
| Merkmal | User Story | Use Case |
|---|---|---|
| Umfang | ein Satz plus Akzeptanzkriterien | strukturiertes Formular, oft eine bis mehrere Seiten |
| Perspektive | Rolle, Ziel, Nutzen | Akteur und System in Interaktion |
| Inhalt | einzelner Wunsch | zusammenhängender Ablauf mit Varianten |
| Alternativen und Fehlerfälle | über Akzeptanzkriterien oder weitere Stories | ausdrücklich als Alternativszenarien |
| Detailtiefe | bewusst gering, Details im Gespräch | hoch, Details schriftlich |
| Typischer Prozess | partizipativ, iterativ, agil | vertragsbasiert oder komplexe Abläufe |
| Schätzbarkeit | gut, wenn klein geschnitten | meist zu gross, wird in Teile zerlegt |
| Überblick über das System | gering, braucht Story Map | gut, besonders mit Use-Case-Diagramm |
Beispiel: dieselbe Anforderung in beiden Formen
Als User Story: «Als Projektleiterin möchte ich eine Monatsauswertung meines Projekts als PDF exportieren, damit ich sie dem Kunden als Leistungsnachweis senden kann.» Akzeptanzkriterien: Die Auswertung enthält Stunden pro Person und Tätigkeit; leere Monate erzeugen einen Hinweis statt einer leeren Datei; Mitarbeitende ohne Leitungsrolle können die Funktion nicht aufrufen.
| Feld | Inhalt |
|---|---|
| Name | Leistungsnachweis exportieren |
| Primärer Akteur | Projektleiterin |
| Ziel | Leistungsnachweis für einen Monat als PDF an den Kunden senden |
| Vorbedingung | angemeldet, Leitungsrolle im Projekt, Monat abgeschlossen |
| Hauptszenario | 1. Projekt wählen 2. Monat wählen 3. Export anfordern 4. System erstellt PDF mit Stunden pro Person und Tätigkeit 5. Projektleiterin lädt PDF herunter |
| Alternativszenario 2a | Monat nicht abgeschlossen: System bietet Abschluss an oder bricht ab |
| Alternativszenario 4a | keine Einträge: System zeigt Hinweis, kein PDF |
| Nachbedingung | PDF ist erstellt und im Projekt abgelegt |
Der Vergleich zeigt den Unterschied deutlich: Die User Story stellt den Nutzen in den Vordergrund und lässt den Ablauf offen. Der Use Case beschreibt den Ablauf vollständig, einschliesslich der Vorbedingung, dass der Monat abgeschlossen sein muss, und der Frage, was in diesem Fall geschieht. In der Story wäre dieser Fall erst im Gespräch oder als weiteres Akzeptanzkriterium aufgetaucht.
Wann passt welche Form?
| Situation | Empfehlung |
|---|---|
| Agiles Team, Fachbereich regelmässig verfügbar | User Stories mit Akzeptanzkriterien |
| Umsetzung durch externen Lieferanten mit Festpreis | Use Cases mit vollständigen Szenarien |
| Komplexe Abläufe mit vielen Varianten und Fehlerfällen | Use Cases, daraus Stories für die Umsetzung ableiten |
| Viele kleine, unabhängige Wünsche | User Stories |
| Regulierte Umgebung mit Nachweispflichten | Use Cases oder Satzschablonen mit Traceability |
| Überblick über ein neues System gewinnen | Use-Case-Diagramm, danach Stories oder Use Cases |
Der IREB-Lehrplan verknüpft die Wahl der Arbeitsprodukte mit der Konfiguration des Prozesses: Im partizipativen Prozess sind Product Backlogs mit User Stories typisch, im vertragsbasierten Prozess klassische Systemanforderungsspezifikationen aus natürlichsprachlichen Anforderungen und Modellen [1]. Die Wahl der Form ist damit eine Folge der Situation, nicht eine Frage der Vorliebe.
Wie lassen sich Use Cases und User Stories kombinieren?
In vielen Vorhaben ist die Kombination am wirksamsten. Use Cases oder ein Use-Case-Diagramm geben den Überblick über die wichtigsten Abläufe; aus jedem Use Case werden User Stories für die schrittweise Umsetzung abgeleitet, etwa eine Story für das Hauptszenario und weitere für die Alternativszenarien. So bleibt der Zusammenhang erhalten, und das Team kann trotzdem in kleinen Schritten liefern. Die Story Map, die Stories entlang der Abläufe der Nutzenden ordnet, erfüllt eine ähnliche Funktion für rein agile Teams.
Der Scrum Guide schreibt bewusst kein Format für Einträge im Product Backlog vor; Beschreibung, Reihenfolge und Grösse sind Attribute, die je nach Arbeitsbereich variieren [2]. Teams sind deshalb frei, Use Cases, User Stories oder andere Formen zu nutzen. Entscheidend ist, dass Einträge verständlich, schätzbar und prüfbar sind. Wie User Stories im Detail geschrieben werden, beschreibt der Beitrag User Stories schreiben im Hub Agil.
Use Cases und User Stories in Normen
Die Norm ISO/IEC/IEEE 29148 schreibt keine bestimmte Form vor, sondern legt fest, welche Informationen Anforderungsdokumente enthalten müssen, und stellt Satz- und Dokumentschablonen bereit [3]. Use Cases und User Stories können in normkonformen Spezifikationen verwendet werden, solange die geforderten Informationen enthalten sind und die Anforderungen verfolgbar bleiben. In vertraglichen Kontexten werden User Stories häufig um ausführlichere Akzeptanzkriterien ergänzt, damit sie als Abnahmegrundlage taugen.
Typische Fehler
- User Stories als Mini-Spezifikationen mit allen Details schreiben und das Gespräch auslassen.
- Use Cases so allgemein formulieren, dass sie keine prüfbaren Aussagen enthalten.
- Alternativ- und Fehlerszenarien vergessen, weil nur der Normalfall beschrieben wird.
- Technische Abläufe als Use Cases beschreiben, statt die Sicht des Akteurs einzunehmen.
- Zwischen den Formen wechseln, ohne die Verbindung zwischen Use Case und abgeleiteten Stories festzuhalten.
Beide Formen im Werkzeug führen
Im Projekttool lassen sich Use Cases als übergeordnete Einträge und User Stories als untergeordnete Aufgaben abbilden, sodass der Zusammenhang sichtbar bleibt. In Flenio können Aufgaben mit Unteraufgaben, Checklisten für Akzeptanzkriterien und Verknüpfungen zu Dokumenten geführt werden. Wie Anforderungen über ihren Lebenszyklus verfolgt werden, beschreibt der Beitrag Requirements Management. Den Gesamtzusammenhang zeigt der Leitfaden Requirements Engineering.
Was zeigt ein Use-Case-Diagramm?
Ein Use-Case-Diagramm in UML zeigt das System als Rahmen, die Use Cases als Ellipsen innerhalb des Rahmens und die Akteure als Figuren ausserhalb, verbunden durch Linien, die zeigen, wer an welchem Use Case beteiligt ist. Es beschreibt keine Abläufe, sondern gibt einen Überblick: Welche Ziele können welche Akteure mit dem System erreichen? Damit eignet es sich gut als erster Schritt in einem neuen Vorhaben und als Einstieg für Stakeholder, die nicht in Details einsteigen möchten. Der IREB-Lehrplan nennt Use-Case-Diagramme ausdrücklich als Möglichkeit, ein System und seinen Kontext zu modellieren.
Für eine Zeiterfassungslösung zeigt ein Use-Case-Diagramm etwa die Akteure Mitarbeitende, Projektleitende und Buchhaltungssystem sowie Use Cases wie «Zeit erfassen», «Monat abschliessen», «Leistungsnachweis exportieren» und «Daten übertragen». Jeder dieser Use Cases kann anschliessend ausführlich beschrieben oder in User Stories zerlegt werden. Der Zusammenhang mit dem Systemkontext ist eng: Die Akteure des Use-Case-Diagramms entsprechen weitgehend den Akteuren im Kontextdiagramm, siehe Systemkontext und Abgrenzung.
Woran erkennt man gute Use Cases und gute User Stories?
Für beide Formen gelten die Qualitätskriterien des IREB-Lehrplans für einzelne Anforderungen: adäquat, notwendig, eindeutig, vollständig, verständlich und prüfbar. Gute Use Cases haben ein klares Ziel aus Sicht des Akteurs, ein Hauptszenario mit fünf bis zehn Schritten, ausdrückliche Alternativ- und Fehlerszenarien und eine prüfbare Nachbedingung. Gute User Stories sind klein genug für einen Sprint, nennen eine konkrete Rolle, beschreiben den Nutzen und haben zwei bis fünf prüfbare Akzeptanzkriterien. Wie einzelne Anforderungen sprachlich präzise formuliert werden, zeigt der Beitrag Anforderungen formulieren.
Ein nützlicher Test für beide Formen: Kann eine Person, die nicht an der Erhebung beteiligt war, daraus Testfälle ableiten? Bei Use Cases gelingt das meist direkt aus den Szenarien; bei User Stories aus den Akzeptanzkriterien. Fehlen diese, ist die Anforderung noch nicht fertig.
Wie gelingt der Übergang von Use Cases zu User Stories?
Viele Organisationen haben bestehende Spezifikationen mit Use Cases und wechseln zu agilen Teams, die mit User Stories arbeiten. Der Übergang gelingt, wenn die Use Cases nicht verworfen, sondern als Landkarte genutzt werden. Jeder Use Case wird in eine Story für das Hauptszenario und weitere Stories für die wichtigsten Alternativszenarien zerlegt. Die Vorbedingungen werden zu Akzeptanzkriterien oder zu eigenen Stories, die Nachbedingungen zu prüfbaren Ergebnissen. Die Verbindung zwischen Use Case und Stories wird im Werkzeug festgehalten, sodass später nachvollziehbar bleibt, welche Stories welchen Ablauf umsetzen.
Umgekehrt kann es sinnvoll sein, für agile Vorhaben nachträglich Use Cases zu erstellen, etwa wenn ein Produkt an einen externen Betreiber übergeben oder für eine Zertifizierung dokumentiert werden muss. Dann fassen die Use Cases das umgesetzte Verhalten zusammen, das in vielen einzelnen Stories verteilt ist.