t2informatik » Wissen kompakt » Use Case 2.0

Was ist Use Case 2.0?

Welche Idee steckt hinter Use Case 2.0, welche Prinzipien gelten und wie ist das Zusammenspiel mit Scrum?

Die Idee von Use Case 2.0

Anwendungsfälle sind sehr nützlich bei der Identifikation von Anforderungen. In der Praxis sind sie aber oftmals zu umfangreich, um bspw. innerhalb eines Sprints in Scrum realisiert werden zu können. Die Frage lautet also: Wie können Unternehmen mit Anwendungsfällen agil planen? Die Antwort haben Ivar  Jacobsen und seine Mitautoren 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.

Prinzipien von Use Case 2.0

Use Case 2.0 ist eine skalierbare Technik zur agilen Entwicklung von Anforderungen, die im Zuge einer inkrementen Entwicklung umgesetzt werden. Die Technik bietet die Möglichkeit, Use Cases direkt auch in der agilen Entwicklung zu nutzen, ohne sie vorher in User Storys übersetzen zu müssen. Grundsätzlich basiert Use Case 2.0 auf sechs einfachen Prinzipien:

  • beschreibe Dinge einfach mit Storys (nicht identtisch mit den User Storys aus Scrum),
  • verstehe das Big Picture,
  • stelle den Nutzen des Akteurs in den Mittelpunkt,
  • erstelle das System in Slices,
  • liefere das System in Inkrementen,
  • und passe das Vorgehen an die Bedürfnisse des Teams an.
Use Case 2.0
\

Folge von Aktionen

In einem Anwendungsfall tritt ein Akteur mit einem System in eine Interaktion, um ein bestimmtes Ziel in einer definierten Folge von Aktionen zu erreichen.

\

Alternativen

Häufig gibt es Alternativen auf dem Weg zum gewünschten Ziel. Diese Abfolge von Schritten nennt sich bei Use Case 2.0 "Alternative Flow". Jeder Weg vom Start bis zum Ende eines Use Cases beschreibt ein Use Case Story.

\

Der gerade Weg zum Ziel

Die Folge von Schritten, die auf geradem Weg zum gewünschten Ziel und damit zum Ende des Use Cases führt, nennt sich "Basic Flow".

\

Das Slicing

Das Zerschneiden des Use Cases erfolgt entlang der Use Case Storys und damit vertikal. Ein horizontales "Slicing" über mehrere Use Case Storys ist nicht sinnvoll.

\

Mehrere Use Case Storys

Beim Zerschneiden können mehrere Use Case Storys zu einem Use Case Slice zusammengefasst werden.

Vorteile von Use Case 2.0

Das Use Case 2.0 Konzept bietet eine Reihe von Vorteilen:

  • Das Konzept lässt sich in klassischen Wasserfall-Projekten als auch in der agilen Entwicklung sehr gut verwenden. Und es ist so leicht zu verstehen, dass sich zwei unterschiedliche Techniken wie die Arbeit mit Use Cases und das Arbeiten mit Backlogs kombinieren lassen.
  • Wie bei der Arbeit mit User Storys wird die Konversation zwischen den Beteiligten gefördert und das gemeinsame Verständnis steigt.
  • Häufig sind Use Cases zu umfangreich für eine Realisierung innerhalb eines Sprints. Durch das Slicing eines Use Cases entstehen kleinere Einheiten, die sich innerhalb eines Sprints realisieren lassen.

Use Case Whitepaper - t2informatik Download Vorschau

Jetzt das Use Case Whitepaper kostenlos downloaden.

Alles Wichtige über Use Cases, Use Case Diagramme, Misuse Cases und Use Case 2.0 auf 14 Seiten zum Mitnehmen.

Hier klicken »

Use Case 2.0 in der Praxis

Use Case 2.0 Begriffe

Use Case 2.0 verwendet einige Begriffe wie Akteure, Stakeholder, System- und Systemelemente oder Use Case Diagramm, die im Kontext von Use Cases üblich sind. Darüber hinaus verwenden Ivar  Jacobsen und seine Mitautoren Spence und Bittner einige weitere Begriffe:

  • Flow: Eine Beschreibung eines vollständigen oder teilweisen Pfades durch einen narrativen Anwendungsfall. Es gibt immer mindestens einen Basic Flow, und es kann Alternative Flows geben.
  • Basic Flow: Die Beschreibung des normalen, geradlinigen Durchlaufs durch den Anwendungsfall. Er ist damit der wichtigste Teile des narrativen Anwendungsfalls und wird von den Akteuren am häufigsten genutzt.
  • Alternative Flow: Beschreibung der Variante oder des optionalen Verhaltens als Teil eines narrativen Anwendungsfalls. Alternative Flows sind relativ zum Basic Flow des Anwendungsfalls definiert.
  • Story: Eine Story beschreibt eine Möglichkeit, ein System zu verwenden, das für einen Benutzer oder einen anderen Stakeholder von Wert ist. In Use Case 2.0 wird eine Story beschrieben durch einen Teil des narrativen Anwendungsfalls, einen oder mehrere Flows, Anforderungen und einen oder mehrere Testfälle. Eine Story ist damit nicht identisch mit einer User Story aus Scrum.
  • Use Case Modell: Ein Use Case Modell besteht hauptsächlich aus einer Reihe von Akteuren und einer Reihe von Anwendungsfällen sowie aus Diagrammen, die ihre Beziehungen veranschaulichen. Es beschreibt die sinnvolle Nutzung eines Systems und den Wert, den das System bietet.
  • Use Case Slice: Ein Use-Case-Slice umfasst eine oder mehrere Storys, die aus einem Anwendungsfall ausgewählt werden und für Anwender einen eindeutigen Wert darstellen.

