Lastenheft und Pflichtenheft – IT-Berufe-Podcast #189

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

Probeabo bei Audible (Affiliate)

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

Heinrich Hübscher - IT-Handbuch: IT-Systemelektroniker/-in, Fachinformatiker/-in: Schülerband (Affiliate)*

Links

Polyglot Clean Code Developer
About the Author
Ausbildungsleiter für Fachinformatiker Anwendungsentwicklung und Systemintegration, IHK-Prüfer und Hochschuldozent für Programmierung und Software-Engineering.

9 comments on “Lastenheft und Pflichtenheft – IT-Berufe-Podcast #189

  1. Michael sagt:

    Hallo Stefan,

    zu diesem Thema hatte ich letztens noch ein mal eine kleine Diskussion mit meinen Mitauszubildenden. Ob man das überhaupt braucht und was eigentlich der Unterschied ist. Eine Frage, die ich mir bis heute noch stelle, ist allerdings: Wie lässt sich vereinbaren, dass das Pflichtenheft ein Vertragsbestandteil ist, allerdings sowohl Muss-Kriterien als auch Wunsch-Kriterien beinhalten kann? Wird dann vertraglich festgehalten, dass es für jedes umgesetzte Wunsch-Kriterium eine Pauschale gibt? Und würde ein Auftraggeber nicht direkt zu einem anderen Anbieter wechseln, der in seinem Pflichtenheft alle Anforderungen als Muss-Kriterien auflistet?
    Und wenn im Lastenheft verschiedene Muss-, Soll- und Kann-Kriterien aufgeführt sind, entscheide ich dann grundsätzlich als Entwickler selbst, welche der Soll-Kriterien ich nur als Wünsche behandle? Oder stelle ich einfach die falschen Fragen?

    Mit freundlichen Grüßen
    Michael

  2. Sebastian sagt:

    Hallo Stefan,

    danke für die Begriffserklärung und die Klarstellung bei den Unterschieden.
    Mir ist das jetzt schon um einiges klarer geworden.

    Gruß
    Sebastian

  3. Stefan Macke sagt:

    Hallo Sebastian, freut mich, dass ich helfen konnte. Viele Grüße! Stefan

  4. David Kogan sagt:

    Hallo Stefan,

    ich habe da noch einige Fragen zum Lasten- und Pflichtenheft.
    Da mein Abschlussprojekt ein internes Projekt ist, gib es kein Lastenheft bzw. es werden von uns in der der Firma auch keine Pflichtenhefte erstellt.
    Jetzt Frage ich mich ob ich für das Abschlussprojekt tatsächlich auch das Lasten- und Pflichtenheft erstellen muss.
    Muss ich Lasten- und Pflichtenheft auch abgeben?
    Wie soll man das bitte in 70Stunden unterbringen oder ist das eine Sache die nicht in den 70 Stunden berücksichtigt werden muss?

    Gruß David

  5. Stefan Macke sagt:

    Hallo David,

    du musst dir für dein Projekt keine Inhalte ausdenken, die ihr in Wirklichkeit nicht erstellt. Meiner Meinung nach sollte es aber definitiv irgendeine Form der Anforderungsdefinition für ein Abschlussprojekt zum Anwendungsentwickler geben. Ob das Lasteheft oder DV-Konzept heißt, ist mir dann egal.

    Du wirst ja (hoffentlich!) nicht einfach „drauflos programmieren“, ohne die Anforderungen aufgenommen zu haben. Und in irgendeiner Weise werden diese Anforderungen dann ja auch niedergeschrieben sein (z.B. Tickets im Bugtracker oder Mails von Kollegen).

    Deine Aufgabe als Anwendungsentwickler ist (zumindest im Rahmen der Prüfung), eine methodische Softwareentwicklung zu zeigen. Und dazu gehört auch eine saubere Definition der Anforderungen. Also wenn ihr im Unternehmen kein Lasten-/Pflichtenheft schreibt, musst du für dein Projekt eine vernünftige Dokumentationsform erarbeiten.

    Diese Anforderungsaufnahme ist auch definitiv Teil der 70 Stunden! Das musstest du bereits im Projektantrag einplanen.

    Viele Grüße!
    Stefan

  6. Simon sagt:

    Hallo Stefan,

    erstmal: Tolle Seite, extrem informativ und hilfreich, vielen Dank für die enorme Arbeit die du hier reingesteckt hast!

    Nun habe ich noch zwei Fragen:
    1. Ich habe sowohl ein Lasten- als auch ein Pflichtenheft erstellt und jeweils einen Auszug daraus in den Anhang der Doku gepackt. Bei meiner IHK (München) kann man die Doku als PDF hochladen. Muss ich nun das Lasten- und Pflichtenheft noch komplett mitschicken oder reicht der Auszug in der Doku? Wenn ja wie mache ich das, da man nur eine Datei hochladen kann. Ich könnte dann höchstens aus dem Lasten- und Pflichtenheft ein PDF machen und das mit dem PDF der Doku verbinden aber das sollte ja denk ich mal nicht so sein?

    Beider IHK kommt bevor man die Doku hochladen kann eine Zustimmungsabfrage, welche einer eidesstaatlichen Erklärung entspricht. Bedeutet dies dass ich keine separate Erklärung in der Doku benötige?

    Gruß Simon

  7. Stefan Macke sagt:

    Hallo Simon,

    bei konkreten Fragen zu deiner Projektarbeit ist es immer am besten, wenn du direkt deine IHK fragst, da das komplett unterschiedlich gehandhabt wird.

    Zu 1) Deine Dokumentation wird bewertet und hat entsprechende Restriktionen (z.B. max. Seitenzahl usw.). Ob du zusätzliche Dateien anhängen musst/darfst, kann dir nur deine IHK sagen. Ich vermute aber nein.
    Zu 2) Das kann ich dir leider nicht sagen. Ich vermute, dass du keine zusätzliche Erklärung brauchst. Einige IHKen wollen aber irgendwo deine Unterschrift sehen. Also bitte nachfragen!

    Viele Grüße!
    Stefan

  8. Thea sagt:

    Sollte es hier nicht “ Lastenheft“ heißen?

    „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.

    Muss nicht alles erst im Lastenheft stehen, da sie alle Forderungen darlegt und somit Grundlage ist?

  9. Stefan Macke sagt:

    Nein. Wie geschrieben: Das Pflichtenheft ist Teil des Vertrags, also ist das „wichtiger“. Natürlich brauchst du letztlich beides, aber im Zweifel zählt das Pflichtenheft.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax