Kolumne: Gute Beispiele statt schlechter Abstarktion

Req4Arcs: BDD und/oder Domain Storytelling

Peter Hruschka, Gernot Starke

© SuS_Media

In den letzten Folgen haben wir Ihnen Optionen für die Darstellung und Klärung funktionaler Anforderungen aufgezeigt. Eingestiegen sind wir über Geschäftsprozesse und haben anschließend die Granularität in kleinen Schritten bis zu User Stories verfeinert [1]. In der letzten Folge haben Sie dann einige Aspekte des Knowledge Crunchings aus dem Domain-driven Design kennengelernt, insbesondere Event Storming und die Ubiquitous Language [2]. Nun stellen wir Ihnen noch eine dritte Perspektive für funktionale Anforderungen vor, nämlich Beispiele.

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.“

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 [4])

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

Wie Sie in Abbildung 1 erkennen, dienen beispielhafte Spezifikationen auch als Grundlage für ausführbare Spezifikationen. Aber lassen Sie uns einen Schritt nach dem Nächsten gehen und zuerst einmal klären, wie Beispiele überhaupt aussehen könnten.

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. 2: Domain Story „Offline-Auskunft“

Abb. 3: Domain Story „Online-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!

Geschrieben von
Peter Hruschka
Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: