Anwendungsfälle und Szenarien

Ziel

Ein Anwendungsfall beantwortet eine Frage: Auf welche Weisen kann ein Versuch verlaufen, wenn ein Akteur ein bestimmtes Ziel über die Lösung verfolgt? Er fasst in einem einzigen Artefakt den Normalweg, die Varianten, die das Ziel dennoch erreichen, und die Fehlschläge zusammen und hängt an jeden, was am Ende wahr bleiben muss. Die Entscheidung, die er stützt, betrifft den funktionalen Umfang: was die Lösung ermöglichen muss, ausgedrückt in Zielen von Akteuren statt in technischen Funktionen. Der Geschäftswert jedes Falls steckt im benannten Ziel, was verhindert, eine Fähigkeit zu schreiben, für deren Ausübung es keinen Grund gibt.

Das Ergebnis hat zwei Seiten. Die textuelle Seite ist der Fall selbst: ein Name im Imperativ, ein Ziel, die Akteure, der Auslöser, die Vorbedingungen, das nummerierte Hauptszenario mit seinen Alternativen und Ausnahmen und die Ausgangsgarantien. Die grafische Seite ist das Anwendungsfalldiagramm, das die Systemgrenze zieht und auf einen Blick zeigt, welche Akteure an welchen Fällen teilnehmen und welche Fälle andere wiederverwenden. Der Text trägt das Verhalten, das Diagramm trägt den Umfang. Ein Projekt braucht beide.

Die Technik entstand bei Ivar Jacobson, der den Anwendungsfall 1987 auf der Konferenz OOPSLA vorstellte und ihn in seiner Methode Objectory sowie in seinem Buch von 1992 entwickelte. Jacobson wurde später einer der drei Autoren von UML, weshalb die Notation des Diagramms heute von der Object Management Group standardisiert ist. Die Art, Szenarien zu schreiben, verdankt das meiste Alistair Cockburn, dessen Buch von 2001 die Zielebenen und die Struktur aus Hauptszenario plus Erweiterungen festlegt, die im Berufsalltag verwendet werden.

Verwendung

Wann einsetzen

• Den funktionalen Umfang einer Lösung abstecken: das Diagramm zeigt die Ziele der Akteure und wo die Systemgrenze verläuft.
• Reiche Interaktion zwischen einem Akteur und einem System: mehrere Wege, Bedingungen, Fehlausgänge, die gemeinsam zu spezifizieren sind.
• Bedarf an einer für Stakeholder lesbaren Sprache: der erzählende Fluss ist ohne Schulung verständlich, anders als eine formale Spezifikation.
• Ziele der Akteure bereits identifiziert: die Liste der Akteure und ihrer Ziele aus der Stakeholder-Analyse speist die Fälle direkt.
• Grundlage für Test und Entwurf: jedes Szenario ist ein möglicher Testfall, jede Garantie eine zu prüfende Zusicherung.
• Verhalten vor der Entwicklung festzuhalten: der Fall benennt, was das System tun muss, unabhängig davon, wie es gebaut wird.

Wann nicht einsetzen

• Bedarf noch unklar, im Gespräch zu erkunden: User Stories nehmen, verhandelbar und auf einen Sprint bemessen.
• Gegenstand sind Regeln und Entscheidungen: die Geschäftsregelanalyse nehmen, die sie gesondert verwaltet.
• Gegenstand sind Aussehen und Anordnung der Bildschirme: das Prototyping nehmen, wo das Detail der Oberfläche hingehört.

Beschreibung

Der Fall, das Szenario, das Diagramm

