„Pflichtenheft" – Versionsunterschied

Das Pflichtenheft beschreibt in konkreter Form, wie der Auftragnehmer die Anforderungen des Auftraggebers zu lösen gedenkt – das sogenannte wie und womit. Der Auftraggeber beschreibt vorher im Lastenheft möglichst präzise die Gesamtheit der Forderungen – was er entwickelt oder produziert haben möchte. Erst wenn der Auftraggeber das Pflichtenheft akzeptiert, sollte die eigentliche Umsetzungsarbeit beim Auftragnehmer beginnen.

Neben dem Begriff Pflichtenheft findet man in der Praxis auch unscharfe Bezeichnungen wie Fachspezifikation, fachliche Spezifikation, Fachfeinkonzept, Sollkonzept, Funktionale Spezifikation, Gesamtsystemspezifikation, Implementierungsspezifikation oder englisch Software Requirements Specification, Scope Statement, Feature Specification, Functional Specification (F-Spec), System Specification. Da diese Bezeichnungen in der Regel nicht standardisiert sind, können damit durchaus Dokumente im Sinne des Pflichtenhefts gemeint sein, aber auch Fachkonzept, Lastenheft oder etwas anderes.

Laut DIN 69901-5 umfasst das Pflichtenheft die „vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts". Die Anforderungen des zuvor ausgearbeiteten Lastenhefts sind nun mit technischen Festlegungen der Betriebs- und Wartungsumgebung verknüpft.^[1]

Nach VDI-Richtlinie 2519 Blatt 1 ist das Pflichtenheft die Beschreibung der Realisierung aller Kundenanforderungen, die im Lastenheft gefordert werden.^[2]

Nach VDI-Richtlinie 3694 erstellt der Auftragnehmer das Pflichtenheft unter Beachtung der im Lastenheft genannten Anforderungen an das Automatisierungssystem.^[3]

Nach VDI-Richtlinie 2221 werden die Begriffe auch synonym verwendet.^[4]

Das Pflichtenheft wird vom Auftragnehmer formuliert und auf dessen Wunsch vom Auftraggeber bestätigt.^[1] Idealerweise sollten erst nach dieser Bestätigung die eigentlichen Entwicklungs-/Implementierungsarbeiten beginnen. Der Auftragnehmer hat einen durch den Vertrag bestimmten Anspruch auf solche Bestätigung (Mitwirkungspflicht nach § 642 BGB).

Es ist bewährte Praxis, bei der Erstellung eines Pflichtenheftes das Ein- und Ausschlussprinzip zu verwenden, das heißt, konkrete Fälle explizit ein- oder auszuschließen.

Bei Lieferung wird formell eine Abnahme vollzogen, welche die Ausführung des Werkvertrages oder auch des Kaufvertrages beschließt. Diese Abnahme wird häufig über einen Akzeptanztest ausgeführt, der feststellt, ob die Forderungen des Lastenheftes in dem Verständnis des Bestellers erfüllt wurden.

In der Softwareentwicklung wird das Pflichtenheft unter anderem im V-Modell 97 definiert. Im aktuellen V-Modell XT wurde die Bezeichnung in Gesamtsystemspezifikation (Pflichtenheft) geändert. Für internationale Projekte wird heutzutage stattdessen meistens eine Software Requirements Specification erstellt. Diese stellt das Pflichtenheft dar und ist weiterhin Ausgangspunkt für die Verfolgbarkeit der Anforderungen in die nächsten Lösungsebenen wie z. B. Architektur-Spezifikationen, SSRS (Subsystem Requirements Specification) und Testfallspezifikationen.

In der internationalen Raumfahrt verwendete Lastenhefte orientieren sich häufig am NASA-Standard, um die internationale Kooperation zu vereinfachen. Es hat sich folgendes Prinzip herausgebildet:

• Der Auftraggeber erstellt eine Anforderungsspezifikation (requirements spec), die die Missionsanforderungen und Rahmenbedingungen enthält (z. B. es soll ein bemanntes Labormodul für die ISS geliefert werden, das mit dem Space Shuttle dorthin transportiert werden soll);
• Der Auftragnehmer antwortet darauf mit einer Implementierungsspezifikation (design-to-spec), die den vom Auftragnehmer gewählten Entwurf spezifiziert (z. B. ein zylinderförmiges Druckmodul mit bestimmtem Durchmesser und Länge);^[5]
• Der Auftraggeber akzeptiert formell die mehr Details enthaltende Implementierungsspezifikation. Im Falle eines später auftretenden Konflikts hat die Anforderungsspezifikation jedoch Vorrang.

Weiterhin fordert der Auftraggeber in einem Pflichtenheft / Statement of Work (SOW) wie und mit welchen Mitteln das gemäß Anforderungsspezifikation zu liefernde Produkt entwickelt, gefertigt und verifiziert werden soll (Entwicklungslogik, Überprüfungen / Reviews, zu liefernde Dokumente usw.).

Der Auftragnehmer antwortet mit verschiedenen Plänen (Entwicklungsplan/Design and Development Plan, Fertigungsplan, EMC Kontrollplan usw.) die im Detail die Umsetzung des SOW beschreiben (z. B. wer das Protokoll einer Besprechung schreibt und in welchem Zeitrahmen die beteiligten Parteien zustimmen müssen).

• Anforderungsanalyse (Informatik)
• Anforderungsmanagement (Requirements management)

• VDI 2519 Blatt 1: Vorgehensweise bei der Erstellung von Lasten-/Pflichtenheft
• VDI 2519 Blatt 2: Lastenheft/Pflichtenheft für den Einsatz von Förder- und Lagersystemen
• VDI 3694: Lastenheft/Pflichtenheft für den Einsatz von Automatisierungssystemen

1. ↑ ^{a b} Thomas Fittkau: Ganzheitliches IT-Projektmanagement. Wissen, Praxis, Anwendungen. Oldenbourg, München [u. a.] 2008, ISBN 3-486-58567-3. 
2. ↑ Ina Depprich: Praxishandbuch Medien-, IT- und Urheberrecht. 2. Auflage. Müller, Heidelberg 2011, ISBN 3-8114-3820-4. 
3. ↑ Verein Deutscher Ingenieure (Hrsg.): VDI/VDE 3694 – Lastenheft/Pflichtenheft für den Einsatz von Automatisierungssystemen. Beuth, 2014. 
4. ↑ Verein Deutscher Ingenieure (Hrsg.): VDI 2221 – Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte. Beuth, 1993. 
5. ↑ Columbus Design Spec (COL-RIBRE-SPE-0028, iss 10/F, 25. Juni 2004).

• Konstruktionslehre
• Qualitätssicherung
• Projektmanagement
• Anforderungsmanagement