Use Case Diagramm erklärt

Use Case Diagramm erklärt – Use Case Diagramme gehören zu den wichtigsten Werkzeugen in der Software- und Systemanalyse, denn sie schlagen eine Brücke zwischen Fachbereich und Technik. Obwohl die Notation aus der UML stammt, können auch Nicht-Entwickler die Diagramme schnell lesen und verstehen, sodass sie sich hervorragend für Workshops, Anforderungsdokumente und Präsentationen eignen.

In diesem Artikel lernst du, was ein Use Case Diagramm ist, welche Elemente es enthält, wie du es korrekt zeichnest und welche typischen Fehler du vermeiden solltest. Außerdem erhältst du praxisnahe Tipps, damit deine Diagramme nicht nur korrekt, sondern auch wirklich hilfreich sind.

Ein Use Case Diagramm ist ein grafisches Modell, das zeigt, wie externe Nutzer (Akteure) mit einem System interagieren, um bestimmte Ziele zu erreichen. Es beantwortet vor allem die Fragen:

Das Diagramm gehört zur Unified Modeling Language (UML) und bildet die funktionalen Anforderungen eines Systems auf hoher Abstraktionsebene ab. Dadurch eignet es sich sehr gut als gemeinsames Kommunikationsmittel zwischen:

Während andere UML-Diagramme häufig sehr technisch wirken, bleibt das Use Case Diagramm bewusst fachlich, denn es konzentriert sich auf sichtbares Verhalten und nicht auf interne Implementierungsdetails.

Ein gutes Use Case Diagramm verfolgt mehrere Ziele gleichzeitig, und es sollte diese klar unterstützen:

Damit dein Diagramm klar und konsistent bleibt, solltest du die grundlegenden Bausteine genau kennen und bewusst einsetzen.

Akteure repräsentieren Rollen, die mit dem System interagieren, und sie stehen immer außerhalb der Systemgrenze. Ein Akteur kann dabei eine Person, ein anderes System oder eine Organisation sein.

Typische Merkmale von Akteuren:

Beispiele:

Wichtig ist, dass du Akteure nach ihrem Interaktionsverhalten und nicht nach ihrer Stellenbezeichnung benennst. Ein „Buchhalter“ kann je nach System sowohl „Rechnungsprüfer“ als auch „Reporting-Verantwortlicher“ sein, sodass du besser fachliche Rollen formulierst.

Use Cases beschreiben zusammenhängende Abläufe, in denen ein Akteur ein konkretes Ziel mit Hilfe des Systems erreicht. Im Diagramm stellst du sie als Ellipsen dar, die innerhalb der Systemgrenze liegen.

Gute Use-Cases-Formulierungen:

Schlechte Formulierungen sind hingegen:

Ein guter Test lautet:
Kann der Akteur sagen: „Ich möchte diesen Use Case, weil ich damit ein sinnvolles Ziel erreiche“?
Wenn die Antwort nicht klar „Ja“ lautet, solltest du den Use Case neu zuschneiden oder umbenennen.

Die Systemgrenze ist meist ein Rechteck, das alle Use Cases enthält. Es markiert, welcher Teil der Gesamtlösung zu deinem System gehört und was stattdessen externe Umwelt bleibt.

Warum die Systemgrenze wichtig ist:

Benutze einen konsistenten Namen für die Systemgrenze, zum Beispiel:

Neben den Elementen sind vor allem die Beziehungen entscheidend, denn sie machen aus einzelnen Use Cases ein strukturiertes Gesamtbild.

Die fundamentalste Beziehung ist die Assoziation zwischen einem Akteur und einem Use Case. Du stellst sie als einfache Linie dar, und du zeigst damit, dass der Akteur an diesem Use Case teilnimmt.

Typische Muster:

Dadurch erkennst du auf einen Blick:

Manchmal teilen sich mehrere Akteure ein gemeinsames Verhalten, doch sie besitzen zusätzlich eigene Spezialfälle. In solchen Situationen nutzt du die Generalisierung (eine Vererbungsbeziehung):

Der übergeordnete Akteur beinhaltet das gemeinsame Verhalten, und die spezialisierten Akteure erben dieses Verhalten und können zusätzliche Use Cases nutzen.

Diese Struktur solltest du aber sparsam einsetzen, weil zu viele Vererbungen das Diagramm schnell unübersichtlich machen.

Die «include»-Beziehung zeigt, dass ein Use Case einen anderen Use Case zwingend einbindet, weil dieser Teilablauf immer benötigt wird.

Beispiel:

Regeln für «include»:

Dadurch verhinderst du Dopplungen und sorgst für eine saubere Struktur, doch du solltest nicht jede Kleinigkeit in eigene «include»-Use-Cases auslagern, damit das Diagramm lesbar bleibt.

Die «extend»-Beziehung steht für optionale oder bedingte Erweiterungen eines Use Cases. Der Basis-Use-Case beschreibt den Normalfall, und der erweiternde Use Case tritt nur unter bestimmten Bedingungen ein.

Beispiel:

Eigenschaften von «extend»:

Mit «extend» modellierst du Alternativ- oder Ausnahmeabläufe, ohne das Hauptszenario zu überfrachten.

Um die Elemente greifbar zu machen, betrachten wir ein vereinfachtes Beispiel: Ein Online-Ticketsystem für Veranstaltungen.

Zusätzlich kannst du sinnvolle Detailbeziehungen modellieren:

So entsteht ein Bild, das sowohl Fachanwendern als auch Entwicklern hilft, das System zu verstehen, und es zeigt auf einen Blick, wie die wichtigsten Rollen mit dem System interagieren.