Drei Objekte überschneiden sich und werden miteinander verwechselt. Der Anwendungsfall ist die zielgerichtete Einheit: die Gesamtheit der Weisen, auf die ein Versuch, ein Ziel zu erreichen, verlaufen kann. Ein Szenario ist ein konkreter Weg durch diesen Fall, eine einzige Folge von Schritten. Das Hauptszenario, jenes, in dem alles gut geht, ist der kürzeste und einfachste Weg zum Ziel. Alternativszenarien erreichen das Ziel auf einem anderen Weg, Ausnahmeszenarien enden, ohne es zu erreichen. Das Anwendungsfalldiagramm erzählt kein Szenario: über all dem zeigt es, welche Akteure an welchen Fällen teilnehmen und wie die Fälle zusammenhängen. Cockburns Formulierung ist die knappste: ein Anwendungsfall ist ein Hauptszenario plus eine Menge von Erweiterungen, wobei jede Erweiterung eine Bedingung und die von ihr ausgelösten Schritte ist.

Die Elemente eines Anwendungsfalls

Der Name ist ein Verb gefolgt von einem Objekt, das die Handlung des Akteurs und ihr Ziel benennt: «Abonnement erneuern», nie ein statischer Titel wie «Abonnementverwaltung». Das Ziel beschreibt in einem Satz den erfolgreichen Ausgang aus Sicht des Primärakteurs und fasst den Fall zusammen. Die Akteure sind die Personen oder Systeme ausserhalb der Lösung, die mit ihr interagieren, bezeichnet nach der Rolle, die sie spielen. Der Primärakteur hat das Ziel und löst den Fall meist aus; die Sekundärakteure, etwa ein Zahlungssystem, leisten einen Dienst, den die Lösung zum Gelingen aufruft. Manche Schulen raten davon ab, ein System oder ein Ereignis als Akteur zu behandeln; die Praxis bleibt eine Minderheit.

Die Vorbedingung nennt, was wahr sein muss, bevor der Fall beginnen kann. Der Fall setzt sie zu Beginn als wahr voraus und lässt sie ausserhalb seines Ablaufs: «der Inhaber ist authentifiziert» als Vorbedingung zu schreiben erspart einen Authentifizierungsschritt im Szenario. Der Auslöser ist das Ereignis, das den Fluss startet, meist eine Handlung des Primärakteurs, manchmal ein zeitliches Ereignis wie eine Tagesabschlussroutine oder ein Monatsabschlussabgleich. Die Garantien oder Nachbedingungen nennen, was wahr sein muss, wenn der Fall endet, und sie teilen sich in zwei: die Erfolgsgarantie gilt auf dem erfolgreichen Weg, die Minimalgarantie gilt selbst bei einem Fehlschlag und schützt Sicherheit und Datenintegrität. Eine Garantie muss für alle Szenarien gelten, das Haupt- wie die Alternativszenarien, sonst ist sie nur ein Wunsch, der allein für das Hauptszenario gilt.

Die Zielebene wählen

Ein Anwendungsfall wird auf einer Ebene geschrieben, und die Wahl der Ebene ist jene, die am häufigsten misslingt. Cockburn bietet dafür eine Skala, jene des Meeresspiegels. Die Ebene des Anwenderziels, die Wasseroberfläche, ist jene, auf der ein einzelner Akteur ein einzelnes Ziel in einer einzigen Sitzung erreicht: dort schreibt man. Darüber deckt die Zusammenfassungsebene einen Prozess ab, der mehrere Anwenderziele umspannt («Das Konto verwalten»): zu breit, um in einem Stück geschrieben zu werden, wird sie zerlegt. Darunter beschreibt die Unterfunktionsebene einen Schritt, der von mehreren Fällen wiederverwendet wird («Authentifizieren», «Zahlung durchführen»): ein Kandidat für die Herausfaktorisierung als eingeschlossener Fall. Der Test ist eine Frage: kann ein Akteur ihn in einem Zug bewältigen und weggehen, nachdem er etwas von Wert erhalten hat?

