Der Untertitel dieser Kolumne deutet unsere Intention an: Statt uns auf möglicherweise schwer verständliche Abstraktionen zu verlassen, versuchen wir durch möglichst konkrete Beispiele die wesentlichen (nicht alle!) Funktionen des Systems zu illustrieren.

Anforderungen durch Beispiele

Traditionelle Analyse- oder Modellierungsmethoden haben lange versucht, Sachverhalte (in unserem Fall: funktionale Anforderungen) ganzheitlich und gesamthaft (generisch) zu erfassen, unter Berücksichtigung von sowohl Normal- als auch Sonderfällen. Heraus kamen oftmals abstrakte Modell- oder Textkonstrukte. Bei denen besteht das große Risiko, dass Entwicklungsteams die Intention dieser Modelle nicht gut verstehen – und deswegen ihre eigene (und vermutlich fehlerhafte) Interpretation dieser Modelle in Quellcode implementieren.

Ein Beispiel für eine solche abstrakte Anforderung aus der Domäne Schulwesen:

„Das System soll registrierten Schülerinnen und Schülern on- und offline den Zugriff auf Stunden-, Vertretungs- und Klausurpläne inklusive der Raumzuordnung erlauben.“

In dieser Domäne Schulwesen ändern sich Vertretungs- und Raumpläne sehr häufig, weil Krankheiten oder Raumänderungen eben kurzfristig und ungeplant auftreten. Ein Offlinezugriff auf Vertretungspläne ergibt daher nur eingeschränkt Sinn. Hingegen sind Stundenpläne über Monate lang fix – die können wir prima dezentral speichern und natürlich offline anzeigen. Solche Details lassen sich oft nur schwer abstrakt formulieren. Alternativ dazu könnte eine Beschreibung auch anhand konkreter Beispiele erfolgen:

„Lea öffnet die App und sieht, dass am heutigen Dienstag der Matheleistungskurs um 10 Uhr in Raum R42 stattfindet und von Frau Yildiz vertreten wird. Franz hat kein Datenvolumen mehr, und sieht in der App, dass der Matheleistungskurs um 10 Uhr stattfindet, ohne Info zum Raum oder Lehrperson.“

The Conference for Continuous Delivery, Microservices, Containers, Cloud & Lean Business

Gamification: A Strategy for Enterprises to enable Product Practices

with Garima Bajpai | capital carbon consulting

Cluster-API: One Kubernetes to rule them all (+ArgoCD)

with Erkan Yanar | linsenraum.de

Die Grundlagen für Spezifikationen anhand von Beispielen stammen von Ward Cunningham, der schon 1996 dazu publizierte. Den Begriff Specification by Example hat (laut Wikipedia) Martin Fowler im Jahr 2004 geprägt. Die erste ausführliche Darstellung präsentierte Gojko Adzic in seinem Buch „Specification by Example“ [3]. Wir haben Abbildung 1 daran angelehnt: Ausgehend von Businesszielen ermitteln Sie unbedingt Scope und Kontext Ihres Systems. Anschließend können Sie im Team kollaborativ einige Schlüsselbeispiele für die Funktionalität Ihres Systems beschreiben, die dann letztlich Grundlage für eine mögliche ausführbare Spezifikation darstellen (dazu weiter unten mehr). Mit „kollaborativ“ sind interaktive Workshops gemeint, in denen Fachexpert*innen aus erster Hand Beispiele fachlicher Abläufe schildern, sowie Entwicklungsteams, die Fragen dazu stellen und Feedback geben. Für komplexe fachliche Abläufe werden Sie sicher mehrere Personen benötigen, um Beispiele von Anfang bis Ende erarbeiten zu können.

Abb. 1: Spezifikation mit Beispielen (nach [3])

Beispiele im DDD: Domain Storytelling

Eine recht junge Kombination von Domain-driven Design und beispielhafter Spezifikation ist unter dem Namen Domain Storytelling (DS) in den Fokus gerückt: Stefan Hofer hat diesen Ansatz aus dem etablierten Werkzeug-Material-Ansatz der Hamburger Software-Engineering Schule entwickelt und damit eine sehr geschickte Kombination aus Diagrammen und Beispielen geschaffen. Im Domain Storytelling werden Beispiele mit einfachen Symbolen zu grafischen Geschichten aufbereitet, die im Team gemeinsam (kollaborativ) erarbeitet werden. Die Abbildungen 2 und 3 zeigen kleine Beispiele (passend zu den oben genannten verbalen Beschreibungen aus der Domäne Schulwesen).

Abb. 2: Domain Story „Offline-Auskunft“

Abb. 3: Domain Story „Online-Auskunft“

Wir empfehlen Ihnen den ausgezeichneten Artikel zu Domain Storytelling von Stefan Hofer und Henning Schwentner – darin finden sich auch ein etwas größeres Beispiel und einige methodische Hinweise zum praktischen Einsatz.

Wir (Peter und Gernot) sind zwischen Bildern und Text hin- und hergerissen und haben keine eindeutige Präferenz. Manche unserer Stakeholder kommen prima mit textuellen Beispielen zurecht, andere mögen lieber grafische Notationen. Ein kurzer Domain-Storytelling-Workshop – eine bis zwei Stunden – kann Ihnen helfen, hier Klarheit zu schaffen.

Beispiele als ausführbare Spezifikation

Insbesondere finden wir an Beispielen nützlich, dass wir diese Art von Spezifikationen automatisiert ausführen (testen!) können: Beispiele in Form von Testfällen werden schon seit langer Zeit als Grundlage für Tests verwendet – da liegt es doch nahe, sie auch für die Klärung von Anforderungen heranzuziehen. An Test-driven Development (TDD) haben Sie sich als Architekt*in hoffentlich schon vor Jahren gewöhnt, da beschreiben Sie das Verhalten letztlich endlich auch exemplarisch. Diesen Gedanken hat Dan North schon 2009 weitergedacht, nämlich in Richtung ausführbarer Spezifikationen: Dan hat BDD (Behavior-driven Development) erstmalig 2009 auf einer Konferenz vorgestellt und als technische Lösung dazu JBehave gebaut. Mittlerweile gibt es mit YatSpec, Cucumber, Jasmine und Squish eine Reihe von Alternativen für unterschiedliche Programmiersprachen. Grundidee ist immer, Anforderungen in einer einfachen DSL exemplarisch zu beschreiben, die ein BDD Framework dann ausführen kann.

Fazit

Konkrete Beispiele können helfen, funktionale Anforderungen besser zu verstehen oder zu erklären als abstrakte Modelle das können. Mit Beispielen bekommen Sie niemals vollständige Spezifikationen, aber das ist in vielen Fällen auch gar nicht nötig. Technische Optionen wie Behavior-driven Development und/oder Domain Storytelling helfen, beispielhaft und anschaulich funktionale Anforderungen zu klären. BDD bringt zusätzlich die Option mit, Anforderungen als ausführbare(!) Spezifikation ständig auf ihre Einhaltung hin prüfen zu können.

Und als kleiner Ausblick: In den nächsten Folgen gehen wir das Thema Qualitätsanforderungen an, bei dem wir dann wiederum von Beispielen profitieren werden. Bis dahin möge die Macht guter Anforderungen mit Ihnen sein!