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).
Teil 1·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).
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.
Anmelden, um den Fortschritt zu speichern.
Nächster Schritt
Aktives Abrufen festigt Wissen schneller als nochmal lesen.
Diese Lerneinheit wurde für typische Bachelor-Klausuren konzipiert. So prüfen wir · Fehler entdeckt? Melde ihn uns oder markiere die fragliche Stelle direkt im Text oben.
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).
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).
Use Case + User Story: Beschreiben WAS ein Nutzer mit einem System erreichen will, in Form einer typischen Interaktion.
Format:
"Als
<Rolle>möchte ich<Funktion>, damit<Nutzen>."
Beispiele:
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.
| 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 |
Use Case = detaillierte Beschreibung eines Anwendungsfalls mit allen Schritten, Alternativen und Fehlerfällen.
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
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" |
| 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.
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."
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.
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.
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.
6 Aufgaben zu Formaten, Beziehungen und typischen Fehlern.
Klausurfragen mit Lösungen (6)
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.
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').
Zuordnungen:
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
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.
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
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.
6 typische Klausurfragen zu Format, Diagrammen und Beziehungen.
Klausurfragen mit Lösungen (6)
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).
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.
Lösungen pro Lücke:
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
Richtige Reihenfolge:
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
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.
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