Angenommen, Sie haben mit den Stakeholdern grob erarbeitet, was das neue IT-System können soll. Sie haben eine grobe Vorstellung, was der Scope des Systems ist, worum es fachlich ungefähr geht, was die Ziele sind und wer aller mit dem neuen System arbeiten soll. Darauf aufbauend können Sie nun beginnen, mit den Stakeholdern zu erarbeiten, wie denn die Anwendungsfälle ausschauen sollen.
Wir nutzen dazu gerne das Workshop-Format, das heißt, wir erarbeiten einen Anwendungsfall gemeinsam mit 1-3 Stakeholdern in einem oder mehreren Workshops. Jeder dieser Workshops dauert 2-4 Stunden. Weniger macht keinen Sinn, weil man nichts weiterbringt, mehr macht keinen Sinn, weil dann die Konzentration nachlässt und auch die Terminfindung schwierig ist. Im Groben hat sich dabei folgende Workshop-Struktur bewährt:
Workshop 1 – Scope abstecken
- Das Thema für den Workshop kurz abstecken („Heute geht es um…“)
- Die Stakeholder erzählen anhand eines konkreten Praxisbeispiels aus den letzten Wochen, wie der Ablauf in der Praxis sein soll
- Zweck/Ergebnis für den Anwendungsfall erarbeiten
- Kontext des Anwendungsfalls beschreiben (umgebender Geschäftsprozess, IT-Systeme, Probleme, …)
- Scope des Anwendungsfalls festlegen (Anfang/Ende, Auslöser, Ergebnis)
- Wichtige Anforderungen abholen
Workshop 2 – Hauptszenario verstehen
- Hauptszenario des Anwendungsfalls beschreiben (Was ist der häufigste/wichtigste Fall?)
- Stakeholder erzählen einige weitere Beispiele aus dem letzten Monat → Varianten heraushören
- Bisheriges (Zweck, Abgrenzung, Prozess, …) prüfen und ggf. überarbeiten.
Workshop 3 – Validieren
- Bisher Erarbeitetes mit anderen Stakeholdern prüfen (Stimmt das? Ist das bei euch auch so? Gibt es bei euch noch anderes?)
Workshop 4 – Alternativen und Details erkunden
- Zusatzinformationen und Details zum Hauptszenario erarbeiten.
- Alternativszenarien beschreiben.
- Fehlerszenarien beschrieben.
- Sonstige Anforderungen besprechen (Qualitätsanforderungen, Lösungsideen, …)
Vier Workshops? Für einen Anwendungsfall? Puh! Schaut auf den ersten Blick viel aus. Rechnet man nach, kommt man auf 8 – 12h, das sind 1 – 1,5 Tage Arbeit. Meistens fallen aus einem Anwendungsfall dann eine ganze Reihe an im Software-System zu entwickelnde Funktionen heraus, sodass das Entwicklungsteam für die Umsetzung des Anwendungsfalls mit all seinen Funktionalitäten dann mindestens einen Sprint, also 2 – 3 Wochen, beschäftigt ist. Oft auch deutlich mehr. Das wären dann 10% Aufwand fürs Erarbeiten der fachlichen Anforderungen, was eigentlich sogar verhältnismäßig wenig ist (gutes Requirements Engineering sollte zwischen 10-20% des Gesamtaufwandes beanspruchen).
„10 für 10!
Zehn Sekunden Nachdenken für die nächsten zehn Minuten Einsatz.“
Daumenregel im Rettungsdienst
Weiterführende Informationen:
Markus Unterauer, "Workshops im Requirements Engineering", 2015, dpunkt-Verlag: www.thalia.at/shop/home/artikeldetails/A1055848583
