Sie haben schon eine beeindruckende Karriere hinter sich: die Use Cases oder Anwendungsfälle. Als Ivar Jacobson 1986 erstmals textuelle und visuelle Modellierungstechniken zur Spezifikation von Use Cases beschrieb, war deren Erfolg kaum vorhersehbar. Richtig durchgestartet sind die Use Cases tatsächlich erst einige Jahre später als Bestandteil der UML – so lange, bis die Welt immer agiler wurde. Ivar Jacobsons Versuch im Jahr 2011, „seine“ Use Cases mit der Methode Use Case 2.0 [1] fit für agile Projekte zu machen, war – vorsichtig formuliert – nur bedingt erfolgreich. Mit der Verbreitung der agilen Entwicklung hat die Anwendung von Use Cases zur Spezifikation von Anforderungen speziell gegenüber den User Stories an Boden verloren. Hier sind einige Zahlen, die dies veranschaulichen. Sie stammen von der Swiss Q Consulting AG, die jährlich Trends & Benchmarks Studien zu den Themen Agilität, Requirements Engineering und Testing veröffentlicht [2].
Die Grafik zeigt Umfrageergebnisse aus den Jahren 2013, 2016 und 2019 zum Einsatz von Use Cases und User Stories bei der Spezifikation von Anforderungen in % der befragten Unternehmen.
Ich möchte Ihnen heute zeigen, dass es ein Gebiet gibt, auf dem sich Use Cases nach wie vor klar behaupten. Gemeint sind die frühen Aktivitäten der Business Analyse, also die Schritte, in denen es darum geht, die Geschäftsziele der Stakeholder zu verstehen und durch Business Use Cases zu konkretisieren. In der aktuellen Projektlandschaft gibt es zwei Arten von Projekten, in denen sich der Einsatz von Business Use Cases besonders lohnt:
- bei der Entwicklung neuer digitaler Geschäftsmodelle oder Services und
- bei der Durchführung von Third-Party-Projekten, bei denen die Lösung von externen Dritten erstellt werden soll.
Grund genug also, Business Use Cases genauer zu betrachten.
Was sind Business Use Cases?
Zweck eines Business Use Cases ist es, deutlich zu machen, wie ein Hauptakteur ein von ihm angestrebtes Ergebnis erzielen kann. Dazu beschreibt er eine Interaktion von Akteuren auf geschäftlichem Niveau mit den jeweils relevanten Teilen eines Unternehmens bzw. einer Organisation. Ein Business Use Case stellt eine äußere Sicht auf Unternehmen oder Organisation dar. Ein zentraler Punkt dabei ist, dass eine einzige Ausführung eines Business Use Cases alle Aktionen umfassen sollte, die
- notwendig sind, um das zu tun, was der Akteur will, und
- das Unternehmen durchführen muss, bevor der Prozess aus seiner Sicht abgeschlossen ist.
Die wichtigsten Unterschiede zwischen Business Use Cases und dem „Original“ – sprich den System Use Cases der Software- und Systementwicklung – zeigt nachfolgende Tabelle.
System Use Cases werden typischerweise textuell anhand einer Schablone oder mit grafischen Modellen wie den Aktivitätsdiagrammen der UML beschrieben. Dasselbe gilt für Business Use Cases.
Auch die Entwicklung von Business Use Case Diagrammen ist sinnvoll. Sie helfen zum Beispiel dabei, sich in Meetings mit Stakeholdern und Sponsoren auf die Auswirkungen von Lösungen auf Geschäftsprozesse und Rollen zu fokussieren und sich nicht in Details zu verlieren.
Wie sehen Business Use Case Diagramme aus?
Mit einem flüchtigen Blick auf das Diagramm lautet unsere Antwort auf diese Frage: Eigentlich genauso wie „normale“ Use Case Diagramme.
Ein Beispiel für ein Business Use Case Diagramm
Aber eben nur „eigentlich“. Ich empfehle Ihnen, die klassische Notation für Use Case Diagramme zu verwenden, aber die Elemente des Diagramms für den Einsatz auf Geschäftsniveau zu spezialisieren. Konkret heißt das, dass ein Business Use Case Diagramm folgende Elementtypen enthalten sollte:
Business Actor (Spezialisierung von Actor): Ist eine unternehmensexterne Einheit, wie beispielsweise ein Kunde, ein Lieferant oder ein externes System.
Business Use Case (Spezialisierung von Use Case): Beschreibt eine Interaktion mit einem Geschäftsbereich, einem Geschäftsservice oder einem Geschäftsprozess.
Worker (Spezialisierung von Actor): Ist eine Organisationseinheit oder Rolle innerhalb des Geschäftsbereichs, die an der Implementierung eines Geschäftsprozesses beteiligt ist.
System Actor (Spezialisierung von Actor): Kennzeichnet ein externes IT-System.
System-level Actor (Spezialisierung von Actor): Repräsentiert einen Akteur – Mensch oder Technologie –, der mit dem IT-System interagiert.
In objectiF RM und objectiF RPM werden diese Spezialisierungen durch Substereotypen der Elemente «Actor» und «Use Case» definiert. Wenn Sie weitere Differenzierungen vornehmen möchten, können Sie mit wenigen Klicks in beiden Werkzeugen weitere eigene Substereotypen definieren. Der Substereotyp wird in den Diagrammelementen textlich abgebildet. Wir verwenden keine modifizierte grafische Notation für die Elemente im Business Use Diagramm. Der Vorteil: Wenn bei der Systementwicklung ebenfalls Use Cases verwendet werden, ist durch die einheitliche Notation von Use Case Diagrammen auf Geschäfts- und Systemebene die Konsistenz des Use-Case-Ansatzes über den gesamten Lebenszyklus einer Geschäftslösung gewährleistet. Use Case Diagramme bleiben somit für alle Beteiligten lesbar.
Blicken wir abschließend auf die wichtigste Frage:
Welchen Nutzen schaffen Business Use Cases im Projekt?
Am Anfang jedes Projekts stehen die Ziele der Stakeholder, die mit einer neuen Business-Lösung erreicht werden sollen. Business Use Cases sind dafür gemacht, diese Ziele zu verstehen und gemeinsam mit den Stakeholdern Lösungsansätze zu finden, wie diese Ziele erreicht werden könnten. Mit Tool-Unterstützung wie z.B. objectiF RM oder objectiF RPM kann man den Weg von der Analyse der Stakeholder und ihrer Ziele bis zur Lösungsidee nachvollziehbar machen. Aber das sehen Sie sich am besten einmal in bewegten Bildern an. Ich habe dazu ein kurzes Video für Sie vorbereitet:
Modellieren Sie doch einfach selbst mal ein Business Use Case Diagramm. Mit den kostenlosen Trial Editions von objectiF RPM oder objectiF RM können Sie gleich loslegen.
Quellen:
[1] Ivar Jacobson, Ian Spence und Kurt Bittner: Use-Case 2.0, The Guide to Succeeding with Use Cases. Als Download verfügbar unter diesem Link: https://www.ivarjacobson.com/publications/white-papers/use-case-ebook
[2] Die Studien der Swiss Q Consulting AG von 2014 bis 2019 finden Sie hier: https://swissq.it/de/agile/research-information2/
Die Studie von 2013 ist verfügbar unter: https://swissq.it/wp-content/uploads/2016/02/RE-Trends_und_Benchmarks2013.pdf