Pflichtenheft und Lastenheft.

Die Begriffe stammen aus dem klassischen Projektmanagement und sind in Normen beschrieben. Das Lastenheft entsteht beim Auftraggeber. Es beschreibt Ausgangslage, Ziele, Nutzergruppen, gewünschte Funktionen, Rahmenbedingungen wie Budget und Termin sowie nicht verhandelbare Anforderungen, etwa Datenhaltung in der Schweiz. Es sagt, was gebraucht wird, nicht wie es technisch gelöst wird.

Das Pflichtenheft entsteht beim Auftragnehmer als Antwort auf das Lastenheft. Es beschreibt, wie die Anforderungen umgesetzt werden: Architektur, Technologien, Funktionen im Detail, Schnittstellen, Datenmodell, Testkonzept und Abnahmekriterien. Nach Freigabe durch den Auftraggeber ist es die verbindliche Grundlage. Was nicht im Pflichtenheft steht, ist im Zweifel nicht geschuldet — ein häufiger Streitpunkt bei Projekten mit unklarer Beschreibung.

In agilen Projekten wird oft argumentiert, Pflichtenhefte seien überholt. Das stimmt nur teilweise. Richtig ist, dass ein hundertseitiges Dokument zu Beginn selten die Wirklichkeit trifft. Falsch ist, dass man deshalb keine Anforderungen braucht. Eine schlanke Form bewährt sich: ein Lastenheft mit Zielen, Nutzern und Muss-Kriterien, eine Discovery-Phase zur Klärung und ein Pflichtenheft, das den ersten Umsetzungsschritt verbindlich beschreibt und spätere Schritte als Rahmen.

Für KMU ist das Lastenheft das wichtigste Werkzeug, um vergleichbare Offerten zu erhalten. Ohne Beschreibung rechnet jeder Anbieter mit anderen Annahmen, und die Preise liegen weit auseinander. Mit einem klaren Lastenheft lässt sich erkennen, wer die Aufgabe verstanden hat — und wer nur einen Preis nennt.