Was ist ein Use Case? – Use Cases gehören zu den meistgenutzten Werkzeugen in der Anforderungsanalyse, doch in vielen Projekten bleibt unklar, was genau damit gemeint ist und wie man sie sauber einsetzt. Wenn Sie Software, Prozesse oder Services konzipieren, hilft ein gut formulierter Use Case dabei, Missverständnisse zu vermeiden, bessere Lösungen zu entwerfen und das Team zu fokussieren.
In diesem Artikel erfahren Sie, was ein Use Case ist, warum er so wichtig ist und wie Sie selbst professionelle Use Cases erstellen, die in der Praxis tatsächlich genutzt werden.
1. Grundverständnis: Was ist ein Use Case?
Ein Use Case (Anwendungsfall) beschreibt, wie ein bestimmter Nutzer – der sogenannte Akteur – mit einem System interagiert, um ein konkretes Ziel zu erreichen. Es geht dabei nicht um technische Details, sondern um fachliche Abläufe und sichtbare Ergebnisse.
Ein Use Case beantwortet immer Fragen wie:
- Wer möchte was erreichen?
- Mit welchem System interagiert diese Person?
- Welche Schritte durchläuft sie, um ihr Ziel zu erreichen?
- Welche Bedingungen müssen vorher erfüllt sein?
- Welches Ergebnis steht am Ende?
1.1 Formale Definition
Vereinfacht ausgedrückt:
Ein Use Case ist eine strukturierte Beschreibung einer Interaktion zwischen einem Akteur und einem System, die zu einem für den Akteur messbaren Mehrwert führt.
Wichtig ist, dass der Use Case immer ein Ziel hat. Deshalb beschreiben Sie nicht „Klicks“ oder „Buttons“, sondern Zielerreichung aus Sicht des Nutzers.
Beispielsweise ist nicht „Formular ausfüllen“ der Use Case, sondern „Neukundenkonto eröffnen“.
1.2 Abgrenzung: Was ein Use Case nicht ist
Damit Sie Use Cases sauber einsetzen, lohnt sich die Abgrenzung zu anderen Artefakten:
- Kein technisches Design
Der Use Case sagt nicht, wie die Datenbank strukturiert wird oder welche Technologie Sie nutzen. - Keine Schritt-für-Schritt-Bedienungsanleitung
Er erinnert eher an ein Drehbuch als an ein Handbuch, denn er beschreibt typische Abläufe, nicht jede mögliche Variante bis ins letzte Detail. - Kein User Story Backlog-Eintrag
Eine User Story ist kürzer, agiler und oft techniknäher, während ein Use Case den vollständigen Ablauf eines Geschäftsvorgangs beschreibt.
2. Warum sind Use Cases so wichtig?
Use Cases unterstützen Projekte an mehreren Stellen gleichzeitig, weil sie eine gemeinsame Sprache für Fachbereich, IT, UX und Management schaffen.
2.1 Zentrale Vorteile von Use Cases
Use Cases bringen insbesondere folgende Nutzen:
- Klarheit in den Anforderungen
Sie beschreiben, was ein System leisten soll, sodass sowohl Fachseite als auch Entwickler dieselbe Vorstellung haben. - Bessere Kommunikation im Team
Alle reden über denselben Ablauf und über dieselben Begriffe, statt über vage „Features“. - Fokus auf Nutzerziele
Durch die konsequente Orientierung am Ziel des Akteurs bleiben Sie kundenzentriert, anstatt sich in technischen Details zu verlieren. - Basis für Testfälle
Aus den Schritten eines Use Cases lassen sich sehr gut Testfälle ableiten, wodurch Sie später systematisch prüfen können, ob das System richtig funktioniert. - Strukturierte Dokumentation
Use Cases bieten ein wiederverwendbares Gerüst, das Anforderungen dokumentiert, ohne sie in reinen Textwüsten zu verlieren.
2.2 Typische Einsatzbereiche
Use Cases kommen in vielen Kontexten zum Einsatz, zum Beispiel:
- bei der Einführung neuer Software (ERP, CRM, Portale, Apps)
- in Digitalisierungsprojekten, in denen analoge Prozesse erstmals systemgestützt abgebildet werden
- in Produktentwicklungsprojekten, wenn neue Funktionen entworfen werden
- in der Prozessoptimierung, um bestehende Abläufe zu analysieren und zu verbessern
- in Ausschreibungen, weil Auftraggeber konkrete Szenarien vorgeben können, die der Anbieter abdecken muss
3. Bausteine eines Use Cases
Damit ein Use Case strukturiert und leicht verständlich bleibt, folgt er üblicherweise einem wiederkehrenden Aufbau.
3.1 Typische Bestandteile im Überblick
Ein professioneller Use Case enthält meist:
- Name des Use Case
Kurz, prägnant, zielorientiert (z. B. „Rechnung bezahlen“, „Neukunde registrieren“). - Ziel / Zweck
Was will der Akteur erreichen und warum ist das wichtig? - Akteur(e)
Wer interagiert mit dem System (z. B. Kunde, Sachbearbeiter, Admin, externer Dienst)? - Vorbedingungen (Preconditions)
Was muss erfüllt sein, bevor der Use Case starten kann? - Nachbedingungen (Postconditions)
Was ist nach erfolgreicher Durchführung wahr? Welche Resultate liegen vor? - Trigger / Auslöser
Welches Ereignis startet den Use Case? - Hauptablauf (Main Success Scenario)
Der „Happy Path“: Wie läuft der Idealfall Schritt für Schritt ab? - Alternative Abläufe / Ausnahmen
Was passiert, wenn etwas schiefgeht oder Sonderfälle auftreten? - Geschäftsregeln und Fachlogik
Welche Regeln beeinflussen Entscheidungen im Ablauf?
3.2 Beispiel: Struktur in Kurzform
Zur Veranschaulichung eine kompakte, generische Struktur:
- Name: „Neukunde registrieren“
- Ziel: Ein Interessent legt ein Kundenkonto an, um im Online-Shop bestellen zu können.
- Akteur: Neukunde
- Vorbedingungen: Interessent verfügt über eine gültige E-Mail-Adresse.
- Nachbedingungen: Kundenkonto existiert, Bestätigungsmail versendet.
- Trigger: Nutzer klickt im Shop auf „Registrieren“.
- Hauptablauf:
- Nutzer öffnet Registrierungsformular.
- Nutzer gibt Pflichtdaten ein.
- System prüft Daten auf Vollständigkeit und Plausibilität.
- System legt neues Kundenkonto an.
- System sendet Bestätigungsmail.
- Nutzer erhält Bestätigung und kann sich einloggen.
- Alternative Abläufe:
- 3a: E-Mail-Adresse bereits vergeben → System zeigt Fehlermeldung und schlägt „Passwort vergessen“ vor.
- 3b: Pflichtfeld leer → System markiert das Feld und fordert Eingabe an.
4. Konkretes Beispiel: Use Case „Rechnung online bezahlen“
Damit das Konzept greifbarer wird, betrachten wir einen konkreten Use Case aus einem typischen Self-Service-Portal.
4.1 Kontext
Stellen Sie sich einen Energieversorger vor, der seinen Privatkunden ein Online-Portal anbietet. Dort können Kunden ihre Rechnungen einsehen und online bezahlen.
4.2 Ausformulierter Use Case (vereinfachte Form)
Name: Rechnung online bezahlen
Ziel: Der Kunde bezahlt eine offene Rechnung bequem online und erhält eine unmittelbare Bestätigung.
Akteur: Privatkunde
System: Online-Kundenportal des Energieversorgers
Vorbedingungen:
- Kunde besitzt einen aktiven Online-Zugang.
- Mindestens eine offene Rechnung liegt vor.
Nachbedingungen:
- Die ausgewählte Rechnung ist als „bezahlt“ verbucht.
- Der Kunde erhält eine Zahlungsbestätigung.
Trigger:
- Kunde meldet sich im Portal an und wählt im Menü „Rechnungen“ aus.
Hauptablauf (Happy Path):
- Der Kunde meldet sich im Online-Portal an und gelangt zur Startseite.
- Er navigiert zum Bereich „Rechnungen“ und wählt eine offene Rechnung aus.
- Das System zeigt die Rechnungsdetails sowie verfügbare Zahlungsarten an.
- Der Kunde entscheidet sich für eine Zahlungsart (z. B. Kreditkarte) und gibt die erforderlichen Zahlungsdaten ein.
- Das System prüft die Zahlungsdaten und leitet die Zahlung an den Zahlungsdienstleister weiter.
- Der Zahlungsdienstleister bestätigt die erfolgreiche Zahlung.
- Das System markiert die Rechnung als bezahlt und aktualisiert den offenen Saldo.
- Der Kunde erhält im Portal eine Bestätigungsmeldung und optional eine E-Mail mit der Zahlungsbestätigung.
Alternative Abläufe / Ausnahmen:
- 5a: Zahlungsdaten fehlerhaft
- Das System erkennt fehlende oder ungültige Angaben und informiert den Kunden.
- Der Kunde korrigiert die Eingaben und startet den Zahlungsvorgang erneut.
- 6a: Zahlung abgelehnt
- Der Zahlungsdienstleister lehnt die Zahlung ab.
- Das System informiert den Kunden über die Ablehnung und nennt – soweit möglich – den Grund.
- Der Kunde wählt eine andere Zahlungsart oder bricht den Vorgang ab.
Dieses Beispiel zeigt, wie ein Use Case fachliche Abläufe beschreibt, ohne in technische Implementierungsdetails abzurutschen.
5. Wie erstellt man einen guten Use Case?
Gute Use Cases sind präzise, verständlich und nutzenorientiert. Damit Ihnen das gelingt, hilft ein praktikables Vorgehen, das Sie in fast jedem Projekt anwenden können.
5.1 Schritt-für-Schritt-Vorgehen
Sie können Use Cases unter anderem so erarbeiten:
- Zielgruppe und Akteure identifizieren
- Wer nutzt das System?
- Welche Rollen gibt es (Kunde, Mitarbeiter, Partner, Systemakteure)?
- Geschäftsziele klären
- Welche geschäftlichen Ziele sollen unterstützt werden?
- Welche Vorgänge sind dafür wirklich kritisch?
- Kandidaten für Use Cases sammeln
- Listen Sie zunächst alle relevanten Aktivitäten stichwortartig auf.
- Verdichten Sie ähnliche Aktivitäten zu übergeordneten Use Cases.
- Priorisieren
- Fragen Sie: Welche Use Cases sind am wichtigsten für den Geschäftserfolg?
- Beginnen Sie mit 5–10 Kern-Use-Cases statt mit 50 Detailfällen.
- Use Cases strukturieren und ausformulieren
- Nutzen Sie die in Abschnitt 3 vorgestellte Struktur.
- Formulieren Sie in klarer, einfacher Sprache und vermeiden Sie unnötigen Jargon.
- Mit Stakeholdern validieren
- Gehen Sie jeden Use Case gemeinsam mit Fachbereich, IT und ggf. UX durch.
- Prüfen Sie, ob die Abläufe realistisch, vollständig und verständlich sind.
- Pflegen und iterativ verfeinern
- Passen Sie die Use Cases an, wenn sich Anforderungen oder Rahmenbedingungen ändern.
- Ergänzen Sie bei Bedarf neue Alternativabläufe oder Geschäftsregeln.
5.2 Formulierungstipps
Damit Ihre Use Cases in der Praxis tatsächlich gelesen und verstanden werden, achten Sie auf folgende Punkte:
- Nutzenorientierte Titel verwenden
Schreiben Sie „Rechnung bezahlen“ statt „Zahlungsmodul bedienen“. - Aus Sicht des Akteurs formulieren
Verwenden Sie aktive Formulierungen wie „Der Kunde wählt…“ statt abstrakter Beschreibungen. - Einfache, klare Sprache
Vermeiden Sie unnötige Fremdwörter und lange Schachtelsätze, damit auch Nicht-Techniker folgen können. - Konsequente Terminologie
Nutzen Sie für dieselben Dinge immer dieselben Begriffe, weil das Missverständnisse reduziert. - Konkrete, aber nicht überdetaillierte Schritte
Formulieren Sie so genau wie nötig, aber so knapp wie möglich.
Sie beschreiben den Ablauf, jedoch nicht jedes einzelne Klick-Detail.
6. Typische Fehler bei Use Cases – und wie Sie sie vermeiden
In vielen Projekten existieren zwar Use Cases, allerdings nutzen sie ihrem Zweck kaum, weil einige klassische Fehler auftreten.
6.1 Zu technische Beschreibung
Oft verfallen Teams beim Schreiben in technische Details, sodass der Use Case eher wie ein technisches Design wirkt. Damit Sie das vermeiden, konzentrieren Sie sich auf:
- fachliche Abläufe statt Datenbankstrukturen
- Nutzerentscheidungen statt UI-Implementierung
- Ergebnisse statt interner Systemlogik
6.2 Kein klares Ziel
Manche Use Cases hängen „in der Luft“, weil das Ziel unscharf bleibt. Achten Sie deshalb darauf, dass:
- der Name des Use Case ein erkennbares Ziel enthält
- die Nachbedingungen messbar sind („Rechnung ist bezahlt“, „Konto ist angelegt“)
6.3 Vermischung mehrerer Use Cases
Ein weiterer typischer Fehler besteht darin, mehrere unabhängige Abläufe in einem einzigen Use Case zu bündeln. Dadurch wird der Text schwer lesbar und kaum testbar.
Fragen Sie sich deshalb:
- Lässt sich der Ablauf logisch als abgeschlossene Einheit verstehen?
- Hat der Use Case genau einen klaren Auslöser und ein klares Ergebnis?
Wenn Sie Zweifel haben, lohnt sich oft eine Auftrennung in zwei getrennte Use Cases.
6.4 Fehlende Alternativabläufe
Wenn nur der ideale Ablauf beschrieben wird, übersehen Teams häufig wichtige Sonderfälle. Planen Sie deshalb bewusst Zeit ein, um alternative Abläufe zu identifizieren:
- Was passiert, wenn Eingaben fehlen oder fehlerhaft sind?
- Was geschieht, wenn externe Dienste nicht erreichbar sind?
- Welche Sonderregeln gelten für bestimmte Kundengruppen?
7. Use Cases, User Stories und Prozesse – wie passt das zusammen?
In modernen Projekten existieren verschiedene Artefakte nebeneinander, sodass schnell Verwirrung entsteht. Trotzdem ergänzen sich diese Werkzeuge, wenn Sie sie klar abgrenzen.
7.1 Unterschied zum Geschäftsprozess
Ein Geschäftsprozess beschreibt aus Unternehmenssicht, wie Wertschöpfung entsteht. Er betrachtet daher häufig mehrere Systeme, Rollen und Organisationseinheiten.
Ein Use Case fokussiert dagegen auf:
- eine Interaktion zwischen einem Akteur und einem System
- ein klar definiertes Ziel dieses Akteurs
Ein komplexer Geschäftsprozess setzt sich somit aus mehreren Use Cases zusammen, die nacheinander oder parallel ausgeführt werden.
7.2 Unterschied zur User Story
Eine User Story (z. B. in Scrum) ist ein kurzer Eintrag im Product Backlog, der den Bedarf aus Nutzersicht beschreibt, zum Beispiel:
„Als registrierter Kunde möchte ich meine offenen Rechnungen online einsehen, damit ich jederzeit einen Überblick über meine Zahlungen habe.“
Der Unterschied liegt vor allem:
- im Detailgrad (User Story ist kurz, Use Case ist ausführlich)
- im Zweck (User Story für Planung & Priorisierung, Use Case für detaillierte Anforderung und Tests)
- in der Struktur (User Stories folgen einem Satzmuster, Use Cases folgen einer Ablaufstruktur)
In der Praxis ergänzen sich beide:
- User Stories helfen Ihnen, das Produkt inkrementell zu planen.
- Use Cases liefern die notwendige Tiefe, um komplexe Abläufe korrekt umzusetzen.
8. Fazit Was ist ein Use Case?: Wann lohnt sich der Einsatz von Use Cases?
Use Cases lohnen sich insbesondere dann, wenn:
- Sie komplexe Abläufe mit mehreren Entscheidungspunkten modellieren müssen.
- viele Stakeholder mit unterschiedlichen Hintergründen beteiligt sind.
- Sie Anforderungen nachvollziehbar dokumentieren und später gezielt testen möchten.
- ein System kunden- oder nutzerzentriert weiterentwickelt werden soll.
Richtig eingesetzt, helfen Use Cases dabei, Anforderungen klar zu strukturieren, Kommunikationslücken zu schließen und Risiken in der Implementierung zu reduzieren. Wenn Sie Schritt für Schritt vorgehen, Stakeholder aktiv einbeziehen und auf eine klare, nutzenorientierte Sprache achten, entwickeln Sie nach und nach ein Set an Use Cases, das Ihre Projekte spürbar stabiler macht – von der Idee bis zum Go-live.