Seite 3: Fazit

Inhaltsverzeichnis

Plädoyer für Use Cases

Sogar einer der Urheber des agilen Manifests, Alistair Cockburn, benennt drei "echte, schmerzhafte und teure Probleme" [6], die die ausschließliche Verwendung von User Stories statt Use Cases in agilen Projekten bringt:

• User Stories bieten den Entwicklern keinen Kontext.
• Sie geben dem Projektteam keine Hinweise auf den Grad der Fertigstellung.
• User Stories stellen keinen ausreichenden Mechanismus bereit, um vorausschauend die Schwierigkeiten von noch nicht getaner Arbeit zu ermitteln.

Statt also User Stories als Liste in einem Backlog zu sammeln, geben einem Use Case Slices durch die übergeordnete Use-Case-Ebene und eventuelle Use-Case-Diagramme der UML einen Gesamtüberblick über das System sowie über die Abhängigkeiten und Zusammenhänge der Anforderungen. Diese übergeordneten Instanzen ermöglichen eine bessere Nachvollziehbarkeit und Strukturierung der Anforderungen, noch bevor die eigentliche Entwicklung begonnen hat. Im Projekt helfen Use Cases dabei, sich einen Überblick über schon fertige Systemteile zu verschaffen.

Oft wird die für die Stakeholder mangelnde Lesbarkeit von Use Cases angeprangert. Man sollte generell nie Stakeholder mit der Dokumentation von Use Cases und Use-Case-Diagrammen allein lassen. Es reicht also nicht, nur Dokumente zu generieren, sie dem Stakeholder zu schicken und auf ein Feedback zu hoffen. Das gilt auch für Use Case 2.0. Stattdessen sollten Teams miteinander reden – das Prinzip der Konversation, also das zweite C der User Stories, ist auch hier sinnvoll.

Das Use-Case-2.0-Konzept eignet sich sowohl für agile Entwicklung als auch für das klassische Wasserfallmodell, weil es skalierbar ist. Kleine Teams, die eng zusammenarbeiten, können ihre Use-Case-Beschreibungen auf das Notwendigste beschränken. Große, verteilte Teams können aufwendige Beschreibungen und Dokumente erstellen. Wie detailliert die Anforderungen an das zu entwickelnde System dokumentiert werden, hängt also vom Team ab.

Fazit

Use Cases sind nicht ohne Grund so beliebt: Für viele Unternehmen bilden sie das Mittel der Wahl für die Stakeholder-Kommunikation. Sie helfen dabei zu verstehen, wie ein System dazu beiträgt, die vom User angestrebten Ziele zu erreichen und die gewünschten Ergebnisse zu erzeugen. Der noch wenig bekannte Mehrwert von Use Case 2.0 liegt in der Integration etablierter Techniken des Requirements Engineering in eine agile Vorgehensweise. Damit bieten Use Cases auch in agilen Projekten viele Vorteile.

Ursula Meseberg
ist Mitbegründerin und Geschäftsführerin der Berliner microTOOL GmbH. Ihren beruflichen Weg begann sie als Consultant für Software Engineering und Softwareentwicklungsprozesse. In dieser Funktion hat sie an der Entwicklung zahlreicher unternehmenseigener Vorgehensmodelle mitgewirkt.

Literatur

1. Ivar Jacobson: Object Oriented Development in an Industrial Environment, OOPSLA – Proceedings, October 4-8, 1987, ACM 0-89791-247-0/87/0010-0183
2. HK Business Solutions, Fraunhofer IESE: Ergebnisbericht "Use Cases in der Praxis", 2013
3. SwissQ Consulting in Kooperation mit der Universität St. Gallen: Requirements Trends & Benchmarks Schweiz, 2013
4. Ron Jeffries; Essential XP: Card, Conversation, Confirmation (30.08.2001)
5. Ivar Jacobson, Ian Spence, Kurt Bittner; Use Case 2.0 (E-Book), Ivar Jacobsen International 2011
6. Alistair Cockburn; Why I still use use cases (01.09.2008)
   

(ane)