de_DEen_USes_ESfa_IRfr_FRhi_INid_IDjapl_PLpt_PTvizh_CNzh_TW

Use-Case 2.0: Die agile Evolution der Anforderungsspezifikation (Leitfaden 2026)

„Die Zukunft der Anforderungen ist keine zusätzliche Dokumentation – sondern intelligenter, leichter und besser auf die Lieferung ausgerichtet.“
— Ivar Jacobson, Ian Spence, Kurt Bittner

In der heutigen dynamischen Landschaft der Softwareentwicklung benötigen Teams eine Methode, die ausbalanciertKlarheit, Agilität, undSkalierbarkeit. Treten Sie einUse-Case 2.0 — die moderne, agile Weiterentwicklung klassischer Use-Cases, entwickelt, um in Scrum-, Kanban- und Lean-Umgebungen erfolgreich zu sein, während die Stärke strukturierter Anforderungen erhalten bleibt.

Entwickelt von PionierenIvar Jacobson, Ian Spence, undKurt Bittner (ca. 2011–2012),Use-Case 2.0 redefiniert Use-Cases als leichtgewichtige, zerlegbare, wertorientierte Einheiten, die den gesamten Lebenszyklus der Softwarebereitstellung unterstützen – von der Entdeckung bis zur Betriebssicherheit.

Dieser Artikel geht tief inUse-Case 2.0, und bietet einen umfassenden, praktischen Leitfaden für Teams, die ihre Anforderungspraxis modernisieren möchten, ohne an Strenge oder Rückverfolgbarkeit einzubüßen.

🔹 1. Was ist Use-Case 2.0?

Use-Case 2.0 ist ein agiler, skalierbarer Ansatz zur Erfassung und Bereitstellung von Systemfunktionen überUse-Cases — aber mit einem Twist. Es behält die Kernstärke klassischer Use-Cases (Klarheit der Ziele, akteurzentriertes Design, ganzheitliche Szenariomodellierung) bei, während es die Schwere, Bürokratie und vorab dokumentierte Anforderungen beseitigt, die agile Teams oft behindern.

✅ Hauptziele:

  • Leichtgewichtig: So minimal wie eine Benutzerstory auf einer Indexkarte.

  • Schrittweise: Zerlegt große Ziele in kleine, lieferbare Abschnitte.

  • Testgetrieben: Tests werden früh definiert – sogar noch vor dem Code.

  • Wertorientiert: Jeder Abschnitt liefert greifbaren Kundennutzen.

  • Lebenszyklusbereit: Unterstützt Anforderungen, Architektur, Design, Implementierung, Test und Betrieb.

🔄 Unterschiede zu traditionellen Anwendungsfällen:

Funktion Traditionelle Anwendungsfälle Anwendungsfall 2.0
Größe Schwer, umfassende Dokumentation (10+ Seiten) Leichtgewichtig, maximal 1–2 Seiten
Lieferung Großes vorab festgelegtes Design Schrittweise, sprintweise
Schwerpunkt Systemverhalten Benutzerziele und Nutzen
Testen Nach der Entwicklung abgeschlossen Vorab definiert (nach BDD-Stil)
Skalierbarkeit Schwer zu skalieren Skaliert „in“, „out“ und „up“

✅ Bestes aus beiden Welten: Use-Case 2.0 kombiniert die Struktur von Use-Cases mit der Agilität von User Stories — ideal für komplexe Systeme, bei denen reine User Stories den Kontext verlieren können.

🔹 2. Die sechs ersten Prinzipien von Use-Case 2.0

Diese grundlegenden Prinzipien leiten jeden Schritt des Prozesses. Sie sind nicht freiwillig — sie sind die DNA der Methode.

  1. Halten Sie Use-Cases einfach und verständlich
    Vermeiden Sie fachliche Fachbegriffe. Konzentrieren Sie sich darauf, was der Benutzer erreichen möchte, nicht darauf, wie das System intern funktioniert.

  2. Kennen Sie Ihren Zweck
    Fragen Sie: Warum schreibe ich diesen Use-Case? Ist es für das Backlog-Pflegen? Für die Architekturplanung? Für das Testdesign? Passen Sie das Detailniveau entsprechend an.

  3. Konzentrieren Sie sich auf Akteure und ihre Ziele
    Jeder Use-Case muss beantworten: Wer ist beteiligt? Was wollen sie erreichen? Warum ist das wichtig?
    Akteure können Menschen (z. B. Kunde, Administrator), externe Systeme (z. B. Zahlungsgateway) oder sogar zeitbasierte Auslöser sein.

  4. Bauen Sie das System in Scheiben
    Teilen Sie Use-Cases in dünne, vertikale Scheiben die alle Schichten umfassen: Benutzeroberfläche, Backend-Logik, Daten und Tests.

  5. Vollständige Scheiben liefern
    Jede Scheibe muss potenziell lieferbar — vollständig getestet, dokumentiert und nachweisbar. Keine teilweisen Lieferungen.

  6. An den Kontext anpassen
    Use-Case 2.0 ist nicht für alle gleich. Passen Sie die Detailtiefe für Unternehmenssysteme hoch oder für Start-ups herunter. Es ist flexibel, nicht starr.

🔹 3. Grundkonzepte in Use-Case 2.0

🎯 Aktor

Jede Entität (Mensch oder System), die mit dem System interagiert.

  • Primärer Akteur: Initiiert den Use-Case (z. B. ein Kunde, der Bargeld abhebt).

  • Unterstützender Akteur: Unterstützt den primären Akteur (z. B. eine Bankdatenbank oder Zahlungsprozessor).

📌 Use-Case

Eine zielorientierte Beschreibung, wie ein Akteur ein wertvolles Ergebnis erzielt.

  • Benannt als Verb + Substantiv: Bargeld abheben, Versicherungsanspruch bearbeiten, Benutzerkonto erstellen.

  • Umfang: Meist systembasiert, kann aber auch geschäfts- oder komponentenbasiert sein.

📝 Beispiel:
Use-Case: Bargeld abheben
Ziel: Um einem Kunden die Abhebung von Geld aus ihrem Konto über einen Geldautomaten zu ermöglichen.

🧩 Use-Case-Narrativ / Geschichte

Eine präzise, erzählungsartige Beschreibung des Use-Cases. Enthält:

  • Titel und Ziel

  • Primäre und unterstützende Akteure

  • Umfang

  • Haupterfolgsszenario (glücklicher Pfad)

  • Erweiterungen (Alternativen, Fehler)

📌 Format-Tipp:Verwenden Sie 1–2 Absätze oder Aufzählungspunkte. Vermeiden Sie vollständige UML-Diagramme, es sei denn, sie sind unbedingt erforderlich.

🔪 Use-Case-Slice (Der Game-Changer!)

Die leistungsstärkste Innovation in Use-Case 2.0.

Ein Use-Case-Slice ist:

  • Ein kleiner, selbstständiger Teil eines Use-Cases.

  • Bereitstellung von klarem, messbarem Nutzen.

  • Testbar, abschätzbar und in einem Sprint umsetzbar.

  • Ein vertikaler Slice der alle Ebenen durchschneidet: Anforderungen → Design → Code → Tests → UI.

💡 Stellen Sie sich vor, es sei ein gut geschriebene Benutzerstory, aber mit Kontextaus dem größeren Anwendungsfall.

✅ Eigenschaften einer guten Slice:

  • Unabhängig von anderen Slices (sofern möglich)

  • Bietet Wert für sich allein

  • Kann mit Tests verifiziert werden

  • Stimmt mit einem einzigen Sprint-Ziel überein

🔹 4. Schritt-für-Schritt-Prozess: So wenden Sie Use-Case 2.0 an

Verfolgen Sie diesen bewährten Workflow, um Visionen in funktionierende Software umzusetzen – schrittweise und kooperativ.

✅ Schritt 1: Identifizieren von Akteuren und Anwendungsfällen (Entdeckungsphase)

Beginnen Sie mit einer Brainstorming-Sitzung:

  • Wer nutzt das System?

  • Was sind ihre wichtigen Ziele?

👉 Ziele setzen auf 5–15 hochrangige Anwendungsfälle pro System. Vermeiden Sie die Erstellung von über 100 kleinen Anwendungsfällen.

🛠️ Beispiel: Geldautomatensystem

  • Akteure: Kunde, Bankangestellter, Bank-Administrator

  • Anwendungsfälle: Bargeld abheben, Geld einzahlen, Geld überweisen, Kontostand prüfen, PIN ändern

✅ Schritt 2: Skizzieren der Anwendungsfälle (leichtgewichtige Erzählung)

Für jeden Anwendungsfall schreiben Sie eine kurze Erzählung:

  • Titel: Bargeld abheben

  • Ziel: Ermöglicht einem Kunden, Geld von seinem Konto über einen Geldautomaten abzuheben.

  • Akteure: Kunde (primär), Geldautomat, Bankensystem (unterstützend)

  • Umfang: Nur Geldautomatensystem

  • Haupterfolgsszenario:

    1. Der Kunde steckt die Karte ein.

    2. Das System überprüft die Karte.

    3. Der Kunde gibt die PIN ein.

    4. Das System überprüft die PIN.

    5. Der Kunde wählt „Geld abheben“ aus.

    6. Der Kunde gibt den Betrag ein.

    7. Das System prüft das Guthaben.

    8. Geld wird ausgestellt.

    9. Ein Beleg wird gedruckt (optional).

    10. Transaktion abgeschlossen.

📌 Enthaltenwichtige Erweiterungen:

  • Unzureichendes Guthaben

  • Abgelaufene Karte

  • Tageslimit für Abhebungen überschritten

✅ Schritt 3: Die Anwendungsfälle aufteilen

Teilen Sie jeden Anwendungsfall in 3–10+ vertikale Slices. Verwenden Sie diese Aufteilungsmuster:

Muster Zweck
Grundslice Glücklicher Pfad mit minimaler Funktionalität
Vorbedingungs-Slice Authentifizierung, Einrichtung oder Anmeldung
Einfache Alternative Eine Variante (z. B. unzureichendes Guthaben)
Fehler-/Randfall-Slice Fehlerbehandlung (z. B. Timeout, Netzwerkfehler)
Erweiterungs-Slice Funktionen hinzufügen (z. B. Beleg, Mehrwertwährung)

📌 Beispiel: „Geld abheben“-Slices

  1. Benutzer authentifizieren + Kontostand anzeigen (Grundlage)

  2. Gültige Betrag ≤ Guthaben abheben → Bargeld ausgeben (Kern)

  3. Abheben → unzureichendes Guthaben → Fehlermeldung anzeigen

  4. Abheben → tägliche Grenze überschritten → Transaktion blockieren

  5. Beleg nach Abhebung ausdrucken

  6. Unterstützung für Abhebungen in mehreren Währungen

Jedes Slice ist nun ein Backlog-Eintrag bereit für die Sprintplanung.

✅ Schritt 4: Die Slices detaillieren (genug, aber nicht zu viel)

Für jedes Slice definieren:

  • Akzeptanzkriterien (in Gherkin/BDD-Format):

    Gegeben sei, dass der Kunde eine gültige Karte hat
Wenn sie eine gültige PIN eingeben
Und „Geld abheben“ für 50 $ auswählen
Und ausreichendes Guthaben haben
Dann sollte Bargeld ausgegeben werden
Und ein Beleg sollte gedruckt werden

  • UI/UX-Skizzen (falls erforderlich)

  • Test-Szenarien (automatisiert oder manuell)

  • Abhängigkeiten (z. B. Integration des Zahlungsgateways)

📌 Keine übermäßige Dokumentation! Nur das aufnehmen, was zum Erstellen und Testen benötigt wird.

✅ Schritt 5: Planen und Priorisieren

  • Fügen Sie Slices zum Produkt-Backlog.

  • Priorisieren nach:

    • Geschäftsvalue

    • Risiko (frühe Risikobehandlung)

    • Abhängigkeiten (kritische Pfade zuerst aufbauen)

    • Auswirkung auf den Kunden

Verwenden Sie die Use-Case-Übersicht um den Kontext zu bewahren – vermeiden Sie, den Wald vor lauter Bäumen zu verlieren.

🧭 Pro-Tipp: Verwenden Sie Use-Case-Diagramme oder visuelle Karten (z. B. Miro, Confluence), um Beziehungen zwischen Use Cases und Slices darzustellen.

✅ Schritt 6: Schrittweise Entwicklung

  • Ziehen Sie Slices in Sprints.

  • Implementieren Sie vollständig vertikalen Slice: UI + Backend + Datenbank + Tests.

  • Demonstrieren Sie funktionierende Funktionalität am Ende jedes Sprints.

  • Sammle Feedback und verfeinere.

✅ Jeder Sprint endet mit einem funktionsfähiges, getestetes, potenziell lieferbares Increment.

✅ Schritt 7: Überprüfen und Anpassen

Verfolge den Fortschritt jedes Slices mithilfe von Statusübergänge:

Status Bedeutung
Abgegrenzt Identifiziert und priorisiert
Vorbereitet Detailliert mit Akzeptanzkriterien, Tests, Design
Implementiert Code geschrieben und integriert
Überprüft Tests bestanden, vorgestellt, akzeptiert
Außer Dienst gestellt Nicht mehr benötigt oder veraltet

Verwende diese Verfolgung, um den Fortschritt zu überwachen und Engpässe zu identifizieren.

🔹 5. Praxisbeispiel: Online-Buchhandlung

Lassen Sie uns Use-Case 2.0 auf ein reales System anwenden.

