Use Case

Was ist ein Use Case?

Use Cases betrachten ein System aus der Perspektive seiner Nutzung. Ein Akteur verfolgt ein Ziel und interagiert dafür mit dem System. Ivar Jacobson, der den Use-Case-Ansatz maßgeblich popularisierte, beschreibt einen Use Case als Folge von Aktionen, die ein beobachtbares Ergebnis von Wert für einen bestimmten Nutzer liefert.

Damit ist „Login“ nicht automatisch ein sinnvoller Use Case. Häufig ist Login nur ein Teilschritt eines größeren Ziels wie „Auftrag freigeben“ oder „Rechnung abrufen“.

Fachliche Grundlage: Jacobson und UML

Use Cases wurden durch Ivar Jacobsons Arbeiten und das Buch „Object-Oriented Software Engineering: A Use Case Driven Approach“ bekannt. Später wurden Use Cases Bestandteil der Unified Modeling Language (UML).

Die OMG-Spezifikation UML 2.5.1 definiert eine standardisierte Modellierungssprache, in der Use-Case-Diagramme Akteure, Systemgrenzen und Beziehungen visualisieren können. Das Diagramm allein enthält jedoch selten genug Information für komplexe Anforderungen. Der textuelle Ablauf bleibt entscheidend.

Bestandteile eines textuellen Use Cases

Je nach Methode kann ein Use Case enthalten:

• Name und Ziel,
• primärer Akteur,
• weitere beteiligte Akteure oder Systeme,
• Vorbedingungen,
• Auslöser,
• Hauptablauf,
• alternative Abläufe und Fehlerfälle,
• Nachbedingungen beziehungsweise Erfolgsergebnis.

Beispiel: Rechnung freigeben

So wird nicht nur eine einzelne Bildschirmfunktion beschrieben, sondern ein fachlicher Ablauf.

Use Case vs. User Story

User Stories sind typischerweise kürzer und dienen als Kommunikationsanker für einen priorisierbaren Bedarf. Use Cases können einen vollständigen Interaktionsablauf und Alternativen beschreiben. Bei komplexen Geschäftsanwendungen sind sie deshalb oft wertvoll, wenn mehrere Rollen, Entscheidungen und Fehlerpfade verstanden werden müssen.

Use Case vs. Prozessmodell

Ein Use Case fokussiert die Interaktion mit einem betrachteten System. Ein Geschäftsprozess kann dagegen mehrere Systeme, manuelle Tätigkeiten und organisatorische Schritte umfassen. Für Prozessdigitalisierung werden deshalb häufig Prozessmodelle und Use Cases gemeinsam verwendet.

Typische Fehler

• Use Cases werden zu technischen Funktionslisten.
• Der fachliche Wert für den Akteur bleibt unklar.
• Systemgrenzen sind nicht definiert.
• Nur der Happy Path wird dokumentiert.
• Das Diagramm wird mit der vollständigen Anforderung verwechselt.

Wann lohnt sich ein Use Case?

Use Cases sind besonders hilfreich, wenn Interaktionen komplexer werden, mehrere Akteure beteiligt sind oder alternative Abläufe fachlich relevant sind. Für eine einzelne kleine UI-Änderung kann eine User Story mit Akzeptanzkriterien dagegen ausreichend sein.

Use Cases helfen bei Ausnahmefällen

Gerade in Geschäftsanwendungen liegt Komplexität selten im Happy Path. Freigabe wird verweigert, Daten fehlen, ein externes System ist nicht erreichbar oder eine Rolle besitzt nur eingeschränkte Rechte. Textuelle Use Cases machen solche alternativen Pfade systematisch diskutierbar.

Dadurch eignen sie sich auch als Brücke zu Testfällen: Aus Haupt- und Alternativabläufen lassen sich konkrete Szenarien ableiten, gegen die eine Implementierung später geprüft werden kann.

Fazit

Use Cases strukturieren Anforderungen aus Nutzungsperspektive. Ihre Stärke liegt in der Verbindung von Ziel, Akteur, Systemgrenze und Ablauf. Sie sind damit ein nützliches Werkzeug im Requirements Engineering – insbesondere für individuelle Geschäftsanwendungen und komplexe Interaktionen.