Typische Modellierungsfehler beim Use Case Diagramm – Use-Case-Diagramme gehören zu den bekanntesten UML-Artefakten, doch in vielen Projekten liefern sie weniger Erkenntnisgewinn als möglich wäre, weil typische Modellierungsfehler ihre Aussagekraft untergraben. In diesem Artikel erfahren Sie, welche Fallstricke immer wieder auftreten, warum sie problematisch sind und wie Sie Ihre eigenen Diagramme deutlich verbessern.
Wozu Use-Case-Diagramme eigentlich dienen – und wozu nicht
Bevor wir über Fehler sprechen, lohnt sich ein kurzer Blick auf die Rolle von Use-Case-Diagrammen im Anforderungsprozess, denn viele Probleme entstehen bereits aus falschen Erwartungen.
Ein Use-Case-Diagramm soll:
- die fachlichen Ziele der Akteure sichtbar machen
- das Systemverhalten aus Nutzersicht strukturieren
- einen gemeinsamen Kommunikationsrahmen zwischen Fachbereich, Entwicklung und Test liefern
- als Einstiegspunkt für detaillierte Use-Case-Beschreibungen dienen
Ein Use-Case-Diagramm soll nicht:
- komplette Ablauflogik im Detail zeigen
- technische Architektur oder APIs dokumentieren
- Oberflächen-Layouts oder Navigationsstrukturen abbilden
Wenn Teams Use-Case-Diagrammen Aufgaben zuschreiben, die eher zu Aktivitätsdiagrammen, Sequenzdiagrammen oder UI-Prototypen passen, entstehen zwangsläufig Missverständnisse und Überfrachtung.
Häufige Modellierungsfehler im Überblick
Im Folgenden gehen wir Schritt für Schritt durch typische Fehler, die in der Praxis immer wieder auftreten. Zu jedem Punkt finden Sie Diagnosehinweise und konkrete Verbesserungsansätze.
1. Falsch gezogene Systemgrenze
Die Systemgrenze (das Rechteck im Diagramm) definiert, was „das System“ ist und was zur Umgebung gehört. Viele Diagramme leiden darunter, dass diese Grenze zu unscharf oder schlicht falsch gezogen ist.
Typische Symptome:
- Akteure tauchen innerhalb des Systemrechtecks auf.
- Externe Systeme erscheinen als Use Cases anstatt als Akteure.
- Fachliche Funktionen, die eigentlich von anderen Systemen übernommen werden, landen im eigenen System.
Warum das problematisch ist:
Eine falsche Systemgrenze führt zu falschen Erwartungen an Verantwortlichkeiten und damit zu späteren Integrationsproblemen. Stakeholder glauben, das System übernehme Aufgaben, die in Wahrheit extern bleiben sollen, oder umgekehrt.
Wie Sie es besser machen:
- Formulieren Sie vor der Modellierung in einem Satz, was Ihr System leisten soll:
„Das System XY unterstützt [Zielgruppe] bei [Kernaufgabe]…“ - Leiten Sie daraus ab, welche Funktionen innerhalb liegen und welche als externe Umwelt zu modellieren sind.
- Repräsentieren externe Systeme im Diagramm immer als Akteure, nicht als Use Cases.
Wenn Sie die Systemgrenze bewusst entscheiden und dokumentieren, vermeiden Sie lange Diskussionen in späteren Projektphasen.
2. Akteure zu technisch oder fachlich unscharf
Akteure repräsentieren Rollen, die mit dem System interagieren, nicht konkrete Personen oder technische Komponenten. Trotzdem sieht man oft:
- „Datenbank“, „Microservice A“ oder „Webserver“ als Akteur
- konkrete Mitarbeiter-Namen („Herr Müller“) statt Rollen („Sachbearbeiter“)
- Duplikate wie „Kunde“, „Endkunde“ und „User“, obwohl sie dasselbe meinen
Warum das problematisch ist:
Zu technische Akteure vernebeln die fachliche Sicht und erschweren die Kommunikation mit dem Business. Gleichzeitig machen unsaubere Rollenbegriffe die spätere Rechte- und Aufgabentrennung unnötig kompliziert.
Besser so:
- Benennen Sie Akteure immer als Rolle, z. B. „Sachbearbeiter“, „Administrator“, „Externer Zahlungsdienstleister“.
- Verwenden Sie für Systeme als Akteur deren Systemnamen, allerdings immer mit klarem Bezug zur Rolle (z. B. „ERP-System“, „Zahlungsgateway“).
- Konsolidieren Sie ähnliche Rollen, sodass jede Rolle eine klare, unterscheidbare Verantwortung hat.
Diskutieren Sie die Akteursliste bewusst mit Fach- und IT-Vertretern, denn oft liegen hier schon wichtige fachliche Entscheidungen verborgen.
3. Use Cases als technische Funktionen statt fachliche Ziele
Ein sehr verbreiteter Fehler besteht darin, Use Cases mit technischen Funktionen oder GUI-Aktionen zu verwechseln. Aussagen wie:
- „Button klicken“
- „CSV exportieren“
- „REST-Service aufrufen“
sind keine sinnvollen Use Cases.
Kernprinzip:
Ein Use Case beschreibt ein fachliches Ziel eines Akteurs – also das Warum, nicht das Wie.
Schlechte Beispiele:
- „Login-Formular anzeigen“
- „Datei auf Server speichern“
Bessere Alternativen:
- „Benutzer authentifizieren“
- „Vertrag archivieren“
Sofern Sie sich konsequent auf fachliche Ziele fokussieren, gewinnen Sie Klarheit über den eigentlichen Nutzen des Systems, und Sie lösen sich von Details, die sich im Projektverlauf häufig noch ändern.
4. Zu grobe oder zu feine Granularität
Ein weiteres typisches Problem: Use Cases sind entweder so groß, dass sie kaum noch greifbar sind, oder so klein, dass das Diagramm explodiert.
Anzeichen für zu grobe Use Cases:
- Ein einzelner Use Case deckt den kompletten End-to-End-Prozess über viele Abteilungen hinweg ab.
- Die Use-Case-Beschreibung würde Dutzende von Seiten umfassen, wenn man sie sauber ausschreibt.
Anzeichen für zu feine Use Cases:
- Für jede Kleinigkeit existiert ein eigener Use Case, z. B. „Artikel suchen“, „Artikel auswählen“, „Artikel in den Warenkorb legen“, „Warenkorb anzeigen“.
- Das Diagramm wird unübersichtlich, obwohl der fachliche Umfang überschaubar ist.
Pragmatische Leitlinie:
- Ein einzelner Use Case sollte ein klares, von den Stakeholdern erkennbares Ergebnis liefern.
- Wenn Sie sich fragen müssen, ob Fachanwender diesen Use Case überhaupt als eigenständiges Ziel wahrnehmen, ist er vermutlich zu fein.
- Wenn Sie den Use Case kaum noch präzise benennen können, weil er „alles Mögliche“ umfasst, ist er zu grob.
Häufig hilft es, mit einer grobgranularen Sicht zu beginnen und später gezielt zu verfeinern, wenn Sie merken, dass einzelne Teile sehr komplex werden.
5. Missbrauch von «include» und «extend»
Die Beziehungen «include» und «extend» sorgen regelmäßig für Verwirrung, weil sie auf den ersten Blick ähnlich wirken, aber unterschiedliche Zwecke haben.
Typische Fehlanwendungen:
- «include» wird genutzt, um eine bloße Schrittfolge darzustellen.
- «extend» wird verwendet, um jede Art von Bedingung abzubilden.
- Die Beziehungen entstehen, weil „man sie halt mal verwenden wollte“, nicht weil sie fachlich sinnvoll sind.
Richtige Verwendung in Kurzform:
- «include»:
- Mehrere Use Cases nutzen denselben obligatorischen Teilablauf.
- Dieser Teilablauf hat eigenständige fachliche Bedeutung.
- Beispiel: „Identität prüfen“ kann in „Konto eröffnen“ und in „Kredit beantragen“ inkludiert sein.
- «extend»:
- Ein Use Case beschreibt eine optionale Erweiterung eines Basisszenarios.
- Die Erweiterung tritt nur unter bestimmten Bedingungen auf.
- Beispiel: „Zusätzliche Bonitätsprüfung durchführen“ erweitert „Kredit beantragen“, wenn der Betrag einen Schwellenwert überschreitet.
Nutzen Sie diese Beziehungen also sparsam und nur dann, wenn sie wirklich helfen, Gemeinsamkeiten oder optionale Ergänzungen strukturiert zu zeigen.
6. UI-Elemente und technische Details im Use-Case-Diagramm
Ein sehr häufiges Problem: Use-Case-Diagramme mutieren zu UI-Skizzen, weil Modellierer Bedienelemente, Masken oder Navigationsschritte aufnehmen.
Typische Fehlformen:
- Use Cases wie „Suchmaske öffnen“, „Filter setzen“, „Tab wechseln“.
- Kommentare im Diagramm, die konkrete Buttons oder Felder benennen.
Folge:
Das Diagramm altert extrem schnell, sobald sich das UI ändert, und es verliert seinen Wert als langfristig gültiges Fachmodell.
Empfehlung:
- Trennen Sie konsequent fachliche Ziele (Use Cases) und Bedienabläufe (UI-Design, Prototypen, Storyboards).
- Verweisen Sie ggf. aus Use-Case-Beschreibungen auf UI-Skizzen, aber halten Sie das Diagramm selbst frei von UI-Details.
So bleibt das Use-Case-Diagramm auch dann nützlich, wenn Sie das UI später neu gestalten oder Plattformen wechseln.
7. Inkonsistenz zwischen Diagramm und Use-Case-Beschreibungen
Ein gutes Use-Case-Diagramm dient als Übersicht, und die dazugehörigen textuellen Use-Case-Beschreibungen liefern die Tiefe. In vielen Projekten entwickeln sich beide jedoch voneinander weg.
Typische Diskrepanzen:
- Use Cases im Diagramm, für die es keine Beschreibung gibt.
- Beschriebene Use Cases, die im Diagramm fehlen.
- Unterschiedliche Benennungen oder leicht variierte Begriffe für denselben Use Case.
Warum das gefährlich ist:
Stakeholder vertrauen entweder dem Diagramm oder den Texten – und sind uneins, welcher Stand „gültig“ ist. Das schwächt das Vertrauen in die Anforderungsdokumentation insgesamt.
So stellen Sie Konsistenz sicher:
- Führen Sie eine gemeinsame Quelle der Wahrheit, z. B. eine Tabelle oder ein Backlog, in der jeder Use Case mit ID, Name und Status geführt wird.
- Synchronisieren Sie Diagramm und Texte bei Änderungen bewusst, nicht „irgendwann später“.
- Benutzen Sie möglichst Werkzeugunterstützung, damit Diagramm-Elemente direkt mit Beschreibungen verknüpft sind.
8. Überladene, unlesbare Diagramme
Selbst fachlich korrekte Diagramme können scheitern, wenn sie zu vollgestopft sind. Viele Teams versuchen, alle Use Cases und alle Akteure in ein einziges Großdiagramm zu pressen.
Erkennungsmerkmale:
- Mehr als zehn bis zwölf Akteure im selben Diagramm.
- Linienkreuze, überlappende Beziehungen, kaum lesbare Bezeichnungen.
- Neue Stakeholder verstehen das Diagramm nur mit langer Erklärung.
Konsequenz:
Was eigentlich ein Kommunikationsinstrument sein soll, wird zum abschreckenden Poster, das niemand freiwillig interpretiert.
Besser: Modularisieren
- Erstellen Sie kontextbezogene Sichten, z. B. pro Fachbereich oder pro Hauptakteur.
- Nutzen Sie Package-Diagramme oder einfache logische Gruppen, um Use Cases zu clustern.
- Verwenden Sie sprechende Layouts: wichtige Use Cases zentral, verwandte Use Cases in räumlicher Nähe.
Ein etwas längerer Satz an Diagrammen ist meist deutlich verständlicher als ein einziges „Monsterdiagramm“.
Wie Sie Modellierungsfehler systematisch vermeiden
Einzelne Tipps helfen, doch wirkliche Qualität entsteht, wenn Sie einen klaren Prozess für die Modellierung etablieren.
1. Klare Modellierungsziele definieren
Bevor Sie das erste Symbol ziehen, beantworten Sie gemeinsam:
- Wer soll das Diagramm nutzen (Fachabteilung, Architektur, Test, Management)?
- Welche Fragen soll das Diagramm beantworten?
- Welche Details gehören in andere Artefakte (User Stories, Aktivitätsdiagramme, UI-Prototypen)?
Wenn Sie diese Fragen sauber klären, entscheiden Sie viel leichter, was ins Use-Case-Diagramm gehört und was nicht.
2. Gemeinsames Vokabular festlegen
Uneinheitliche Begriffe erzeugen Missverständnisse, deshalb sollten Sie früh ein gemeinsames Glossar etablieren:
- zentrale Rollenbegriffe (Akteure)
- Kernobjekte der Domäne (Vertrag, Auftrag, Ticket, Konto …)
- fachliche Prozessnamen
Dieses Vokabular verwenden Sie konsequent in Diagrammen und Beschreibungen, sodass sich Leser schneller zurechtfinden.
3. Iterativ arbeiten statt Perfektion erzwingen
Use-Case-Diagramme profitieren stark von iterativer Verfeinerung:
- Grobe Skizze mit den wichtigsten Akteuren und 5–10 Kern-Use-Cases.
- Gemeinsame Review-Runde mit Fachbereich und Entwicklung.
- Identifizierte Lücken oder Unschärfen gezielt nachmodellieren.
- Erst danach über include/extend und Verfeinerungen nachdenken.
Wenn Sie diesen Prozess mehrfach durchlaufen, wächst das Diagramm organisch, und Sie vermeiden „Overengineering“ beim ersten Wurf.
4. Qualität regelmäßig prüfen – mit einer Checkliste
Nutzen Sie für jedes Use-Case-Diagramm eine kurze Qualitätscheckliste, zum Beispiel:
- Ist die Systemgrenze klar und plausibel?
- Sind alle Akteure Rollen und keine Personen oder technischen Komponenten?
- Beschreibt jeder Use Case ein fachliches Ziel eines Akteurs?
- Ist die Granularität der Use Cases in sich konsistent?
- Sind «include» und «extend» sparsam und korrekt eingesetzt?
- Gibt es Redundanzen oder Use Cases ohne erkennbaren Mehrwert?
- Passt das Diagramm in ein bis zwei Seiten, ohne unlesbar zu wirken?
Solche Fragen kosten nur wenige Minuten, sie verbessern jedoch die Qualität so deutlich, dass sie sich praktisch immer lohnen.
Fazit Typische Modellierungsfehler beim Use Case Diagramm: Gute Use-Case-Diagramme sind bewusst einfach
Use-Case-Diagramme wirken auf den ersten Blick einfach, doch genau darin liegt die Gefahr: Man zeichnet schnell etwas hin, ohne die zugrunde liegenden Entscheidungen klar zu treffen. Die meisten typischen Modellierungsfehler – falsche Systemgrenzen, technische Akteure, unpassende Granularität, übermäßige Detailverliebtheit – entstehen aus fehlender Klarheit über Zweck, Zielgruppe und fachliche Sicht.
Wenn Sie:
- die Systemgrenze bewusst festlegen,
- Akteure als Rollen verstehen,
- Use Cases konsequent als fachliche Ziele formulieren,
- Beziehungen wie «include» und «extend» gezielt und sparsam nutzen,
- Diagramme modular strukturieren und mit Beschreibungen verknüpfen,
dann gewinnen Ihre Use-Case-Diagramme erheblich an Aussagekraft. Sie werden nicht nur für Architekten und Analysten wertvoll, sondern auch für Fachbereiche, Tester und Entscheider, die eine schnelle, verständliche Übersicht benötigen.