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,...
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.