Zwei Fehlentwicklungen folgen aus einer falschen Ebene. Die erste ist der zu hoch geschriebene Fall, der zu einem Sammelbecken wird, in dem sich das Ziel auflöst. Die zweite, heimtückischere, ist das CRUD-Muster: Anlegen, Lesen, Ändern, Löschen in vier Anwendungsfälle je Entität zu verwandeln. Das sind Unterfunktionen; sie blähen das Modell auf und lehren nichts über die Absicht des Akteurs. Niemand meldet sich an, um «eine Abonnementzeile zu ändern», man meldet sich an, um sein Abonnement zu erneuern. Die Ebene des Anwenderziels ist das Geländer gegen beide Fehlentwicklungen.

Das Hauptszenario als Blackbox schreiben

Das Hauptszenario wird in nummerierten Schritten geschrieben, abwechselnd Akteur und Lösung, aus Sicht des Akteurs und vor allem als Blackbox: jeder Schritt sagt, was das System tut, von aussen gesehen. Drei bis neun Schritte genügen einem gesunden Fall. Dieses Blackbox-Prinzip ist die am leichtesten zu verratende Leitlinie, auf zwei Weisen.

Die erste ist das Durchsickern der Oberfläche in den Fluss: «der Inhaber klickt auf die blaue Schaltfläche», «wählt aus der Auswahlliste», «das modale Fenster erscheint». Der Fluss sagt, was das System vollbringt. Das Detail der Oberfläche gehört zum Prototyping, wo es entworfen und geprüft wird, ohne das Verhalten verfrüht festzulegen. Die zweite ist das Vergraben der Geschäftsregeln in den Schritten: einen Tarif, eine Satztabelle, eine Berechtigungslogik im Szenario hart zu codieren. Diese Regeln werden gesondert verwaltet, durch die Geschäftsregelanalyse, und der Schritt verweist auf sie. Ein Fall, der eine Regel einschliesst, wird an dem Tag falsch, an dem die Regel sich ändert, und die Regel bleibt in einem Dokument vergraben, das niemand erneut liest.

Alternativen und Ausnahmen ableiten

Ist das Hauptszenario einmal gesetzt, geht man jeden Schritt durch und fragt: was könnte hier sonst geschehen? Jeder Zweig wird durch die Nummer des Schritts markiert, den er verlässt, wobei ein Buchstabe die Zweige desselben Schritts unterscheidet: 5a, 6a. Eine Alternative erreicht das Ziel dennoch auf einem anderen Weg und mündet wieder in den Hauptfluss. Eine Ausnahme endet ohne das Ziel, und man nennt dann den Ausgang: was das System tut und welche Garantie trotz des Fehlschlags gilt. Hier gewinnt die Minimalgarantie ihren Sinn, indem sie nennt, was wahr bleibt, wenn das Ziel nicht erreicht wird. Vollständigkeit ist eine Falle: das lockere Format verleitet dazu, jede Mikrovariante zu erfassen, und ein Fall, der unter vierzig Zweigen ertrinkt, wird nicht mehr gelesen. Man behält die realen Wege und lässt die Laborhypothesen weg.

Das Anwendungsfalldiagramm lesen

Das Diagramm zieht die Systemgrenze und verteilt die Ziele der Akteure um sie herum. Die von UML standardisierte Notation kommt für den Lesenden mit wenigen Zeichen aus. Ein Akteur ist ein Strichmännchen, ausserhalb der Grenze platziert: eine Rolle. Ein Anwendungsfall ist eine Ellipse, innerhalb platziert, mit dem Namen aus Verb plus Objekt. Die Systemgrenze ist ein Rechteck, das die Ellipsen umschliesst; man beschriftet sie mit dem Namen des Systems. Eine Assoziation ist eine durchgezogene Linie, die einen Akteur mit einem Fall verbindet: sie markiert, dass der Akteur am Fall teilnimmt und die beschriebene Funktionalität erreicht.

Zwei Beziehungen verbinden die Fälle untereinander, und Lesende verfehlen diese Unterscheidung häufiger als jede andere. «include» ist ein gestrichelter Pfeil mit offener Spitze, mit dem Schlüsselwort versehen, der vom Basisfall zum eingeschlossenen Fall läuft: der Basisfall führt das eingeschlossene Verhalten immer aus. Man verwendet es, um Verhalten herauszufaktorisieren, das von mehreren Fällen geteilt wird, «Zahlung durchführen», wiederverwendet von «Abonnement erneuern» und von «Billett kaufen». «extend» ist ebenfalls ein gestrichelter Pfeil mit offener Spitze, aber er zeigt vom erweiternden Fall zum Basisfall, was die meisten Lesenden überrascht: der Pfeil zielt auf den Basisfall. Die Erweiterung fügt bedingtes Verhalten an einem definierten Erweiterungspunkt hinzu, und der Basisfall bleibt ohne sie vollständig und funktionsfähig. Die Regel passt in eine Zeile: «include» heisst «immer und wiederverwendet», «extend» heisst «manchmal und optional». Das eine für das andere zu verwenden oder den «extend»-Pfeil zum erweiternden Fall zu zeichnen, ist der häufigste UML-Fehler. Eine Generalisierung gibt es auch, eine durchgezogene Linie mit hohlem Dreieck am Ende, für einen Akteur oder einen Fall, der eine spezialisierte Art eines anderen ist; sie ist die am wenigsten verwendete Beziehung.

Die Notation endet hier für die Business-Analyse: diese wenigen Zeichen genügen, um ein Anwendungsfalldiagramm zu lesen und es mit den Stakeholdern zu besprechen. Die feine Semantik von UML, seine übrigen Diagramme und der fortgeschrittene Gebrauch von «include» und «extend» gehören in eine spezialisierte Modellierungsschulung. Ein Modell in verschachtelte Einschlüsse zu überzerlegen ist verkappte funktionale Dekomposition, die das Ziel verliert, das der Fall tragen sollte.

Die Übung durchführen

1. Die Akteure und ihre Ziele identifizieren
   Aus der Stakeholderliste jede externe Rolle benennen, die mit der Lösung interagiert, und das Ziel, das sie verfolgt.
2. Jeden Fall nach seinem Ziel benennen
   Ein Verb, ein Objekt, auf der Ebene des Anwenderziels.
3. Das Hauptszenario schreiben
   Nummerierte Schritte, Blackbox, aus Sicht des Akteurs. Keine Bildschirmmechanik, keine hart codierte Geschäftsregel.
4. Die Alternativen und Ausnahmen ableiten
   Jeden Schritt durchgehen, die Zweige gegen den Schritt beschriften, den sie verlassen, für jede Ausnahme einen Ausgang nennen.
5. Vorbedingung, Auslöser und Garantien definieren
   Was bereits wahr sein muss, was den Fall startet, was am Ende bei Erfolg und selbst bei Fehlschlag gilt.
6. Das Diagramm zeichnen
   Akteure ausserhalb der Grenze, Fälle als Ellipsen innerhalb, Assoziationen als durchgezogene Linien, geteiltes Verhalten als «include», optionales Verhalten als «extend». Regeln und Entscheidungen aus den Schritten heraushalten und auf sie verweisen.

Anwendungsfall oder User Story

Die Verwechslung mit der User Story lohnt sich aufzulösen, denn beide decken dasselbe Feld ab. Eine User Story ist ein kurzer, verhandelbarer Platzhalter für ein Gespräch, «als Reisender möchte ich mein Abonnement erneuern, um weiterhin zu fahren», bemessen, um in einen Sprint zu passen. Ein Anwendungsfall ist eine vollständigere Verhaltensspezifikation eines Ziels, mit allen seinen Flüssen und Garantien. Beide ergänzen sich: eine Story, deren Interaktion sich als komplex erweist, wird zu einem Anwendungsfall ausgearbeitet, wenn es Zeit ist, die Wege und Ausgänge festzulegen. Man wählt nach dem Risiko und der Reife des Bedarfs, die eine, um die Diskussion zu eröffnen, den anderen, um das Verhalten festzuschreiben.

KI-Betrachtungen

