Ein Use-Case-Diagramm ist ein grundlegendes Modellierungswerkzeug in Anforderungstechnik zur Visualisierung der Interaktionen zwischen Aktoren (Nutzer oder externe Systeme) und dem System (oder seinen FunktionalitĂ€ten). Es hilft den Stakeholdern, zu verstehen, was das System aus funktionaler Sicht leisten muss, und dient als KommunikationsbrĂŒcke zwischen technischen Teams und GeschĂ€ftsanwendern.
Trotz seiner Einfachheit wird das Use-Case-Diagramm hĂ€ufig falsch angewendet aufgrund schlechter Aktorenidentifikation, unklarer Use-Cases oder falscher Beziehungen. Dieser Leitfaden soll die wichtigen Konzepte, bietet eine Schritt-fĂŒr-Schritt-Methode, und hebt hĂ€ufige Fehlerquellen zur Vermeidung hervor.
| Konzept | ErklÀrung |
|---|---|
| Aktor | Ein menschlicher Nutzer, eine Organisation oder ein externes System, das mit dem System interagiert. Funktioniert als âNutzerâ im Kontext des Systems. Beispiele: SchĂŒler, Lehrer, Administrator, Zahlungsgateway. |
| Use-Case | Eine Beschreibung eines spezifischen Ziels oder einer Funktion, die das System fĂŒr einen Aktor erfĂŒllt. Definiert, was was das System tut, nicht wie. Beispiele: âFĂŒr einen Kurs anmeldenâ, âNoten einreichenâ, âBericht generierenâ. |
| Systemgrenze | Die Grenze, die das System von externen Akteuren und Systemen trennt. Alles innerhalb der Grenze ist Teil des Systems. |
| Assoziation | Eine Linie, die einen Akteur mit einem Use Case verbindet, was darauf hinweist, dass der Akteur diesen Use Case ausfĂŒhren kann. |
| Generalisierung | Eine Beziehung, bei der ein Akteur Verhaltensweisen von einem anderen erbt (z.âŻB. âStudentâ ist eine Art von âBenutzerâ). |
| AbhÀngigkeit | Eine Beziehung, die darauf hinweist, dass ein Use Case von einem anderen abhÀngt (e |
| g., âBericht generierenâ hĂ€ngt von âStudentendaten abrufenâ ab). | |
| Einbeziehen | Ein Use Case, dererforderlichist, damit ein anderer ausgefĂŒhrt werden kann (z.âŻB. âNoten einreichenâ beinhaltet âStudenten-ID ĂŒberprĂŒfenâ). |
| Erweitern | Ein Use Case, derbedingtFunktionalitĂ€t hinzufĂŒgt (z.âŻB. âBenachrichtigung sendenâ erweitert âNoten einreichenâ, wenn die Noten unter der Schwelle liegen). |
â ïžÂ Wichtiger Hinweis: Use Cases sind nicht ĂŒberFunktionenâ sie handeln vonfunktionellen Zielendie BenutzerbedĂŒrfnisse erfĂŒllen.
Stellen Sie sich diese zentralen Fragen, um alle relevanten Akteure zu identifizieren:
| Frage | Warum es wichtig ist |
|---|---|
| Wer nutzt die HauptnutzungsfĂ€lle? | Identifiziert primĂ€re Nutzer (z.âŻB. Studierende, Professoren). |
| Wer benötigt UnterstĂŒtzung fĂŒr die tĂ€gliche Arbeit? | Identifiziert UnterstĂŒtzungsrollen (z.âŻB. HR-Mitarbeiter, IT-UnterstĂŒtzung). |
| Wer ist fĂŒr die Systemadministration verantwortlich? | Identifiziert Administratorenrollen (z.âŻB. Systemmanager, Datenbankadministrator). |
| Mit welchen externen GerĂ€ten/Software-Systemen interagiert das System? | Identifiziert externe Systeme (z.âŻB. E-Mail, Zahlungsgateway, ERP). |
| Wer hat ein Interesse an den Ergebnissen des Systems? | Identifiziert Beteiligte (z.âŻB. Eltern, Vorstandsmitglieder). |
đ Tipp: Beginnen Sie mit den kritischsten Nutzern und erweitern Sie nach auĂen. Verwenden Sie realistische Szenarien oder Interviews, um die Identifizierung der Akteure zu ĂŒberprĂŒfen.
đĄ Beispiel: In einem Studentenverwaltungssystem einer UniversitĂ€t, könnten Akteure beinhalten:
Student
Hochschullehrer
Akademischer Berater
Verwaltungsmitarbeiter
Zahlungsgateway
ERP-System
Sobald die Akteure identifiziert sind, stellen Sie die folgenden Fragen zu jedem Akteur:
| Frage | Zweck |
|---|---|
| Welche Hauptaufgaben muss ein Akteur ausfĂŒhren? | Identifiziert funktionale Ziele (z.âŻB. anmelden, einschreiben, Noten anzeigen). |
| Will der Akteur Daten im System abfragen oder Ă€ndern? | Weist auf Lese-/SchreibvorgĂ€nge hin (z.âŻB. DatensĂ€tze anzeigen, Profil bearbeiten). |
| Will der Akteur das System ĂŒber Ănderungen in anderen Systemen informieren? | Deutet auf ereignisgesteuerte Auslöser hin (z.âŻB. System benachrichtigen, wenn ein Kurs hinzugefĂŒgt wird). |
| Soll der Akteur ĂŒber unerwartete Ereignisse informiert werden? | Weist auf BenachrichtigungsanwendungsfĂ€lle hin (z.âŻB. âWarnung: KursĂŒberlastung erkanntâ). |
đ Verwenden Sieeinfache, zielorientierte Sprache. Vermeiden Sie technische Begriffe.
â Guter Anwendungsfall: âIn einen Kurs einschreibenâ
â Schlechter Anwendungsfall: âAnmeldeformular mit Validierung absendenâ â wird zu technisch.
AnwendungsfÀlle können auf verschiedenen Ebenen modelliert werden:
| Ebene | Beschreibung |
|---|---|
| Höchstebenen-AnwendungsfĂ€lle | Breite funktionale Ziele, die GeschĂ€ftsziele widerspiegeln (z.âŻB. âStudentenakten verwaltenâ). |
| Verfeinerte AnwendungsfÀlle | Detaillierte Aktionen, abgeleitet von oberen Zielsetzungen. |
đ Iterativer Entwicklungsansatz:
Beginnen Sie mit hochwertigen GeschÀftszielen.
Teilen Sie sie in Teilziele auf.
Verfeinern Sie jeden Anwendungsfall, bis er spezifisch und umsetzbar ist.
đ Beispielhafte Aufteilung:
Höchstebene: âUnterstĂŒtzung der Studentenverwaltungâ
Verfeinerung:
Student kann sich anmelden
Student kann sich fĂŒr Kurse anmelden
Das System speichert Noten
Das System sendet eine BestÀtigung der Anmeldung
Dies stellt sicher, dass das System erfĂŒllt GeschĂ€ftsziele wĂ€hrend es bleibt praktisch und testbar.
Platzieren Sie nun Akteure und Use Cases auf dem Diagramm und verbinden Sie sie angemessen.
[Akteur] --> [Use-Case]
â
[Einbeziehung] [Erweiterung]
â
[AbhÀngigkeit]
Platzieren Sie Akteure auĂerhalb der Systemgrenze (typischerweise links/rechts/oben).
Platzieren Sie Use Cases innerhalb der Systemgrenze (Mitte oder unten).
Verwenden Sie feste Linien fĂŒr Assoziationen.
Verwenden Sie gestrichelte Linien fĂŒr AbhĂ€ngigkeiten.
Verwenden Sie Einbeziehungspfeile (â) fĂŒr Einbeziehung Beziehungen.
Verwenden Sie Erweiterungspfeile (â) fĂŒr erweitern Beziehungen.
Vermeiden Sie ĂŒberlappende AnwendungsfĂ€lle; halten Sie das Diagramm ĂŒbersichtlich und lesbar.
đ Visuelles Beispiel (textbasiert):
+------------------+
| Student | --> Einschreiben in Kurs
+------------------+
|
v
+------------------+
| System | --> Speichern von Kursanmeldungen
| (Grenze) |
+------------------+
^
|
+------------------+
| Zahlungsgateway| --> Bearbeiten der GebĂŒhrenzahlung
+------------------+
đš HĂ€ufiger Fehler: Zeichnen von Akteuren innerhalb der Systemgrenze â dies suggeriert, dass sie Teil des Systems sind, was nicht der Fall ist.

Dieses Diagramm wurde von der Visual Paradigm AI Chatbot generiert:

Â
| Falle | Warum es falsch ist | Wie man es behebt |
|---|---|---|
| đ«Â Akteure zu kompliziert gestalten | Zu viele Akteure erstellen (z.âŻB. âJohn Doeâ, âSarah Smithâ) anstatt Rollen zu gruppieren | Ăhnliche Rollen gruppieren (z.âŻB. âStudentâ, âMitarbeiterâ) |
| đ«Â Vage AnwendungsfĂ€lle verwenden | Phrasen wie âDaten verwaltenâ, âetwas tunâ | Ersetzen durch spezifische, zielgerichtete Phrasen (z.âŻB. âKursanmeldung einreichenâ) |
| đ«Â Fehlende AbhĂ€ngigkeiten | Nicht zeigen, wie ein Anwendungsfall von einem anderen abhĂ€ngt | FĂŒgen Sie hinzu einbeziehen oder erweitern Beziehungen, wenn nötig |
| đ«Â Falscher Gebrauch von âerweiternâ | Verwenden von erweiternfĂŒr normale ArbeitsablĂ€ufe |
Verwenden Sie enthaltenfĂŒr obligatorische Schritte; verwenden Sie erweiternnur fĂŒr optionale, bedingte |
| đ«Â Ignorieren externer Systeme | Ohne Zahlungsgateways, E-Mail usw. | Identifizieren Sie alle externen Systeme und zeigen Sie ihre Interaktionen |
| đ«Â Verwenden Sie nur einen Akteur | Annahme, dass nur ein Benutzer das System nutzt | Identifizieren Sie alle Beteiligten und ihre BedĂŒrfnisse |
| đ«Â Verwendung von Fachjargon | z.âŻB. âDatenbank aktualisierenâ, âAPI aufrufenâ | Bleiben Sie bei funktionalen Verhaltensweisen â âAntrag einreichenâ ist besser |
| Praxis | ErklÀrung |
|---|---|
| â Beginnen Sie mit den GeschĂ€ftszielen | Modellieren Sie von oben nach unten â richten Sie sich nach strategischen Zielen. |
| â Beteiligen Sie Beteiligte frĂŒh | FĂŒhren Sie Interviews mit Endbenutzern oder Fachexperten durch, um Use-Cases zu validieren. |
| â Halten Sie Use-Cases unabhĂ€ngig | Jeder Use-Case sollte ein eindeutiges, klares Ziel darstellen. |
| â Verwenden Sie realistische Szenarien | Basis fĂŒr Use-Cases sind tatsĂ€chliche BenutzeraktivitĂ€ten (z.âŻB. ein Student, der sich fĂŒr eine Klasse anmeldet). |
| â Mit dem Team ĂŒberprĂŒfen | Das Diagramm mit Entwicklern, Testern und Business-Analysten ĂŒberprĂŒfen. |
| â Iterativ aktualisieren | Wenn die Anforderungen sich weiterentwickeln, verfeinere das Diagramm in kleineren Zyklen. |
| â Verwende Use Cases detailliert dokumentieren | EnthĂ€lt Vorbedingungen, Nachbedingungen und Erfolgs-/Fehlversuchs-Kriterien in einem separaten Dokument. |
[30] Anforderungswesen â Grundlegendes Werk zum Use-Case-Modellieren.
[27] Identifizierung von Use Cases in Software-Anforderungen â Praktische Methoden zur Ableitung von Use Cases aus Akteuren.
[16, 40]Â â Umfassende Literatur zum Anforderungswesen und Systemdesign.
IEEE/ISO-Standards: ISO/IEC 29148 â Leitlinien fĂŒr die Use-Case-Spezifikation.
Empfohlene BĂŒcher:
Software-Anforderungen: Es richtig machen beim ersten Mal von Ian Sproul
Der einheitliche Softwareentwicklungsprozess (RUP)Â â EinfĂŒhrung in das Use-Case-Modellieren in UML
Mitglied
Bibliothekar
Administrator
Online-Katalog-System
Zahlungsgateway
Mitglied:
Ein Buch ausleihen
Ein Buch zurĂŒckgeben
BĂŒcher suchen
Mitgliedsstatus anzeigen
Bibliothekar:
BĂŒcher ausleihen
BĂŒcher zurĂŒckgeben
Buchdaten aktualisieren
ĂberfĂ€llige Liste generieren
Administrator:
Neue BĂŒcher hinzufĂŒgen
Benutzerkonten verwalten
Jahresbericht generieren
Online-Katalogsystem:
BĂŒcher suchen
Mitglied ĂŒber neue AnkĂŒnfte benachrichtigen
Zahlungsgateway:
BuĂgelder bearbeiten
VerlĂ€ngerungsgebĂŒhren bearbeiten
Mitglied â Ausleihen â Enthalten â ZurĂŒckgeben
Bibliothekar â Ausleihen â VerlĂ€ngern â Erinnerung senden (falls ĂŒberfĂ€llig)
Administrator â Buch hinzufĂŒgen â Enthalten â Katalog aktualisieren
Dieses Diagramm zeigt deutlich, wer was tut, was sie tun können und wie die Systeme miteinander interagieren.
â
Habe ich alle relevanten Akteure identifiziert?
â
Sind die AnwendungsfÀlle beschreibend und zielorientiert?
â
Sind alle Akteure mit mindestens einem Anwendungsfall verbunden?
â
Sind die AbhÀngigkeiten (Einbeziehen/Erweitern) korrekt modelliert?
â
Gibt es fehlende Akteure oder AnwendungsfÀlle?
â
Ist das Diagramm leicht zu lesen und zu verstehen?
â
Habe ich es mit den Stakeholdern ĂŒberprĂŒft?
Erstellen eines Anwendungsfalldiagramms ist mehr als nur Linien und KĂ€stchen zeichnen â es ist ein strategischer Prozess der tiefes VerstĂ€ndnis der BenutzerbedĂŒrfnisse, Klarheit in der Sprache, und Aufmerksamkeit fĂŒr Details.
Obwohl das Diagramm einfach erscheint, Missbrauch von Akteuren und AnwendungsfĂ€llen fĂŒhrt zu schlechtem Systemdesign, verpassten Anforderungen und frustrierten Benutzern. Indem Sie die Schritte in diesem Leitfaden befolgen â Akteure durch realweltbezogene Fragen identifizieren, AnwendungsfĂ€lle aus den BedĂŒrfnissen der Akteure ableiten und hĂ€ufige Fallstricke vermeiden â können Sie genaue, umsetzbare und an Stakeholder ausgerichtete Anwendungsfalldiagramme erstellen.
â Denken Sie daran: Ein gutes Anwendungsfalldiagramm erzĂ€hlt eine Geschichte â die Geschichte davon, wie Benutzer mit dem System interagieren, um ihre Ziele zu erreichen.