Lastenheft und Pflichtenheft – wer schreibt eigentlich was, und warum trennt man das überhaupt?

Der Merksatz, der bei mir hängen geblieben ist: Das Lastenheft beschreibt das WAS und WOFÜR, das Pflichtenheft das WIE und WOMIT. Oder noch kürzer: Lastenheft = die Lasten des Kunden, Pflichtenheft = die Pflichten des Auftragnehmers.

Beispiel Onlineshop:

• Lastenheft (schreibt der Auftraggeber): „Kunden müssen ihre Bestellung nach dem Absenden noch 30 Minuten stornieren können. Die Stornierung muss im ERP sichtbar sein.“ Fachlich, lösungsneutral, ohne Technikvorgabe.
• Pflichtenheft (antwortet der Auftragnehmer): „Umsetzung als Statuswechsel im Bestellobjekt, Übergabe an das ERP über die vorhandene REST-Schnittstelle im 5-Minuten-Takt, Storno-Schaltfläche im Kundenkonto, Rollen X und Y dürfen …“

Der Sinn der Trennung ist kein Formalismus: Das Lastenheft ist die Ausschreibungsgrundlage – mehrere Anbieter bekommen dasselbe Dokument und können vergleichbar anbieten. Das Pflichtenheft ist das, was der gewählte Anbieter daraus macht, und wird nach der Freigabe zur Abnahmegrundlage. Bei Streit wird genau dagegen geprüft: Steht es drin und funktioniert nicht, ist es ein Mangel. Steht es nicht drin, ist es ein Änderungsantrag – also Zusatzaufwand und Zusatzkosten.

Zwei Dinge, die in Klausuren gern abgefragt werden, ergänzend zu Daniels Erklärung:

1. Funktionale vs. nichtfunktionale Anforderungen. Funktional = was das System tun soll (stornieren, drucken, exportieren). Nichtfunktional = wie gut (Antwortzeit, Verfügbarkeit, Bedienbarkeit, Datenschutz, Skalierbarkeit). Die nichtfunktionalen werden im Lastenheft am häufigsten vergessen – und sind später der teuerste Nachtrag.
2. Priorisierung nach Muss, Soll und Kann. Ohne die redet man am Ende über 300 gleichrangige Punkte. Gute Anforderungen sind außerdem prüfbar formuliert: „schnell“ ist keine Anforderung, „Seitenaufbau unter 2 Sekunden bei 200 gleichzeitigen Nutzern“ schon.

Zur Agil-Frage: Die Dokumente verschwinden nicht, sie ändern nur die Form. Aus dem Lastenheft wird die Produktvision plus Product Backlog mit User Stories („Als Kunde möchte ich …, damit …“), aus dem Pflichtenheft werden Akzeptanzkriterien und die Definition of Done. Der Unterschied ist, dass klassisch alles einmal vorne festgezurrt wird, agil dagegen laufend nachgeschärft. Der eigentliche Grund für die Trennung – Anforderung und Lösungsweg auseinanderhalten – gilt in beiden Welten.