Der erste lohnende Einsatz ist der Entwurf. Aus einem Interviewtranskript, einer Prozessbeschreibung oder einer Menge von User Stories schlägt ein Sprachmodell ein erstes nummeriertes Hauptszenario und eine Liste möglicher Alternativen und Ausnahmen vor. Es ist schnell bei diesem mechanischen Teil und überlässt der Analyse die Sortierarbeit statt des leeren Blatts. Der zweite Einsatz ist jener, in dem die Maschine glänzt: aufzählen, was bei Schritt N schiefgehen kann. Zahlung abgelehnt, Sitzung abgelaufen, Artikel nicht mehr verfügbar, gleichzeitige Änderung: ein Modell rollt diese Ausnahmen als Prüfliste aus, und die Business-Analyse behält nur jene, die eintreten können.

Der dritte Einsatz ist die strukturelle Prüfung. Man fragt das Modell, ob jeder Schritt einen definierten Ausgang hat, ob die Garantien über alle Flüsse gelten, ob eine Vorbedingung angenommen wird, ohne geschrieben zu sein, ob sich zwei Fälle überschneiden. Es erkennt die strukturellen Auslassungen; wie schwer sie wiegen, bleibt zu beurteilen. Der vierte Einsatz ist Benennung und Einstufung: zu melden, dass ein «Fall» in Wahrheit eine CRUD-Unterfunktion oder eine Zusammenfassung ist, und Namen aus Verb plus Objekt vorzuschlagen. Der fünfte ist die Formatumwandlung, von einem vollständigen Fall zu einem informellen Absatz oder umgekehrt, und die Vorbereitung der mehrsprachigen Fassungen.

Was die KI nicht tragen kann, liegt in der Natur der Technik. Die Identifikation der Akteure und Ziele ist ein Akt der Erhebung und ein politisches Abwägen: wer die wahren Stakeholder sind, welche Ziele zählen, wo die Systemgrenze verläuft. Das Modell wird plausible und falsche Akteure erfinden. Das reale Verhalten des Systems lässt sich nicht erraten: nur die Stakeholder und die Beschränkungen der Lösung definieren, was das System tut, und ein von einem Modell erzeugter Fluss ist eine zu prüfende Hypothese. Die Gültigkeit der Grenzfälle mischt reale Risiken und Fiktion im selben Atemzug: ein Mensch entscheidet, welche im Umfang liegen, welche anderswo behandelt werden, welche nicht eintreten können. Schliesslich darf das Modell keine erratenen Berechtigungsregeln, Sätze oder Handhabungen personenbezogener Daten in die Schritte vergraben. Die KI entwirft und belastet die Flüsse, die Business-Analyse besitzt die Akteure, den Umfang und das, was wahr ist.

Beispiele

Ein Selbstbedienungsportal, auf dem eine Kundschaft ihre Verkehrsabonnements online verwaltet. Der Fall «Abonnement erneuern» übt die zwei Beziehungen des Diagramms: «Zahlung durchführen» wird mit dem Billettkauf geteilt, also eingeschlossen, und ein Rabattgutschein ist optional, also eine Erweiterung.

Zuerst liest man den Umfang. Das Diagramm stellt den Inhaber und das Zahlungssystem beiderseits der Grenze auf, teilt die Ziele des Inhabers in eigene Fälle und zeigt, was diese Fälle teilen. Die Assoziation verbindet den Akteur mit dem Fall, an dem er teilnimmt. Der «include»-Pfeil zieht «Zahlung durchführen» aus den zwei Fällen heraus, die es wiederverwenden, was das geteilte Verhalten sichtbar macht, ohne es zu kopieren. Der «extend»-Pfeil hängt «Rabattgutschein anwenden» an die Erneuerung, indem er auf den Basisfall zeigt, der ohne die Erweiterung vollständig und funktionsfähig bleibt.

Das schriftliche Artefakt erzählt dieselbe Geschichte aus der Nähe: Identität und Garantien zuerst, dann die in einer einzigen Tabelle versammelten Szenarien, in der jede Zeile ihren Wegtyp trägt.

