Lastenheft und Pflichtenheft – IT-Berufe-Podcast #189

Die Unterscheidung von Lastenheft und Pflichtenheft ist Thema der
einhundertneunundachzigsten Episode des IT-Berufe-Podcasts.
Inhalt Kurzübersicht Lastenheft

Definition laut DIN 69901-5: „vom Auftraggeber festgelegte
Gesamtheit der Forderungen an die Lieferungen und Leistungen
eines Auftragnehmers innerhalb eines Auftrages“.

Verfasst von: Auftraggeber, also aus Sicht des Kunden.

Inhalt: Lösungsneutrale funktionale und nicht-funktionale
Anforderungen an ein Produkt, eine zu erstellende Software oder
ein Projektergebnis aus Sicht des Auftraggebers.

Fragen: WAS soll erreicht werden? WARUM ist das wichtig?
WOFÜR wird das benötigt? WER will das haben?

Ziel: Basis, um Angebote von potenziellen Auftragnehmern
einzuholen. Es bildet die Grundlage für das vom Auftragnehmer zu
erstellende Pflichtenheft.

Rechtliche Relevanz: keine

Mögliche Inhalte

Anforderungen der Stakeholder (z.B. Fachlichkeit,
Regualatorik, Usability, Performance,
Hardware-/Netwerk-/Softwareumgebung)

Ist-Zustand und Soll-Zustand

Abnahmekriterien für die Prüfung, ob die Anforderungen
erfüllt sind

Einschränkungen bei zu verwendenden Technologien

Anforderungen an den Auftragnehmer (z.B. Zertifizierung)

Schnittstellen

Sonstige Anforderungen (z.B. Dauer, Kosten, Meilensteine)



Kurzübersicht Pflichtenheft

Definition laut DIN 69901-5: „vom Auftragnehmer
erarbeitete[n] Realisierungsvorgaben aufgrund der Umsetzung des
vom Auftraggeber vorgegebenen Lastenhefts“.

Verfasst von: Auftragnehmer, also aus Sicht des
Dienstleisters.

Inhalt: Vorschlag für technische Lösung der Anforderungen aus
dem Lastenheft.

Fragen: WIE sollen die Anforderungen umgesetzt werden? WELCHE
Technologien kommen zum Einsatz?

Ziel: Konkretes Angebot eines Auftragnehmers, um die
Anforderungen aus dem Lastenheft des Auftraggebers zu erfüllen.
Basis für die Kalkulation von Kosten/Aufwänden und das Erstellen
eines Angebots. Definiert die Vorgaben für die spätere
Implementierung.

Rechtliche Relevanz: wird Vertragsbestandteil und dient zur
Abnahme der erbrachten Leistung

Mögliche Inhalte

Spezifikationen des geplanten Ergebnisses bzw. die
technische Realisierung, z.B. Architektur, Technologien,
UML-Diagramme, ER-Modelle, geplante Prozessabläufe,
UI-Entwürfe

Entwicklungsprozess, Projektplan mit Meilensteinen,
Vorgaben zur Kommunikation

Ressourcen wie konkrete Personen, Subunternehmen,
Technologien



Definitionen aus dem IT-Handbuch

Beginnen wir mit einer Definition der Begriffe. Dafür schaue ich
immer gerne in das IT-Handbuch*, das bis vor einigen Jahren noch
der „offizielle“ Prüfungsbegleiter war und als Nachschlagewerk
mit in die Prüfung genommen werden durfte. Dort werden Lasten-
und Pflichtenheft wie folgt definiert:


Lastenheft


Das Lastenheft enthält alle Forderungen des Auftraggebers
(Kunden) an die Lieferungen und/oder Leistungen eines
Auftragnehmers. Die Forderungen sind aus Anwendersicht
einschließlich aller Randbedingungen zu beschreiben. Diese
sollten quantifizierbar und prüfbar sein. Im Lastenheft wird
definiert, was für eine Aufgabe vorliegt und wofür diese zu lösen
ist.


Pflichtenheft


Das Pflichtenheft enthält das vom Auftragnehmer erarbeitete
Realisierungsvorhaben auf der Grundlage des Lastenheftes. Das
Pflichtenheft enthält als Anlage das Lastenheft. Im Pflichtenheft
werden die Anwendervorgaben detailliert und in einer Erweiterung
die Realisierungsforderungen unter Berücksichtigung konkreter
Lösungsansätze beschrieben. Im Pflichtenheft wird definiert, wie
und womit die Forderungen zu realisieren sind.


