Lasten- und Pflichtenheft in der Projektdokumentation

Ein Hörer meines Podcasts bat mich, doch einmal die Begriffe Lasten- und Pflichtenheft voneinander abzugrenzen, da diese zwar häufig verwendet werden, aber anscheinend nicht immer allen Beteiligten so ganz klar sind (siehe auch Was? Pflichtenheft und Lastenheft sind nicht dasselbe?).

Definition

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

Relevanz für die Praxis

Lasten- und Pflichtenheft sind zwei Artefakte, die ich in (fast) jeder IHK-Projektdokumentation erwarte. Aber auch im realen Leben haben sie ihre Daseinsberechtigung. Maik Pfingsten hat zum Thema Lastenhefte sogar einen eigenen Podcast laufen: Lastenheft erstellen – lastenhefterstellen.de. In Episode 2 geht er – wie passend – auf den Unterschied zwischen Lasten- und Pflichtenheft ein: Lastenheft vs. Pflichtenheft. Und in diesem kurzen Blog-Artikel behandelt er das Thema auch noch einmal: Der Unterschied zwischen Lastenheft und Pflichtenheft.

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 😉

Wer erstellt das Lasten- und Pflichtenheft?

Wie die Definitionen oben nahelegen, sollte das Lastenheft vom Kunden erstellt werden und das Pflichtenheft vom Entwickler. Der Kunde formuliert, was er gerne hätte (also die fachlichen Anforderungen), und der Entwickler definiert die dazu passende konkrete technische Lösung.

In der Praxis ist es allerdings häufig so, dass der Kunde seine Anforderungen gar nicht genau kennt, geschweige denn sie so formulieren kann, dass ein Entwickler sie versteht. Daher spricht nichts dagegen, dass die Entwickler schon beim Erstellen des Lastenhefts mitarbeiten.

Wenn ihr genau in die Zeitplanung von Gerdas und Markus‘ Dokumentation schaut, werdet ihr 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 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 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. diesen hier: Lastenheft: Anforderungen für die Webentwicklung definieren. Und wer es richtig „enterprisey“ haben will, dem empfehle ich die 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 Softwareentwickler ohne Kommentar auf den Tisch legen können und er 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 zeigt 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. Schaut euch die Definitionen und einige Beispiele in Ruhe an und lernt sie auch für die Prüfung. Wie man sie sinnvoll in die Projektdokumentation einbaut, könnt ihr in den Dokumentationen von Gerda und Markus sehen.


Setzt ihr in eurem Unternehmen Lasten- und/oder Pflichtenhefte ein? Habt ihr vielleicht Vorlagen oder Styleguides für die beiden Artefakte? Oder Links zu guten Beispielen? Ich würde mich über eure Kommentare freuen!

7 thoughts on “Lasten- und Pflichtenheft in der Projektdokumentation

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

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

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

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

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