Die Unterscheidung von Lastenheft und Pflichtenheft ist Thema der
einhundertneunundachzigsten Episode des IT-Berufe-Podcasts. TL;DR
Für dein IHK-Abschlussprojekt empfehle ich dir Lastenheft und
Pflichtenheft, weil du damit die Anforderungen und deinen
technischen Entwurf festhalten kannst. Im Lastenheft beschreibt
dein:e Auftraggeber:in, was erreicht werden soll und warum; das
darauf aufbauende Pflichtenheft enthält deine konkrete technische
Lösung und wird Vertragsbestandteil sowie Grundlage für die
Abnahme. Beide Dokumente sind prüfungsrelevant und passen zu
zeitlich begrenzten Projekten mit festen Anforderungen. Wenn sich
Anforderungen während eines längeren Projekts verändern, bieten
agile Verfahren mehr Spielraum. Kapitelmarken [00:00] Einstieg:
Lastenheft und Pflichtenheft [00:37] Bedeutung für Prüfung und
IHK-Abschlussprojekt [02:47] Überblick über die beiden Dokumente
[05:02] Lastenheft nach DIN 69901-5 [06:51] Kund:innensicht und
lösungsneutrale Anforderungen [08:13] Funktionale und
nichtfunktionale Anforderungen [09:59] Leitfragen und Angebote auf
Basis des Lastenhefts [11:42] Mögliche Inhalte eines Lastenhefts
[14:23] Pflichtenheft nach DIN 69901-5 [15:31] Technische Details
und Aufwand kalkulieren [18:42] Diagramme und Modelle im
Pflichtenheft [20:18] Projektablauf und beteiligte Personen
festlegen [21:35] Pflichtenheft als Vertragsbestandteil [23:14]
Aufwand, Risiken und veränderte Anforderungen [25:21] Agile
Verfahren und Minimum Viable Product [26:51] Klassisches Vorgehen
im IHK-Projekt [28:40] Lastenheft und Pflichtenheft in der
Projektarbeit [29:23] Kund:innen beim Lastenheft unterstützen
[31:38] Form und Vorlagen für die Dokumente [32:42] Anforderungen
einheitlich formulieren und User Stories [34:41] Volere-Templates
und Snow Cards [36:33] Geeignete Auszüge für den Anhang auswählen
[39:48] Prüfungsvorbereitung und weiterführende Quellen [40:31]
Newsletter zur IT-Ausbildung 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....
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.