Die Anforderungsingenieurwesen bildet die Grundlage jedes erfolgreichen Softwareprojekts. Unter den verschiedenen verfügbaren Techniken bleibt die Use-Case-Beschreibung eine der effektivsten Methoden, um funktionale Anforderungen aus Sicht des Benutzers zu erfassen. Eine gut verfasste Use-Case verbindet die Lücke zwischen geschäftlichen Anforderungen und technischer Umsetzung und stellt sicher, dass alle Stakeholder eine einheitliche Vorstellung über das Systemverhalten haben.
Allerdings führt die Mehrdeutigkeit in diesen Beschreibungen oft zu Entwicklungsfehlern, Scope-Creep und Testversagen. Dieser Leitfaden bietet einen strukturierten Ansatz zur Erstellung präziser, handlungsorientierter Use-Case-Beschreibungen unter Verwendung der Unified Modeling Language (UML)-Standards. Durch die Einhaltung etablierter Muster können Teams Dokumentationen erstellen, die sowohl als Gestaltungsgrundlage als auch als Überprüfungskontrollliste dienen.
🔍 Verständnis der Kernkomponenten
Bevor der narrative Text verfasst wird, ist es unerlässlich, die strukturellen Elemente zu definieren, aus denen eine vollständige Use-Case besteht. Diese Komponenten stellen sicher, dass der Szenario abgegrenzt und messbar ist.
1. Der Akteur 🧍
Ein Akteur stellt eine Rolle dar, die von einer Entität gespielt wird, die mit dem System interagiert. Akteure liegen außerhalb der Systemgrenze. Sie können sein:
- Menschliche Akteure:Echte Personen, wie ein Kunde, Administrator oder Techniker.
- Externe Systeme:Andere Software- oder Hardware-Schnittstellen, die Daten auslösen oder empfangen.
- Zeitbasierte Akteure:Ereignisse, die durch eine Uhr oder einen Timer ausgelöst werden, wie ein geplanter Sicherungsprozess.
Bei der Definition eines Akteurs sollte eine spezifische Rolle anstelle eines konkreten Berufsbezeichnungen zugewiesen werden. Zum Beispiel „Registrierter Benutzer“ anstelle von „John Doe“. Dadurch bleibt die Anforderung auch dann gültig, wenn sich das Personal ändert.
2. Die Systemgrenze ⬜
Die Systemgrenze definiert, was innerhalb der Software und was außerhalb liegt. Sie klärt die Verantwortung. Alles innerhalb des Kastens ist das System; alles außerhalb ist die Umgebung. Diese Unterscheidung ist entscheidend dafür, wer für einen bestimmten Fehler oder eine bestimmte Aktion verantwortlich ist.
3. Das Ziel 🎯
Jede Use-Case stellt ein einzelnes Ziel dar, das der Akteur erreichen möchte. Wenn eine Beschreibung mehrere unzusammenhängende Ziele enthält, sollte sie in separate Use-Cases aufgeteilt werden. Ein einzelnes Ziel stellt sicher, dass die Use-Case testbar und handhabbar bleibt.
📋 Aufbau einer Use-Case-Beschreibung
Eine umfassende Beschreibung geht über ein einfaches Diagramm hinaus. Sie erfordert eine textliche Spezifikation, die den Interaktionsablauf detailliert beschreibt. Unten ist die Standardstruktur aufgeführt, die in professionellen Anforderungsdokumentationen verwendet wird.
Metadaten und Identifikation
- Use-Case-ID:Eine eindeutige Kennung (z. B. UC-001) zur Verfolgung.
- Use-Case-Name:Ein Verb-Substantiv-Ausdruck, der die Aktion beschreibt (z. B. „Bestellung absenden“).
- Primärer Akteur:Der Hauptnutzer, der die Aktion initiiert.
- Sekundäre Akteure:Alle unterstützenden Systeme oder Nutzer.
- Priorität: Kritisch, Hoch, Mittel oder Niedrig.
Voraussetzungen
Voraussetzungen definieren den Zustand des Systems, bevor der Anwendungsfall beginnt. Wenn diese Bedingungen nicht erfüllt sind, kann der Anwendungsfall nicht gestartet werden. Dies hilft Testern, die erforderliche Einrichtung zu verstehen.
- Der Benutzer muss im System angemeldet sein.
- Der Warenkorb muss mindestens ein Artikel enthalten.
- Der Zahlungsgateway muss online sein.
Nachbedingungen
Nachbedingungen beschreiben den Zustand des Systems nach einer erfolgreichen Ausführung des Anwendungsfalls. Sie dienen als Akzeptanzkriterien für die Funktion.
- Es wird ein neuer Auftragseintrag in der Datenbank erstellt.
- Eine E-Mail-Bestätigung wird an den Benutzer gesendet.
- Die Bestandsmengen werden aktualisiert.
Ablauf der Ereignisse
Dies ist das Herzstück der Beschreibung. Er beschreibt die Reihenfolge der Schritte, die der Akteur und das System ausführen. Er ist typischerweise in den Haupterfolgsverlauf und Erweiterungen unterteilt.
🚀 Der Haupterfolgsverlauf (Glücklicher Pfad)
Der Haupterfolgsverlauf beschreibt den idealen Pfad, bei dem alles reibungslos verläuft. Es gibt keine Fehler, Unterbrechungen oder alternative Entscheidungen. Jeder Schritt muss atomar sein, das heißt, es handelt sich um eine einzelne Aktion, die ohne Verlust der Bedeutung nicht weiter zerlegt werden kann.
Beim Schreiben dieser Schritte gelten folgende Richtlinien:
- Nummerieren Sie die Schritte:Verwenden Sie 1, 2, 3…, um die Reihenfolge anzugeben.
- Identifizieren Sie die Quelle:Geben Sie klar an, wer den Schritt initiiert (Akteur oder System).
- Verwenden Sie aktive Verben:Beginnen Sie mit Handlungsverben wie „Wählen“, „Eingeben“, „Anzeigen“ oder „Validieren“.
- Vermeiden Sie technische Fachbegriffe:Beschreiben Sie, was der Benutzer sieht, nicht die dahinterliegende Datenbankabfrage.
🛑 Alternative und Ausnahmepfade
Im echten Einsatz verläuft die Nutzung selten perfekt. Erweiterungen behandeln Abweichungen vom Hauptpfad. Diese sind entscheidend für eine robuste Anforderungserhebung.
Alternative Pfade
Sie treten auf, wenn der Akteur eine andere Entscheidung trifft als im Hauptpfad. Sie führen weiterhin zum selben Ziel, allerdings über einen anderen Weg.
- Beispiel: Der Benutzer wählt aus, während der Kasse einen Rabattcode anzuwenden.
Ausnahmeabläufe
Diese treten auf, wenn etwas schief geht. Das System muss Fehler reibungslos behandeln. Das Ziel des Anwendungsfalls könnte fehlschlagen, oder es könnte wiederhergestellt werden.
- Beispiel: Der Zahlungsgateway gibt eine Fehlermeldung zurück.
- Beispiel: Der Benutzer verfügt über unzureichende Mittel.
Erweiterungen sollten die spezifische Schrittnummer im Haupterfolgsszenario referenzieren, an der die Abweichung auftritt.
📝 Praktisches Beispiel: „Zahlung verarbeiten“
Um diese Konzepte zu veranschaulichen, betrachten Sie eine generische Zahlungsverarbeitungssituation. Dieses Beispiel zeigt, wie abstrakte Ideen in konkrete Schritte übersetzt werden können.
| Schritt | Akteur/System | Aktion | Antwort |
|---|---|---|---|
| 1 | Akteur | Wählt die Schaltfläche „Jetzt bezahlen“ aus. | – |
| 2 | System | Zeigt das Zahlungsformular an. | Das Formular erscheint mit Kartenfeldern. |
| 3 | Akteur | Gibt Karteninformationen ein. | – |
| 4 | System | Überprüft die Karteninformationen. | Prüft auf Format und Ablaufdatum. |
| 5 | System | Übermittelt Transaktion an Gateway. | – |
| 6 | Gateway | Gibt Autorisierung zurück. | Erfolgs- oder Fehlercode. |
| 7 | System | Bestätigt Zahlung. | Zeigt Erfolgsbildschirm an. |
Alternativer Pfad A (Ungültige Karte):
- Bei Schritt 4, falls die Überprüfung fehlschlägt, Fehlermeldung anzeigen.
- Benutzer erlauben, Daten erneut einzugeben.
Alternativer Pfad B (Zeitüberschreitung):
- Bei Schritt 5, falls das Gateway innerhalb von 10 Sekunden nicht antwortet, Zeitüberschreitungs-Meldung anzeigen.
- Benutzer erlauben, erneut zu versuchen oder abzubrechen.
🛠 Best Practices für Klarheit und Präzision
Anforderungen zu schreiben ist eine Fähigkeit, die durch Übung verbessert wird. Die Einhaltung spezifischer Standards verringert Missverständnisse zwischen Business Analysten, Entwicklern und Testern.
1. Granularität beibehalten
Kombinieren Sie nicht mehrere Aktionen in einem Schritt. Wenn ein Schritt erfordert, dass der Benutzer auf eine Schaltfläche klickt und danach Text eingibt, teilen Sie ihn in zwei Schritte auf. Die Granularität stellt sicher, dass Testfälle für jede spezifische Interaktion verfasst werden können.
2. Vermeiden Sie Annahmen
Gehen Sie niemals davon aus, dass der Benutzer technische Begriffe kennt. Vermeiden Sie Wörter wie „parsen“, „commiten“ oder „cache“ außer wenn die Oberfläche sie explizit anzeigt. Beschreiben Sie das Ergebnis, nicht den Mechanismus.
3. Konsistenz in der Terminologie
Verwenden Sie ein kontrolliertes Vokabular. Wenn Sie es in einem Abschnitt als „Produkt“ bezeichnen, nennen Sie es in einem anderen nicht „Artikel“. Inkonsequenz verwirrt Entwickler und führt zu Fehlern bei der Datenbankabgleichung.
4. Fokus auf Verhalten, nicht auf Implementierung
Beschreiben Sie, was das System tut, nicht, wie es es tut. Zum Beispiel schreiben Sie „Das System prüft den Bestand“ statt „Das System fragt die SQL-Bestandstabelle ab“. Letzteres ermöglicht dem Implementierungsteam, die beste Technologie zu wählen.
⚠️ Häufige Fehler, die vermieden werden sollten
Selbst erfahrene Autoren machen Fehler. Die frühzeitige Erkennung dieser Muster verhindert späteren Aufwand im Entwicklungszyklus.
Fehlerquelle 1: Der „Gott-Nutzungsfall“
Dies tritt auf, wenn ein einzelner Anwendungsfall zu viel versucht. Wenn ein Anwendungsfall 50 Schritte hat, ist es wahrscheinlich, dass er mehrere Ziele abdeckt. Zerlegen Sie ihn in kleinere, fokussierte Anwendungsfallbeschreibungen.
Fehlerquelle 2: Fehlende Voraussetzungen
Das Überspringen von Voraussetzungen lässt Tester raten, in welchem Anfangszustand sich die Umgebung befindet. Dies führt oft zu instabilen Tests, die zufällig fehlschlagen, weil die Umgebung nicht korrekt eingerichtet war.
Fehlerquelle 3: Umschreibende Verben
Vermeiden Sie Wörter wie „verwalten“, „bearbeiten“ oder „verarbeiten“. Diese sind zu ungenau. Verwenden Sie stattdessen „Aktualisieren“, „Löschen“, „Berechnen“ oder „Senden“. Präzision beseitigt Mehrdeutigkeiten.
Fehlerquelle 4: Vermischung von Detailgraden
Mischen Sie keine hochrangigen Geschäftsziele mit niedrigen UI-Klicks. Halten Sie den Haupterfolgsszenario auf einer logischen Ebene. UI-Details können separat in Wireframes oder UI-Spezifikationen dokumentiert werden.
🔗 Integration mit anderen Spezifikationen
Anwendungsfallbeschreibungen existieren nicht isoliert. Sie sind mit anderen Artefakten in der Anforderungsdokumentation verknüpft.
- Nachvollziehbarkeit:Jeder Anwendungsfall sollte bestimmten Benutzergeschichten oder geschäftlichen Zielen zugeordnet werden. Dadurch wird sichergestellt, dass jedes Feature einen Zweck erfüllt.
- Testfälle:Die Schritte im Haupterfolgsszenario werden direkt in positive Testfälle übersetzt. Erweiterungen werden in negative Testfälle übersetzt.
- UI-Design:Die Akteure und Schritte informieren über die Navigationsstruktur und Bildschirmlayouts.
- Datenbank-Design:Die in den Schritten genannten Daten (z. B. „Kreditkarte eingeben“) beeinflussen die Anforderungen an das Datenmodell.
📊 Vergleich: Wirksame vs. unwirksame Beschreibungen
Der Unterschied zwischen einer guten und einer schlechten Anforderung liegt oft im Grad der Detailgenauigkeit und Klarheit. Die folgende Tabelle verdeutlicht diese Unterschiede.
| Funktion | ❌ Unwirksame Beschreibung | ✅ Wirksame Beschreibung |
|---|---|---|
| Akteur | „Der Benutzer“ | „Registrierter Administrator“ |
| Schritt | „Login bearbeiten“ | „Benutzernamen und Passwort eingeben“ |
| Ergebnis | „System prüft den Zugriff“ | „Das System überprüft die Anmeldeinformationen gegen die Datenbank“ |
| Ausnahme | „Falls es fehlschlägt“ | „Falls die Anmeldeinformationen falsch sind, zeige eine Fehlermeldung an und leere das Feld“ |
| Umfang | „Verwalte alles“ | „Benutzerprofil anzeigen und bearbeiten“ |
Beachten Sie, wie die effektive Beschreibung spezifische Aktionen und klare Grenzen liefert. Dies verringert die kognitive Belastung für den Entwickler, der die Funktion implementiert.
🧩 Behandlung komplexer Szenarien
Nicht alle Anforderungen passen zu einem einfachen linearen Ablauf. Einige Szenarien beinhalten parallele Prozesse oder bedingte Logik.
Einbeziehung- und Erweiterungsbeziehungen
In UML können Use-Cases miteinander verbunden sein. Eine EinbeziehungBeziehung tritt auf, wenn ein Use-Case immer einen anderen benötigt, um zu funktionieren. Zum Beispiel beinhaltet „Bestellung aufgeben“ immer „Zahlung überprüfen“. Dies reduziert Redundanz in Beschreibungen.
Eine ErweiterungBeziehung ermöglicht es einem Use-Case, unter bestimmten Bedingungen Verhalten zu einem anderen hinzuzufügen. Zum Beispiel erweitert „Rabatt anwenden“ „Bestellung aufgeben“, nur wenn der Benutzer einen Gutschein-Code hat.
Parallelverarbeitung
Für komplexe Systeme reicht ein einziger Ablauf möglicherweise nicht aus. Verwenden Sie Unterabläufe oder getrennte Diagramme, um parallele Aktivitäten darzustellen. Stellen Sie sicher, dass die Interaktionspunkte zwischen diesen Abläufen klar definiert sind.
🔍 Überprüfung und Validierung
Sobald eine Beschreibung verfasst ist, muss sie validiert werden. Ein Dokument ist nicht abgeschlossen, bis es von den zuständigen Stakeholdern überprüft wurde.
- Durchgang:Führen Sie einen Durchgang mit dem Geschäftsinhaber durch. Bitten Sie ihn, die Schritte zu lesen und zu bestätigen, dass sie seinem mentalen Modell entsprechen.
- Möglichkeitsprüfung:Konsultieren Sie den Leitenden Entwickler. Stellen Sie sicher, dass die Schritte innerhalb der Projektbeschränkungen technisch umsetzbar sind.
- Vollständigkeit:Prüfen Sie auf fehlende Fehlerpfade. Was passiert, wenn die Internetverbindung unterbrochen wird? Was passiert, wenn die Datenbank voll ist?
- Konsistenz:Stellen Sie sicher, dass die Begriffe im gesamten Anforderungsdokument übereinstimmen.
🛠 Werkzeuge und Formate
Das Format der Use-Case-Beschreibung kann je nach Projektanforderungen variieren. Häufig verwendete Formate sind:
- Strukturiertem Text: Ein nummerierter Listenformat, geeignet für Word oder Google Docs.
- Tabellenformat: Eine tabellarische Darstellung zur schnellen Übersicht, häufig in Tabellenkalkulationen verwendet.
- Datenbankeinträge: Gespeichert in Anforderungsmanagement-Tools zur Nachverfolgbarkeit.
- Wiki-Seiten: Zusammenarbeitss Seiten, die Versionsverlauf und Verknüpfungen ermöglichen.
Unabhängig vom Medium bleibt die Inhaltstruktur gleich. Ziel ist Zugänglichkeit und Klarheit, nicht der spezifische Dateityp.
🔗 Von Anforderungen zum Testen
Der größte Wert einer Use-Case-Beschreibung liegt in ihrer Nützlichkeit während der Testphase. Tester verwenden den Haupterfolgsszenario, um die „Glückliche Pfad“-Tests zu definieren. Sie verwenden die Erweiterungen, um die „Negative Pfad“-Tests zu definieren.
Wenn eine Use-Case-Beschreibung unklar ist, werden Testfälle unvollständig sein. Dies führt zu Lücken in der Abdeckung und zu Bugs, die in die Produktion gelangen. Klare Beschreibungen wirken als Vertrag zwischen dem Geschäft und dem Engineering-Team.
📈 Messen der Qualität
Wie erkennen Sie, ob Ihre Use-Cases von guter Qualität sind? Achten Sie auf diese Indikatoren:
- Testbarkeit: Kann ein Tester einen Testfall allein auf Grundlage dieses Textes erstellen?
- Eindeutigkeit: Gibt es nur eine mögliche Deutung?
- Nachverfolgbarkeit: Können Sie dies zurück zu einem Geschäftsziel verknüpfen?
- Vollständigkeit: Sind alle Hauptpfade und Ausnahmen abgedeckt?
🏁 Zusammenfassung der wichtigsten Erkenntnisse
Die Erstellung wirksamer Use-Case-Beschreibungen erfordert Disziplin und Sorgfalt. Es geht nicht nur darum, festzuhalten, was das System tut, sondern auch die Grenzen seines Verhaltens zu definieren. Durch Fokussierung auf atomare Schritte, klare Voraussetzungen und robuste Ausnahmehandhabung können Teams Unsicherheiten reduzieren und die Lieferqualität verbessern.
Wichtige Elemente, die Sie beachten sollten, sind:
- Definieren Sie Akteure und Systemgrenzen eindeutig.
- Verwenden Sie ein strukturiertes Format mit ID, Name und Ablauf.
- Trennen Sie den Haupterfolgsszenario von alternativen und Ausnahmepfaden.
- Verwenden Sie aktive Verben und spezifische Fachbegriffe.
- Validieren Sie Beschreibungen mit den Stakeholdern, bevor die Entwicklung beginnt.
Die Investition von Zeit in die klare Formulierung von Anforderungen bringt während des gesamten Projektzyklus Erträge. Sie reduziert Nacharbeiten, klärt Erwartungen und stellt sicher, dass das Endprodukt den tatsächlichen Bedürfnissen der Nutzer entspricht.