📚 Anwendungsfall: Buch kaufen

🎯 Ziel:

Ermögliche einem Kunden, ein Buch online mit einem nahtlosen Checkout-Prozess zu kaufen.

📝 Haupterfolgsszenario:

  1. Der Kunde durchstöbert/sucht nach Büchern.

  2. Ansicht der Buchdetails und Hinzufügen zum Warenkorb.

  3. Geht zur Kasse.

  4. Gibt Versand- und Zahlungsinformationen ein.

  5. Bestätigt die Bestellung.

  6. Erhält eine Bestellbestätigung (E-Mail + auf dem Bildschirm).

🔪 Use-Case-Slices (Backlog-Elemente)

Jeder Slice ist ein vertikaler, lieferbarer Fortschritt:

Slice Beschreibung Wert geliefert
Slice 1: Durchstöbern und Suchen nach Büchern Der Kunde kann Bücher nach Titel, Autor oder Kategorie suchen (kein Login erforderlich). Grundlegende Entdeckungsfähigkeit
Slice 2: Buchdetails anzeigen + zum Warenkorb hinzufügen Der Kunde sieht die Buchbeschreibung, den Preis und fügt es dem Warenkorb hinzu. Kernfluss des Einkaufs
Slice 3: Warenkorb anzeigen und Mengen aktualisieren Der Kunde sieht den Warenkorb und bearbeitet die Mengen der Artikel. Personalisierung und Kontrolle
Slice 4: Gast-Kasse (Grundfunktionen) Der Kunde kauft ohne Konto ab; gibt grundlegende Versand- und Zahlungsinformationen ein. Geringer Widerstand beim Einsteigen
Slice 5: Anmeldung als registrierter Nutzer + Gespeicherte Adressen Angemeldete Benutzer können Adressen speichern und automatisch ausfüllen. Wiederverwendbarkeit und Bequemlichkeit
Slice 6: Integriere echten Zahlungsgateway Verbinde dich mit Stripe/PayPal; verwalte sichere Transaktionen. Vertrauen und Abschluss
Slice 7: Bestellbestätigungs-E-Mail Das System sendet eine E-Mail mit Zusammenfassung der Bestellung und Verfolgungsnummer. Sicherheit nach dem Kauf
Slice 8: Behandle fehlgeschlagene Zahlung + Wiederholung Der Kunde sieht die Fehlermeldung und kann die Zahlung erneut versuchen oder die Zahlungsmethode ändern. Widerstandsfähigkeit und UX-Feinschliff

✅ Jeder Slice kann unabhängig getestet, vorgeführt und veröffentlicht werden.

🔹 6. Use-Case 2.0 im Vergleich zu User Stories: Ein Seitenvergleich

Funktion Reine User Story Use-Case 2.0-Slice
Format „Als [Rolle] möchte ich [Ziel], damit [Nutzen]“ „Teil von ‚Buch kaufen‘ — gültigen Betrag abheben“
Kontext Isoliert; kann die Verbindung zu größeren Abläufen verlieren In einem Use-Case eingebettet – zeigt Beziehungen
Nachvollziehbarkeit Schwach (schwer, Geschichten zu verknüpfen) Stark (Slices lassen sich auf den Use-Case zurückverfolgen)
Komplexitätsbewältigung Hat Schwierigkeiten mit mehrstufigen, verzweigten Szenarien Bleibt stark bei Erweiterungen, Alternativen und Fehlerpfaden
Testen Wird oft nach der Implementierung definiert Tests definiert vor Codierung (BDD-zuerst)
Skalierbarkeit Stürzt bei Skalierung ab (zu viele Geschichten) Skaliert gut über Use-Case-Pakete und Hierarchien

✅ Use-Case 2.0 ist keine Ersetzung für Nutzerstories – es ist eine Verbesserung.
Es gibt Ihnen die Agilität von Nutzerstories mit der Struktur und Sichtbarkeit von Use-Cases.

🔹 7. Tipps für Erfolg und Skalierung

🎯 Starten Sie leicht, skalieren Sie schlau

  • Beginnen Sie mit Indexkarten oder One-Pagers.

  • Verwenden Sie digitale Whiteboards (Miro, FigJam, Confluence) zur Zusammenarbeit.

  • Vermeiden Sie zu früh eine Überkonstruktion.

🖼️ Nutzen Sie Visualisierungen strategisch

  • Use-Case-Diagramme: Zeigen Sie systemweite Grenzen auf hoher Ebene und Beziehungen zwischen Akteuren.

  • Aktivitätsdiagramme: Modellieren Sie komplexe Abläufe (z. B. mehrstufiger Checkout).

  • Slice-Karten: Visualisieren Sie, wie Slice in den größeren Use-Case passen.

