Use Cases sind seit vielen Jahren ein beliebtes Mittel zur Strukturierung und Dokumentation funktionaler Anforderungen. Ein Use Case, oder Anwendungsfall, stellt dar, wie ein System mit einem Benutzer oder einem anderen System zusammenwirkt, um eine bestimmte Aufgabe zu erledigen. Ein Use Case-Diagramm zeigt die Akteure und ihre Use Cases im Überblick. Als Bestandteil der Unified Modeling Language (UML) haben Use Case-Diagramme eine weite Verbreitung gefunden. Noch wichtiger als die Diagramme sind aber die Beschreibungen der einzelnen Use Cases, meist in Form von Texten, die nach bestimmten Vorlagen strukturiert sind. Diese Beschreibungen der Abläufe bei der Bearbeitung einer bestimmten Aufgabe dienen als Grundlage für die eigentliche Entwicklung, aber auch für den anschließenden Test.
In klassischen, wasserfallartigen Vorgehensmodellen hatten die Use Cases ihren Platz als Beschreibungsmittel im Rahmen der Anforderungsanalyse. Wie sieht dies aber in der agilen Entwicklung aus? Zumeist wird ja auf ein komplettes Anforderungsdokument verzichtet. Anforderungen werden eher in Form von User Stories definiert, die auf Karteikarten oder Haftzetteln notiert und je nach Planungs- oder Bearbeitungszustand in unterschiedliche Bereiche einer Wandtafel gehängt werden. Haben Use Cases damit zumindest in der agilen Entwicklung ausgedient?
Nicht wenn es nach Ivar Jacobson, einem der Erfinder der Use Cases und Mitentwickler der UML, geht. Er hat die Use Cases weiterentwickelt, zum Konzept des „Use Case 2.0“, das er in einem kostenlos erhältlichen E-Book beschreibt. Darin erläutert er ausführlich, wie Use Cases in unterschiedlichen Entwicklungsmodellen eingesetzt werden können – insbesondere auch bei agilen Vorgehensweisen. So kann man beispielsweise leichtgewichtige Use Case-Beschreibungen erstellen, die nur kurze Erzählungen enthalten – vergleichbar einer User Story.
Ein nützliches Prinzip bei der Dokumentation von Use Cases ist es, zunächst den einfachen, typischen Ablauf zu beschreiben, den „Happy Path“. Erst anschließend werden die verschiedenen möglichen Alternativen und Ausnahmen in einem eigenen Abschnitt dargestellt. In einem agilen Projekt kann man bereits beim Erstellen der Use Case-Beschreibungen iterativ vorgehen, indem man zu Beginn nur den Standardablauf beschreibt, und erst in späteren Iterationen verschiedene Alternativen ausarbeitet.
Für die Entwicklung schlägt Jacobson vor, die Use Cases in verschiedene „Scheiben“ (Slices) zu zerschneiden, wobei eine Scheibe jeweils einen sinnvoll nutzbaren Ausschnitt eines Use Cases darstellt. Beispielsweise kann man den Standardablauf und ein oder zwei sehr wichtige Alternativen zu einer Scheibe zusammenfassen. Jede Scheibe enthält dann eine kurze Beschreibung und einen Testfall, mit dem die Umsetzung später überprüft werden kann. Die verschiedenen Scheiben aus allen Use Cases bilden damit den Product Backlog. Daraus wird dann jeweils ausgewählt, welche Scheiben in der nächsten Iteration umgesetzt werden.
Damit nehmen die Use Case-Scheiben in einem agilen Projekt die Rolle der User Stories ein. Welchen Vorteil bringt die Nutzung der Use Cases? Im Gegensatz zu einer reinen Sammlung von User Stories stellen die Use Cases als übergeordnete Einheiten zusammen mit den Use Case-Diagramme den Zusammenhang der verschiedenen Anforderungen dar. Somit bieten sie einen Gesamtüberblick über das System, der sowohl vor Entwicklungsbeginn zur Strukturierung und Ermittlung der Anforderungen genutzt werden kann, als auch während des Projektes die Möglichkeit bietet, die Anforderungen weiter zu entwickeln und den Abdeckungsgrad der fertiggestellten Systemteile zu verfolgen.
Damit die Use Case-Übersicht immer aktuell ist, muss man sie aber auch regelmäßig aktualisieren. Eine User Story bzw. eine einzelne Use Case-Scheibe kann man gut auf einem Haftzettel notieren, den man nach Bearbeitung umhängt. Will man aber wissen, wie weit die Umsetzung eines gesamten Use Case gediehen ist, muss man nachverfolgen, in welche Scheiben er zerlegt ist und wo sich die betreffenden Haftzettel gerade befinden. Wenn außerdem noch die Use Cases selbst erst über mehrere Iterationen hinweg immer weiter ausgearbeitet werden, erschwert das die Nachverfolgung zusätzlich. Prinzipiell könnte man dies mit einem geeigneten Tool unterstützen, was aber der Idee einer leichtgewichtigen Low Tech-Lösung widerspricht.
Insofern bringt der Use Case 2.0-Ansatz auch einige Herausforderungen mit sich. Andererseits ist ein Gesamtüberblick über das System auch für agile Projekte wichtig. In vielen Fällen können Use Cases hierfür das geeignete Mittel sein. Das E-Book gibt Anregungen, wie der konkrete Einsatz für unterschiedliche Projekttypen gelingen kann, sowohl für klassische als auch für agile.
Ich glaube, die Unterscheidung zwischen Use Case und User Story ist rein akademisch. In beiden Fällen formuliert man sinnvolle in sich abgeschlossene Einheiten von Funktionalität. Die grafische Darstellung von Use Cases in der UML fand ich schon immer recht fraglich, da mit viel zu viel Platz viel zu wenig Details transportiert werden.
Deshalb gilt, für die User Story oder eben Use Case eine knackige kurze Überschrift finden und die Details in der Beschreibung pflegen. Falls nicht ersichtlich, kann man diese strukturieren und z.B. die beteiligten Akteure besonders hervorheben. Hat man dann eine entsprechende Liste, kann man sich sehr schnell einen Überblick verschaffen, ob man alle wichtigen Pfade des Features bereits abgedeckt hat oder ob noch Ausnahmen fehlen.
Hallo Sebastian,
mein Bauch sagte mir gerade ja, als ich las:
„Die grafische Darstellung von Use Cases in der UML fand ich schon immer recht fraglich, da mit viel zu viel Platz viel zu wenig Details transportiert werden.“
Wir arbeiten in unserer Entwicklung seit 4 Jahren agil auf Basis von SCRUM, und es reichen uns hier genau auch ein sprechender Titel für die User Story, einen Beschreibung aus Sicht der Rolle sowie die Liste der Abnahmekriterien. Auf weitere Grafiken haben wir überwiegend verzichtet, es wurde auch nie nachgefragt. Wenn sie etwas an Mehr gebracht hätten, wären sie sicher verwendet worden, da die Teams selbstverantwortlich sich selbst kontinuierlich via Retrospektive verbessern.
VG Martin
Hallo,
ob ein Use Case Diagramm mehr aussagt als eine simple Liste, ist eine berechtigte Frage. Was mich interessieren würde, Herr Bartonitz, erstellen Sie im Vorfeld ein „Big Picture“ der funktionalen Anforderungen? Und in welcher Form sind die enthaltenen Features für die Nachwelt dokumentiert, z. B. für neue Mitarbeiter, die Änderungen in das bestehende System einbringen wollen?
Das sind zwei Fragen, die für mich in der „reinen agilen Lehre“ immer etwas kurz kommen: Von Sprint zu Sprint können die User Stories im Backlog geändert werden, und nach Fertigstellung werden die Kärtchen mit den User Stories weggeworfen.
Ich erlaube mir mal aus meiner Erfahrung heraus zu antworten. Es ist die Aufgabe des Produktmanagers oder Product Owner genau diese Vision zu haben und gezielt durch eine Priorisierung des Product Backlogs darauf hin zu arbeiten.
Für das Produkt, an dem ich momentan beteiligt bin, habe ich zusammen mit dem Produktmanager eine niemals schaffbare Liste von Features definiert. Zusammen haben wir sie mit Prioritäten versehen. Nun arbeitet das Entwicklungsteam diese Liste von oben nach unten ab, wobei natürlich auch mehrere Features gleichzeitig in Bearbeitung sein können, wenn sich die Arbeit aus Entwicklungssicht so besser organisieren lässt. Ein Feature ist dabei definiert als eine Erweiterung des Produkts, die einen vermarktbaren Mehrwert für den Kunden darstellt. Ein Feature besteht aus einer Vielzahl von User Stories, wobei jede User Story in einem Sprint schaffbar sein muss. Wir beginnen auch kein Feature, bevor wir uns nicht im Klaren über die User Stories sind, auch wenn es während der Entwicklung sein kann, dass mal noch die eine oder andere User Story dazu kommt.
Scrum bedient deshalb also auch eine langfristige Planung und ist nicht nur von Sprint zu Sprint gedacht.