Stephan Bauer, freiberufl. Diplom-Informatiker FH

 

Usecase-Analyse angereichert mit Requirements

Als Methode für die fachliche Analysephase präferiere ich aus langjähriger eigener Erfahrung nach wie vor einen Usecase-zentrierten Ansatz - im Sinne der "Effective Usecases" von Alistair Cockburn. Hierbei wird ein Fachprozess schnell und effizient hierarchisch strukturiert. Wünscht der Kunde eine grafische Darstellung - z.B. in Form von BPMN - erscheint es dennoch sinnvoll, die ersten Analyse-Iterationen zuerst textuell zu erfassen. Der Einstieg in die grafische Modellierung erfolgt erst ab einer gewissen Stabilisierung der Summary-Level-Usecases. Dies ist schlicht und ergreifend dem deutlich höheren Änderungsaufwand geschuldet, der entsteht, wenn man von Anfang an grafisch modelliert.

Ich habe mehrmals erlebt, dass in Projekten, in denen keine Usecases aufgeschrieben wurden (Stichwort "Prosa-Fachkonzept"), letztlich der Überblick über komplexere Zusammenhänge verloren ging und die Diskussionen über spätere Änderungswünsche deutlich schwieriger wurden.

Das klassische Beispiel schlechthin sind die "Variationen" des sog. "Haupterfolgsszenarios" eines Usecase. Hat man keine Usecases, werden häufig diverse Nebenabläufe übersehen. Dies führt unweigerlich dazu, dass dieser Teil der Anforderungen erst später entdeckt wird und somit weitere Änderungswünsche erst in einer noch späteren Entwicklungsphase nachgeschoben werden müssen.

Da der erwartete "Produktionstermin" dann oft schon viel näher gerückt ist, steckt hier das Potential, dass die Entwickler unter dem Zeitdruck ihre eigenen Qualitätsstandards (sofern sie welche haben) über Board werfen um vermeindlich schneller ausliefern zu können. Dies ist insbesondere dann der Fall wenn die Qualitätsstandards nicht fest vom Kunden vorgegeben sind sondern vom individuellen Know-how des einzelnen Entwicklers abhängen. Entwickler, die die "Clean-Code-Prinzipien" und Tools wie Sonarqube gewissenhaft einsetzen, sollten hierfür zwar nicht anfällig sein, aber leider sind insbesondere die Prinzipien in der von "Uncle Bob" konsolidierten Form nach wie vor (noch?) nicht sehr weit verbreitet.

Requirements und Masken-Entwürfe

Auf der Ebene der sog. "Usergoal-Usecases" gehören in der Regel auch Entwürfe der Eingabe-Masken sowie  detailliert beschriebene Requirements unabdingbar zur fachlichen Konzeption.

Damit meine ich strukturiert formulierte Requirements nach dem Ansatz der Sophisten, die häufig gestützt werden von Entscheidungsmatrizen. Da "Usergoal-Usecases" ein Ping-Pong-Spiel zwischen Anwender- und Systemaktionen darstellen, ist es ein sehr eleganter Weg, die System-Steps mit Verweis auf das entsprechende Requirement zu formulieren. Beispiel: "Das System berechnet den Score gemäß Requirement XY".

Im Umkehrschluss ist es erfahrungsgemäß ineffizient, Requirements direkt innerhalb eines Usecase-Steps zu beschreiben.

Usecases und Agilität

Nach meiner Erfahrung ist es zielführend, vor Beginn der Entwicklung eine initiale Analyse soweit voranzubringen, dass die Summary-Level Usecases in etwa zu 80% stabil sind (80:20-Prinzip).

Dies beruht auch auf der Empfehlung von Adolph und Bramble (Buch "Patterns for Effective Usecases"), die diesen Ansatz als "Breadth Before Depth" beschrieben haben.

Häufig bietet es sich an, Backlog-Items auf der Granularität eines Steps eines Usergoal-Usecases zu schneiden.

Usecases vs Userstories

Insgesamt empfinde ich die Kombination aus Effective Usecases und Requirements weiterhin als die deutlich effizientere Methode gegenüber den "Userstories". Beschränkt man sich aufgrund eines (vermeintlich) agilen Ansatzes rein auf das Schreiben von Userstories, fehlt häufig der Kontext, in den die Story eingebettet ist. Es besteht die Gefahr, dass sich Userstories überschneiden. Außerdem ist es schwerer zu erkennen, wann man alles abgedeckt hat. Im Gegensatz dazu dient die hierarchische Usecase-Analyse als eine Art "Inhaltsangabe", sodass man immer genau den Gesamtkontext kennt und gezielt die sog. Preconditions beschreiben kann.

 

 

 

Stephan Bauer, Fullstack Software-Engineer, Architekt und Coach (Java / JEE)  |  sb(at)stephanbauer.me