Software-Anforderungen dokumentieren ohne IT-Hintergrund – Ein Leitfaden für Fachabteilungen

"Ich bin kein Techniker, wie soll ich ein Anforderungsdokument schreiben?" Die gute Nachricht: Ein Lastenheft ist kein technisches Dokument. Es beschreibt, was das System können soll – nicht, wie es technisch umgesetzt wird. Genau dafür bist Du als Fachabteilung die richtige Person.

Der wichtigste Grundsatz: WAS, nicht WIE

Schreibe nicht "die Datenbank soll Nutzerdaten in einer separaten Tabelle speichern" (das ist Technik – Aufgabe des Entwicklers). Schreibe stattdessen "jeder Nutzer soll sein eigenes Profil mit Namen, E-Mail und Rolle haben" (das ist eine Anforderung – Deine Aufgabe). Wer in WIE-Formulierungen denkt, verwechselt Lastenheft und Pflichtenheft und schränkt den Entwickler unnötig ein.

Konkret statt allgemein

Die häufigste Fehlerquelle sind Formulierungen, die "klar genug" klingen, aber mehrere Interpretationen zulassen.

Vage: "Nutzer sollen benachrichtigt werden." Konkret: "Nutzer erhalten eine E-Mail, wenn eine neue Bestellung eingeht. Die E-Mail wird innerhalb von 5 Minuten nach Bestelleingang verschickt."

Die konkrete Version lässt keinen Interpretationsspielraum – und genau das verhindert spätere Nachforderungen, weil "Benachrichtigung" anders umgesetzt wurde als gedacht.

Die Struktur, die für jedes Lastenheft funktioniert

Ziel und Zweck: Welches Problem löst das System? Für wen?
Funktionale Anforderungen: Was soll das System konkret tun? Am besten als nummerierte, einzelne Anforderungen, nicht als Fließtext.
Nicht-funktionale Anforderungen: Wie schnell, wie sicher, wie verfügbar muss das System sein?
Abgrenzung: Was soll das System explizit nicht tun? Diese Liste ist genauso wichtig wie die Funktionsliste.
Randbedingungen: Bestehende Systeme, gesetzliche Vorgaben, Budgetrahmen.

Die Prioritäten-Frage, die zu oft fehlt

Nicht jede Anforderung ist gleich wichtig. Markiere für jede Anforderung, ob sie für die erste Version zwingend nötig ist oder auch später nachgeliefert werden könnte. Diese Unterscheidung ist der Unterschied zwischen einem MVP, das pünktlich startet, und einem Projekt, das sich endlos verzögert, weil alles gleichzeitig "must-have" ist.

Der Praxistest: Würde ein Fremder es eindeutig umsetzen?

Bevor Du Dein Dokument abschickst, stell Dir die Frage: Könnte ein Entwickler, der Dein Unternehmen nicht kennt, dieses Dokument lesen und genau das bauen, was Du Dir vorstellst – ohne Rückfragen zu stellen? Wenn die Antwort "wahrscheinlich nicht" lautet, ist die jeweilige Anforderung noch zu vage.

Du musst es nicht allein machen

Ein erster Entwurf reicht völlig aus, um damit weiterzuarbeiten – die Feinarbeit übernimmt im zweiten Schritt eine systematische Prüfung. Eine KI-gestützte Analyse zeigt Dir konkret, welche Anforderungen noch zu vage formuliert sind und welche fehlen, bevor Du das Dokument an einen Entwicklungspartner gibst.