Antwort.

Geschichte der Frage:

Das Auftreten und die Entwicklung der Methodik zur Beschreibung von Systemen mithilfe von Anwendungsfällen sind mit der Notwendigkeit eines einheitlichen und verständlichen Weges verbunden, um Geschäftslogik und Benutzer-Szenarien für komplexe Lösungen festzuhalten. Die UML-Sprache hat die Anwendungsfalldiagramme als Standard populär gemacht, was die Transparenz der Kommunikation zwischen Entwicklern, Geschäft und Analysten erhöht hat.

Problem:

In echten Projekten reicht es oft nicht aus, einfach ein Diagramm zu zeichnen — es muss die Vollständigkeit der Anforderungen sichergestellt, die Konsistenz zwischen den Szenarien gewährleistet und bis ins Detail auf die Schritte des Akteurs und des Systems eingehen werden. Große Systeme haben Hunderte von Variationen, Alternativen und Fehlern, was dazu führt, dass es „weiße Flecken“ und Kollisionen gibt.

Lösung:

Der Systemanalytiker muss eine Liste von Benutzern und Rollen erstellen, deren Ziele umfassend beschreiben, die Haupt- und Alternativereignisströme identifizieren, Annahmen klar festhalten und Alternativen zur Fehlerbehandlung einplanen. Hierfür werden Szenarientabellen, Diagramme, Prioritätsattribute sowie Review-Tools zwischen den Stakeholdern verwendet.

Schlüsselmerkmale:

Formalisierung von Szenarien und deren Reihenfolge.
Manuelle und automatische Überprüfung der Szenarien auf Vollständigkeit und Überschneidungen.
Detaillierung auf der Ebene von mindestens einer Interaktion „Akteur — System“.

Fangfragen.

Kann man sich auf das Hauptszenario beschränken und alternative Ströme ignorieren?

Nein, das Ignorieren von alternativen und Ausnahmeflüssen führt zu unvollständigen Szenarien und hohen Fehlerrisiken bei der Umsetzung.

Reicht es aus, nur die Schnittstelleninteraktionen zu bearbeiten, während interne Systemaktionen ausgelassen werden können?

Nein, das Fehlen von Details zu den Systemaktionen (zum Beispiel „Daten werden validiert“ ohne Erläuterung der Bedingungen) kann zu Missverständnissen und Mehrdeutigkeiten bei der Umsetzung führen.

Ist es immer ratsam, alle Szenarien in einem einzigen Use Case-Dokument zu beschreiben, um Zeit zu sparen?

Nein, übermäßige Aggregation von Szenarien verringert die Lesbarkeit und erschwert das Testen und die Anforderungsunterstützung.

Typische Fehler und Anti-Patterns

Beschreibung nur idealer Pfade (Happy Path) ohne Berücksichtigung von Fehlern.
Fokussierung auf die Benutzeroberfläche anstelle der Geschäftslogik.
Unbegründete Zusammenfassung komplexer Szenarien in eine Entität.

Beispiel aus dem Leben

Negativer Fall: Nur die Hauptströme (Happy Path) beschrieben, Zahlungsverfehlungen in einem E-Commerce-System nicht berücksichtigt.

Vorteile:

Schnelle Abstimmung

Nachteile:

Massenfehler in der Produktion bei fehlerhaften Zahlungen
Teure Nachbesserungen

Positiver Fall: Use Cases sind mit Verzweigungen — Alternativen, Fehlern, Stornierungen, Grenzfällen — ausgearbeitet.