Lastenheft vs. Pflichtenheft - Der Unterschied einfach erklärt

Lastenheft und Pflichtenheft - zwei Begriffe, die in Softwareprojekten immer wieder auftauchen und fast genauso oft verwechselt werden. Dabei ist der Unterschied einfach: Das eine beschreibt, WAS gebaut werden soll, das andere, WIE es gebaut wird.

Der Unterschied auf einen Blick

	Lastenheft	Pflichtenheft
Erstellt von	Auftraggeber (du)	Auftragnehmer (Entwickler/Agentur)
Beantwortet	WAS soll gebaut werden?	WIE wird es gebaut?
Zeitpunkt	Vor der Ausschreibung/Anfrage	Als Reaktion auf das Lastenheft
Fokus	Fachliche Anforderungen	Technische Umsetzung
Detailgrad	Funktional, nicht technisch	Technisch, konkret bis ins Detail
Beispielinhalt	"Nutzer sollen sich einloggen können"	"Login via JWT-Token, Session-Dauer 24h, bcrypt-Hashing"

Das Lastenheft: WAS soll gebaut werden?

Das Lastenheft beschreibt die Anforderungen des Auftraggebers. Es beantwortet die Frage: Was soll das System können?

Wer erstellt es? Der Auftraggeber (also du als KMU oder Unternehmen). Nicht der Entwickler.

Was steht drin?

Ziele und Zweck des Systems
Funktionale Anforderungen (was das System tun soll)
Nicht-funktionale Anforderungen (Performance, Sicherheit, Verfügbarkeit)
Abgrenzung (was das System nicht tun soll)
Randbedingungen (Technologien, Gesetze, Integrationen)

Typischer Fehler: Viele Unternehmen beauftragen Entwickler ohne Lastenheft und hoffen, dass der Entwickler schon weiß, was gemeint ist. Das endet fast immer in Missverständnissen.

Das Pflichtenheft: WIE wird es gebaut?

Das Pflichtenheft beschreibt die technische Lösung des Auftragnehmers. Es beantwortet die Frage: Wie wird das Lastenheft technisch umgesetzt?

Wer erstellt es? Der Auftragnehmer (Entwickler, Agentur, Softwarehaus) - als Reaktion auf das Lastenheft.

Was steht drin?

Technische Architektur
Datenmodelle und Schnittstellen
Implementierungsdetails
Testszenarien
Zeitplanung und Meilensteine

Ein Anforderungspunkt in beiden Dokumenten

Am konkretesten wird der Unterschied, wenn man dieselbe Anforderung in beiden Dokumenten sieht:

Im Lastenheft steht:

"Kunden sollen sich mit E-Mail und Passwort registrieren und einloggen können. Passwörter dürfen nicht im Klartext gespeichert werden."

Im Pflichtenheft steht dazu:

"Registrierung und Login werden über JWT-Tokens umgesetzt. Passwörter werden mit bcrypt (Kostenfaktor 12) gehasht. Die Session-Dauer beträgt 24 Stunden, danach ist ein erneuter Login erforderlich. Bei fünf fehlgeschlagenen Login-Versuchen wird das Konto für 15 Minuten gesperrt."

Das Lastenheft sagt, was passieren soll und welche Rahmenbedingung gilt (kein Klartext). Das Pflichtenheft übersetzt das in eine konkrete technische Lösung (JWT, bcrypt, Sperrlogik) - Entscheidungen, die technisches Fachwissen erfordern und deshalb beim Auftragnehmer liegen.

Der Zusammenhang

Lastenheft (Auftraggeber) → Pflichtenheft (Auftragnehmer)
WAS?                        WIE?

Das Pflichtenheft ist die Antwort auf das Lastenheft. Ein gutes Pflichtenheft zeigt, dass der Auftragnehmer das Lastenheft vollständig verstanden hat.

Woher kommen die Begriffe?

Lastenheft und Pflichtenheft stammen ursprünglich aus dem deutschen Maschinen- und Anlagenbau. Die klassische Referenz ist die VDI-Richtlinie 2519, die die Vorgehensweise bei der Erstellung von Lasten- und Pflichtenheften für automatisierte Anlagen beschreibt. Der Ansatz - erst die fachlichen Anforderungen festhalten, dann die technische Lösung dokumentieren - wurde später auf Softwareprojekte übertragen und ist heute fester Bestandteil deutscher Ausschreibungs- und Vertragspraxis.

