Anforderungen 101: Warum, wann und wie man Anforderungen schreibt
Die meisten technischen Fehlschläge werden nicht durch schlechten Code verursacht, sondern dadurch, dass ein Team das Falsche baut — und es erst nach Monaten bemerkt. Anforderungsmanagement ist die Disziplin, festzuhalten, was ein System leisten muss, bevor jemand mit dem Bauen beginnt, damit der teuerste Fehler dort abgefangen wird, wo er am günstigsten zu beheben ist.
Dieser Leitfaden ist die Landkarte: Warum Anforderungen wichtig sind, wann man sie schreiben sollte und wie man sie so formuliert, dass sie den Kontakt mit einem echten Team überstehen.
Was eine Anforderung eigentlich ist
Eine Anforderung ist eine einzelne, überprüfbare Aussage darüber, was ein System tun muss. „Das System muss innerhalb von 5 Sekunden eine E-Mail-Bestätigung senden“ ist eine Anforderung. „Das System muss gut sein“ ist keine — „gut“ lässt sich nicht testen.
Anforderungen liegen an der Grenze zwischen denen, die ein System brauchen, und denen, die es bauen. Sie sind der Vertrag zwischen beiden — und wie jeder Vertrag gewinnen sie ihren Wert dadurch, dass sie konkret, vereinbart und schriftlich festgehalten sind.
Warum schriftliche Anforderungen wichtig sind
Die Kosten eines Fehlers steigen stark, je später man ihn entdeckt. Eine falsche Anforderung, die beim Schreiben auffällt, kostet Minuten. Derselbe Fehler nach dem Release kann das Hundertfache kosten — er hat womöglich Design, Code, Tests, Dokumentation und ein Support-Team hervorgebracht, die alle auf einer falschen Annahme aufbauen.
- Sie machen Meinungsverschiedenheiten sichtbar, bevor sie zu teurer Nacharbeit werden.
- Sie geben jedem Entwickler dieselbe Definition von „fertig“.
- Sie sind die Grundlage für Tests — ohne Anforderung gibt es nichts, wogegen man prüft.
- Sie schützen bei Scope-Änderungen: Eine schriftlich vereinbarte Spezifikation ist die einzige Verteidigung gegen „ich dachte, du wolltest…“.
- In regulierten Bereichen sind sie nicht optional — sie sind der Audit-Trail, der Sie konform hält.
Wann man sie schreiben sollte
Nicht alles braucht eine formale Spezifikation. Ein Wegwerf-Prototyp braucht keine. Ein Produkt, das gewartet, zertifiziert oder an ein anderes Team übergeben werden muss, sehr wohl.
- Es wird über Jahre gewartet — oder von jemand anderem.
- Mehr als ein Team oder eine Person baut dagegen.
- Es berührt Sicherheit, Security oder einen regulierten Bereich.
- Ein Fehler wäre teuer (Hardware, Firmware oder ein öffentlicher Launch).
- Sie müssen — gegenüber Kunde oder Prüfer — nachweisen, was vereinbart wurde.
Wie man eine gute Anforderung schreibt
Gute Anforderungen teilen eine Handvoll Eigenschaften, die in Normen wie ISO/IEC/IEEE 29148 festgehalten sind: Jede Anforderung soll notwendig, eindeutig, atomar, umsetzbar und verifizierbar sein. Ein hilfreicher Einstieg ist die EARS-Notation (Easy Approach to Requirements Syntax), die ein wiederholbares Muster liefert.
- Atomar: Eine Anforderung pro Aussage — „das System muss X“ enthält genau ein X.
- Eindeutig: Ein Leser kann sie nicht auf zwei Arten interpretieren.
- Verifizierbar: Sie können auf einen Test zeigen, der sie als wahr oder falsch belegt.
- „Muss“ für verbindliche Anforderungen, „soll“ für Ziele, „kann“ für Optionen — und niemals vermischen.
- Vage Adjektive wie „schnell“, „freundlich“, „robust“ oder „bei Bedarf“ vermeiden — durch Zahlen ersetzen.
Die deutsche Unterscheidung: Lastenheft und Pflichtenheft
Die deutsche Ingenieurskunst trennt zwei Dokumente, die anderswo oft zu einem verschmelzen. Das Lastenheft beschreibt, WAS der Kunde benötigt — in der Sprache des Kunden. Das Pflichtenheft beschreibt, WIE der Lieferant es umsetzt — verfasst vom Lieferanten.
Die Trennung verhindert den häufigsten Scope-Streit: Der Kunde sagt „ich wollte nur X“, der Lieferant sagt „X bedeutet auch Y“. Ein sauberes Lastenheft ist der Referenzpunkt, den beide Seiten unterschrieben haben.
Ein Beispiel
Dieselbe Idee, einmal schlecht und einmal gut formuliert. Der Unterschied ist der Unterschied zwischen einem testbaren Vertrag und einem Wunsch.
Schlecht: „Das System muss schnell und benutzerfreundlich sein.“
Gut: „Das System muss die Anforderungsliste für ein Dokument mit bis zu 500 Anforderungen innerhalb von 500 ms darstellen, gemessen in einem aktuellen Desktop-Browser auf einem Rechner mit 8 GB RAM.“
Die zweite Formulierung lässt sich testen. Die erste beginnt eine Diskussion. Das ist die gesamte Kunst des Anforderungsmanagements in einer Zeile.