Hanse Holding
Projekt besprechen

Wissen

Lastenheft und Pflichtenheft: der Unterschied, mit Beispiel bis zur Abnahme

Zwei Dokumente, die ständig verwechselt werden. Das eine schreibst du, das andere der Anbieter. Wir bekommen Lastenhefte auf den Tisch und machen daraus Angebot, Pflichtenheft und am Ende eine Abnahme. Hier steht, was in welches Dokument gehört, wie eine einzelne Anforderung durch alle drei Stufen läuft und was im Streitfall rechtlich zählt.

Kurz gesagt

Das Lastenheft schreibt der Auftraggeber. Es beschreibt das Was und Wozu: Ziele, Anforderungen, Rahmen. Das Pflichtenheft schreibt der Auftragnehmer als Antwort darauf. Es beschreibt das Wie und Womit, also die technische Umsetzung, und wird meistens Teil des Vertrags.

Eselsbrücke: Im Lastenheft stehen die Lasten, die du dem Anbieter auferlegst. Im Pflichtenheft stehen die Pflichten, die er dafür übernimmt.

Lastenheft und Pflichtenheft im direkten Vergleich

LastenheftPflichtenheft
Wer schreibt esDer Auftraggeber, also duDer Auftragnehmer, also die Agentur oder der Dienstleister
KernfrageWas soll entstehen und wozu?Wie und womit wird es gebaut?
InhaltZiele, Anforderungen, Rahmen, AbnahmekriterienLösung je Anforderung, Architektur, Abgrenzung, Testfälle
ZeitpunktVor der AnbieterauswahlNach dem Lastenheft, vor dem Bau
ZweckVergleichbare Angebote einholenVerbindlicher Plan und Maßstab für die Abnahme
RechtlichGrundlage der Ausschreibung, selten selbst VertragWird meist Vertragsbestandteil
Auf EnglischCustomer oder User Requirements SpecificationFunctional Specification

Was die Norm sagt

Die Begriffe sind in der DIN 69901-5 festgelegt, der deutschen Norm für Begriffe im Projektmanagement. Dort heißt das Lastenheft die "vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages".

Das Pflichtenheft beschreibt die Norm sinngemäß als die vom Auftragnehmer erarbeiteten Realisierungsvorgaben, mit denen er das Lastenheft des Auftraggebers umsetzt. Also: wie und womit die Forderungen erfüllt werden.

Für Software wichtiger als jede deutsche Norm ist die internationale ISO/IEC/IEEE 29148. Sie regelt, wie man Anforderungen so formuliert, dass sie eindeutig und prüfbar sind: eine Anforderung pro Satz, ohne Interpretationsspielraum, mit einem Weg, sie zu testen.

Welche Norm wofür

DIN 69901-5
Begriffe: was ein Lastenheft und ein Pflichtenheft ist.
ISO/IEC/IEEE 29148
Anforderungen an Software und Systeme sauber formulieren.
VDI 2519 Blatt 1, VDI/VDE 3694
Vorgehen bei Lasten- und Pflichtenheften für Anlagen und Automatisierungstechnik. Für eine Web- oder Business-Software passen sie nur bedingt.

Was ins Lastenheft gehört

Vollständigkeit um jeden Preis ist nicht das Ziel. Das Ziel ist, dass ein Anbieter danach ein belastbares Angebot rechnen kann, ohne zu raten.

Gib jeder Anforderung eine Priorität. Muss heißt: ohne das keine Abnahme. Soll heißt: wichtig, aber notfalls im zweiten Schritt. Kann heißt: schön, wenn Budget übrig ist. Erst diese Einteilung macht Angebote vergleichbar, weil jeder Anbieter sonst selbst entscheidet, was er weglässt.

Die Gliederung mit einem komplett ausgefüllten Beispiel steht in der Lastenheft-Vorlage, als Word-Datei zum Herunterladen, ohne Anmeldung.

  1. 1

    Ausgangslage und Ziel

    Warum das Projekt jetzt kommt und woran du in einem Jahr Erfolg misst. Eine Zahl ist besser als ein Adjektiv.

  2. 2

    Ist-Zustand

    Wie der Ablauf heute läuft, mit welchen Programmen, wer daran beteiligt ist und wo es hakt.

  3. 3

    Funktionale Anforderungen

    Was das System können muss, in der Sprache deines Ablaufs. Jede Anforderung mit Nummer und Priorität.

  4. 4

    Nicht-funktionale Anforderungen

    Tempo, Datenschutz, Barrierefreiheit, Verfügbarkeit, Rollen und Rechte, Hosting.

  5. 5

    Mengengerüst

    Wie viele Nutzer, Datensätze, Bestellungen oder Buchungen pro Tag. Ohne diese Zahlen rät jeder Anbieter anders.

  6. 6

    Schnittstellen

    Welche Systeme mitspielen müssen, etwa Warenwirtschaft, Buchhaltung, CRM oder PMS, und in welche Richtung Daten fließen.

  7. 7

    Rahmen

    Budgetkorridor, Wunschtermine, rechtliche Vorgaben, wer intern entscheidet.

  8. 8

    Abnahmekriterien

    Woran alle erkennen, dass eine Anforderung wirklich erfüllt ist.