Im internationalen Kontext gibt es kein exaktes Gegenstück. Am nächsten kommt der IEEE-830-Standard für eine Software Requirements Specification (SRS), der ähnliche Inhalte wie ein Lastenheft fordert: eindeutige, testbare und priorisierte Anforderungen. Der Unterschied: IEEE 830 trennt nicht so strikt zwischen Auftraggeber- und Auftragnehmerdokument wie die deutsche Praxis, sondern beschreibt meist ein gemeinsames Anforderungsdokument. Für Festpreisprojekte in Deutschland hat sich die klare Trennung in zwei Dokumente bewährt, weil sie Verantwortlichkeiten eindeutig zuordnet: Wer entscheidet WAS, wer entscheidet WIE.

Vom Beispiel zur Abnahme: So schließt sich der Kreis

Bleiben wir beim Login-Beispiel von oben. Nachdem das Pflichtenheft steht, folgt der nächste Schritt: die Abnahmekriterien. Sie leiten sich direkt aus beiden Dokumenten ab und sollten schon vor Projektstart schriftlich festgehalten werden, nicht erst bei der Lieferung.

Für unser Beispiel könnten die Abnahmekriterien so aussehen:

Ein Nutzer kann sich mit gültiger E-Mail und Passwort registrieren; das Passwort wird nachweislich nicht im Klartext in der Datenbank gespeichert.
Nach fünf fehlgeschlagenen Login-Versuchen in Folge wird das Konto für 15 Minuten gesperrt, eine entsprechende Meldung erscheint im Frontend.
Nach 24 Stunden Inaktivität wird die Session ungültig, ein erneuter Login ist erforderlich.

Ohne diesen dritten Schritt bleibt offen, wer am Ende der Umsetzung entscheidet, ob eine Anforderung erfüllt ist. In der Praxis ist genau das der häufigste Streitpunkt bei der Abnahme: Der Auftraggeber prüft gegen sein Verständnis vom Lastenheft, der Entwickler liefert gegen seine Interpretation im Pflichtenheft - und ohne vorher vereinbarte Abnahmekriterien haben am Ende beide Seiten recht und trotzdem ein Problem.

Typische Verwechslungen und ihre Folgen

Verwechslung 1: Der Auftraggeber schreibt technische Details ins Lastenheft. Etwa "die Login-Funktion soll mit JWT umgesetzt werden". Das schränkt den Entwickler unnötig ein - vielleicht hat er eine bessere oder günstigere technische Lösung für dieselbe Anforderung. Ergebnis: höhere Kosten oder eine technisch suboptimale Umsetzung, nur weil der Auftraggeber sich in Details eingemischt hat, die eigentlich Sache des Entwicklers sind.

Verwechslung 2: Der Auftragnehmer beginnt ohne echtes Lastenheft zu entwickeln. Er interpretiert mündliche Absprachen oder eine grobe E-Mail als ausreichende Grundlage. Ergebnis: Am Ende des Projekts stellt sich heraus, dass die gelieferte Software nicht das ist, was sich der Auftraggeber vorgestellt hat - und beide Seiten sind sich uneinig, wer dafür verantwortlich ist, weil es keine schriftliche Grundlage gab.

Verwechslung 3: Das Pflichtenheft wird nie mit dem Lastenheft abgeglichen. Der Auftraggeber erhält ein Pflichtenheft, versteht es nicht (weil es technisch ist) und unterschreibt es ungeprüft. Erst bei der Abnahme fällt auf, dass eine Anforderung aus dem Lastenheft im Pflichtenheft fehlt oder anders interpretiert wurde.

Verwechslung 4: Anforderungen ändern sich, aber nur ein Dokument wird aktualisiert. Während des Projekts kommt häufig eine neue Anforderung dazu oder eine bestehende ändert sich. Wird das nur im Pflichtenheft nachgetragen, weil es näher am Code ist, verliert das Lastenheft seine Funktion als verbindliche Referenz für den Auftraggeber. Ergebnis: Bei der nächsten Abnahme wird gegen ein veraltetes Lastenheft geprüft, während die Software längst nach dem aktualisierten Pflichtenheft gebaut wurde - eine Quelle für Change-Request-Streit, die sich mit einer einfachen Versionierung beider Dokumente vermeiden lässt.

Warum beide Dokumente wichtig sind