Das Vorgehen in der Entwicklung

Wie lassen sich die Use Case 2.0 Prinzipien in der Produktentwicklung nutzen? Zuerst gilt es die Akteure zu identifizieren, die mit dem System arbeiten. Welche Ziele verfolgen diese Akteure? Es ist wichtig, diese Ziele zu verstehen, denn Anwendungsfälle dienen immer dazu, Ziele der Anwender zu erreichen. Auf dieser Grundlage können Sie damit beginnen, Use Cases zu ermitteln. Dazu gibt es zwei Optionen:

  1. Top Down – also vom Use Case ausgehend einzelne Schritte, Abläufe und Alternativen ermitteln.
  2. Bottom Up – also beispielsweise per Brainstorming, Brainwriting oder Braindumping verschiedene Abläufe sammeln und zu Anwendungsfällen zusammenfassen.

Beide Optionen lassen sich auch miteinander kombinieren. Es ist hilfreich, gleichzeitig zur Beschreibung der Abläufe – jeder sinnvolle Weg durch einen Anwendungsfall wird als Use Case Story bezeichnet – Testfälle zu entwickeln. Sobald Use Case Storys definiert sind, können Use Case Slices gebildet werden. 

Use Case 2.0 setzt nicht voraus, dass alle Anwendungsfälle vollständig definiert werden, bevor Ihre Realisierung beginnt. Ein solches Vorgehen wäre alles andere als agil. Die Identifikation einiger zentraler Use Cases ist die Basis für die Definition der ersten Slices, die als solche direkt in das Backlog aufgenommen werden können. Ein Use Case muss auch nicht komplett in Slices zerlegt werden – es reicht aus, die Slices, die für die Planung des nächsten Sprints notwendig sind, nach Bedarf zu definieren.

Den drei Autoren von Use Case 2.0 war natürlich bekannt, dass es keine einheitliche Lösung für alle Herausforderungen bei der Entwicklung von Software und Systemen gibt. Kleine, kollaborative Teams können mit einfachen Karteikarten, große, verteilte Teams mit umfassenden Anwendungsfalldokumenten und spezialisierten Tools arbeiten. Für eine Organisation ist es wichtig, ein Vorgehen zu wählen, dass zur Organisation passt und den größten Nutzen bietet.

Use Case Slices definieren

Es gelten die folgenden Regeln zur Bildung von Use Case Slices:

  • Use Case Slices müssen so klein geschnitten werden, dass sie in einem Sprint umgesetzt werden können.
  • Die erste Use Case Story wird als Basic Flow bezeichnet. Sie wird als erstes realisiert.
  • Ein Slice wird immer vertikal, also entlang einer oder mehrerer Use Case Storys, geschnitten. Er kann auch mehrere Use Case Storys umfassen.
  • Jeder Slice benötigt mindestens einen Testfall
  • Wenn zwei Use Case Slices dieselben Use Case Storys enthalten, müssen sie sich durch ihre Testfälle unterscheiden.
  • Unklare Use Case Storys können nicht in die agile Planung aufgenommen werden. Hier ergibt die Verwendung von Technical Story oder Spike Story Sinn.

Slice the Slice

Was passiert, wenn ein Use Case Slice für einen Sprint zu groß ist? Die Antwort lautet: Slice the Slice. Oder auf Deutsch: Verkleinern Sie den Slice so weit wie möglich. Lässt er sich aber nicht weiter verkleinern, sollten Organisation bei der Einplanung und Realisierung folgende agile Regeln beachten:

  • Durch die Implementierung des Slices entsteht ein Stück funktionierende Software.
  • Durch die Implementierung des Slices entsteht ein Wert für den Anwender.
  • Die Implementierung des Slices ermöglicht ein Feedback des Anwenders.

Sind diese Regeln erfüllt, kann ein zu großer Use Case Slice durch mehrere kleine Use Case Slices ersetzt werden, die jeweils Teil-Storys mit zugehörigen Testfällen enthalten. Diese Use Case Slices für die Teil-Stories werden im Backlog Refinement aufbereitet und priorisiert, im Sprint Planning eingeplant, im Sprint implementiert und im Sprint Review geprüft. Sind alle Teil-Storys implementiert, müssen die Testfälle des ursprünglichen Use Case Slices durchlaufen werden. Sind alle Use Case Storys implementiert, müssen die Testfälle des ursprünglichen Use Cases geprüft werden.

User Storys vs. Use Case Storys

Alistair Cockburn, einer der Urheber des agilen Manifests, hat drei Probleme beschrieben, die durch die ausschließliche Verwendung von User Storys in agilen Projekten entstehen:

  • Die reine Verwendung von User Storys bietet Entwicklern keine Kontextinformationen.
  • User Storys liefern dem Projektteam keine Hinweise auf den Grad der Fertigstellung.
  • User Storys stellen keinen hinreichenden Mechanismus zur Verfügung, um in der Vorausschau mögliche Schwierigkeiten von noch nicht erledigter Arbeit zu ermitteln.

Ein großer Vorteil der Verwendung von Use Case 2.0 liegt in der Skalierbarkeit des Konzepts. Kleine Teams können ihre Beschreibungen so kurz wie möglich halten, so dass sie ähnlich einfach zu verstehen sind wie User Storys. Größere, möglicherweise verteilte Teams können hingegen umfassendere Beschreibungen erstellen und so alle wichtigen Aspekte dokumentieren. Dieses Vorgehen ist flexibel und liefert bei Bedarf sinnvolle Kontextinformationen. Wie detailliert die Use Case Storys dokumentiert werden, hängt also von der konkreten Situation und von den beteiligten Mitarbeitern ab.

Im Gegensatz zu User Storys, die meist in einem Backlog verwaltet werden, bieten Use Case Storys durch die Verbindung zu Use Cases und Use Case Diagrammen einen besseren Überblick über das System. Auch Abhängigkeiten zwischen Anforderungen lassen sich so besser nachvollziehen. Darüber hinaus helfen Use Case Storys während der Realisierung, einen Überblick über bereits fertig gestellte Systemteile zu erhalten.

User Storys sind mit Ihrem einfachen Aufbau „Als (Rolle) möchte ich (Funktionalität), um (Nutzen) zu erreichen“ leicht zu verstehen. Bei Use Cases wird hingegen häufig die Lesbarkeit als schwierig empfunden. Es empfiehlt sich daher, Stakeholder nicht mit der Dokumentation von Use Cases, Use Case Diagrammen oder Use Case Storys zu überfordern. Als Ausdrucks- und Arbeitsmittel sollten sie für die Kommunikation über Inhalte genutzt werden. Es ist sicherlich sinnvoll, wenn Stakeholder, Systemanalytiker und Entwickler auch im Zuge von Use Case 2.0 regelmäßig miteinander kommunizieren, zumal so auch mögliche Schwierigkeiten frühstmöglich erkannt werden können.

Wollen Sie mehr über Use Cases erfahren?

Dann schauen Sie sich einfach  die allgemeine Beschreibung von Use Cases, die Darstellung mit Use Case Diagrammen oder die Vorteile von Misuse Cases an.

Herausforderungen für Unternehmen

Das Schneiden von Use Cases

Beim Formulieren von Anwendungsfällen sollten Organisationen darauf achten, detaillierte Beschreibungen zu erstellen, die nicht zu kompliziert formuliert werden. Bei der Umsetzung selbst ist das Zerschneiden von Anwendungsfällen in Slices, die innerhalb eines Sprints realisiert werden, sehr wichtig. Die Umsetzung der Slices ist abhängig von der Größe eines Slices; gegebenenfalls müssen auch sie nochmals verkleinert werden.  Hier ist technisches und wirtschaftliches Verständnis gefragt. Organisationen müssen abwägen, ob sie diejenigen Use Cases bzw. Use Case Slices zuerst realisieren, die technisch oder fachlich einen großen Anwenderkreis adressieren, oder solche, die einen kleineren Kreis ansprechen, der gegebenenfalls eine größere finanzielle Auswirkung hat.

Grundsätzlich bietet das Arbeiten mit Use Cases, Anwendungsfalldiagrammen, Use Case 2.0 und Misuse Cases ein umfassendes Konzept, um Systeme nicht nur im Detail sondern als Ganzes gut zu verstehen. Unternehmen müssen „lediglich“ die Konzepte konsequent und passend zur Organisation anwenden.

Gerne stellen wir Ihnen Wissen, Erfahrung und 100% Leidenschaft für Ihre Softwareentwicklung und Anforderungsanalyse zur Verfügung. Wir helfen Ihnen bei der Beschreibung von Use Cases und der Erhebung, Strukturierung und Verwaltung von Anforderungen. Dabei achten wird auf Konsistenz, Vollständigkeit und Nachvollziehbarkeit. Wir unterstützen Sie beim Identifizieren von technischen Zusammenhängen und berücksichtigen Stakeholder, Ziele und Randbedingungen. Und wir planen und steuern Ihre Projekte mit diesen Anforderungen auf Basis definierter Prozesse.

Hier erfahren Sie mehr zum Thema Softwareentwicklung »

Weitere Details und Hintergründe

Share This