🏢 Skalierung für große Projekte

  • Gruppieren Sie verwandte Use-Cases in Use-Case-Pakete (z. B. „Bestellverwaltung“, „Benutzerkonto“).

  • Verwenden Sie Geschäfts-Use-Cases für die Planung auf Unternehmensebene (z. B. „Neuen Kunden onboarden“).

  • Implementieren Sie modulare Architektur um vertikales Slicing zu unterstützen.

🛠️ Empfohlene Werkzeuge

Werkzeug Use-Case
Visual Paradigm Vollständige UML-Modellierung, Use-Case-Diagramme, Rückverfolgbarkeit
Enterprise Architect Erweiterte Modellierung, Integration mit ALM-Werkzeugen
Miro / FigJam Kooperatives Whiteboarding, Slice-Zuordnung
Jira / Azure DevOps Backlog-Management, Sprint-Verfolgung, Zustandsübergänge
Cucumber / SpecFlow BDD-Tests mit Gherkin-Syntax

✅ Pro-Tipp: Verwenden Sie Gherkin für Akzeptanzkriterien – es ist sowohl für Entwickler als auch für nicht-technische Stakeholder verständlich.

⚠️ Häufige Fehler, die vermieden werden sollten

  1. Zu viele Slices pro Anwendungsfall → Todesdurch-Details.
    → Lösung: Begrenzen Sie auf 3–10 Slices; konzentrieren Sie sich auf den Wert, nicht auf die Feinheit.

  2. Zu wenige Slices → Riesige, nicht testbare Geschichten.
    → Lösung: Zerlegen Sie große Abläufe in schmale vertikale Slices.

  3. Ignorieren von Erweiterungen und Fehlern → Unzuverlässige Systeme.
    → Lösung: Fügen Sie mindestens einen Fehler-/Alternativ-Slice pro Anwendungsfall hinzu.

  4. Behandeln von Anwendungsfällen als endgültige Spezifikationen → Anti-agil.
    → Lösung: Behandeln Sie sie als lebendige Artefakte – verfeinern Sie sie, während Sie lernen.

🔹 Fazit: Die Zukunft der Anforderungen ist da

Use-Case 2.0 ist nicht nur eine Methodik – es ist eine Verhaltensänderung.

Es beantwortet die altbekannte Spannung zwischen Klarheit und Agilität, zwischen Struktur und Geschwindigkeit. Durch die Kombination von:

  • Die zielorientierter Fokus von Anwendungsfällen,

  • Die leichte, iterative Natur von Nutzergeschichten,

  • Die Test-zuerst, vertikales Slicing moderner agiler Praktiken,

…Use-Case 2.0 bietet einen leistungsstarken, zukunftssicheren Ansatz für Softwareanforderungen.

✅ Warum Teams es 2026 lieben:

  • ✅ Schnellerer Wertvorteil – liefern Sie funktionale Features frühzeitig.

  • ✅ Bessere Zusammenarbeit – gemeinsames Verständnis über Produkt, Entwicklung und QA.

  • ✅ Weniger Fehler – Tests werden vor dem Code definiert.

  • ✅ Einfachere Skalierung – geeignet für Start-ups und globale Unternehmen.

  • ✅ Nachvollziehbare Lieferung – Jede Funktion ist auf ein Nutzerziel zurückzuführen.

📚 Weitere Lektüre:

  • Use-Case 2.0: Der Leitfaden zum Erfolg mit Use-Cases von Ivar Jacobson, Ian Spence, Kurt Bittner

  • Kostenloser Download: https://www.ivarjacobson.com

  • Entdecken Sie die Ivar Jacobson International Seite für Schulungen, Tools und Community.

📌 Letzte Überlegung

„Schreiben Sie keine Anforderungen – liefern Sie Wert.“
Use-Case 2.0 verwandelt abstrakte Ziele in greifbare, getestete und wertvolle Schritte – Schritt für Schritt.

Egal, ob Sie eine Fintech-App, eine E-Commerce-Plattform oder ein missionskritisches Unternehmenssystem entwickeln, Use-Case 2.0 gibt Ihnen das Framework, um schlauer, schneller und mit größerer Sicherheit zu bauen.

🚀 Viel Erfolg beim Slicing!
Machen Sie sich auf den Weg und liefern Sie Wert – Schritt für Schritt, vertikal.

Der Artikel ist auch in English, Español, فارسی, Français, English, Bahasa Indonesia, 日本語, Polski, Portuguese, Việt Nam, 简体中文 and 繁體中文 verfügbar.