Read this post in: en_USes_ESfr_FRhi_INid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

Umfassender Leitfaden zum Erstellen von Use-Case-Diagrammen

🔍 Übersicht

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.


🔑 Wichtige Konzepte

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.


🚀 Schritt-fĂŒr-Schritt-Prozess zum Erstellen eines Use-Case-Diagramms

Schritt 1: Akteure identifizieren

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


Schritt 2: NutzungsfÀlle identifizieren

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.


Schritt 3: AnwendungsfÀlle auf verschiedenen Ebenen organisieren

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:

  1. Beginnen Sie mit hochwertigen GeschÀftszielen.

  2. Teilen Sie sie in Teilziele auf.

  3. 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.


Schritt 4: Erstellen des Use-Case-Diagramms

Platzieren Sie nun Akteure und Use Cases auf dem Diagramm und verbinden Sie sie angemessen.

Diagrammstruktur:

[Akteur] --> [Use-Case]
    ↑
[Einbeziehung]     [Erweiterung]
    ↓
[AbhÀngigkeit]

Regeln zum Zeichnen des Diagramms:

  • 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:

 


đŸš« HĂ€ufige Fallen und wie man ihnen aus dem Weg geht

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

✅ Best Practices fĂŒr eine effektive Use-Case-Modellierung

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.

📚 Quellen und weiterfĂŒhrende Literatur

  • [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


📝 Beispiel: Use-Case-Diagramm fĂŒr ein Bibliotheks-Verwaltungssystem

Akteure:

  • Mitglied

  • Bibliothekar

  • Administrator

  • Online-Katalog-System

  • Zahlungsgateway

Use Cases:

  • 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

Beziehungen:

  • 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.


đŸ§© Endkontrolle vor Abschluss des Diagramms

✅ 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?


🏁 Fazit

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.

Sidebar Search
Loading

Signing-in 3 seconds...

Signing-up 3 seconds...