Wann braucht man überhaupt eine schriftliche Spezifikation?

„Brauchen wir dafür eine schriftliche Anforderungsspezifikation?“ ist die falsche Frage. Die richtige lautet: Ab welchem Punkt kostet es mehr, keine zu haben, als eine zu schreiben?

Die ehrliche Antwort ist manchmal: nie. Ein Wegwerf-Skript, ein Wochenend-Prototyp, ein einmaliges internes Werkzeug — nichts davon braucht eine formale Spezifikation. Dieser Beitrag liefert eine Entscheidungsregel, damit Sie nicht mehr darüber streiten, sondern schreiben — oder aufhören zu schreiben und anfangen zu bauen.

Das Spektrum

Formalität sollte dem Risiko folgen. Die meiste Arbeit fällt in eines von vier Bändern:

• Wegwerf-Prototyp oder Skript — keine Spezifikation. Der Code ist die Spezifikation; funktioniert er, ist es gut — und Sie werfen ihn ohnehin weg.
• MVP oder frühes Produkt — ein einseitiges Briefing. Ziele, der Kernablauf und was ausdrücklich außerhalb des Umfangs liegt. Genug, um ein kleines Team auszurichten.
• Langlebiges Produkt oder Mehr-Team-Bau — eine echte, versionierte und nachverfolgbare Anforderungsspezifikation. Das ist das Lastenheft.
• Reguliertes oder sicherheitskritisches System — eine vollständige Spezifikation ist Pflicht, mit Nachverfolgbarkeit von der Anforderung über den Entwurf bis zum Test. Kein Nice-to-have, sondern der Audit-Trail.

Die Auslöser, die den Schalter umlegen

Wenn auch nur einer dieser Punkte zutrifft: erst aufschreiben, dann bauen.

• Mehr als eine Person oder ein Team baut dagegen — Sie brauchen eine gemeinsame, schriftliche Definition von „fertig“.
• Jemand anderes wird es warten — die nächste Person kann Ihre Gedanken nicht lesen.
• Ein Kunde oder Prüfer fragt später „was haben wir vereinbart?“ — Sie brauchen den unterschriebenen Nachweis.
• Es berührt Sicherheit, Security, Geld oder Compliance — die Kosten eines Fehlers sind inakzeptabel.
• Sie können es sich nicht leisten, es zweimal zu bauen — eine Spezifikation ist der günstigste Weg, es einmal zu bauen.
• Es muss mit anderen Systemen integriert werden — Schnittstellen müssen festgelegt sein, bevor beide Seiten bauen.

Eine Entscheidungsregel zum Anwenden

Schreiben Sie auf, wenn die Kosten einer falschen Annahme die Kosten des Schreibens übersteigen. Das ist die ganze Regel. Kostet eine missverstandene Anforderung einen Nachmittag Nacharbeit, lassen Sie die Spezifikation weg. Kostet sie ein Vierteljahr Hardware, einen Zertifizierungszyklus oder einen öffentlichen Launch, ist die Spezifikation die günstigste Versicherung, die Sie kaufen können.

Beachten Sie: Die Regel betrifft Konsequenzen, nicht Teamgröße oder Budget. Ein Zwei-Personen-Team, das ein sicherheitskritisches Gerät baut, braucht die Spezifikation weit mehr als ein Fünfzig-Personen-Team, das ein internes Dashboard baut.

Was „schriftlich“ tatsächlich bedeutet

Eine Spezifikation ist kein einziges 200-seitiges Dokument, das man entweder hat oder nicht. Sie ist eine Skala — und Sie passen die Formalität dem Risiko an.

Ein einseitiges Briefing für das MVP. Eine Funktionsliste mit Abnahmekriterien für das Produkt. Ein vollständiges Lastenheft/Pflichtenheft-Paar für das regulierte System. Der Fehler ist nicht, zu wenig zu schreiben — sondern zu viel für das Risiko, was das Team in Prozessen begräbt, oder zu wenig, was es in Nacharbeit begräbt.

Drei Fälle

• Ein Datenmigrations-Skript — weglassen. Ist das Schema falsch, merken Sie es in Minuten und lassen es neu laufen.
• Ein Web-MVP eines Startups — eine Seite: für wen es ist, was es unbedingt können muss, was Sie bewusst noch nicht bauen.
• Ein Batteriespeichersystem mit Leistungselektronik (PCS) — volle Spezifikation. Sicherheit, Hardware, Zertifizierung und die Integration mit einer Monitoring-Plattform treffen hier zusammen; eine falsche Anforderung ist kein erneuter Lauf, sondern ein Rückruf.