Gut verständlich finde ich auch die Erläuterungen in der
Wikipedia, die sich auf die DIN 69901 stützen (die leider nicht
kostenfrei verfügbar ist):


Lastenheft


Gemäß DIN 69901-5 […] beschreibt das Lastenheft die „vom
Auftraggeber festgelegte Gesamtheit der Forderungen an die
Lieferungen und Leistungen eines Auftragnehmers innerhalb eines
Auftrages“. Das Lastenheft beschreibt in der Regel somit,
was und wofür etwas gemacht werden soll. [Herv.
d. Verf.]


Pflichtenheft


Das Pflichtenheft beschreibt in konkreter Form, wie der
Auftragnehmer die Anforderungen des Auftraggebers zu lösen
gedenkt – das sogenannte wie und womit. […] Laut
DIN 69901-5 umfasst das Pflichtenheft die „vom Auftragnehmer
erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom
Auftraggeber vorgegebenen Lastenhefts“. [Herv. d. Verf.]
Vor- und Nachteile von Lasten- und Pflichtenheft

Gute Planungssicherheit für den Auftraggeber. Er weiß genau,
was er bekommt und wie teuer es wird.

Eher starres Vorgehen ist nur geeignet für Projekte, die für
einen langen Zeitraum unverändert bleiben (Wasserfallmodell).

Das Erstellen der Dokumente ist sehr aufwändig und
zeitintensiv.

In agilen Vorgehensmodellen wie Scrum werden sie nicht
verwendet.

Alternative: Arbeit in Inkrementen, Minimum Viable Product

Relevanz für die Praxis und die IHK-Projektarbeit

Lasten- und Pflichtenheft sind zwei Artefakte, die ich in (fast)
jeder IHK-Projektdokumentation erwarte. Da die Abschlussprojekte
eine genaue Zeitvorgabe haben (40 bzw. 80 Stunden) und auch die
Anforderungen zu Beginn komplett feststehen (sollten), eignen
sich Lasten- und Pflichtenheft gut für die Dokumentation der
Anforderungen.


Wenn man eine Priorisierung durchführen müsste, würde ich mehr
Gewicht auf das Pflichtenheft legen, da dieses die Grundlage für
den Vertrag zur Erstellung der Software ist. Das heißt, die
Abnahme am Ende des Projekts erfolgt „gegen“ das Pflichtenheft.
Was dort nicht enthalten ist, wird auch nicht umgesetzt.


Das ist übrigens auch eine häufige Frage im Fachgespräch: Warum
ist das Pflichtenheft so wichtig? Weil es Vertragsbestandteil
ist. Die Abgrenzung zwischen Lasten- und Pflichtenheft wird
übrigens auch gerne als Prüfungsfrage (schriftlich und mündlich)
genommen.


Aber auch im realen Leben haben Lasten- und Pflichtenheft ihre
Daseinsberechtigung in bestimmten Projekten, z.B. wenn es um
sicherheitskritische Produkte geht, die nicht „mal eben“ agil
entwickelt werden können/dürfen.
Wer erstellt das Lasten- und Pflichtenheft?

Wie die Definitionen oben nahelegen, sollte im Rahmen des
IHK-Abschlussprojekts das Lastenheft vom Kunden bzw. der
Kundin erstellt werden und das Pflichtenheft vom
Prüfling. Der/die Kund:in formuliert, was er/sie gerne
hätte (also die fachlichen Anforderungen), und der Prüfling
definiert die dazu passende konkrete technische Lösung.


In der Praxis ist es allerdings häufig so, dass Kunden ihre
Anforderungen gar nicht genau kennen, geschweige denn sie so
formulieren können, dass ein:e ITler:in sie versteht. Daher
spricht nichts dagegen, dass Prüflinge schon beim Erstellen des
Lastenhefts mitarbeiten.


