Was wird gefordert, was wird umgesetzt?
Lastenheft und Pflichtenheft gehören zu den bekanntesten Begriffen im Systems Engineering. Trotzdem ist oft unklar, wo das eine Dokument endet und das andere beginnt. Dazu kommt: In verschiedenen Unternehmen werden die Begriffe nicht immer gleich verwendet.
Ich nutze sie in diesem Artikel in ihrer klassischen Bedeutung: Das Lastenheft beschreibt, was der Auftraggeber erreichen möchte und wofür. Das Pflichtenheft beschreibt, wie der Auftragnehmer diese Anforderungen erfüllen will. Entscheidend ist, dass beide Seiten die Begriffe und den Umfang der Dokumente zu Projektbeginn gemeinsam klären.
Kurz erklärt: Lastenheft und Pflichtenheft
- Lastenheft
- Beschreibt den Bedarf aus Sicht des Auftraggebers
- Beantwortet: Was soll erreicht werden – und wozu?
- Enthält Anforderungen und Rahmenbedingungen
- Dient als Grundlage für Angebote und die weitere Spezifikation
- Ist Vertragsbestandteil – weil es die ursprünglichen Bedarfe besschreibt
- Pflichtenheft
- Beschreibt die geplante Umsetzung aus Sicht des Auftragnehmers
- Beantwortet: Wie soll die Lösung die Anforderungen erfüllen?
- Konkretisiert Anforderungen und Lösungsansatz
- Dient als Grundlage für Entwicklung, Abstimmung und Umsetzung.
- Ist ebenfalls Vertragsbestandteil – weil es beschreibt, was geliefert werden kann
Das Lastenheft und das Pflichtenheft sind also keine konkurrierenden Dokumente. Sie betrachten dasselbe Vorhaben aus unterschiedlichen Perspektiven und auf unterschiedlichen Spezifikationsebenen.
Das Lastenheft beschreibt den Bedarf
Im Lastenheft – oder besser, der Customer Requirments Specification (CRS) – hält der Auftraggeber fest, welche Anforderungen und Rahmenbedingungen für das neue System gelten. Dabei geht es nicht darum, bereits die konkrete technische Lösung vorzugeben. Im Mittelpunkt stehen der Bedarf, der Nutzen und der gewünschte Zielzustand.
Dazu gehört zunächst der Kontext des Systems: In welcher Umgebung soll es eingesetzt werden? Mit welchen Menschen, Systemen und Prozessen interagiert es? Welche Aufgaben oder Probleme soll es unterstützen?
Die heutige Ausgangslage kann dabei wichtig sein. Sie sollte aber nicht den Blick auf das Zielsystem verstellen. Eine Beschreibung der bestehenden Abläufe hilft nur dann, wenn sie erklärt, welche Anforderungen daraus entstehen. Das Ziel ist nicht, den Ist-Zustand einfach in eine neue Lösung zu übertragen. Das Ziel ist, klar zu beschreiben, was künftig gebraucht wird.
Um den Kontext greifbar zu machen, nutze ich unter anderem den System Context und den System Footprint. Damit lassen sich die Systemgrenze, relevante Akteure und umliegende Systeme übersichtlich darstellen. So wird sichtbar, welche Anforderungen aus dem Umfeld kommen und an welchen Stellen Schnittstellen berücksichtigt werden müssen.
Abb. 1: Ebenen der Spezifikationen
Anforderungen kommen von mehreren Beteiligten
Nicht alle Anforderungen stammen direkt vom Kunden oder vom Produktmanagement. Auch weitere Stakeholder können Anforderungen einbringen. Dazu gehören zum Beispiel interne Fachbereiche, Betreiber, Service, Einkauf oder externe Interessengruppen. Hinzu kommen Vorgaben aus Normen, Richtlinien und anderen verbindlichen Rahmenbedingungen.
Deshalb sollte vor dem Schreiben geklärt werden, wer relevante Anforderungen beisteuern kann. Manche Beteiligte lassen sich direkt in Gespräche oder Workshops einbinden. Bei großen oder schwer erreichbaren Nutzergruppen kann es sinnvoll sein, mit Personas oder typischen Nutzungsszenarien zu arbeiten. Wichtig ist, dass die verschiedenen Perspektiven nicht unter den Tisch fallen.
Anwendungsfälle helfen, den Bedarf konkret zu machen. Sie sollten nicht nur den späteren Betrieb abdecken. Ein System hat einen Lebenszyklus: Es wird geplant, entwickelt, getestet, genutzt, gewartet und irgendwann außer Betrieb genommen. Auch während der Entwicklung können Anwendungsfälle wichtig sein, etwa für Tests und die Dokumentation von Ergebnissen.
Zur Stilllegung gehören ebenfalls Anforderungen. Wird das System zurückgenommen und verwertet? Wird es archiviert oder entsorgt? Oder bleibt es an einem Ort zurück, an dem andere Menschen darauf zugreifen könnten? Je nach System und Einsatzumgebung kann es notwendig sein, eine sichere Außerbetriebnahme vorzusehen.
Das Pflichtenheft beschreibt den Lösungsweg
Auf Basis des Lastenhefts konkretisiert der Auftragnehmer, wie die Anforderungen erfüllt werden sollen. Das Pflichtenheft beschreibt damit den Lösungsansatz und die geplante Umsetzung.
Bei komplexen Systemen kann diese Arbeit in mehrere Spezifikationsebenen gegliedert werden. Auf der Kundenebene stehen beispielsweise Kundenanforderungen und Stakeholder-Anforderungen. Darunter liegt die Systemebene mit den Systemanforderungen – oft als System Requirements Specification (SRS) bezeichnet – und der Systemarchitektur, häufig als System Architecture Specification (SAS).
Auf weiteren Ebenen werden Anforderungen und Architekturen für einzelne Technologien ausgearbeitet. Dazu können Software, Hardware und mechanische Komponenten gehören. Welche Dokumente dafür sinnvoll sind, hängt vom System und vom Projekt ab. Nicht jedes Vorhaben braucht jede Spezifikation in derselben Ausführlichkeit.
Auf Systemebene wird unter anderem geklärt:
- Welche Funktionen muss das System bereitstellen?
- Aus welchen Komponenten besteht es?
- Welche Schnittstellen sind erforderlich – physikalisch, elektrisch oder logisch?
- Welche vorhandenen Komponenten lassen sich wiederverwenden?
- Wie werden die Anforderungen überprüft?
So wird aus dem beschriebenen Bedarf ein nachvollziehbarer Lösungsweg. Gleichzeitig entsteht eine Verbindung zwischen der ursprünglichen Anforderung und den daraus abgeleiteten System- und Technologieanforderungen. Diese Nachvollziehbarkeit hilft später zu verstehen, warum eine Funktion oder Komponente entwickelt wurde und welche Anforderung sie erfüllt.
Anforderungen sind keine Aufgaben
Im Lastenheft beschreibe ich, was das System leisten oder erfüllen muss. Dazu können funktionale Anforderungen, Leistungsmerkmale, physikalische Eigenschaften, Qualitätsanforderungen und Schnittstellen gehören.
Eine Anforderung beschreibt also eine Eigenschaft oder ein Verhalten des Systems. Sie ist nicht mit einer Projektaufgabe zu verwechseln. Aufgaben werden im Projekt- und Aufgabenmanagement geplant. Sie entstehen, wenn aus Anforderungen konkrete Arbeitspakete und Zuständigkeiten abgeleitet werden.
Damit Anforderungen in der Entwicklung nutzbar sind, sollten sie klar, eindeutig und überprüfbar formuliert sein. Eine konsistente Satzschablone – zum Beispiel aus dem SOPHIST-Umfeld – kann dabei helfen. Sie unterstützt unterschiedliche Formulierungen, ohne dass jede Anforderung denselben Satzanfang haben muss.
Auch eine Priorisierung kann nützlich sein, ist für mich aber nicht automatisch der erste Schritt bei der Erstellung des Lastenhefts. Zunächst möchte ich den Bedarf vollständig verstehen und einordnen. Wenn später entschieden werden muss, was zuerst umgesetzt wird oder welche Leistungen in welchem Zeitraum entstehen, bekommt die Priorisierung eine andere Rolle. Das wird dann mit dem Auftragnehmer abgestimmt.
Die Spezifikation muss zum Projekt passen
Lastenheft und Pflichtenheft sind wichtige Hilfsmittel. Sie sollten aber kein Selbstzweck sein. Je nach Größe und Komplexität des Projekts reicht eine schlanke Spezifikation aus. Bei komplexen Systemen kann eine stärkere Aufteilung in Ebenen und Dokumente sinnvoll sein.
Für mich zählt, dass Anforderungen verständlich und überprüfbar sind und dass ihre Ableitung in die Umsetzung nachvollziehbar bleibt. Ein gutes Lastenheft schafft ein gemeinsames Verständnis des Bedarfs. Ein gutes Pflichtenheft zeigt, wie daraus eine tragfähige Lösung entstehen soll.
Das ist ähnlich wie bei einer Bandprobe: Erst wenn alle dasselbe Stück vor Augen haben, kann aus den einzelnen Instrumenten ein stimmiger gemeinsamer Sound werden.
Du möchtest Lastenheft und Pflichtenheft in deinem Projekt klar voneinander abgrenzen? Dann schreib mir an backstage@wir-rocken-engineering.de – und wir schauen gemeinsam auf deinen Bedarf.
