Ein Use Case (deutsch „Anwendungsfall") beschreibt, wie ein Nutzer oder ein anderes System mit einer Software interagiert, um ein bestimmtes Ziel zu erreichen. Er beantwortet die Frage: „Wer will mit diesem System was tun – und was passiert dabei?" Ein Use Case ist damit die Brücke zwischen dem fachlichen Bedarf eines Unternehmens und der konkreten technischen Umsetzung. Er übersetzt „wir möchten, dass Kunden online bestellen können" in eine präzise, nachvollziehbare Beschreibung dessen, was das System tatsächlich leisten muss. Der englische Begriff „Application" verweist dabei auf die Anwendung selbst – die Software, in der sich der Anwendungsfall abspielt.
Der Begriff hat zwei eng verwandte Bedeutungen, die im Sprachgebrauch oft verschwimmen. In der Softwareentwicklung ist ein Use Case eine formale Beschreibung einer Interaktion. Im Geschäfts- und KI-Kontext meint „Use Case" häufig etwas weiter gefasst einen sinnvollen Einsatzzweck für eine Technologie – etwa „ein guter Use Case für KI ist die automatische Sortierung von Support-Anfragen". Beide Bedeutungen teilen denselben Kern: Es geht um einen konkreten, abgegrenzten Zweck, den eine Lösung erfüllt.
Warum Use Cases wichtig sind
Software scheitert selten an der Technik und oft an unklaren Anforderungen. Wenn niemand präzise beschrieben hat, was das System eigentlich tun soll, baut das Entwicklungsteam an den Bedürfnissen vorbei. Use Cases zwingen alle Beteiligten, früh konkret zu werden: Wer nutzt das System? Was will diese Person erreichen? Welche Schritte sind nötig? Was passiert, wenn etwas schiefgeht? Diese Klarheit ist die günstigste Versicherung gegen teure Fehlentwicklungen – denn ein Missverständnis, das im Konzept auffällt, kostet einen Bruchteil dessen, was seine Korrektur im fertigen Produkt verschlingt.
Aufbau eines Anwendungsfalls
Ein klassischer Use Case folgt einer wiederkehrenden Struktur. Er besteht typischerweise aus diesen Bestandteilen:
| Bestandteil | Bedeutung |
|---|---|
| Akteur | Wer löst die Interaktion aus (z. B. „Kunde", „Administrator", „Zahlungsdienst") |
| Ziel | Was der Akteur erreichen will (z. B. „eine Bestellung aufgeben") |
| Vorbedingung | Was gegeben sein muss, damit der Fall startet (z. B. „Kunde ist eingeloggt") |
| Hauptablauf | Die Schritte im Normalfall, von Start bis Erfolg |
| Alternativabläufe | Was bei Abweichungen oder Fehlern passiert (z. B. „Zahlung abgelehnt") |
| Nachbedingung | Der Zustand nach erfolgreichem Abschluss (z. B. „Bestellung ist gespeichert") |
Diese Struktur macht den Unterschied zwischen einem vagen Wunsch und einer umsetzbaren Spezifikation. Besonders die Alternativabläufe sind wertvoll: Sie zwingen dazu, früh über Fehlerfälle nachzudenken, statt sie spät und teuer im Live-Betrieb zu entdecken.
Ein konkretes Beispiel
Nehmen wir den Use Case „Gutschein einlösen" in einem Onlineshop. Der Akteur ist ein eingeloggter Kunde, das Ziel ist ein Rabatt auf den Warenkorb. Vorbedingung: Der Warenkorb enthält mindestens einen Artikel. Der Hauptablauf: Der Kunde gibt einen Gutscheincode ein, das System prüft ihn, der Rabatt wird abgezogen, der neue Gesamtpreis wird angezeigt. Die Alternativabläufe: Der Code ist ungültig (Fehlermeldung), abgelaufen (Hinweis aufs Ablaufdatum) oder nicht mit anderen Aktionen kombinierbar (entsprechende Meldung). Die Nachbedingung: Der reduzierte Preis gilt für den weiteren Bestellprozess. Aus dieser einen kompakten Beschreibung kann ein Entwicklungsteam unmittelbar ableiten, was zu bauen und was zu testen ist.
Use Case und User Story – wo liegt der Unterschied?
In agilen Projekten begegnet einem häufig die User Story statt des klassischen Use Case. Beide beschreiben Anforderungen aus Nutzersicht, unterscheiden sich aber im Detailgrad. Eine User Story ist bewusst knapp gehalten – typischerweise im Format „Als [Rolle] möchte ich [Ziel], um [Nutzen]". Sie ist ein Platzhalter für ein Gespräch. Ein Use Case geht tiefer und beschreibt den vollständigen Ablauf inklusive aller Verzweigungen. In der Praxis ergänzen sich beide: Die User Story hält fest, warum etwas gebraucht wird, der Use Case oder konkrete Akzeptanzkriterien beschreiben, wie es sich genau verhalten soll.
Use Cases im KI-Kontext
Gerade bei KI-Projekten ist der Begriff „Use Case" allgegenwärtig – und entscheidend. Die wichtigste Frage vor jedem KI-Vorhaben lautet nicht „welches Modell nehmen wir?", sondern „welchen Anwendungsfall lösen wir damit, und lohnt sich das?". Ein tragfähiger KI-Use-Case zeichnet sich durch drei Dinge aus: ein klar umrissenes Problem, messbaren Nutzen und verfügbare Daten. „Wir machen irgendwas mit KI" ist kein Use Case, sondern ein teures Missverständnis. „Wir klassifizieren eingehende E-Mails automatisch nach Dringlichkeit und sparen dem Support-Team täglich zwei Stunden Triage" hingegen ist ein Anwendungsfall, an dem sich Aufwand und Ertrag ehrlich abwägen lassen. Eine strukturierte Use-Case-Analyse am Anfang verhindert, dass Budget in technisch beeindruckende, aber geschäftlich nutzlose Experimente fließt.
Von der Analyse zur Umsetzung
Use Cases stehen am Anfang eines guten Softwareprojekts, nicht am Ende. Sie sind das Werkzeug, mit dem aus einer Geschäftsidee eine baubare Spezifikation wird. Eine etablierte Methode, um Anwendungsfälle und ihre Akteure visuell darzustellen, ist das Use-Case-Diagramm der Unified Modeling Language (UML), das die Beziehungen zwischen Nutzern und Systemfunktionen auf einen Blick zeigt. Ob in formaler UML-Notation oder als pragmatische Liste – entscheidend ist nicht die Form, sondern die Disziplin, früh und konkret zu beschreiben, was das System für wen leisten soll. Wer diese Arbeit ernst nimmt, baut Software, die tatsächlich das Problem löst, das gelöst werden sollte.