Eine Spezifikation schreiben, die Entwickler wirklich lesen

Was hineingehört und was nicht

Eine Spezifikation, die jedes Pixel beschreibt, wird nach zwei Wochen von niemandem mehr gepflegt. Eine, die nur eine Vision beschreibt, erzeugt zwanzig Rückfragen am Tag. Der Punkt dazwischen: pro Fähigkeit — wer sie nutzt, was auf dem Normalweg passiert, was bei einem Fehler passiert, und unter welcher Bedingung sie als fertig gilt.

Abnahmekriterien ersparen die meisten Diskussionen. „Die Nutzerin erhält innerhalb einer Minute eine Benachrichtigung“ ist ein Kriterium; „der Vorgang soll schnell sein“ ist ein Wunsch.

Abläufe beschreiben, keine Bildschirme

Beschreiben Sie den Ablauf als Folge: Ausgangszustand, Aktion, Ergebnis. Danach die Fehlerpfade — keine Verbindung, Abbruch mittendrin, defekte Datei, verweigerte Berechtigung. In realen Projekten sind Fehlerpfade die Hälfte der Arbeit und ein Viertel der Spezifikation.

Bildschirme werden neu gestaltet, Abläufe bleiben. Deshalb wird das Design aus der Spezifikation verlinkt und nicht in sie eingebettet.

Der Teil, den alle überspringen

Halten Sie ausdrücklich fest, was außerhalb des Umfangs dieser Version liegt. Eine „Nicht jetzt“-Liste ist ein Steuerungsinstrument, keine Entschuldigung: Sie erlaubt „richtig, und das kommt als Nächstes“ statt einer Neuauflage der Debatte in jeder Sitzung.

Ergänzen Sie die Annahmen, auf die Sie sich stützen. Eine aufgeschriebene Annahme ist ein gesteuertes Risiko; eine ungeschriebene ist eine Überraschung.