Lastenheft und Pflichtenheft

Softwareentwicklung

Das Lastenheft beschreibt, was der Auftraggeber braucht. Das Pflichtenheft beschreibt, wie der Auftragnehmer es umsetzt. Zusammen bilden sie die Grundlage für Angebot, Vertrag und Abnahme.

Das Lastenheft ist die Sicht des Kunden: Ziele, Nutzergruppen, Funktionen, Rahmenbedingungen, Qualitätsanforderungen – bewusst ohne technische Lösung. Das Pflichtenheft ist die Antwort der Agentur oder des Softwarehauses: Architektur, Umfang, Vorgehen, Termine. Was dort steht, wird gebaut; was fehlt, ist eine Änderung.

Beide Dokumente haben einen schlechten Ruf, weil sie oft zu dick und zu früh zu detailliert sind. Gemeint ist etwas anderes: ein gemeinsames Verständnis, das so konkret ist, dass man es prüfen kann. Zwanzig klare Seiten schlagen zweihundert vage.

In agilen Projekten tritt an die Stelle des starren Pflichtenhefts ein priorisiertes Backlog mit User Storys und Abnahmekriterien. Die Frage dahinter bleibt dieselbe: Was genau ist vereinbart, und woran erkennen beide Seiten, dass es fertig ist?

Das ist der Kern meiner Arbeit als Requirements Engineer für Werbe- und Digitalagenturen. Ich übersetze zwischen Auftraggeber und Umsetzung – und schreibe Anforderungen so auf, dass ein Geschäftsführer aus Günzburg sie versteht und ein Entwickler danach schätzen kann. Die meisten Budgetüberschreitungen, die ich gesehen habe, waren keine Technikprobleme, sondern ungeklärte Anforderungen.

Wer schreibt das Lastenheft?

Verantwortlich ist der Auftraggeber. In der Praxis hilft oft ein Requirements Engineer oder die Agentur dabei, die richtigen Fragen zu stellen und das Ergebnis prüfbar zu formulieren.

Braucht ein kleines Website-Projekt ein Lastenheft?

Nicht im klassischen Umfang. Zwei bis drei Seiten mit Zielen, Zielgruppen, Seitenstruktur, Funktionen und Abnahmekriterien genügen – sie ersparen aber fast immer Streit über das Angebot.

  • Lastenheft
  • Pflichtenheft
  • Requirements Engineering
  • Abnahme