Nach der Spezifikation: Nachverfolgbarkeit, Versionierung und Änderungen

Die meisten Teams behandeln das Schreiben der Spezifikation als Ziellinie. Das ist sie nicht — es ist die Startlinie. Das Dokument vom ersten Tag leistet seine eigentliche Arbeit in den Monaten danach — und nur, wenn es nachverfolgbar, versioniert und änderungskontrolliert ist.

Ein statisches Dokument in einer Datei sagt Ihnen, was einmal gewünscht war. Eine lebende Spezifikation sagt Ihnen, was jetzt gewünscht ist, warum es sich geändert hat und ob alles Versprochene tatsächlich gebaut und getestet ist. Dieser Beitrag handelt von dem Unterschied.

Die Spezifikation ist ein lebendes Dokument, kein Liefergegenstand

Anforderungen ändern sich. Kunden ändern ihre Meinung, Regulierer ändern die Regeln, und die Realität ändert die Randbedingungen. Wenn Ihre Spezifikation diese Änderungen nicht festhält, hört sie still auf, der Vertrag zu sein, und wird zum historischen Artefakt.

Die Disziplin, die sie am Leben hält, hat drei Teile: Nachverfolgbarkeit, Versionierung und Änderungsmanagement.

Nachverfolgbarkeit: warum sie wichtig ist

Nachverfolgbarkeit ist die Verbindung von einer Anforderung zu Entwurf, Code und Tests, die sie erfüllen. In der Praxis oft eine Matrix: Anforderungen in den Zeilen, die nachgelagerten Artefakte in den Spalten, und ein Zeichen, wo eines das andere erfüllt.

Es klingt nach Papierkram. Tatsächlich ist es die Antwort auf drei Fragen, die jedem Projekt irgendwann gestellt werden:

• Abdeckung — haben wir alles Versprochene gebaut, oder gibt es Anforderungen ohne etwas dahinter?
• Auswirkung — wenn sich diese Anforderung ändert, was bricht dann?
• Audit — können wir Anforderung für Anforderung nachweisen, dass sie umgesetzt und verifiziert wurde?

Baselines und Versionen

Eine Baseline ist eine Momentaufnahme der Spezifikation zu einem sinnvollen Zeitpunkt — vor einem Release, bei einem Meilenstein, bei der Vertragsunterzeichnung. Jede Baseline ist eine Version, zu der man zurückkehren kann.

Versionen erfüllen zwei Aufgaben. Sie geben einen Rücksetzpunkt, wenn eine Änderung schiefgeht, und sie geben eine Historie: wer hat was, wann und warum geändert. Ohne Versionen hat „was haben wir eigentlich vereinbart?“ keine Antwort.

Änderungsmanagement

Eine Änderung an einer Anforderung ist eine Änderung am Vertrag und sollte auch so behandelt werden. Die Disziplin ist einfach: Eine Änderung wird beantragt, ihre Auswirkung wird bewertet, sie wird von jemandem mit Befugnis angenommen oder abgelehnt und — falls angenommen — an der betroffenen Anforderung dokumentiert.

Das Schlüsselwort ist dokumentiert. Eine undokumentierte Änderung ist eine Landmine: Der Code spiegelt sie wider, die Spezifikation nicht — und der Nächste, der beides liest, wird in die Irre geführt.

Warum sich hier ein Werkzeug lohnt

In einem Dokument, das in einer gemeinsamen Ablage liegt, lässt sich all das nicht gut machen. Versionierung wird zu „final_v2_wirklich_final.docx“, Nachverfolgbarkeit zu einer Tabelle, die aus dem Takt gerät, und Änderungsmanagement zu einer Erinnerung. Der Wert eines echten Anforderungssystems liegt darin, dass die Spur automatisch gepflegt wird: Jede Anforderung ist verknüpft, versioniert und prüfbar — ohne manuelles Ritual.

Das ist der Unterschied zwischen einem Dokument und einem System — und der Unterschied zwischen einer Spezifikation, die man einmal liest, und einer, die Sie über die gesamte Lebensdauer des Produkts schützt.