Was ins Pflichtenheft gehört

Das Pflichtenheft ist die Antwort des Anbieters. Es übersetzt jede Anforderung aus dem Lastenheft in eine konkrete Lösung. Ein gutes Pflichtenheft macht sichtbar, wo Annahmen stecken, bevor sie Geld kosten.

Prüfe beim Lesen eine Sache zuerst: Hat jede Muss-Anforderung aus deinem Lastenheft eine Antwort und einen Testfall? Fehlt eins von beiden, ist das Heft nicht fertig. Wie ein Pflichtenheft aus Sicht des Anbieters aussieht, zeigt die Pflichtenheft-Vorlage mit Beispiel.

  • Lösung je Anforderung

    Für jede Nummer aus dem Lastenheft steht da, wie sie umgesetzt wird. Keine Anforderung bleibt ohne Antwort.

  • Architektur und Technik

    Aufbau des Systems, eingesetzte Software, Hosting, Datenmodell.

  • Schnittstellen und Datenflüsse

    Welche Daten wann wohin gehen, in welchem Format, und was bei einem Ausfall passiert.

  • Abgrenzung

    Was ausdrücklich nicht Teil des Auftrags ist. Dieser Abschnitt erspart später die meisten Diskussionen.

  • Meilensteine

    Reihenfolge, Zwischenstände, wann du was zu sehen bekommst.

  • Testfälle zur Abnahme

    Für jede Muss-Anforderung ein Test, den beide Seiten nachvollziehen können.

  • Betrieb

    Wer nach dem Start Updates, Sicherheit und Fehler übernimmt.

Ein Beispiel: eine Anforderung, drei Stufen

Die meisten Erklärungen hören beim Unterschied auf. Spannend wird es erst, wenn man eine einzige Anforderung verfolgt, vom Wunsch bis zum Test. Das Beispiel ist ausgedacht, aber typisch: ein Handwerksbetrieb, der Terminanfragen nicht mehr am Telefon annehmen will.

StufeSo steht es daWas daran wichtig ist
LastenheftLH-07 (Muss): Kunden buchen einen freien Termin online, ohne anzurufen. Sie bekommen sofort eine Bestätigung.Beschreibt nur das Was. Kein Wort zu Kalender, Programm oder Technik.
PflichtenheftPH-07: Buchungsformular auf der Website. Freie Termine kommen live aus dem bestehenden Kalender über dessen Schnittstelle. Nach der Buchung geht innerhalb einer Minute eine Bestätigung per E-Mail raus, der Termin steht im Kalender des Mitarbeiters.Beantwortet das Wie und legt eine messbare Grenze fest: eine Minute.
AbnahmetestT-07: Drei Testbuchungen an drei verschiedenen Tagen. Bestanden, wenn jeder Termin im Kalender erscheint, jede Bestätigung in unter einer Minute ankommt und ein bereits belegter Termin nicht buchbar ist.Macht aus der Anforderung etwas, das man an einem Nachmittag prüfen kann.

Achte auf die Nummer. LH-07, PH-07 und T-07 hängen zusammen. Wenn bei der Abnahme ein Test scheitert, weiß jeder sofort, welche Anforderung betroffen ist und was vereinbart war. Ohne diese Kette diskutiert man über Erinnerungen.

Wie ein Anbieter dein Lastenheft liest

Wenn ein Lastenheft bei uns ankommt, suchen wir nicht zuerst die Funktionen. Wir suchen die Stellen, an denen wir raten müssten. Jede davon wird im Angebot entweder zu einem Risikopuffer oder zu einer Rückfrage.

Drei Dinge entscheiden, ob sich ein Angebot sauber rechnen lässt. Erstens das Mengengerüst: Ein Formular für zehn Anfragen am Tag ist ein anderes Projekt als eins für zehntausend. Zweitens die Schnittstellen: Jedes Fremdsystem, das angebunden werden muss, ist ein eigenes kleines Projekt mit eigener Dokumentation. Drittens die Abnahmekriterien: Erst sie sagen, wann wir fertig sind.

Fehlt eins davon, bekommst du von verschiedenen Anbietern Preise, die weit auseinanderliegen. Das liegt dann selten an den Anbietern. Jeder hat die Lücke anders gefüllt.

Die Fehler, an denen Projekte vor der ersten Zeile Code kippen

Lösung statt Ziel. Wer ins Lastenheft schreibt, welche Datenbank es sein soll, engt die Lösung ein, bevor sie durchdacht ist. Beschreibe, was der Ablauf leisten muss, nicht womit.

Adjektive statt Zahlen. "Schnell", "intuitiv", "modern" lassen sich nicht abnehmen. "Die Suche zeigt Ergebnisse in unter zwei Sekunden" schon.

Das Unsichtbare fehlt. Datenschutz, Barrierefreiheit, Tempo unter Last, Rollen und Rechte, Hosting. Was nicht drinsteht, wird später teuer nachgezogen.

Keine Prioritäten. Wenn alles Muss ist, ist nichts Muss. Dann rechnet jeder Anbieter mit seiner eigenen Auswahl, und der niedrigste Preis ist oft nur der mit der knappsten Auslegung.

Daten vergessen. Welche Bestandsdaten umziehen, in welcher Qualität, wer sie bereinigt. Der Satz "Bestandsdaten werden übernommen" kann ein paar Stunden Arbeit bedeuten oder mehrere Wochen, je nachdem, wie sauber die Daten heute sind.

Keine Abnahmekriterien. Ohne den Satz, woran fertig erkennbar ist, streiten am Ende beide Seiten über Auslegung. Wie wir aus Anforderungen ein Projekt machen, das nicht an diesen Stellen kippt, steht unter Softwareentwicklung.

Was rechtlich zählt

Individuell entwickelte Software und Websites laufen in Deutschland meist als Werkvertrag. Der Bundesgerichtshof hat das etwa für einen Internet-System-Vertrag so eingeordnet (BGH, Urteil vom 04.03.2010, III ZR 79/09). Für dich heißt das: Geschuldet ist ein funktionierendes Ergebnis, und am Ende steht eine Abnahme.

Bei der Abnahme ist das Pflichtenheft der Maßstab. Nach § 640 BGB musst du ein vertragsgemäß hergestelltes Werk abnehmen und darfst die Abnahme wegen unwesentlicher Mängel nicht verweigern. Setzt dir der Anbieter nach Fertigstellung eine angemessene Frist und du verweigerst die Abnahme nicht innerhalb dieser Frist unter Nennung mindestens eines Mangels, gilt das Werk als abgenommen. Ohne klare Abnahmekriterien ist schwer zu sagen, was ein wesentlicher Mangel ist.

Gibt es gar keine genaue Leistungsbeschreibung, schuldet der Anbieter nach der Rechtsprechung des BGH einen mittleren Ausführungsstandard, also das, was zum Zeitpunkt des Vertrags üblich ist (u. a. BGH X ZR 129/01). Was "üblich" ist, entscheidet im Streit ein Gutachter. Genau das will keine Seite.

Und noch etwas: Dass du Informationen, Zugänge und Ansprechpartner lieferst, ist rechtlich meist eine Mitwirkung. Kommst du ihr nicht nach, kann der Anbieter eine Entschädigung verlangen (§ 642 BGB) und unter Umständen kündigen (§ 643 BGB). Schreib in den Vertrag, wer was bis wann beisteuert.

Das ist eine allgemeine Einordnung, keine Rechtsberatung. Bei einem konkreten Vertrag lohnt sich der Blick eines Anwalts für IT-Recht.

Wenn sich nach der Freigabe etwas ändert

Es ändert sich immer etwas. Das ist kein Fehler im Projekt, das ist das Projekt. Entscheidend ist, dass jede Änderung denselben Weg nimmt: kurz beschreiben, Auswirkung auf Preis und Termin schätzen, beide Seiten geben frei, dann wird gebaut. Im Projektalltag heißt das Change Request.

Gib Lastenheft und Pflichtenheft eine Versionsnummer und ein Datum. Eine Änderung, die nur in einer E-Mail steht, ist bei der Abnahme schwer zu belegen. Eine Änderung in Version 1.3 des Pflichtenhefts nicht.

Wer viele Änderungen erwartet, kann das gleich einplanen: ein fester Kern zum Festpreis und ein Änderungsbudget daneben, über das du verfügst. Das ist ehrlicher als ein Festpreis, der Änderungen schon heimlich einpreist.

Ist ein Lastenheft noch zeitgemäß?

Kommt darauf an, und das ist keine Ausrede. Für ein klar abgegrenztes Projekt mit festen Vorgaben ist ein Lastenheft weiter das richtige Werkzeug.

Für Software, deren Anforderungen sich erst im Tun schärfen, ist ein starres Heft oft ein Problem. Du legst früh Dinge fest, die nach dem ersten echten Test anders aussehen, und arbeitest dann gegen dein eigenes Papier.

In agilen Projekten ersetzt man das dicke Heft deshalb durch etwas Schlankeres: Ziele und Prioritäten bleiben, die Anforderungen werden als User Stories mit Akzeptanzkriterien geschrieben, und das Backlog ist eine Art lebendes Pflichtenheft. Ganz ohne Aufschreiben geht es nicht. Die Abnahme braucht trotzdem einen Maßstab.

Unser Weg dafür ist ein gemeinsamer Discovery-Schritt: Anforderungen, Prioritäten, ein Prototyp und ein Festpreis-Angebot entstehen zusammen, bevor größere Beträge gebunden sind. Das Ergebnis gehört dir.

Anforderungen gemeinsam schärfen

Lastenheft und Pflichtenheft auf Englisch

Eine Eins-zu-eins-Übersetzung gibt es nicht, weil das Begriffspaar sehr deutsch ist. Für das Lastenheft passen Customer Requirements Specification oder User Requirements Specification (URS). Die ISO/IEC/IEEE 29148 spricht von der Stakeholder Requirements Specification.

Für das Pflichtenheft sagt man meist Functional Specification oder System Requirements Specification. Die VDI-Richtlinie 2519 übersetzt das Paar mit Tender Specification und Performance Specification.

Vorsicht beim Statement of Work: Das ist die Leistungsbeschreibung im Vertrag, kein Pflichtenheft. Wer die beiden verwechselt, unterschreibt womöglich weniger Detail, als er glaubt.

FAQ

Häufig gestellte Fragen

Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?

Das Lastenheft schreibt der Auftraggeber und beschreibt das Was und Wozu: Ziele, Anforderungen, Rahmen. Das Pflichtenheft schreibt der Auftragnehmer als Antwort darauf und beschreibt das Wie und Womit: die technische Lösung. Erst das Problem aus deiner Sicht, dann der Plan aus Sicht dessen, der baut.

Wer erstellt das Pflichtenheft?

Der Auftragnehmer, also der Anbieter, der die Umsetzung übernimmt. Er baut es auf dem Lastenheft auf. Gute Anbieter erarbeiten es gemeinsam mit dir, weil nur du weißt, wie euer Ablauf wirklich läuft.

Was ist ein Beispiel für ein Lastenheft?

Eine typische Zeile lautet: Kunden buchen einen freien Termin online, ohne anzurufen, und bekommen sofort eine Bestätigung. Das ist eine Muss-Anforderung, ohne Technik. Ein vollständig ausgefülltes Lastenheft mit allen Abschnitten findest du in unserer Lastenheft-Vorlage.

Ist das Pflichtenheft rechtlich bindend?

Meistens ja, sobald es Teil des Vertrags wird. Bei Softwareprojekten, die als Werkvertrag laufen, ist es dann der Maßstab für die Abnahme. Fehlt eine solche Beschreibung, schuldet der Anbieter nach der Rechtsprechung des BGH einen mittleren Ausführungsstandard, und darüber lässt sich trefflich streiten.

Sind Lastenhefte noch zeitgemäß?

Für ein klar abgegrenztes Projekt mit festen Vorgaben ja. Für Software, deren Anforderungen sich erst im Tun schärfen, ist ein starres Heft oft das falsche Werkzeug. Dann passt ein schlankes Lastenheft mit Zielen und Prioritäten plus ein gemeinsamer Discovery-Schritt besser.

Wie heißen Lastenheft und Pflichtenheft auf Englisch?

Das Lastenheft heißt Customer Requirements Specification oder User Requirements Specification, in der Norm ISO/IEC/IEEE 29148 Stakeholder Requirements Specification. Das Pflichtenheft heißt meist Functional Specification oder System Requirements Specification. Statement of Work ist kein Pflichtenheft, sondern eine Leistungsbeschreibung im Vertrag.

Wer bezahlt das Pflichtenheft?

Das ist Verhandlungssache. Bei kleinen Vorhaben steckt es oft im Angebot. Bei größeren Projekten ist es eine eigene, bezahlte Konzeptphase, weil ein gutes Pflichtenheft Tage an Analyse kostet. Wichtig ist, dass das Ergebnis dir gehört, auch wenn du danach mit einem anderen Anbieter baust.

Quellen

Stand: Oktober 2026