Zwei völlig unterschiedliche Dokumente: Lastenheft vs. Pflichtenheft

Mehrfach durfte ich schon die Erfahrung machen, dass in Projekten nicht allen klar war, was der Unterschied zwischen Lastenheften und Pflichtenheften ist – und warum beide in einem Projekt erstellt werden sollten.

Von Äpfeln und Birnen

Häufig werden diese beiden Dokumente durcheinandergeworfen. Dabei haben Lastenhefte und Pflichtenhefte sehr unterschiedliche und sehr wichtige Zwecke, wenn es darum geht, ein System zu entwickeln. Leider habe ich viele Projekte erlebt, die entweder kein Lastenheft angelegt hatten oder sich das Pflichtenheft sparen wollten.

Im extremsten Fall wird versucht, beide zu vereinen, sodass ein Lastenheft gleichzeitig auch das Pflichtenheft darstellen soll. Ich habe tatsächlich erlebt, dass diese zwei Dokumente sich einzig durch die Farbe der Sätze voneinander unterschieden. Das ist eine Katastrophe und führt mit Sicherheit zu nicht lösbaren Schwierigkeiten.

Zwei Dokumente – auf zwei Ebenen

Um diese Unterscheidung besser zu verstehen, sollte man sich die unterschiedlichen Ebenen klar machen, die hier involviert sind: Auf der obersten Ebene – der Kundenebene – gibt es die sogenannten Customer Requirements, also die Kundenanforderungen. Das sind ganz klassische Lastenhefte. Zusätzlich finden sich auf dieser Kundenebene noch die Stakeholder Requirements, also Anforderungen von Interessengruppen, die beispielsweise in internen oder externen Normen fixiert sind.

Bei komplexeren Systemen finden wir auf der direkt darunter liegenden Ebene die Systemebene. Hier wird das Pflichtenheft angesetzt. Im englischen Sprachgebrauch liegen hier die System Requirements Specification (SRS) und die System Architecture Specification (SAS). Erstere ist die Spezifikation der Systemanforderungen, letztere die Architekturbeschreibung des Systems.

Wünsche des Kunden – und Antworten des Projekts

Das Lastenheft ist also das „Wünsch-Dir-Was“ des Kunden bzw. des Auftraggebers. Wenn es keinen externen Kunden gibt, liegt es beispielsweise in der Verantwortung des Marketings oder des Produktmanagements, ein Lastenheft zu erstellen und freizugeben.

Ein Pflichtenheft hingegen ist die Antwort des Projektes auf die Wünsche im Lastenheft. Solange sich beide Parteien in einem Unternehmen befinden, ist es noch relativ einfach. Richtig schwierig wird es jedoch, wenn das Lastenheft von einem externen Kunden kommt.

Beide Dokumente sind wichtige Bestandteile des Vertragsabschlusses zwischen zwei Unternehmen – oft wird das aber nicht beachtet und führt dann zu sehr unschönen Situationen – vor allem, wenn das Projekt schief hängt.

Deshalb mein Rat: Unabhängig davon, wie groß dein Projekt ist und wie gut die Anforderungen an dein zu entwickelndes System beschrieben sind – achte darauf, dass du in deinem Projekt ein Lastenheft und ein Pflichtenheft getrennt vorliegend hast. Es ist entscheidend, dass beide zwei unabhängig voneinander existierende Dokumente sind!

Welche Erfahrungen hast du bislang mit dieser Unterscheidung gemacht? Hast du ein Lastenheft für dein Projekt erhalten? Und hast du dir die Zeit genommen, dich um ein Pflichtenheft zu kümmern?

1 Antwort
  1. Joachim Reinke
    Joachim Reinke sagte:

    Ich erlebe dieses Durcheinanderwerfen ebenfalls hier. Es gibt sogar für bestimmte interne “Produkte” SOPs, die vorschreiben, *nur* ein Lastenheft zu schreiben und *kein* Pflichtenheft. Halte ich für falsch.

    Meiner Beobachtung nach kommt das Durcheinanderwerfen v.a. durch Unkenntnis in der Kunst des Requirements Managements. Die beiden völlig unterschiedlichen Sichten, die ein Lastenheft und ein Pflichtenheft auf ein entstehendes Produkt (ich benutze das Wort mal völlig allgemein) haben sollen, sind vielen einfach nicht bewußt.

    Dazu kommt, dass Menschen mit ingenieursartiger Vorbildung (ich rechne da mal grob folgende Ausbildungen dazu: Physiker, Informatiker, Mathematiker, Biologen, Ingenieure, Mechatroniker, MTAs) von Haus aus dazu neigen, ausschließlich “in Lösungen zu denken”. Ich nehme mich da gar nicht aus. So sind wir einfach gestrickt.

    Ich frage meine Zuhörer immer “Habt ihr euch schon mal auf einer Party selbst dabei ertappt, wie euch irgendwer zu später Stunde mal ein technisches Problem geschildert hat und ihr geantwortet habt mit ‘Nee Du, das ist ja echt ein totales Problem, Du. Lass uns einfach mal hinsetzen, ‘ne Tasse Tee trinken und schauen, was das mit uns so macht’?”

    Hat natürlich keiner.

    Nein. “Wir” sind da schnell bei der Hand mit Lösungen. So sind wir halt gestrickt. Uns macht die Anwendung von Technik auf ein Problem Spaß. Nicht das Verstehen eines Problems. Ein Problem ist nur dann etwas wert, wenn es uns den Vorwand für ein Herumbasteln mit einer technischen Lösung gibt.

    Da stehen wir uns selbst im Weg.

    Wollen “wir Ingenieure” gute Lastenhefte schreiben, müssen wir lernen umzudenken, für einen Moment mal “auf Soziologe machen” und vergessen, dass wir gerne coole Lösungen ersinnen. Wir müssen uns erst einmal voll und ganz darauf einlassen, dass wir unseren Verstand auch einzig und alleine dazu brauchen können, ein Problem einfach nur zu verstehen. Klingt banal, ist es in der Praxis aber nicht.

    In dieser Hinsicht wären Soziologen vielleicht die besseren Lastenheftschreiber. Nur haben die “von Haus aus” nicht immer einen unbedingten Drang zu strukturierter Vorgehensweise. Nichts ist perfekt. Leider 😉

Kommentare sind deaktiviert.