Use-Case-Diagramm

• grafische Darstellung

• Verwendung Softwareentwicklung

• dient der Visualisierung von funktionalen Anforderungen eines Systems/einer Anwendung

• Zeigt, wie Akteure (Benutzer oder externe Systeme) mit verschiedenen Anwendungsfällen (Use Cases) interagieren

Akteure:

• externe Entitäten wie Benutzer oder andere Systeme, die mit dem System interagieren.

Use Cases:

• repräsentieren einzelne Funktionen oder Interaktionen, die das System ausführen kann

Beziehungen zwischen Akteuren und Use Cases:

• Es gibt verschiedene Arten von Beziehungen

• Primary Actor (initiates): "Akteur initiiert Use Case" (zeigt, welche Use Cases von einem Akteur ausgelöst werden können)

• Secondary Actor (reactionary): "Akteur kommuniziert mit Use Case" (zeigt, dass ein Akteur mit einem Use Case interagiert).

Assoziationen:

• zeigen, wie Use-Cases verbunden sind

• Include: Ausführung von Base-Use-Case verspricht die Ausführung von Included-Use-Case

• Extend: Ausführung von Base-Use-Case verspricht keine Ausführung der Extend-Use-Case. Extend-Use-Case wird erst ausgeführt, wenn bestimmte Kriterien erreicht wurden.

Systemgrenze:

• Linie, die das System von seiner Umgebung trennt und den Bereich zeigt, in dem die Interaktionen stattfinden

• verschiedenen Teammitgliedern, abhängig von der Rolle und den Fähigkeiten jedes Mitglieds.

• Business-Analysten, Entwicklern, Product Ownern oder sogar im Rahmen von kollaborativen Workshops vom gesamten agilen Team durchgeführt werden

Ziel ist es, sicherzustellen, dass das Diagramm die Funktionalitäten klar und präzise darstellt und als Grundlage für die Anforderungsdefinition und -priorisierung dient

Entwickler:

• verwenden das Diagramm, um zu verstehen, welche Funktionen das System bereitstellen muss und wie die Interaktionen zwischen den Akteuren und Use Cases ablaufen

Business-Analysten:

• nutzen das Diagramm, um die Anforderungen der Benutzer zu erfassen und zu analysieren, um sicherzustellen, dass das System ihre Bedürfnisse erfüllt

Product Owner:

• verwendet das Diagramm, um die Funktionen zu priorisieren und sicherzustellen, dass die Anforderungen des Kunden im Fokus bleiben

Benutzer:

• können das Diagramm verwenden, um einen Überblick über die Funktionalitäten des Systems und ihre Interaktionen damit zu erhalten.

Klarheit und Einfachheit:

• Das Diagramm sollte einfach und verständlich sein, um Missverständnisse zu vermeiden.

Vollständigkeit:

• Alle relevanten Akteure und Use Cases sollten erfasst werden, um eine umfassende Übersicht zu bieten.

Konsistenz:

• Die Beziehungen zwischen Akteuren und Use Cases sollten logisch und konsistent sein.

Relevanz:

• Nur diejenigen Use Cases sollten enthalten sein, die für das Verständnis der Funktionalitäten wirklich wichtig sind.

Anpassungsfähigkeit:

• Das Diagramm sollte flexibel genug sein, um Änderungen und Iterationen im Entwicklungsprozess aufzunehmen.