Pflichtenheft: Aufbau und Abgrenzung zum Lastenheft
Pflichtenheft einfach erklärt: Unterschied zum Lastenheft nach DIN 69901-5, Aufbau, rechtliche Bedeutung und Beispiel für eine TMS-Schnittstelle.
Pflichtenheft einfach erklärt: Unterschied zum Lastenheft nach DIN 69901-5, Aufbau, rechtliche Bedeutung und Beispiel für eine TMS-Schnittstelle.
Ein Pflichtenheft ist das Dokument, in dem der Auftragnehmer beschreibt, wie und womit er die Anforderungen des Auftraggebers umsetzt. Es baut auf dem Lastenheft auf, das die Anforderungen aus Sicht des Auftraggebers festhält. Nach DIN 69901-5 enthält das Pflichtenheft die vom Auftragnehmer erarbeiteten Realisierungsvorgaben.
Das Pflichtenheft ist ein Begriff aus dem Projektmanagement und der Softwareentwicklung. Die Norm DIN 69901-5 definiert es als die vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts. Das Pflichtenheft beantwortet also die Frage, wie und womit ein Vorhaben umgesetzt wird. In der Logistik-IT betrifft das zum Beispiel die Einführung eines Transport Management Systems, einer Lagerverwaltung oder einer Schnittstelle zwischen zwei Systemen.
Beide Dokumente beschreiben dasselbe Vorhaben aus unterschiedlicher Sicht:
Das Lastenheft entsteht zuerst und kann die Grundlage einer Ausschreibung sein, auch bei einer Logistikausschreibung. Das Pflichtenheft setzt das Lastenheft voraus und ordnet jeder Anforderung eine Lösung zu.
Eine gesetzlich vorgeschriebene Gliederung gibt es nicht. Gängige Inhalte sind:
Jede Anforderung aus dem Lastenheft sollte im Pflichtenheft wieder auftauchen. Eine durchgehende Nummerierung erleichtert die Zuordnung und später die Abnahme.
Wird das Pflichtenheft Bestandteil des Vertrags, beschreibt es die geschuldete Leistung. Bei der Abnahme wird geprüft, ob das Ergebnis den dort festgelegten Kriterien entspricht. Was nicht im Pflichtenheft steht, ist im Streitfall schwer einzufordern. Änderungen nach der Freigabe werden über ein Änderungsverfahren (Change Request) vereinbart, weil sie Aufwand, Termine und Preis verändern können. Der Auftraggeber sollte das Pflichtenheft deshalb prüfen und schriftlich freigeben, bevor die Umsetzung beginnt.
Eine Spedition möchte Aufträge, die Kunden per E-Mail senden, ohne Abtippen in ihre Speditionssoftware übernehmen. Im Lastenheft beschreibt sie das Ziel: Auftragsdaten aus E-Mails und Anhängen sollen als Aufträge im TMS ankommen, Adressen sollen mit den Stammdaten abgeglichen werden, und ein Disponent soll jeden Auftrag vor der Übernahme prüfen.
Der Dienstleister legt im Pflichtenheft fest, wie das umgesetzt wird:
Ein solches Projekt verändert die Auftragserfassung. Die Disponenten sollten daher an Lasten- und Pflichtenheft mitarbeiten, weil sie die Sonderfälle aus dem Alltag kennen.
In agilen Vorgehensmodellen wie Scrum werden Anforderungen nicht vorab vollständig beschrieben, sondern in einem Product Backlog gesammelt und schrittweise verfeinert. Ein klassisches Pflichtenheft steht dazu in einem Spannungsverhältnis. Möglich ist eine Kombination: Rahmenbedingungen wie Schnittstellen, Datenformate, Datensicherheit und Abnahmekriterien werden verbindlich festgeschrieben, einzelne Funktionen im Backlog geplant.
Das Pflichtenheft erstellt der Auftragnehmer, also der Softwarehersteller oder Dienstleister. Er stimmt es mit dem Auftraggeber ab, der es prüft und freigibt. Das Lastenheft schreibt dagegen der Auftraggeber.
Zuerst entsteht das Lastenheft mit den Anforderungen des Auftraggebers. Darauf aufbauend erarbeitet der Auftragnehmer das Pflichtenheft mit der konkreten Umsetzung.
Verbindlich wird es, wenn die Parteien es zum Vertragsbestandteil machen. Dann dient es als Maßstab, ob die Leistung vertragsgemäß erbracht wurde, etwa bei der Abnahme.
Eine vorgeschriebene Länge gibt es nicht. Es muss jede Anforderung aus dem Lastenheft so konkret beschreiben, dass Umsetzung und Abnahme daran gemessen werden können. Bei einer einzelnen Schnittstelle genügt ein kurzes Dokument, bei einer TMS-Einführung wird es deutlich umfangreicher.