Mit Spec(k) fängt man Mäuse – Teil 2: Wie schreibt man eine Spezifikation für Entwickler?
In der Serie „Mit Spec(k) fängt man Mäuse“ erläutere ich mit welchen Modellen, Textbausteinen und Strukturierungen in einer Spezifikation welche Lesergruppe am besten ansprechbar ist. Also welche Mäuse mit welchem Speck am besten gefangen werden können 🙂 .
In meinem letzten Beitrag habe ich beschrieben, wie man eine Spezifikation für Kunden gestalten kann, so dass beide Seiten eine gemeinsame Vorstellung der technischen und geschäftlichen Zusammenhänge bekommen. Am Ende soll eine Software entstehen, die die Erwartung des Kunden hinsichtlich Funktionalität und Qualität erfüllt.
Heute geht es um die Spezifikation für Entwickler:
Welche Informationen brauchen Entwickler?
Entwickler wollen wissen, was sie implementieren sollen. In der Regel wollen sie eine “schöne” Lösung entwickeln. “Schöne” Lösung heißt hierbei nicht etwa ein schön designtes User Interface, sondern vielmehr ein leicht lesbarer Code und leicht nachvollziehbare Implementierungen.
Ein leicht nachvollziehbarer Code entsteht dann, wenn einzelne Komponenten wenige Abhängigkeiten haben. Und wenn Abhängigkeiten nötig sind, werden sie explizit codiert als Interfaces. Dies macht es für einen anderen Entwickler möglich, den Code nachzuvollziehen und auch Fehler zu beseitigen – auch wenn er den Code nicht selber geschrieben hat.
Im folgenden Beispiel wird eine Position einer Rechnung hinzufügt – einmal fast nicht lesbar und einmal auch für einen Nicht-Programmierer (fast) lesbar. 
Beide kleinen Ausschnitte machen genau das gleiche 🙂 . Allerdings kann man beim ersten Beispiel kaum erkennen, was der Code wirklich machen soll, während beim zweiten Beispiel schon klarer wird, was passieren soll (auch wenn man die Kommentare nicht hätte).
Nun ist klarer Code vielleicht ein Ziel von Entwicklern, aber hat wohl doch nichts mit der Spezifikation zu tun. Leider doch! Die Begriffe, die innerhalb des Codes auftauchen – also in unserem Beispiel Invoice und Item – müssen wir aus Business-Sicht in den Spezifikationen definieren.
Hierzu können wir verschiedene Wege gehen – oder diese auch kombinieren.
Ein Glossar ist immer hilfreich und sollte in keiner Spezifikation fehlen. Allerdings kann es sehr lang werden und wenn viele Begriffe zu erklären sind, gehen unter Umständen die Zusammenhänge zwischen den einzelnen Business-Objekten – die wir ja erklären wollen – verloren.
Daher ist es empfehlenswert die Business Objekte, die in unserer Spezifikation auftauchen, in einem sogenannten Domain-Modell zu modellieren. Dieses Modell enthält in einer grafischen Systematik die Zusammenhänge von den Business Objekten – aber wie immer reicht dies allein nicht. Die Business Objekte müssen auch definiert werden – unter der Benutzung der natürlichen Sprache. Die Grafik rechts zeigt unser Beispiel als Domain-Modell.
Und hier geht es gleich weiter: Wie schreibe ich eine Spezifikation für Tester?