Was unterscheidet das Pflichtenheft vom Lastenheft? Im allgemeinen Sprachgebrauch werden die beiden Begriffe Lastenheft und Pflichtenheft häufig synonym gebraucht, obwohl sie rechtlich und vor allem praktisch sehr gr0ße Unterschiede aufweisen.

Was erfahren Sie in diesem Beitrag? – Inhalte

Lastenheft Pflichtenheft  – Gemeinsamkeiten

Lasten- und Pflichtenheft sind wichtige Dokumente im Anforderungsmanagement und in der Produktentwicklung. Beide beschreiben grundsätzlich die Anforderungen an das zu entwickelnde Produkt, den Prozess oder die Dienstleistung. Aber hier enden auch die Gemeinsamkeiten.

Lastenheft Pflichtenheft  – Unterschiede

Der wesentliche Unterschied zwischen Lastenheft und Pflichtenheft ist die Sichtweise auf das Produkt.

• das Lastenheft beschreibt umfassend und detailliert die Anforderungen des Kunden oder des Auftraggebers an das Produkt (idealerweise für alle Betriebssituationen und Stufen des Produktlebenszyklus).
• das Pflichtenheft beschreibt detailliert die Produktspezifikation bzw. Lieferspezifikation, mit der der Lieferant glaubt, das Lastenheft erfüllen zu können.

Wichtig und hilfreich im Zuge einer Abgrenzung ist in beiden Fällen auch,  explizit zu beschreiben, was das Produkt nicht ist oder nicht leisten kann bzw. soll oder welche Betriebs- und Nutzungssituationen nicht berücksichtigt werden. Ebenso wichtig ist die Beschreibung der Schnittstellen zum umgebenden Systemumfeld.

Definition von Lastenheft – Pflichtenheft

• Das Lastenheft ist der Forderungskatalog des Auftraggebers bzw. Kunden.
  Andere Begriffe, die oft anstelle des Lastenheft-Begriffs verwendet werden sind u.a.  Kundenspezifikation, Anforderungsspezifikation oder Anforderungskatalog.
• Das Pflichtenheft ist der auf Basis des Lastenhefts erstellte Leistungskatalog des Auftragnehmers bzw. Lieferanten. Mit den darin zugesicherten, spezifizierten Merkmalen wird das zu entwickelnde Produkt die vom Kunden im Lastenheft geforderten Anforderungen erfüllen.
  Andere Begriffe, die sich oft anstelle des Pflichtenheft-Begriffs verwendet werden sind u.a.  Leistungsbeschreibung oder Leistungsspezifikation.

Anforderungsmanagement und Lasten- / Pflichtenheft

Eine zentrale Aufgabe des Anforderungsmanagements ( Requirements Engineering) ist die Erstellung des Pflichtenhefts. In der Regel umfasst dies auch die Klärung und Vervollständigung des kundenseitigen Lastenhefts, denn die meisten Lastenhefte und Pflichtenhefte sind unvollständig!

Anforderungsanalyse Workshop – Operative Unterstützung

Warum sind die meisten Lastenhefte unvollständig?

Ein Kunde bzw. Auftraggeber wird bei Beauftragung meist die Defizite und Verbesserungspotentiale des Vorgängerprodukts erinnern und entsprechend den Fokus für die Neu-Entwicklung legen. Der „Rest“ – sprich alle übrigen Merkmale – sollen idealerweise „genauso“ und unverändert bleiben. Oft werden diese aber nicht exakt im Anforderungskatalog beschrieben und spezifiziert. In der Folge fehlen dem Entwickler wichtige Informationen.

Warum sind die meisten Pflichtenhefte unvollständig?

Unvollständige Lastenhefte führen zwangsläufig zu unvollständigen, lückenhaften Pflichtenheften. Die Defizite werden häufig erst bei einer Muster- oder Protoypenpräsentation erkannt. Dies führt zu zeitraubenden und kostentreibenden Änderungsschleifen.

Erfahrene Entwickler, die Produkt und Anwendung gut kennen, werden meist die Lücken intuitiv füllen, in dem sie Annahmen treffen. Leider treffen die Annahmen nicht immer die Realität.

Methoden für vollständige Lastenhefte und vollständige Pflichtenhefte

• Markt- & Wettbewerbsanalyse
• Kundenbefragung z.B. Interview-Techniken
• Kunden- & Anwenderbeobachtung z.B. Customer Journey
• strukturierte Anforderungsnalayse mit Quality Funktion Deployment (QFD)

In der Praxis wird eine Kombination der Methoden die besten Ergebnisse liefern. Als Grundlage für Kundeninterviews und Anwendungsbeobachtungen verwenden wir immer QFD, weil diese Methode es erlaubt, strukturiert und systematisch alle relevanten Anforderungen zu erfassen.

Lastenheft erstellen – prinzipielle Vorgehensweise

1. Projektbegründung
2. Ausgangssituation
3. Soll-Situation
   1. Funktionale Anforderungen
   2. Nicht-funktionale Anforderungen
   3. Schnittstellen / Systemabgrenzung
4. Auftragsrahmen & Abnahmekriterien

Projektbegründung

Im Schritt 1 – Projektbegründung –  werden die für das Projekt relevanten Auslöser und Hintergründe dargestellt. In einigen Fällen werden bereits hier Zeitrahmen, Ziele bzw. angestrebte Verbesserungen und auch der Budgetrahmen skizziert.

Ausgangssituation / IST-Zustand

Im Schritt 2 – Ausgangssituation –  wird das aktuelle Produkt in seiner Verwendung, seiner Zielgruppe, Kosten und Marktpreisen, den marktseitigen, technischen, rechtlichen Rand- und Einsatzbedingungen sowie ggfs. mit Nachteilen oder Einschränkungen beschrieben.  Wichtig ist ebenfalls die Beschreibung der Schnittstellen sowie der relevanten Stakeholder.

SOLL-Zustand

Funktionale Anforderungen

Im Schritt 3.1 – funktionale Anforderungen –  werden – idealerweise in messbarer Form – die angestrebten Veränderungen bzw. Verbesserungen oder Erweiterungen gegenüber dem Ist-Produkt bzw. Ist-Zustand beschrieben. Idealerweise werden nur funktionale Forderungen im Lastenheft definiert und konstruktive Vorgaben vermieden.

Nicht funktionale Anforderungen

Im Schritt 3.2 – nicht funktionale Anforderungen –  werden weitere, über die funktionalen Anforderungen hinausgehende Anforderungen gesammelt. Diese können z.B. Performance-Merkmale, Komfort, Nutzbarkeit, Identifikation, Sicherheit oder Rückverfolgbarkeit innerhalb des Systemrahmens sein, d.h. sie sind nicht nur dem Produkt zugeordnet.

Schnittstellen / Systemabgrenzung

Im Schritt 3.3 – werden die Schnittstellen zum umgebenden System, die Kontrollelemente und Infrastruktur beschrieben. Wichtig ist sowohl den Material- als auch den Informationsfluss über die Schnittstellen zu definieren.

Auftragsrahmen und Abnahmekriterien

Der Auftraggeber / Kunde sollte den Auftragsrahmen beschreiben. In vielen Fällen wird er eine grobe Zeitplanung mit Meilensteinen erstellen –  idealerweise mit messbare Inhalten, Abnahme- und Abbruchkriterien den jeweiligen Meilenstein. Häufig wird an dieser Stelle auch eine Risikobetrachtung z.B. mit FMEA definiert.

Lastenheft erstellen – Beispiel

• Produktname
• Projektziel
• Produktbeschreibung Ist vs. Soll
• Beschreibung Systemumfeld und Schnittstellen
• Anwendungsbeschreibung (zulässig vs. nicht zulässig)
• Betriebssituationen
• Produktlebenszyklus
• Funktionale Anforderungen
• Qualitäts- und Zuverlässigkeitsanforderungen
• Sicherheitsanforderungen
• legislative bzw. normative Vorgaben
• Zeitrahmen
• Kostenrahmen
• Ressourcenrahmen
• Organisatorische Randbedingungen
• u.a.

Anforderungsanalyse Workshop

Üblicherweise werden die oben beschriebenen Inhalte im Team in Form von Anforderungsanalyse Workshops zusammengetragen und strukturiert. Folgende Methoden kommen häufig zum Einsatz:

Methoden im Anforderungsanalyse –  Workshop

• Produktklinik
• Kundeninterviews
• Anwenderbeobachtungen z.B. Customer Journey
• Lebenszyklusanalyse
• Wertanalyse
• Quality Function Deployment (QFD) und House of Quality (HoQ)
• Design Thinking

Sie haben unvollständige Lastenhefte, fehlerhafte Spezifikationen, späte Änderungen, Projektverzug oder  Kostenüberschreitungen?

Beratung Produktentwicklung – Lastenheft und Pflichtenheft