Lastenheft erstellen ohne IT-Hintergrund - Der komplette Leitfaden mit Vorlage

"Ich bin kein Techniker, wie soll ich ein Lastenheft erstellen?" 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, nicht der Entwickler.

Dieser Leitfaden zeigt dir Schritt für Schritt, wie du ein vollständiges Lastenheft erstellst: mit einer copy-paste-fertigen Vorlage, einem durchgerechneten Praxisbeispiel und einer Checkliste gegen die häufigsten Fehler.

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, bevor er überhaupt seine eigene Lösung entwerfen kann.

Konkret statt allgemein

Die häufigste Fehlerquelle beim Lastenheft erstellen 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.

Lastenheft-Vorlage zum Copy-Paste

Diese Struktur funktioniert für so gut wie jedes Softwareprojekt. Kopiere sie als Ausgangspunkt und fülle jeden Abschnitt für dein Projekt aus:

1. Ziel und Zweck
   - Welches Problem löst das System?
   - Für wen wird es gebaut? (Zielgruppe/Nutzer)
   - Wie wird der Erfolg gemessen?

2. Funktionale Anforderungen
   - Nummerierte, einzelne Anforderungen (kein Fließtext)
   - Jede Anforderung: eine Aussage, ein prüfbares Ergebnis
   - Beispiel: "FA-01: Nutzer können sich per E-Mail und Passwort registrieren."

3. Nicht-funktionale Anforderungen
   - Performance (z. B. Ladezeiten, gleichzeitige Nutzer)
   - Sicherheit (z. B. Datenverschlüsselung, Zugriffsrechte)
   - Verfügbarkeit (z. B. Betriebszeiten, Wartungsfenster)

4. Abgrenzung - was das System NICHT tun soll
   - Explizit ausgeschlossene Funktionen
   - Bewusst spätere Ausbaustufen

5. Randbedingungen
   - Bestehende Systeme, an die angebunden werden muss
   - Gesetzliche Vorgaben (z. B. DSGVO)
   - Budget- und Zeitrahmen

6. Priorisierung
   - Must-have für Version 1
   - Nice-to-have für spätere Versionen

Für jeden dieser sechs Punkte findest du unten ein konkretes Beispiel, damit die Struktur nicht abstrakt bleibt.

Praxisbeispiel: Ein Anforderungspunkt vollständig ausformuliert

Angenommen, du brauchst eine Funktion, mit der Kunden ihre Bestellung stornieren können. So sieht ein gut formulierter Lastenheft-Eintrag dafür aus:

FA-07: Bestellstornierung durch den Kunden Kunden können eine Bestellung im Kundenkonto stornieren, solange sie noch nicht versendet wurde. Nach der Stornierung erhält der Kunde innerhalb von 5 Minuten eine Bestätigungs-E-Mail. Der Bestellstatus wechselt sofort sichtbar auf "storniert". Eine Rückerstattung wird nicht automatisch ausgelöst, sondern manuell vom Kundenservice geprüft (siehe Abgrenzung).

Dieser eine Absatz beantwortet, was passieren soll, wer betroffen ist, wie schnell reagiert wird und was explizit nicht automatisch passiert. Ein Entwickler kann daraus direkt ein Pflichtenheft ableiten, ohne Rückfragen stellen zu müssen. Vergleiche das mit einer vagen Version wie "Kunden sollen stornieren können" - daraus lässt sich weder ein Zeitrahmen noch der Umgang mit Rückerstattungen ableiten, und genau diese Lücken werden später zu teuren Nachforderungen.

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.

Häufige Fehler beim Lastenheft erstellen

Fehler 1: Lösungen statt Anforderungen beschreiben. "Wir brauchen eine Suchleiste mit Elasticsearch" ist eine technische Lösung, keine Anforderung. Die Anforderung dahinter ist: "Nutzer sollen Produkte anhand von Namen oder Kategorie in unter 2 Sekunden finden." Wie das technisch gelöst wird, ist Aufgabe des Entwicklers.

Fehler 2: Fehlende Abgrenzung. Ein Lastenheft ohne "Das soll das System NICHT tun" lädt zu Scope Creep ein, weil jede zusätzliche Funktion im Zweifel "irgendwie mit gemeint" sein könnte.

Fehler 3: Alles ist "must-have". Wenn jede Anforderung höchste Priorität hat, gibt es faktisch keine Priorisierung - und keine Grundlage für Entscheidungen, wenn Zeit oder Budget knapp werden.

Fehler 4: Kein Review durch eine zweite Person. Was für dich eindeutig klingt, kann für jemand anderen mehrdeutig sein. Ein zweites Augenpaar - intern oder extern - findet Lücken, die dir selbst nicht mehr auffallen.

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 nach der Vorlage oben 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, welche fehlen und wo sich Widersprüche verstecken, bevor du das Dokument an einen Entwicklungspartner gibst.

Lastenheft jetzt kostenlos mit KI erstellen →

Häufig gestellte Fragen

Wie lang sollte ein Lastenheft sein?

Es gibt keine feste Seitenzahl - entscheidend ist Vollständigkeit, nicht Länge. Ein Lastenheft für ein kleines internes Tool kann zwei Seiten haben, eines für eine komplexe Plattform zwanzig. Wichtiger als die Länge ist, dass jede der sechs Kategorien aus der Vorlage oben abgedeckt ist.

Muss ich das Lastenheft allein schreiben oder kann ich es mit einem Team erstellen?

Ein Lastenheft profitiert fast immer von mehreren Perspektiven - zum Beispiel Fachabteilung, IT-Ansprechpartner im Haus und gegebenenfalls der Geschäftsführung für Budget- und Prioritätsfragen. Wichtig ist nur, dass am Ende eine Person die Verantwortung für die finale Version übernimmt, damit das Dokument in sich konsistent bleibt.

Was ist der Unterschied zwischen einem Lastenheft und einem Pflichtenheft?

Das Lastenheft beschreibt die Anforderungen des Auftraggebers (WAS soll gebaut werden), das Pflichtenheft die technische Lösung des Auftragnehmers (WIE wird es umgesetzt). Eine ausführliche Gegenüberstellung mit Beispielen findest du in Lastenheft vs. Pflichtenheft - der Unterschied einfach erklärt.

Was kostet die Erstellung eines Lastenhefts?

Wenn du es selbst nach der Vorlage oben schreibst, kostet es nur deine Zeit - meist ein bis zwei Arbeitstage für ein mittelgroßes Projekt. Lässt du es von einem externen Berater erstellen, hängen die Kosten stark vom Projektumfang ab. Eine KI-gestützte Prüfung deines eigenen Entwurfs ist eine kostenlose Zwischenlösung, die die häufigsten Lücken vor der Weitergabe an einen Entwicklungspartner aufdeckt.