Use Case – das Verhalten eines Systems aus Anwendersicht beschreiben
Use Cases beschreiben das Verhalten eines Systems, insbesondere die Interaktion zwischen dem System und seinen Anwendern. Der Anwender ist eine Person, eine Rolle, eine Organisation oder ein anderes System. Er tritt als Akteur mit dem System in Interaktion, um ein bestimmtes Ziel in einer definierten Folge von Aktionen zu erreichen. Aus dem Ziel (bspw. “Fahrzeuggeschwindigkeit regeln” oder “Geld abheben”) ergibt sich normalerweise der Name des Use Cases, so dass auf einen Blick zu erkennen ist, welches Systemverhalten beschrieben wird.
Use Cases zeigen das Big Picture eines zu entwickelnden Systems. Ohne dieses “große Ganze” fehlt es oftmals an Orientierung und in der Folge lassen sich Entscheidungen über den Scope – was ist zu entwickeln, was lässt sich später entwickeln oder was kann sogar weggelassen werden – nur schwer treffen. Unvollständige oder unklare Anforderungen behindern die Entwicklung und den Markterfolg. Änderungen müssen nachträglich implementiert werden. Je später dies geschieht, desto schwieriger und teurer wird die Entwicklung.
Anwendungsfälle – die deutsche Übersetzung von Use Cases – werden in der Softwareentwicklung, bei der Systemerstellung und auch in der Produktentwicklung genutzt. Sie sind sehr beliebt, denn sie dokumentieren die Funktionalität eines vorhandenen oder geplanten Systems mit einfachen Modellen.
- So wird das gemeinsame Verständnis der Interaktion zwischen Akteur und System deutlich erhöht,
- Anwendungsszenarien lassen sich identifizieren und
- aus den Zielen der Akteure lassen sich funktionale Anforderungen sowie entsprechende Testfälle ableiten.
Zwei Ansätze im Use Case Konzept
Ivar Jacobson präsentierte 1987 das Konzept der Use Cases. Er definierte einen Anwendungsfall als „a special sequence of transactions, performed by a user and a system in a dialogue“ – frei ins Deutsche übersetzt als “eine spezielle Abfolge von Transaktionen, die von einem Benutzer und einem System in einem Dialog durchgeführt werden”.
Das Konzept umfasst zwei Ansätze, die sich gemeinsam nutzen lassen und sich gegenseitig ergänzen:
Use Case Spezifikationen
Use Case Spezifikationen enthalten natürlich-sprachliche Informationen zur Systematik der Interaktionen eines Anwendungsfalls (sogenannte “Narratives”). Idealerweise werden diese Informationen mit einer Vorlage textuell erfasst. Diese Vorlage sollte mindestens folgende Elemente umfassen:
- Name des Use Cases und Use Case Nummer zwecks eindeutiger Identifizierung
- Akteure
- Auslöser
- Kurzbeschreibung
- Beschreibung der essentiellen Schritte als Standardablauf
- Beschreibung von alternativen Abfolgen
- Vorbedingungen und Nachbedingungen
- Beschreibung der Systemgrenzen
Zusätzlich empfiehlt es sich, Referenzen auf andere Anwendungsfälle oder Dokumente, die Häufigkeit, die Priorität und gegebenenfalls auch Invarianten als nicht abänderbare Bedingungen zu erfassen.
Use Case Diagramme
Use Case Diagramme visualisieren Anwendungsfälle und Akteure mit ihren jeweiligen Beziehungen. Sie liefern einen guten Überblick über das Gesamtsystem, beschreiben aber im Gegensatz zu den Spezifikationen keine Abläufe, sondern die Zusammenhänge zwischen einer Menge von Anwendungsfällen und den daran beteiligten Akteuren. Sie gelten als grafische Repräsentation von Anwendungsfällen und die Unified Modeling Language (UML) definiert sie als sogenannte Verhaltensdiagramme.
Die wichtigsten Modellelemente sind hierbei:
- Akteure
- Anwendungsfälle
- Beziehungen
- Systemgrenzen
Grundsätzlich können folgende verschiedene Beziehungen bzw. Beziehungsarten in einem Diagramm verwendet werden:
- Assoziationsbeziehung,
- Include-Beziehung und Extend-Beziehung sowie
- Generalisierung.
Das Vorgehen zur Use Case Erstellung
Mit Anwendungsfällen lässt sich ein System aus Anwendersicht gut beschreiben und verstehen. Die erste Herausforderung für Unternehmen bei der Nutzung ist das Finden der Themen und Inhalte. Je mehr Mitarbeiter daran beteiligt sind, desto aufwendiger wird dieser Schritt. Gleichzeitig werden die Ergebnisse und die daraus gewonnenen Anforderungen detaillierter. Beim Formulieren sollten Organisationen darauf achten, detaillierte Beschreibungen zu erstellen, die nicht zu kompliziert formuliert werden. Hier ist etwas Übung gefragt.
Es gibt einige Fragen, die bei der Erstellung von Use Cases helfen:
Fragen zum Akteur
- Wer nutzt das System?
- Was ist das Ziel des Akteurs?
- Welche anderen Systeme interagieren mit dem System?
- Wer liefert dem System Informationen oder erhält Information?
Fragen zu den Vor- und Nachbedingungen
- Welche Bedingung muss erfüllt sein, damit der Anwendungsfall eintritt?
- In welchem Zustand befindet sich das System, wenn der Anwendungsfall eintritt?
- Wie und unter welcher Bedingung wird der Use Case abgeschlossen?
- In welchem Zustand muss sich das System befinden, so dass der Anwendungsfall abgeschlossen wird?
Hinweis: Die Verwendung von Standardtexten bei der Beschreibung der Auslöser und der Vor- und Nachbedingungen ist nicht zu empfehlen. Oftmals lassen sich auch aus den Vor- und Nachbedingungen Reihenfolgen zur Umsetzung ableiten: ein Use Case mit der Nachbedingungen X kann vor einem anderen mit der Vorbedingung X umgesetzt werden.
Fragen zu den Abläufen
- Welcher Akteur und welches Event initiiert die Ablauffolge?
- Wie interagiert der Akteur mit dem System und wie reagiert das System?
- Welche alternativen Aktionen kann der Akteur bei jedem Schritt initiieren?
- Welche Unterbrechungen oder Fehler können bei jedem Schritt des Anwendungsfalls auftreten?
- Was passiert, wenn der Akteur den Vorgang abbricht?
Sonstige Fragen
- Mit welcher Frequenz wird der Anwendungsfall ausgeführt?
- Welche Beziehungen gibt es zu anderen Anwendungsfällen?
Use Case Vorteile
Die Nutzung von Anwendungsfällen bietet eine Reihe von Vorteilen:
- Sie sind leicht zu verstehen und relativ einfach zu erstellen, denn sowohl die Interaktion zwischen Akteur und System als auch die Beziehung zwischen verschiedenen Anwendungsfälle lassen sich gut abstrahieren.
- Sie eignen sich als gute Quelle für die Ermittlung von Anforderungen, die sich aus diesen Interaktionen ergeben.
- Umfangreiche Anforderungen lassen sich mittels Zerlegung der Interaktionen zwischen Akteur und System verfeinern. Damit steigt das Verständnis der Beteiligten.
- Durch die Kombination von textuellen Beschreibungen in Spezifikationsdokumenten und der Visualisierung per Diagramm gewinnen Organisationen gleichzeitig nützliche Detailinformationen und einen guten Überblick über das gesamte System.
- Sie können auf verschiedenen Abstraktionsebenen eingesetzt werden, z.B. auf der Ebene von Software und Systemen oder der Geschäftsebene als Business Use Cases.¹
Fragen im Kontext von Use Cases
Hier finden Sie einige Fragen und Antworten im Kontext von Anwendungsfällen:
Welche Arten von Use Cases gibt es?
Es gibt zwei Arten von Anwendungsfällen:
- Bei einem Black-Box Use Case wird dokumentiert, was ein System leisten soll und nicht, wie es dies leisten soll. Die Black-Box-Ansicht zeigt, wie ein System von außen aussieht, einschließlich der erforderlichen und bereitgestellten Schnittstellen, sowie der Beziehung zu anderen Systemen. Eine Black-Box-Ansicht beschreibt aber nicht die interne Implementierung eines Systems.
- Ein White-Box Use Case dokumentiert hingegen, welche Klassen, Schnittstellen und anderen Komponenten einer Komponente helfen, die gewünschte Funktionalität bereitzustellen.
In der Praxis werden Anwendungsfälle meist als Black-Box beschrieben. Darüber hinaus werden sie auch in
- Geschäftsanwendungsfälle und
- Systemanwendungsfälle
aufgeteilt. So kann es bspw. für den Geschäftsanwendungsfall “Reise reservieren” mehrere Systemanwendungsfälle wie bspw. “Telefonische Reise reservieren” oder “Online Reise reservieren” geben.
Anmerkung: Die Verwendung von Black-Box Use Cases stellt Unternehmen vor Herausforderungen bei der Ableitung von Testfällen. Hier können bspw. formale Notationen wie Aktivitätsdiagramme oder Zustandsdiagramme als Ergänzung helfen, denn aus ihnen lassen sich Test Cases relativ leicht ableiten. Zusätzlich sind die Vor- und Nachbedingungen eines Anwendungsfalls eine gute Quelle für Testfälle. Da sie aber untereinander Beziehungen oder parallele Abläufe haben, ist eine getrennte Betrachtung für einen Test des Gesamtsystems nicht ausreichend.
Was ist Use Case 2.0?
Die Antwort haben Ivar Jacobsen, Ian Spence und Kurt Bittner im Dezember 2011 mit dem Buch “USE-CASE 2.0 – The Guide to Succeeding with Use Cases” geliefert. Sie lautet: Ein Use Case wird entlang seiner Abläufe in Scheiben geschnitten, die jeweils innerhalb eines Sprints realisiert werden können. Das Vorgehen nennt sich slicing, das Ergebnis sind Use Case Slices
Hier finden Sie weitere Informationen zu Use Case 2.0.
Was sind Misuse Cases?
Erstmals beschrieben wurde der Ansatz 2001 von Guttorm Sindre und Andreas Lothe Opdahl in “Capturing Security Requirements through Misuse Cases”. Misuse Cases ergänzen herkömmliche Anwendungsfälle um eine wertvolle Perspektive. Diese Perspektive lässt sich gut nutzen, um über Bedienungs- und Sicherheitsaspekte nachzudenken und entsprechende Anforderungen zu ermitteln.
Hier finden Sie weitere Informationen zu Misuse Cases.
Was ist der Unterschied zwischen Use Case und User Story?
In der agilen Produktentwicklung erfreuen sich User Storys großer Beliebtheit. Eine User Story ist eine einfache Beschreibung einer Funktion eines Systems aus der Perspektive eines Anwenders, die ihm einen Nutzen bietet. Im Gegensatz zu einem Anwendungsfall bietet sie aber keine Kontextinformationen und liefert keinen hinreichenden Mechanismus, um mögliche Schwierigkeiten von noch nicht erledigter Arbeit zu ermitteln. Use Cases adressieren somit einen größeren Kontext.
Use Case 2.0 bietet einen Ansatz, Anwendungsfälle in kleinere Teile – die sogenannten Slices – zu schneiden, die sich im Rahmen von Sprints realisieren lassen. Eine User Story würde folglich ein konkretes Szenario beschreiben, während der Use Case mehrere dieser Szenarien umfasst.
Wer bietet Software zur Erstellung von Anwendungsfällen an?
Wollen Sie das Use Case Whitepaper kostenlos downloaden?
Alles Wichtige über Use Cases auf einen Blick.
- Was sind Anwendungsfälle und wie werden sie erstellt?
- Welche Bestandteile haben Anwendungsfalldiagramme?
- Was ist Use Case 2.0 und was sind Misuse Cases?
- Herausforderungen und Tipps
Wissen auf 15 Seiten zum Mitnehmen.
Impuls zum Diskutieren:
Wie behandeln Sie Ausnahmesituationen oder nicht vorhergesehene Benutzerverhalten im Kontext eines Use Cases?
Hinweise:
Haben Sie Lust auf einen neuen Lieblings-Newsletter?
Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.
Ivar Jacobson begründet den Erfolg des Konzepts wie folgt: “The reason for the success of the use-case approach is not just that it is a very practical technique to capture requirements from a usage perspective or to design practical user experiences, but it impacts the whole development lifecycle.”² Frei ins Deutsche übersetzt: “Der Grund für den Erfolg des Use-Case-Ansatzes liegt nicht nur darin, dass es eine sehr praktische Technik ist, um Anforderungen aus der Nutzungsperspektive zu erfassen oder praktische Nutzererlebnisse zu entwerfen, sondern sie wirkt sich auf den gesamten Entwicklungslebenszyklus aus.”
[1] Business Use Cases – Da ist noch jede Menge Musik drin
[2] Use-Case 2.0 – The Hub of Software Development
Eine Empfehlung zum praktischen Umgang mit Anwendungsfällen in Backlogs finden Sie im Beitrag: Boost your Backlog.
Hier können Sie eine kostenlose Use Case Vorlage herunterladen.
Hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt:
Welche Elemente kennt ein Use Case Diagramm?
Wie funktioniert das Slicing bei Use Case 2.0?
Wie lassen sich Misuse Cases visualisieren?