Damit deine Diagramme nicht nur korrekt, sondern auch praxistauglich werden, kannst du nach einem klaren Vorgehen arbeiten.

Bevor du zeichnest, solltest du beantworten:

Oft lohnt es sich, den Scope bewusst zu begrenzen, damit das Diagramm nicht überfrachtet wirkt. Für sehr große Systeme erstellst du besser mehrere Diagramme mit jeweils klarem Fokus.

Frage dich zunächst, wer mit dem System interagiert:

Typische Quellen dafür sind:

Schreibe zunächst alle Kandidaten auf, und konsolidiere dann ähnlich agierende Rollen, sodass du eine überschaubare Menge erhältst.

Als Nächstes überlegst du, welche fachlichen Ziele die Akteure mit Hilfe des Systems erreichen möchten. Du kannst dazu Fragen stellen wie:

Notiere zunächst alle Use Cases in Textform, und achte auf:

Wenn deine Liste zu grob oder zu fein wirkt, dann schneidest du Use Cases neu zu, bis sie von Lesern intuitiv verstanden werden.

Nun ziehst du die Systemgrenze, und du platzierst alle Use Cases innerhalb dieses Rahmens. Externe Systeme bleiben bewusst außerhalb, weil sie als Akteure auftreten.

Frage dich dabei:

Eine klar definierte Systemgrenze verhindert Missverständnisse, und sie erleichtert später auch die Definition von Schnittstellen.

Jetzt verbindest du Akteure und Use Cases mit Assoziationslinien, und du prüfst dabei:

Danach ergänzt du optionale Beziehungen:

Halte dich bewusst zurück, denn zu viele Spezialfälle machen dein Diagramm schwer lesbar. Details zu Sonderfällen beschreibst du oft besser in Fließtext oder in separaten Use-Case-Beschreibungen.

Zum Schluss solltest du das Diagramm gemeinsam mit Fachvertretern und Entwicklern sichten, damit alle ein gemeinsames Verständnis entwickeln. In dieser Phase lohnt sich insbesondere:

Ein gutes Use Case Diagramm ist prägnant, aber nicht überladen, und es lässt sich innerhalb weniger Minuten erklären.

Viele Use Case Diagramme sind formal korrekt, aber sie helfen in der Praxis nur wenig. Die folgenden Fehler treten besonders häufig auf, und du kannst sie durch einfache Regeln verhindern.

Ein sehr verbreiteter Fehler besteht darin, technische Aktivitäten als Use Cases zu modellieren, etwa:

Solche Begriffe verstehen Fachanwender kaum, und sie spiegeln auch kein echtes Nutzerziel wider. Du solltest stattdessen fachliche Ziele formulieren, sodass die Beteiligten sofort erkennen, warum ein Use Case existiert.

Manche Teams versuchen, alle möglichen Sonderfälle, Alternativpfade und Fehlerszenarien im Diagramm unterzubringen, doch das führt fast zwangsläufig zu Unübersichtlichkeit.

Stattdessen:

So behältst du die Lesbarkeit, und du kannst trotzdem ins Detail gehen, wenn es nötig ist.

Uneinheitliche Begriffe führen schnell zu Missverständnissen, weil Projektbeteiligte unterschiedliche Dinge hineininterpretieren. Du solltest daher:

Ein weiterer Klassiker besteht darin, reale Namen oder Jobtitel zu verwenden, etwa:

Stattdessen modellierst du Rollen, weil sich die Verantwortlichkeiten ändern können, während das System bestehen bleibt. So bleibt dein Diagramm stabil und länger gültig.

Damit deine Diagramme nicht nur formal richtig, sondern auch in der Praxis wertvoll sind, kannst du dich an einigen erprobten Best Practices orientieren.

Überlege immer zuerst, für wen du das Diagramm erstellst:

Passe Umfang und Detailtiefe an, denn ein einziges „One-size-fits-all“-Diagramm überzeugt selten alle Stakeholder.

Ein Diagramm ersetzt die textuelle Beschreibung eines Use Cases nicht, sondern ergänzt sie. Für zentrale Use Cases solltest du zusätzlich festhalten:

Diese Beschreibungen dienen später als Basis für Testfälle, Abnahmekriterien und Dokumentation, sodass du viel Konsistenz über das gesamte Projekt hinweg erreichst.

Erstelle Use Case Diagramme nicht im stillen Kämmerlein, sondern iterativ:

Dieser Zyklus sorgt dafür, dass sich ein gemeinsames Verständnis etabliert, und er verhindert, dass das Diagramm zur bloßen Formalie verkommt.

Obwohl UML die Notation recht klar vorgibt, lässt sie im Layout Spielraum. Du solltest diesen Spielraum nutzen, um die Lesbarkeit zu verbessern:

Ein aufgeräumtes Layout reduziert kognitive Last, sodass Betrachter sich auf Inhalte konzentrieren können, statt die Struktur erraten zu müssen.

Use Case Diagramme sind mehr als ein UML-Formalismus, denn sie fungieren als zentrales Kommunikationswerkzeug in der frühen Phase eines Projekts. Wenn du Akteure, Ziele und Systemgrenzen sauber herausarbeitest, erhältst du ein Modell, das:

Entscheidend ist, dass du Use Case Diagramme zielgruppenorientiert, pragmatisch und iterativ einsetzt. Dann entwickelst du nicht nur schöne Bilder, sondern schaffst echte Klarheit im Projekt – und genau das macht aus einer einfachen UML-Notation ein wirksames Werkzeug für deine tägliche Praxis.