Ohne Lastenheft: Der Entwickler interpretiert frei. Was geliefert wird, entspricht seiner Interpretation - nicht deiner Vorstellung.

Ohne Pflichtenheft: du weißt nicht, wie der Entwickler deine Anforderungen umsetzen will. Überraschungen sind vorprogrammiert.

Mit beiden Dokumenten: Beide Seiten sind auf dem gleichen Stand. Missverständnisse werden vor Projektstart - nicht danach - aufgedeckt.

Checkliste: Ist dein Lastenheft vollständig?

Ziele und Zweck des Systems sind beschrieben
Alle funktionalen Anforderungen sind einzeln und nummeriert aufgeführt
Nicht-funktionale Anforderungen (Performance, Sicherheit, Verfügbarkeit) sind enthalten
Es gibt eine explizite Abgrenzung ("Das System soll NICHT...")
Randbedingungen (bestehende Systeme, Gesetze, Budget) sind genannt
Jede Anforderung ist priorisiert (must-have vs. nice-to-have)

Eine vollständige, ausfüllbare Vorlage mit Praxisbeispiel findest du in unserem Leitfaden Lastenheft erstellen ohne IT-Hintergrund.

Pairlio und das Lastenheft

Pairlio analysiert dein Lastenheft (oder Briefing) mit KI:

Vollständigkeitsprüfung: Fehlen wichtige Anforderungen?
Widerspruchsanalyse: Gibt es technisch unverträgliche Anforderungen?
Aufwandsschätzung: Wie viele Entwicklertage braucht jede Anforderung?

Das Ergebnis ist ein strukturiertes Anforderungsdokument, das als Grundlage für ein verbindliches Festpreisangebot dient.

Lastenheft & Pflichtenheft jetzt kostenlos prüfen →

Häufig gestellte Fragen

Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?

Das Lastenheft beschreibt die Anforderungen des Auftraggebers und beantwortet die Frage, was das System können soll. Das Pflichtenheft beschreibt die technische Lösung des Auftragnehmers und beantwortet die Frage, wie diese Anforderungen umgesetzt werden. Das Pflichtenheft ist damit die Antwort auf das Lastenheft.

Wer erstellt das Lastenheft und wer das Pflichtenheft?

Das Lastenheft erstellt der Auftraggeber, also das Unternehmen, das die Software in Auftrag gibt. Das Pflichtenheft erstellt der Auftragnehmer, also der Entwickler, die Agentur oder das Softwarehaus, als Reaktion auf das Lastenheft.

Was passiert, wenn ein Projekt ohne Lastenheft startet?

Ohne Lastenheft interpretiert der Entwickler die Anforderungen frei. Was am Ende geliefert wird, entspricht dann seiner Interpretation und nicht zwangsläufig der Vorstellung des Auftraggebers. Das ist eine der häufigsten Ursachen für Missverständnisse und Nacharbeit in Softwareprojekten.

Was gehört inhaltlich in ein Lastenheft?

Ein vollständiges Lastenheft enthält die Ziele und den Zweck des Systems, funktionale und nicht-funktionale Anforderungen, eine klare Abgrenzung dessen, was das System nicht tun soll, sowie Randbedingungen wie Technologien, gesetzliche Vorgaben und benötigte Integrationen. Eine ausfüllbare Vorlage findest du in Lastenheft erstellen ohne IT-Hintergrund.

Braucht jedes Softwareprojekt ein separates Pflichtenheft?

Bei sehr kleinen Projekten wird das Pflichtenheft manchmal informell im Angebot oder in der Projektplanung mitgeliefert, statt als eigenes Dokument. Bei mittleren bis großen Projekten - und immer dann, wenn ein Festpreis vereinbart wird - lohnt sich ein eigenständiges Pflichtenheft, weil es die Grundlage für die spätere Abnahme bildet: Nur was darin steht, lässt sich eindeutig prüfen.

Wie hängen Lastenheft, Pflichtenheft und Abnahmekriterien zusammen?

Die Abnahmekriterien sind die konkrete, prüfbare Übersetzung dessen, was Lastenheft und Pflichtenheft gemeinsam festlegen. Sie sollten schon vor Projektstart schriftlich vereinbart werden, nicht erst bei der Lieferung. Fehlen sie, bleibt am Ende offen, wer entscheidet, ob eine Anforderung tatsächlich erfüllt ist - das ist einer der häufigsten Streitpunkte bei der Softwareabnahme.