Publiziert: Zuletzt aktualisiert:

Lastenheft und Pflichtenheft

Lastenheft und Pflichtenheft: klare Anforderungen, bevor gebaut wird

Das Lastenheft hält fest, was der Auftraggeber will und warum; das Pflichtenheft beschreibt, wie und womit der Auftragnehmer es löst. Zwei getrennte Dokumente, eine Logik: klären, bevor gebaut wird.

Die meisten gescheiterten Projekte scheitern nicht am Code, sondern an der Annahme. Der Auftraggeber meinte etwas anderes, als der Auftragnehmer verstand, und beide merken es erst bei der Abnahme. Die deutschsprachige Ingenieurtradition trennt genau hier sauber: zuerst das Lastenheft, das die Anforderungen aus Sicht des Bestellers festhält, dann das Pflichtenheft, das die Lösung aus Sicht des Lieferanten beschreibt. Diese Seite erklärt die Unterscheidung, warum die Reihenfolge zählt und wo die Disziplin in der Praxis bricht.

Lastenheft: was und warum

Das Lastenheft ist das Dokument des Auftraggebers. Nach DIN 69901-5 ist es die vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers. Es beantwortet zwei Fragen, was soll entstehen und warum, und es überlässt das Wie bewusst noch offen. Ein gutes Lastenheft beschreibt das Problem und die Ziele, nicht die Implementierung. Es ist die Grundlage der Ausschreibung: Mehrere Anbieter sollen auf derselben Basis ein Angebot rechnen können, ohne dass eine konkrete Technologie vorweggenommen wird. Genau diese Ergebnisoffenheit macht das Lastenheft auch zum natürlichen Ausgangspunkt einer Make-or-Buy-Entscheidung: Erst wenn die Anforderung steht, lässt sich beantworten, ob sie gekauft oder gebaut wird.

Pflichtenheft: wie und womit

Das Pflichtenheft ist die Antwort des Auftragnehmers. DIN 69901-5 fasst es als die vom Auftragnehmer erarbeiteten Realisierungsvorgaben auf Basis des vom Auftraggeber vorgegebenen Lastenhefts. Wo das Lastenheft das Ziel nennt, beschreibt das Pflichtenheft den Weg dorthin: die konkrete Lösung, die Architektur, die Schnittstellen, die Annahmen und die Abgrenzungen. Jede Anforderung des Lastenhefts findet hier ihre Entsprechung, idealerweise nachvollziehbar verknüpft, sodass am Ende belegbar ist, dass nichts verloren ging. Das Pflichtenheft wird damit oft zum Vertragsbestandteil oder Anhang und zum Massstab der Abnahme: Abgenommen wird gegen das Pflichtenheft, nicht gegen die Erinnerung an ein Gespräch.

Der Übergabepunkt

Der entscheidende Moment liegt zwischen den beiden Dokumenten. Das Lastenheft wandert vom Auftraggeber zum Auftragnehmer, der es liest, Rückfragen stellt und mit dem Pflichtenheft antwortet. Erst die abgestimmte Annahme des Pflichtenhefts macht aus zwei Sichtweisen einen gemeinsamen Plan.

flowchart TD
    A["Auftraggeber<br/>Bedarf und Ziele"] --> B["Lastenheft<br/>was und warum"]
    B --> C["Auftragnehmer<br/>liest und prüft"]
    C --> D["Pflichtenheft<br/>wie und womit"]
    D --> E["Abstimmung<br/>Rückfragen, Annahmen"]
    E --> F["Freigabe<br/>Vertrag und Abnahmemassstab"]
    F --> G["Bauen und Abnahme<br/>gegen das Pflichtenheft"]

Die häufigste Verwechslung betrifft genau diese Richtung. Das Lastenheft gehört dem, der bestellt; das Pflichtenheft dem, der liefert. Wer als Auftraggeber bereits ein Pflichtenheft schreibt, nimmt die Lösung vorweg und verschenkt die Expertise des Anbieters; wer als Auftragnehmer ohne Lastenheft startet, baut auf Vermutungen.

Wo die Disziplin bricht

  • Vermischung. Lasten- und Pflichtenheft werden in ein Dokument gepresst, das Anforderung und Lösung nicht mehr trennt. Dann lässt sich nicht mehr sagen, was Wunsch und was Zusage ist.
  • Lösung statt Bedarf. Das Lastenheft schreibt bereits ein Produkt oder eine Technologie vor. Die Ausschreibung wird zur Scheinausschreibung, und bessere Lösungen fallen heraus.
  • Keine Rückverfolgbarkeit. Anforderungen und Realisierungsvorgaben sind nicht verknüpft. Bei der Abnahme streitet man darüber, ob eine Funktion je gefordert war.
  • Eingefroren statt gepflegt. Beide Dokumente werden einmal geschrieben und nie aktualisiert. In iterativen Vorhaben veraltet das Pflichtenheft schneller, als es gelesen wird.

Klassische Spezifikation und agile Praxis

Die strikte Trennung stammt aus dem Anlagen- und Auftragsgeschäft, in dem ein fester Liefergegenstand gegen einen festen Preis vereinbart wird. In iterativ entwickelten Software-Vorhaben verschiebt sich die Form, nicht aber die Logik. Das Lastenheft lebt dann in Form von Epics, Zielen und Akzeptanzkriterien weiter, das Pflichtenheft in Architekturentscheidungen, die etwa über RFCs und ADRs dokumentiert werden. Wo die fachliche Komplexität hoch ist, hilft eine gemeinsame Fachsprache, wie sie Domain-Driven Design etabliert, Anforderung und Umsetzung an dieselbe Begriffswelt zu binden. Auch hier gilt das Grundprinzip: Bedarf und Lösung getrennt halten, beide nachvollziehbar verknüpfen. Ob klassisch oder agil entschieden wird, klärt vorab die Methodenwahl im Methoden-Überblick.

Die Spezifikation als Vertragsgrundlage

Eine prüfbare Beschreibung des geschuldeten Ergebnisses ist die Grundlage jeder Abnahme. In der Praxis wird das Pflichtenheft zum Anhang des Vertrags und damit zum vereinbarten Soll, gegen das die Abnahme prüft. Fehlt diese Beschreibung, bleibt im Streitfall nur die Auslegung. Im Schweizer Recht hat diese Unterscheidung einen konkreten vertraglichen Ort: Ein Werkvertrag nach Obligationenrecht schuldet ein Ergebnis, und dieses Ergebnis braucht eine prüfbare Beschreibung. Genau deshalb beginnt eine belastbare Lieferung mit sauberen Anforderungen, lange bevor die erste Zeile entsteht.

Referenzen

Verwandte Themen

KI fragen

Diese Links öffnen externe KI-Dienste, die Unterhaltung und deren Inhalt werden dabei an den jeweiligen Anbieter übertragen.