Das Lastenheft beschreibt aus Kundensicht das Was und Warum eines Softwareprojekts, das Pflichtenheft aus Anbietersicht das Wie und Womit. Beide zusammen machen ein Projekt planbar, kalkulierbar und rechtssicher – und verhindern die teuersten Fehler, bevor die erste Zeile Code entsteht.
Der Unterschied liegt in Perspektive und Zeitpunkt: Das Lastenheft beschreibt die Anforderungen aus Sicht des Auftraggebers, das Pflichtenheft die geplante Umsetzung aus Sicht des Auftragnehmers. Das eine ist die Frage, das andere die verbindliche Antwort.
Laut DIN 69901-5 enthält das Lastenheft „die Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers“. Das Pflichtenheft umfasst dagegen „die vom Auftragnehmer erarbeiteten Realisierungsvorgaben“ auf Basis dieses Lastenhefts.
Die Reihenfolge ist fest: Zuerst formuliert der Kunde im Lastenheft, was er braucht. Darauf antwortet die Agentur im Pflichtenheft, wie sie es baut. Erst nach Abnahme des Pflichtenhefts startet die Entwicklung.
| Kriterium | Lastenheft | Pflichtenheft |
|---|---|---|
| Perspektive | Auftraggeber (Kunde) | Auftragnehmer (Agentur) |
| Kernfrage | Was und Warum? | Wie und Womit? |
| Wer erstellt es | Auftraggeber | Auftragnehmer |
| Zeitpunkt | Zuerst, vor der Ausschreibung | Danach, als Antwort darauf |
| Inhalt | Ziele, Anforderungen, Rahmen | Lösung, Architektur, Aufwand |
| Rechtliche Rolle | Grundlage der Ausschreibung | Basis für Vertrag & Abnahme |
Für ein sauberes Fundament lohnt sich diese Trennung fast immer – egal ob Sie eine Software entwickeln lassen oder eine App entwickeln lassen möchten.
Ein Lastenheft ist die strukturierte Sammlung aller Anforderungen an das gewünschte Produkt – formuliert vom Auftraggeber, bewusst lösungsneutral. Es beantwortet, was das System leisten soll und unter welchen Bedingungen, ohne die technische Umsetzung vorwegzunehmen.
Diese Bausteine gehören in ein vollständiges Lastenheft:
Ein gutes Lastenheft bleibt lösungsoffen: Es formuliert Anforderungen als Ziele, nicht als vorgegebene Technik. So kann der Anbieter seine Erfahrung einbringen. Wer noch unsicher ist, holt sich hier früh IT-Beratung dazu.
Ein Pflichtenheft ist die technische Antwort des Auftragnehmers auf das Lastenheft. Es übersetzt jede Anforderung in eine konkrete Lösung und wird damit zur Brücke zwischen Kundenwunsch und Entwicklung. Laut VDI-Richtlinie 2519 beschreibt es die Realisierung aller im Lastenheft geforderten Anforderungen.
Diese Inhalte gehören in ein belastbares Pflichtenheft:
Das Pflichtenheft ist für den Auftraggeber die Kontrollinstanz: Erkennt er darin seine Anforderungen richtig übersetzt wieder, gibt er es frei – und beide Seiten wissen genau, was gebaut wird.
Die Zuständigkeit ist klar geregelt: Der Auftraggeber verfasst das Lastenheft, der Auftragnehmer das Pflichtenheft. Diese Rollenverteilung nach DIN 69901-5 sorgt dafür, dass jeder das beschreibt, was er am besten kennt – der Kunde sein Ziel, die Agentur die Umsetzung.
Lastenheft – der Auftraggeber: Der Kunde kennt sein Geschäft, seine Nutzer und sein Ziel. Er formuliert die Anforderungen, oft mit Unterstützung eines Business Analysten oder externen Beraters.
Pflichtenheft – der Auftragnehmer: Die Agentur oder der Entwickler übersetzt diese Anforderungen in eine technische Lösung. Wie sich Zuständigkeiten je nach Modell verschieben, zeigt der Vergleich Agentur, Freelancer oder Inhouse.
In agilen Projekten verschwimmt die strikte Trennung: Statt eines dicken Pflichtenhefts entstehen Product Backlog, User Stories und Akzeptanzkriterien iterativ. Gerade bei einem MVP ist ein schlankes Lastenheft plus laufende Verfeinerung oft sinnvoller – mehr dazu im Ratgeber MVP: Definition, Vorteile & Ablauf.
Lastenheft und Pflichtenheft sparen Kosten, weil sie Fehler in der billigsten Projektphase aufdecken: der Planung. Ein Missverständnis, das früh auf Papier auffällt, kostet einen Bruchteil dessen, was seine Korrektur nach dem Launch verursacht.
Als Faustregel gilt in der Softwarequalität die „Zehnerregel“ (Rule of Ten): Die Kosten, einen Anforderungsfehler zu beheben, steigen grob um etwa den Faktor zehn pro Projektphase, in der er unentdeckt bleibt. Ein in der Konzeptphase korrigierter Denkfehler ist damit tendenziell um ein Vielfaches günstiger als derselbe Fehler nach dem Go-live. Die genaue Größenordnung schwankt je nach Projekt – die Richtung ist aber stabil: je später, desto teurer.
Die reine Erstellung von Lasten- und Pflichtenheft macht meist nur einen überschaubaren Anteil des Projektbudgets aus – oft im niedrigen bis mittleren einstelligen Prozentbereich, abhängig von Umfang und Komplexität. Der Hebel steht dazu in keinem Verhältnis: Klare Anforderungen reduzieren teure Change Requests, Nacharbeit und Streit über den Leistungsumfang.
Für die Vertragsgestaltung ist das Pflichtenheft zudem die Basis eines Festpreises (Werkvertrag nach § 631 BGB): Ohne definierten Umfang kein belastbarer Festpreis. Wie sich das auf das Budget auswirkt, vertiefen die Ratgeber Software-Entwicklungskosten 2026 und App-Entwicklung Kosten 2026.
Hinweis: Prozent- und Faktorangaben sind marktübliche Größenordnungen und Faustregeln, keine projektgenauen Werte. Der tatsächliche Aufwand hängt vom konkreten Vorhaben ab.
Das Lastenheft beschreibt aus Sicht des Auftraggebers, was und warum etwas entwickelt werden soll – also Ziele, Anforderungen und Rahmenbedingungen. Das Pflichtenheft beschreibt aus Sicht des Auftragnehmers, wie und womit diese Anforderungen technisch umgesetzt werden. Kurz: Das Lastenheft ist die Frage, das Pflichtenheft die verbindliche Antwort. Laut DIN 69901-5 kommt immer erst das Lastenheft, dann das Pflichtenheft.
Das Lastenheft erstellt der Auftraggeber, also der Kunde, der die Software benötigt. Er formuliert darin seine Anforderungen. Das Pflichtenheft erstellt der Auftragnehmer, also die Software-Agentur oder der Entwickler, auf Basis des Lastenhefts. Erst wenn der Auftraggeber das Pflichtenheft abnimmt, beginnt die eigentliche Entwicklung.
Ein Lastenheft enthält typischerweise: Ausgangssituation und Zielsetzung, die funktionalen Anforderungen (Was soll die Software können?), die nicht-funktionalen Anforderungen (Performance, Sicherheit, Bedienbarkeit), Rahmenbedingungen und Schnittstellen sowie Lieferumfang, Termin- und Budgetvorgaben und Abnahmekriterien. Es beschreibt das Was und Warum, nicht die technische Lösung.
Nicht zwingend in voller Form. Bei einem MVP oder einem agilen Projekt genügt oft ein schlankes Lastenheft plus User Stories und Akzeptanzkriterien statt eines umfangreichen Pflichtenhefts. Für Festpreis-Projekte mit klar definiertem Umfang (Werkvertrag) bleibt ein Pflichtenheft dagegen sinnvoll, weil es den vereinbarten Leistungsumfang rechtssicher festhält.
Weitere Grundlagen und Vergleiche finden Sie im Ratgeber, etwa zur Dauer der App-Entwicklung oder zur passenden Flutter-Umsetzung.
Sie haben ein Projekt, aber noch kein sauberes Lastenheft? Wir strukturieren Ihre Anforderungen, erstellen ein belastbares Pflichtenheft und machen daraus einen planbaren Fahrplan – mit klarem Umfang, Aufwand und Zeitplan.