Wenn du genau in die Zeitplanung von Gerdas und Markus‘
Dokumentation schaust, wirst du feststellen, dass bei uns im
Unternehmen genau so gearbeitet wird. Es wurde nämlich im Rahmen
der Projektplanung Zeit für die Unterstützung des Fachbereichs
bei der Erstellung des Lastenhefts eingeplant. Die
Entwickler:innen helfen den Kunden z.B. bei der Formulierung der
Anforderungen, aber auch bei deren Identifikation. Gute Methoden
dafür sind z.B. Brainstorming oder Interviews.
Aufbau und Formulierung

Zu Inhalt, Aufbau und (gerade für die Projektdokumentation
interessant) Formulierung von Lasten- und Pflichtenheft gibt es
keine harten Vorgaben. Letztlich bestehen beide Artefakte aus
Prosa.
Lastenheft

Ich persönlich würde einen etwas „moderneren“ Ansatz wählen und
im Lastenheft User-Storys verwenden (für Beispiele verweise ich
wieder auf die beiden obigen Dokumentationen). Durch diese
Vorgabe wird man bei der einheitlichen Formulierung unterstützt
und muss sich nicht alles neu ausdenken.


Es gibt aber auch andere Ansätze, wie z.B. die richtig
„enterprisey“ Volere-Templates. Da ist allein das
Inhaltsverzeichnis aller möglichen Anforderungen schon ellenlang.
Pflichtenheft

Das Pflichtenheft sollte dann natürlich einige konkrete
technische Artefakte beinhalten, da es ja so spezifisch wie
möglich sein muss. Ich beschreibe es immer gerne so: Das
Pflichtenheft muss man einem/einer Softwareentwickler:in ohne
Kommentar auf den Tisch legen können und er/sie entwickelt dann
allein auf dieser Basis die gewünschte Software. Dass das in der
Praxis so nicht funktioniert (und auch nicht meine präferierte
Umgangsweise ist) ist hoffentlich klar.


Man kann aber durchaus alle in der Entwurfsphase erstellten
Artefakte ins Pflichtenheft packen: Use-Case-Diagramm,
Klassendiagramm, Komponentendiagramm, ERM, Tabellenmodell,
GUI-Mockups, Testszenarien usw. Wie gesagt: Was nicht im
Pflichtenheft steht, wird nicht umgesetzt (und nicht bezahlt).
Berücksichtigung in der IHK-Projektdokumentation

Da sowohl Lasten-, als auch Pflichtenheft recht lang werden
können, empfehle ich, in der Projektdokumentation ausschließlich
Ausschnitte daraus abzubilden. Und damit meine ich nicht
Deckblatt und Inhaltsverzeichnis (habe ich leider schon oft so
gesehen), sondern die konkreten Anforderungen bzw.
Lösungsvorschläge. Also zeig bitte interessante
Inhalte und nicht unwichtigen Kram.


Da die Seiten in der Projektdokumentation begrenzt sind, kann man
vielleicht sogar zwei Fliegen mit einer Klappe schlagen und
Lasten-/Pflichtenheft sowie projektrelevante technische Inhalte
daraus in nur einem Anhang zeigen. Beispiel: Das Pflichtenheft
enthält ein Komponentendiagramm der geplanten Anwendung. Dann
könnte der einseitige Auszug aus dem Pflichtenheft (die Seiten
mit dem Komponentendiagramm) im Anhang der Dokumentation sowohl
im Kapitel „Architektur“, als auch im Kapitel „Pflichtenheft“
referenziert werden. Einmal wird eben auf das Diagramm verwiesen
und einmal auf das Pflichtenheft als erstelltes Artefakt.


Ich persönlich würde aber eher die für die Artefakte spezifischen
Inhalte zeigen, also die formulierten Anforderungen. Denn das ist
der eigentlich interessante Inhalt der beiden Dokumente im Rahmen
der Projektdokumentation. Gerda und Markus haben das auch so
gemacht.
Fazit

Lasten- und Pflichtenheft sind zwei wichtige Artefakte, die
sowohl im richtigen Leben, als auch in der IHK-Abschlussprüfung
relevant sind. Schau dir die Definitionen und einige Beispiele in
Ruhe an und lerne sie auch für die Prüfung.
Literaturempfehlungen

*
Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Was? Pflichtenheft und Lastenheft sind nicht dasselbe?

DIN 69901 – Wikipedia

Lastenheft – Wikipedia

Pflichtenheft – Wikipedia