Technical Spec

Bevor ein Team mit dem Programmieren beginnt, schreibt oft jemand auf, was genau gebaut werden soll. Dieses Dokument heißt Technical Spec, auf Deutsch technische Spezifikation. Darin steht nicht der fertige Programmcode, sondern der Plan dahinter. Beschrieben wird zum Beispiel, aus welchen Teilen das System bestehen soll und wie diese Teile miteinander reden. Außerdem hält die Spec fest, warum man sich für einen Weg entschieden hat und gegen andere. Man kann sie mit dem Bauplan eines Architekten vergleichen: Er zeigt, wo Wände und Leitungen hinkommen, lange bevor jemand einen Stein setzt.

Warum Teams vor dem ersten Code schreiben

Fehler in einem Plan zu korrigieren kostet fast nichts. Man ändert ein paar Sätze im Dokument. Fehler in fertiger Software zu korrigieren kostet dagegen Wochen. Wer die Spec ernst nimmt, verschiebt das Nachdenken an die billigste Stelle des Projekts.

Ein zweiter Grund ist Abstimmung. An großer Software arbeiten selten Einzelpersonen, sondern Gruppen von zehn oder hundert Leuten. Ohne gemeinsames Dokument baut jeder das, was er sich vorgestellt hat. Am Ende passen die Teile nicht zusammen. Die Spec ist der Punkt, an dem alle dieselbe Vorstellung bekommen.

Wichtig ist die Abgrenzung zum Product Requirements Document, kurz PRD. Das PRD beschreibt, was ein Produkt für die Nutzer können soll. Die Technical Spec beschreibt, wie man das technisch löst. Das eine beantwortet also das Was, das andere das Wie. In der Praxis entsteht die Spec meist als Antwort auf ein vorher geschriebenes PRD.

Was in so einem Dokument steht

Fast jede Spec beginnt mit dem Problem. Ein Satz oder Absatz erklärt, was heute nicht funktioniert oder fehlt. Danach folgen die Ziele und ausdrücklich auch die Nicht-Ziele. Diese Nicht-Ziele sind wichtiger, als sie klingen: Sie halten fest, was das Projekt bewusst nicht lösen wird, und verhindern damit endlose Diskussionen.

Der Hauptteil beschreibt die geplante Lösung. Dazu gehören die einzelnen Bausteine des Systems, die Struktur der gespeicherten Daten und die Schnittstellen. Eine Schnittstelle ist die vereinbarte Art, wie zwei Programmteile Daten austauschen. Oft steht dort auch, wie das System reagiert, wenn etwas schiefgeht. Häufig ergänzt eine einfache Skizze die Beschreibung.

Ein guter Abschnitt heißt Alternativen. Dort stehen die Wege, die man geprüft und verworfen hat, samt Begründung. Das klingt nach überflüssiger Mühe, spart aber später viel Zeit. Wenn ein Jahr danach jemand fragt, warum das System so gebaut ist, steht die Antwort schwarz auf weiß im Dokument. Zum Schluss durchläuft die Spec meist ein Review, also eine Prüfung durch erfahrene Kolleginnen und Kollegen, die Kommentare hinterlassen.

Von Bahnhofsuhren bis zu KI-Projekten

Der Begriff kommt nicht aus der Software, sondern aus dem Ingenieurwesen. Bevor eine Brücke oder eine Uhr gebaut wird, gibt es eine Spezifikation mit Maßen, Materialien und Toleranzen. Software hat das Prinzip übernommen. Bei großen Firmen wie Google oder Amazon ist das Schreiben einer Spec ein normaler Teil der Arbeit von Entwicklerinnen und Entwicklern.

In Nachrichten begegnet der Begriff oft im Zusammenhang mit Standards. Wenn ein Gremium eine neue Version von WLAN oder USB festlegt, veröffentlicht es eine Spec. Hersteller weltweit bauen dann Geräte nach diesem Dokument, damit alles zusammenpasst. Auch KI-Anbieter veröffentlichen Spezifikationen für ihre Schnittstellen, damit andere Firmen ihre Modelle in eigene Produkte einbauen können.

Ein verbreiteter Irrtum ist, dass eine Spec unveränderlich sei. In der Praxis ist sie ein lebendes Dokument. Sobald sich beim Bauen zeigt, dass ein Teil des Plans nicht funktioniert, wird die Spec angepasst. Sie ersetzt also nicht das Ausprobieren, sondern gibt ihm eine Richtung. Interessant ist, dass KI-Assistenten diesen Text zunehmend selbst nutzen: Wer einem Modell eine saubere Spec gibt, bekommt deutlich brauchbareren Code zurück als bei einer vagen Anweisung.