Ein Szenario ist ein Weg durch diesen Fall: das Hauptszenario läuft 1 bis 8, die Alternative 5a ersetzt einen Schritt und mündet wieder in den Fluss, die Ausnahme 6a beendet ihn ohne das Ziel, und die Minimalgarantie gilt dann, da nichts belastet oder erfasst wird. Was das Diagramm dem Text hinzufügt, ist der Umfang: «Zahlung durchführen» wird von «Abonnement erneuern» wie von «Billett kaufen» eingeschlossen, und dieses Teilen rechtfertigt es, den Fall als eingeschlossenen Fall herauszulösen, statt ihn in jedes Szenario zu kopieren.

Visualisierungen

Zwei Abbildungen tragen das Beispiel. Das Anwendungsfalldiagramm zeigt den Umfang: den Inhaber und das Zahlungssystem beiderseits einer rechteckigen Grenze, die Fälle als Ellipsen innerhalb, die Assoziation als durchgezogene Linie, «include» und «extend» als gestrichelte Pfeile, den «extend»-Pfeil auf den Basisfall zeigend, um die von der Intuition umgekehrte Richtung sichtbar zu machen. Die Szenarientabelle zeigt das Verhalten: derselbe Fall, als mehrere beschriftete Wege durchlaufen. Die erste beantwortet «wer berührt was und was wird geteilt», die zweite «wie der Versuch verläuft».

Kosten

Werkzeuge

Ein Textverarbeitungsprogramm genügt, um einen Fall zu schreiben, und eine Vorlage, jene von Cockburn etwa, stellt sicher, dass kein Feld vergessen wird: Umfang, Ebene, Primärakteur, Stakeholder, Vorbedingungen, Garantien, Auslöser, Hauptszenario, Erweiterungen. Ein Tabellenkalkulationsprogramm trägt die Tabelle der nummerierten Szenarien gut, und ein Whiteboard genügt, um eine erste Grenze und zwei oder drei Ellipsen zu skizzieren. Diese generischen Werkzeuge taugen, solange die Fälle wenige und untereinander lose verbunden bleiben.

Für das Diagramm tragen allgemeine Zeichenwerkzeuge, diagrams.net, Lucidchart oder Visio, brauchbare Anwendungsfall-Schablonen; ihr Beitrag endet bei der Zeichnung. UML-Modellierungswerkzeuge, Enterprise Architect, Visual Paradigm oder Modelio, halten den Fall und sein Diagramm als Objekte eines Modells, beziehen sie auf die Diagramme, die sie umsetzen, und melden einen falsch gerichteten «extend»-Pfeil oder einen Fall ohne Akteur. Wenn die Fälle nach Dutzenden zählen und als Grundlage für Tests dienen, verbinden Werkzeuge für Anforderungsmanagement und ALM, Jama, Polarion, Azure DevOps oder DOORS, sie mit Anforderungen, Testfällen und Versionen und machen die Abdeckung eines Szenarios durch seine Tests sichtbar.

Quellen

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.47 Use Cases and Scenarios: die Definition, die Liste der Elemente (Akteure, Vorbedingungen, Auslöser, Hauptfluss, Alternativ- und Ausnahmeflüsse, Garantien), das Anwendungsfalldiagramm und der Verweis auf UML für seine Notation.
• Ivar Jacobson, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992: das grundlegende Werk zum Anwendungsfall, aus der Methode Objectory und 1987 auf der OOPSLA vorgestellt.
• Alistair Cockburn, Writing Effective Use Cases, Addison-Wesley, 2001: die Zielebenen (die Meeresspiegel-Skala), die Struktur aus Hauptszenario plus Erweiterungen, das Akteursvokabular und die vollständige und die beiläufige Form.
• Object Management Group, Unified Modeling Language (UML), version 2.5.1 (formal/17-12-05, 2017): die standardisierte Notation des Anwendungsfalldiagramms, Akteur, Fall, Grenze, Assoziation, «include», «extend» und Generalisierung.