Alle Tabs der Lerneinheit (Erklärung · Interaktiv verstehen · Praxis-Übung · Klausur-Quiz) als durchgehender Text. Ideal zum Wiederholen vor der Klausur, und für Suchmaschinen wie Google, Bing und KI-Suche (ChatGPT, Perplexity).
Erklärung
Beides sind Werkzeuge, um funktionale Anforderungen zu beschreiben, aus Nutzer-Perspektive. User Stories sind kurz und agil (Scrum-Welt). Use Cases sind detailliert und formal (UML-Welt).
Die Idee in einem Satz
Use Case + User Story: Beschreiben WAS ein Nutzer mit einem System erreichen will, in Form einer typischen Interaktion.
1. User Story (Scrum)
Format:
"Als
<Rolle>möchte ich<Funktion>, damit<Nutzen>."
Beispiele:
- Als Online-Shop-Kunde möchte ich Produkte in einen Warenkorb legen, damit ich mehrere auf einmal kaufen kann.
- Als Admin möchte ich Bestände in der Datenbank ändern, damit ich auf Lager-Anpassungen reagieren kann.
- Als neuer Nutzer möchte ich mein Passwort per E-Mail zurücksetzen, damit ich auch nach Vergessen wieder Zugriff habe.
Akzeptanzkriterien (Definition of Acceptance)
User Story alleine ist nicht testbar. Daher: Akzeptanzkriterien ergänzen.
Format (Gherkin/BDD):
Given <Vorbedingung>
When <Aktion>
Then <Ergebnis>
Beispiel:
User Story: "Als Kunde möchte ich Produkte in den Warenkorb legen."
Akzeptanzkriterien:
- Gegeben ich bin eingeloggt und auf einer Produktseite,
- wenn ich auf "In den Warenkorb" klicke,
- dann wird der Artikel im Warenkorb hinzugefügt und die Warenkorb-Anzahl erhöht sich um 1.
INVEST-Kriterien für gute User Stories
| Buchstabe | Bedeutung |
|---|---|
| Independent | Unabhängig von anderen Stories |
| Negotiable | Verhandelbar, kein fester Vertrag |
| Valuable | Wert für den Nutzer |
| Estimable | Aufwand schätzbar |
| Small | Klein genug für 1 Sprint |
| Testable | Mit klaren Akzeptanzkriterien |
2. Use Case (UML)
Use Case = detaillierte Beschreibung eines Anwendungsfalls mit allen Schritten, Alternativen und Fehlerfällen.
Struktur eines Use Case (Standard-Vorlage)
Name: [eindeutiger Name, z.B. "Bestellung aufgeben"]
Akteur: [wer interagiert? z.B. "Kunde"]
Vorbedingungen: [was muss erfüllt sein? z.B. "Kunde ist eingeloggt"]
Nachbedingungen: [Endzustand? z.B. "Bestellung ist in DB gespeichert"]
Hauptszenario:
1. Kunde wählt Produkte aus
2. Kunde geht zum Warenkorb
3. System zeigt Übersicht
4. Kunde klickt "Bestellen"
5. System prüft Bestände
6. System speichert Bestellung in DB
7. System sendet Bestätigungs-E-Mail
Alternative Szenarien:
5a. Bestand nicht ausreichend:
5a.1 System zeigt Fehlermeldung
5a.2 Kunde passt Menge an
5a.3 zurück zu Schritt 5
Fehlerfälle:
6e. DB-Fehler:
6e.1 System zeigt Fehlermeldung
6e.2 Bestellung nicht gespeichert
Use Case-Diagramm (UML)
Grafische Übersicht ALLER Use Cases eines Systems, plus Akteure.
┌──────────────────────────────┐
│ Online-Shop System │
│ │
│ ○ Produkte browsen │
│ ○ In Warenkorb legen │
Kunde│ ○ Bestellung aufgeben │ Admin
───→│ ○ Profil bearbeiten │ ←───
│ ○ Bestände anpassen │
│ ○ Bestellungen einsehen │
└──────────────────────────────┘
Beziehungen zwischen Use Cases:
| Beziehung | Bedeutung | Beispiel |
|---|---|---|
<<include>> | Use Case ruft IMMER einen anderen | "Bestellung aufgeben" includes "Adresse prüfen" |
<<extend>> | Use Case erweitert OPTIONAL einen anderen | "Bestellung aufgeben" extends "Coupon einlösen" |
| Generalisierung | Spezialisierung | "Premium-Bestellung" generalisiert von "Bestellung" |
Vergleich: User Story vs. Use Case
| Aspekt | User Story | Use Case |
|---|---|---|
| Format | 1-Satz-Template + Akzeptanzkriterien | Detaillierte Schritte mit Alt./Fehler |
| Länge | 1-3 Sätze | 1-2 Seiten pro Use Case |
| Diagramm | meist keins | UML Use-Case-Diagramm |
| Entstehung | Konversations-Starter | Vollständiges Dokument |
| Welt | Scrum, Agile | UML, Wasserfall, V-Modell |
| Granularität | klein, sprint-fähig | groß, kann mehrere Stories enthalten |
| Detail-Tiefe | Minimum nötig | Maximum, inkl. Alternativen |
Faustregel: Ein Use Case = mehrere User Stories.
3. Personas
Persona: Fiktive Person, die einen Stakeholder repräsentiert. Hilft, sich konkret in Nutzer hineinzuversetzen.
Beispiel:
Persona: Lisa (32, Marketing-Managerin)
- Bestellt 2× / Woche online für ihr Team
- Wichtig: schneller Checkout, Sammel-Rechnung
- Frustriert von langsamen Seiten
- Nutzt iPhone, gern Apple Pay
Geräte: iPhone, MacBook. Erfahrungs-Level: hoch.
User Stories werden oft AUS Personas heraus geschrieben:
"Als Lisa möchte ich eine Sammel-Rechnung für meine Team-Bestellungen, damit ich weniger Buchhaltungs-Aufwand habe."
Klausur-Faustregeln
1. User-Story-Format ist Pflicht: "Als <Rolle> möchte ich <Funktion>, damit <Nutzen>."
2. INVEST-Kriterien: Independent, Negotiable, Valuable, Estimable, Small, Testable.
3. Akzeptanzkriterien in Gherkin: Given / When / Then.
4. Use Case = umfangreich, User Story = kurz. Use Case enthält Schritte + Alternativen + Fehler. User Story enthält nur Wunsch + Nutzen.
5. <<include>> = immer, <<extend>> = optional. Klausur-Klassiker zum Verwechseln.
6. Aktoren stehen außerhalb der System-Box im UML-Diagramm.
Häufige Stolpersteine
1. User Story ohne Nutzen. Falsch: "Als Kunde möchte ich einen Login." Richtig: "Als Kunde möchte ich einen Login, damit ich meine Bestellhistorie sehen kann." Der Nutzen ist Pflicht!
2. Akzeptanzkriterien vergessen. Eine User Story OHNE Akzeptanzkriterien ist nicht testbar. Always-On: für jede Story 2-5 Kriterien definieren.
3. <<include>> und <<extend>> verwechseln. Eselsbrücke: include = inkludiert immer (Pflicht-Teil), extend = erweitert manchmal (optionaler Teil).
4. Use Case als 'fertiges Spec' sehen. Use Cases entwickeln sich. Erst Hauptszenario, dann Alternativen, dann Fehlerfälle.
5. User Stories zu groß. "Als Kunde möchte ich einen vollständigen Shop." Das ist kein Story sondern ein Epic. Zerlegen in viele kleine Stories.
6. Personas erfinden, ohne Daten. Personas sollten auf realen Daten basieren (Interviews, Analytics). Sonst sind sie fiktive Wunsch-Nutzer und führen in die falsche Richtung.
Interaktiv verstehen
Use-Case-Diagramm interaktiv
Klicke auf Use Cases, Akteure und Beziehungen, um Details zu sehen. Das System-Beispiel ist ein Online-Shop mit 3 Akteuren (Kunde / Admin / Gast).
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
Klausur-Tipp: Wenn du in der Klausur ein Use-Case-Diagramm zeichnen sollst: 1) System-Grenze als Rechteck, 2) Akteure als Strichmännchen außerhalb, 3) Use Cases als Ovale innerhalb, 4) Linien zwischen Akteur und Use Case. <<include>> mit gestrichelter Linie + Pfeil; <<extend>> ebenfalls gestrichelt aber andere Richtung.
Praxis-Übung
Use Cases / User Stories, Praxis-Übung
6 Aufgaben zu Formaten, Beziehungen und typischen Fehlern.
Klausurfragen mit Lösungen (6)
- F1.Was ist das korrekte User-Story-Format?
Antwort: Als <Rolle> möchte ich <Funktion>, damit <Nutzen>
Erklärung: Standard-Template: 'Als <Rolle> möchte ich <Funktion>, damit <Nutzen>'. Der NUTZEN-Teil ist Pflicht, ohne ihn fehlt die Begründung, warum die Funktion gebaut werden soll. 'Als Kunde möchte ich einen Login' (ohne Nutzen) ist ein häufiger Anti-Pattern.
- F2.Was bedeutet die <<include>>-Beziehung zwischen zwei Use Cases?
Antwort: Der erste Use Case nutzt IMMER den zweiten
Erklärung: `<<include>>` heißt 'nutzt IMMER'. Beispiel: 'Bestellung aufgeben' includes 'Adresse prüfen', bei jeder Bestellung wird die Adresse geprüft. Im Gegensatz dazu `<<extend>>` = OPTIONAL (z.B. 'Bestellung aufgeben' extends 'Coupon einlösen').
- F3.Ordne die INVEST-Buchstaben ihrer Bedeutung zu.
Zuordnungen:
- I → Independent (unabhängig)
- V → Valuable (wertvoll)
- E → Estimable (schätzbar)
- T → Testable (testbar)
Erklärung: INVEST = Independent (unabhängig) / Negotiable (verhandelbar) / Valuable (Nutzen) / Estimable (Aufwand schätzbar) / Small (klein) / Testable (mit Akzeptanzkriterien). Diese 6 Kriterien helfen zu prüfen, ob eine User Story gut formuliert ist.
Typ: Zuordnung
- F4.Welche Sprache wird typischerweise für Akzeptanzkriterien verwendet?
Antwort: Gherkin (Given/When/Then)
Erklärung: Gherkin ist die Sprache hinter Behavior-Driven Development (BDD): Given <Vorbedingung> / When <Aktion> / Then <Ergebnis>. Wird von Frameworks wie Cucumber direkt als ausführbare Tests genutzt. Klausur-Klassiker, auswendig können.
- F5.Ein Use Case enthält im Standard-Format Vorbedingungen, Nachbedingungen, Hauptszenario, alternative Szenarien und Fehlerfälle.
Antwort: Wahr
Erklärung: RICHTIG. Das ist genau die Standard-Struktur eines Use Case (z.B. nach Cockburn 2001): Name, Akteur, Vorbedingungen, Nachbedingungen, Hauptszenario (Schritt 1-N), alternative Szenarien (z.B. 5a, 5b für Verzweigungen ab Schritt 5), Fehlerfälle (z.B. 6e für Errors ab Schritt 6). Macht Use Cases viel detaillierter als User Stories.
Typ: Wahr/Falsch
- F6.Welche dieser User Stories ist am BESTEN formuliert?
Antwort: Als Premium-Kunde möchte ich eine Express-Lieferung, damit ich meine Bestellung am nächsten Tag erhalte
Erklärung: Option 3 ist die einzige korrekte: spezifische Rolle (Premium-Kunde), konkrete Funktion (Express-Lieferung) UND klarer Nutzen (am nächsten Tag erhalten). Die anderen 3 verletzen INVEST: 'einen Shop' ist viel zu groß, 'einen Login' hat keinen Nutzen, 'eine bessere App' ist vage und nicht messbar.
Klausur-Quiz
Use Cases / User Stories, Klausur-Quiz
6 typische Klausurfragen zu Format, Diagrammen und Beziehungen.
Klausurfragen mit Lösungen (6)
- F1.Wer schreibt User Stories typischerweise?
Antwort: Der Product Owner (mit Input von Stakeholdern)
Erklärung: User Stories werden typischerweise vom Product Owner geschrieben, er ist verantwortlich für das Product Backlog. Aber er sammelt Input von Stakeholdern, dem Team und Personas. Wichtig: nicht der Scrum Master (kein Backlog-Verantwortlicher) und nicht das Team alleine (Team setzt um, definiert nicht WAS).
- F2.Wie wird ein Akteur in einem UML Use-Case-Diagramm dargestellt?
Antwort: Als Strichmännchen außerhalb der System-Grenze
Erklärung: Akteure werden als STRICHMÄNNCHEN außerhalb der System-Grenze (rechteckige Box) dargestellt. Use Cases sind die OVALE innerhalb der System-Grenze. Das ist UML-Standard und Pflicht in jeder Klausur.
- F3.Akzeptanzkriterien werden oft in {{1}}-Sprache geschrieben mit den Schlüsselwörtern {{2}} / When / Then. INVEST steht für Independent, Negotiable, Valuable, Estimable, {{3}}, Testable.
Lösungen pro Lücke:
- {{1}}: Gherkin
- {{2}}: Given / given
- {{3}}: Small
Erklärung: Gherkin ist die Sprache (vom Tool Cucumber bekannt), Schlüsselwörter sind Given/When/Then. Das 'S' in INVEST steht für Small, Story muss klein genug sein, um in einem Sprint umgesetzt zu werden. Zu große Stories (Epics) müssen zerlegt werden.
Typ: Lückentext
- F4.Ein Use Case 'Bestellung aufgeben' hat folgende Schritte. Bringe sie in die richtige Reihenfolge.
Richtige Reihenfolge:
- Kunde wählt Produkte aus
- Kunde klickt 'Bestellen'
- System prüft Bestände
- System speichert Bestellung in DB
- System sendet Bestätigungs-E-Mail
Erklärung: Standard-Reihenfolge: 1) Produkte wählen, 2) Bestellen klicken, 3) Bestände prüfen, 4) Bestellung speichern, 5) Bestätigungs-E-Mail. Wichtig: Bestände werden VOR dem Speichern geprüft (sonst Inkonsistenz). E-Mail kommt erst NACH Speichern (sonst sendet man Bestätigung für eine Bestellung, die fehlschlug).
Typ: Reihenfolge
- F5.Was ist der WICHTIGSTE Unterschied zwischen User Story und Use Case?
Antwort: Use Cases sind detaillierter, User Stories sind kompakt
Erklärung: Hauptunterschied: User Story = kompakt (1-3 Sätze + Akzeptanzkriterien, Konversations-Starter im Scrum). Use Case = detailliert (1-2 Seiten mit Vorbedingungen, Hauptszenario, Alternativen, Fehlerfällen). User Stories sind agil-orientiert, Use Cases UML-orientiert. Faustregel: 1 Use Case = mehrere User Stories.
- F6.Eine <<extend>>-Beziehung zwischen Use Case A → B bedeutet: A wird IMMER durch B erweitert.
Antwort: Falsch
Erklärung: FALSCH. `<<extend>>` heißt 'OPTIONAL erweitert'. Beispiel: 'Bestellung aufgeben' extends 'Coupon einlösen', Coupon wird NUR eingelöst, wenn der Kunde einen hat. Im Gegensatz dazu `<<include>>` = IMMER (Pflicht). Eselsbrücke: **inclu**de = **inklud**iert immer, e**xte**nd = e**xtra** manchmal.
Typ: Wahr/Falsch
