Zwei völlig unterschiedliche Dokumente: Lastenheft vs. Pflichtenheft
Mehrfach durfte ich schon die Erfahrung machen, dass in Projekten nicht allen klar war, worin der Unterschied zwischen Lastenheften und Pflichtenheften besteht – und warum beide in einem Projekt erstellt werden sollten.
Von Äpfeln und Birnen
Häufig werden diese beiden Dokumente durcheinander geworfen. Dabei haben Lastenhefte und Pflichtenhefte sehr unterschiedliche und äußerst wichtige Zwecke, wenn es darum geht, ein System zu entwickeln. Leider habe ich viele Projekte erlebt, in denen entweder kein Lastenheft angelegt wurde oder man sich das Pflichtenheft sparen wollte.
Im extremsten Fall wird versucht, beide zu vereinen, sodass ein Lastenheft gleichzeitig auch das Pflichtenheft darstellen soll. Das geht gar nicht. Ich habe tatsächlich erlebt, dass diese zwei Dokumente sich einzig und allein 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 klarmachen, die hier involviert sind:
1) 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 Abteilungen oder externen Parteien, wie Zulassungsstellen, die in Normen fixiert sind.
Abbildung 1 – Anforderungsebenen
2) Die direkt darunter liegenden Ebene ist 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 und beschreibt den Problemraum des Systems. Letztere ist die Architekturbeschreibung des Systems und stellt heraus, wie mögliche Lösungen des Systems aussehen werden.
Wünsche des Kunden – und Antworten des Projekts
Das Lastenheft ist also das „Wünsch-Dir-Was“ des Kunden bzw. des Auftraggebers. Die Verantwortung für das Lastenheft liegt beim Kunden. Wenn es keinen externen Kunden gibt, liegt es beispielsweise in der Verantwortung des Vertriebes, des Marketings oder des Produktmanagements, ein Lastenheft zu erstellen und freizugeben. Die Erstellung des Lastenhefts liegt in deren Verantwortung. In vielen Fällen nicht so gesehen und es kommt dazu, dass Projekte ohne Lastenheft starten müssen, weil keiner die Lasten an das Projekt zusammengestellt hat.
Ein Pflichtenheft hingegen ist die Antwort des Projektes auf die Wünsche im Lastenheft. Neben den Kundenwünschen werden weitere Anforderungen in Betracht gezogen, auf die im Pflichtenheft ebenfalls Bezug genommen wird. 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! Ein Lastenheft ist unabdingbar für die spätere Abnahme des Systems durch den Kunden. Das Pflichtenheft stellt eine solide Basis für den weiteren Fortschritt im Projektverlauf dar. Wurde keine Spezifikation der Wünsche des Kunden explizit vorgenommen, so empfiehlt es sich, dies als allererstes aufseiten des Projekts zu tun. Betrachte es als Dienstleistung für den Kunden. Er und auch das Projekt wird es dankbar hinnehmen, dass nachträglich ein Lastenheft erstellt wurde.
Der Unterschied zwischen Lastenheft und Pflichtenheft
Worin liegt aber nun der Unterschied zwischen Lastenheft und Pflichtenheft. Ein Thema, das immer wieder Fragen aufwirft und bei dem wir einige Zusammenhänge besprechen müssen, um später die Umsetzung besser zu verstehen.
Die oberste Ebene ist die Kundenebene. Dort gibt es die sogenannten Customer Requirements oder Kundenanforderungen. Das sind beispielsweise ganz klassische Anforderungen, die vom Kunden oder dem Produktmanagement bekommen.
Dann gibt es zusätzlich auch noch Stakeholder Requirements. Das sind Anforderungen von Interessensgruppen. Dabei handelt es sich um externe Gruppen oder Organisationen, wie z. B. den Gesetzgeber im Land des produzierenden Betriebs und im Land des (End-)Kunden. Auch Normungsgremien und Patentämter, die Vorschriften erlassen haben, wie ein Produkt eingesetzt werden kann oder darf, sind in diesem Fall einzubinden. Stakeholder sind aber auch interne Gruppen, die in irgendeiner Art und Weise mit dem Produkt zu tun haben. Dazu zählen die Produktion, der Service, der Versand, aber auch das Marketing, die technische Dokumentation und weitere. All diese Stakeholder haben möglicherweise ihre Anforderungen schon in internen oder externen Normen dokumentiert. Tipp: Willst Du Anforderungen wiederverwenden, dann empfiehlt sich das Aufsetzen einer Normenkommission. In einer Normenkommission wird festgelegt, dass ein gewisses Thema von den Anforderungen her immer gleich definiert wird.
Diese beiden Artefakte – also die Customer Requirements Specification (CRS) und die Stakeholder Requirements Specification (StRS) – sind die Spezifikationen auf der Kundenebene, klassisch die Lastenhefte im allgemeinen Sprachgebrauch.
Um den Unterschied zwischen Lastenheft und Pflichtenheft besser zu verstehen, müssen wir die nächste Ebene betrachten (siehe Abbildung 1). Wir haben bei komplexeren Systemen noch eine direkt darunter liegende Ebene, die Systemebene. Auf dieser nächsten Ebene ist das Pflichtenheft angesiedelt – im englischen Sprachgebrauch wird dies gerne als die System Requirements Specification (SRS) bezeichnet. Das ist aber leider nur die halbe Wahrheit. Denn ein Pflichtenheft ist die Antwort des Entwicklungsprojekts auf die Anforderungen des Kunden und weitere Stakeholder und muss daher auch eine grobe Skizze und Darstellung der Lösung beinhalten. Neben der Spezifikation der Systemanforderungen gehört also die System Architecture Specification (SAS), beziehungsweise die Architekturbeschreibung des Systems in dieses Dokument.
Was ist eigentlich ein Lastenheft?
Wie immer gibt es dazu auch eine wunderschöne Norm, und gemäß der DIN 69901-5 enthält das Lastenheft:
Die vom Auftraggeber festgelegte Gesamtheit der Anforderung an die Lieferung und Leistungen eines Auftragnehmers innerhalb eines Auftrags.
So kann man es bezeichnen. Ich würde einfach das Ganze mal ein bisschen pragmatischer sehen: Das Lastenheft beschreibt in der Regel, wofür etwas gemacht werden soll. Oder bezogen auf meine Schulungen und Trainings: Es ist am Ende des Tages das „Wünsch-dir-was“ des Kunden aus seiner Sicht.
Firmen, die als Zulieferer ein System für speziell einen Kunden im Rahmen eines Projektes entwickeln und herstellen, bekommen von ihrem Kunden üblicherweise auch ein mehr oder weniger gutes Lastenheft. Im Gegensatz zu Unternehmen wie den Automobilzulieferern haben Unternehmen, die für eine größere Masse entwickeln, um einem Markt oder einer Branche damit eine Lösung anzubieten, keinen Kunden, der Lastenhefte vorgibt. Also ist es die Aufgabe des Produktmanagements, alle Anforderungen an das System zu sammeln und dann in ein Lastenheft für die Entwicklung zu kippen. Sozusagen das „Wünsch dir was“ des Produktmanagements.
Dem Lastenheft des Produktmanagements steht dann die Entwicklung eines Pflichtenheftes entgegen. Das Pflichtenheft ist sozusagen die Antwort der Entwicklung auf das Lastenheft. Nur leider ist meine Erfahrung, dass Lasten- und Pflichtenhefte nicht sauber auseinander gehalten werden. Manchmal werden sogar Lastenhefte ohne Sinn und Verstand kopiert und als Pflichtenheft deklariert. Nachher wundern sich alle, dass die Projekte schieflaufen.
Was ist nun das Kernproblem, mit den Lastenheften
Wenn wir über Lastenhefte reden, gesellen sich gleiche mehrere Probleme mit dazu:
- Lastenhefte werden mit allem möglichen vollgemüllt, auch mit nicht-technischen Anforderungen.
Hier ein Originalzitat: „Die Inhalte dieser Spezifikation beschreiben nicht nur die technischen Anforderungen des Systems, sondern beinhalten auch die Anforderungen an das Personal, welches das Projekt umsetzen soll, ….“
- Lastenhefte werden entweder zu oberflächlich beschrieben oder es wird zu sehr ins Detail gegangen.
Zum Beispiel wird Pseudo-Code verwendet, um Verhalten zu beschreiben, der die Softwareentwickler massiv bei der Lösung einschränkt.
Keiner würde auf die Idee kommen, im Lastenheft schon einen 3D-Entwurf oder einen HW-Schaltplan zu skizzieren. Aber Quellcode wird gerne genutzt, um irgendein Verhalten zu beschreiben. Anwendungsfälle oder Zustandsdiagramm – so werden diese Verhaltensbeschreibungen genannt – sind dazu ideal geeignet, weil sie das Problem beschreiben, welches gelöst werden soll und nichts von der Lösung vorwegnehmen.
- Lastenhefte werden in der Regel nicht wirklich gelesen, sondern oft nur kurz überflogen.
Warum ist das so? Meine Erklärung dazu ist, dass wir Menschen gerne etwas erschaffen, wo sich was bewegt, etwas blinkt oder es sonst wie funktioniert. Bei einem Lastenheft ist es aber so, dass alles, was dort beschrieben wird, zunächst einmal ein Luftschloss ist. Es ist nur virtuell vorhanden. Und da nicht jeder ein guter Schriftsteller ist, sind wir auch schnell damit überfordert, die Gedanken des Autors zu verfolgen. Folglich legen wir das Papier schnell wieder weg und machen uns daran, dass wir das, was wir verstanden haben, umsetzen. Zumindest versuchen wir das.
- Die Verantwortlichen für die Erstellung des Lastenhefts haben entweder keine Lust, keine Zeit oder keine Erfahrung, um ein gutes Lastenheft zu erstellen.
Das gleiche Prinzip wie eben – nur umgekehrt. Der Autor selbst hat zwar eine Vorstellung von dem, was er gerne haben möchte, fühlt sich leider selbst nicht in der Lage, eine adäquate Beschreibung des Systems zu Papier zu bringen.
- Es ist immer schwierig, die wilden Kundenanforderungen einzufangen, da sie sich dauernd verändern.
Das einzig Konstante in einem Entwicklungsprojekt sind die Änderungen! Das ist laut einer Studie definitiv so. Im Laufe eines Jahres ändern sich 25 % aller Anforderungen eines Projektes. Entweder fallen sie weg, werden ersetzt oder ändern sich. Daher muss in den Projekten von Anfang an ein Änderungswesen definiert sein, damit diese Änderungen erfasst, gespeichert, bewertet und übernommen werden können.
- Nur wenige Entwickler lesen die Lastenhefte. Die meisten können und wollen sich damit nicht beschäftigen.
Hier spielt der Zeitdruck eine große Rolle. Oftmals sind die Entwickler so eingespannt, weil in laufenden Projekten noch Features realisiert werden sollen oder Fehler behoben werden müssen.
- Es gibt nur wenige, die das große Ganze des Systems sehen und die Zusammenhänge erkennen.
Dies ist eine Herausforderung, die die Fähigkeit, abstrakt zu denken voraussetzt. Das ist nicht jedem gegeben. Menschen denken eher in Lösungen – wie oben schon erwähnt – und wollen sich mit der Umsetzung und den Details auseinandersetzen. Damit komplizierte und komplexe Systeme beherrschbar sind und auch entwickelt werden können, sich auf eine 10.000 m Flughöhe begeben und die groben Strukturen erfassen und beschreiben zu können.
- Oft müssen wir innerhalb kurzer Zeit ein Lastenheft erstellen oder bewerten.
Zwischen einem Kundenbesuch und dem nächsten Lastenheft, mal eben für den Kollegen ein kurzes Review machen. Oder zwischen einem Feature und einem Bugfix schnell noch das Freigabe-Review vorbereiten. Das ist das Tagesgeschäft. Wie kann da ein Lastenheft erstellt oder bewertet werden? Eine Datenbank mit Anforderungen, die wiederverwendet werden kann, wäre da hilfreich. Und für das Review ein Filter, der nur die neuen und geänderten Anforderungen anzeigt. Aber leider steht ein solches Werkzeug nicht zur Verfügung. Also, machen wir es doch wieder mit den Fähnchen (Excel)!
- Gerade bei kritischen Projekten wäre es entscheidend, wenn alle das gleiche Systemverständnis hätten.
Hier helfen nur gemeinsame Workshops, die das Miteinander fördern, Diskussionen zulassen und eine gemeinsame Lösung dokumentieren. Eine Möglichkeit dies zu erreichen und damit eine Basis für das Lastenheft zu legen ist der System-Footprint – das visualisierte Systemverständnis.
Wann und warum ein Lastenheft
Wenn wir mal einen Gedankenschwung über Sinn und Zweck des gesamten Themas machen, so finden wir zwei grundlegende Ausgangslagen für Lastenhefte. Ich möchte diese ein wenig beleuchten.
Unabhängig davon, welchen Business Case Du in Deinem Unternehmen tatsächlich vorliegen hast, es gibt immer diese eine Konstellation: Jemand möchte etwas entwickelt wissen und jemand anderes – ein Spezialist bzw. die richtige Abteilung – entwickelt dieses Etwas.
Die erste typische Ausprägung für ein Lastenheft liegt vor, wenn ein Geschäftskunde sagt: „Ich will für mein Gesamtsystem ein Teilsystem entwickelt haben. Dafür hole ich mir einen externen Spezialisten, der das entwickeln und produzieren kann.“
Diese Situation finden wir typischerweise in der Automobilentwicklung oder bei der Luft- und Raumfahrt, d. h. in Branchen, die mit großen, komplexen Systemen arbeiten. Hier werden die Lastenhefte von den Herstellern erstellt, um den Zulieferern alle nötigen Informationen und Inhalte für die Erstellung und spätere Umsetzung ihrer Angebote vorzulegen.
Die zweite typische Ausprägung bzw. Situation ist die ohne direkten Kunden: Du lieferst in diesem Fall in den Markt hinein, ohne dass es konkrete technische Zielpersonen gibt, wie z. B. in der klassischen Consumer-Elektronik oder bei bestimmten Spezialprodukten.
Hier sind es Produktmanagement und Marketing, die Deine eigentlichen Kunden abbilden. In diesen Fällen arbeitet man nicht mit dem technischen Spezialisten oder dem Projektleiter von beispielsweise VW, wie es bei der ersten Ausprägung der Fall ist. Stattdessen sind es hier eher Produktmanager oder Marketing-Leute, die mit Dir sprechen und Dir eigentlich das Lastenheft übergeben sollten. Warum? Sie dokumentieren damit ihre Wünsche, das Lastenheft ist ihr „Wünsch-Dir-was“ – das zusätzlich auch die Beschreibung ihrer Probleme beinhaltet. Das Entscheidende aber für jede dieser hier beschriebenen Ausprägungen, für jeden Kunden und jedes Lastenheft: Lastenhefte sind nicht für Lösungen da.
Wenn wir das Thema kurz ein wenig größer aufziehen und fragen, wo Lastenhefte hineingehören, so sehen wir wieder die unterschiedlichen Ebenen, die bereits in einigen Podcast-Episoden diskutiert wurden: Es sind diese hierarchisch übereinandergelegten Bereiche, von denen der oberste die Kundenebene darstellt. Und genau auf dieser Ebene existiert das Lastenheft mit der reinen Wunsch- und Problembeschreibung, oft in Kombination mit ergänzenden Grundlagen wie Normen oder referenzierten Standard-Branchenvorgaben etc.
Die nächste Ebene darunter ist die Systemebene mit zwei Artefakten bzw. zwei Teilspezifikationen: Die Systems-Requirements- und die Systems-Architecture-Specification. Ersteres ist die Antwort auf das Lastenheft, während letzteres quasi die Lösungsbeschreibung darstellt. Dies findet also auf einer anderen Ebene statt als das Lastenheft, welches ja als Dokumentation der Wünsche erstellt wird.
Ein Entwicklungsprojekt antwortet auf diese Wunschliste mit einem Pflichtenheft – auch wenn ich diesen Begriff nicht gerne verwende: Er fasst beide Artefakte aus der Systemebene zusammen, obwohl der Systems-Requirements-Teil aus problem-beschreibender Sicht eigentlich schon die Antwort darstellt.
Also: Das Lastenheft gehört als „Wünsch-Dir-was“ auf die oberste, auf die Kundenebene! Und dort ist es DAS entscheidende Dokument, DAS Artefakt, das ausschlaggebend für ein erfolgreiches Projekt ist.
Meine Erfahrungen aus mehreren Jahren als Software- und Systemingenieur zeigen das immer wieder: Projekte, die extreme Schwierigkeiten hatten und sehr stark gestrauchelt sind, hatten immerhin ein mangelhaftes Lastenheft, an dem sie sich mehr schlecht als recht entlanghangeln konnten.
Die Projekte allerdings, die grandios und komplett an die Mauer gefahren wurden, hatten überhaupt kein Lastenheft. Daher denkt daran: Warum Lastenhefte? Weil sie absolut essenziell für erfolgreiche Projekte sind!
Was gehört ins Lastenheft und was nicht?
In diesem Abschnitt gehe ich darauf ein, welchen Zweck ein Lastenheft hat und was ins Lastenheft für ein technisches System gehört.
Was ist der Zweck eines Lastenheftes?
Der Sinn und Zweck eines Lastenheftes ist es, Klarheit zu schaffen, welche Anforderungen ich als Kunde an ein zu entwickelndes Systems stelle. Somit beschreibt es meine Wünsche, die ich an das zu entwickelnde System habe. Der Zweck eines Lastenheftes ist es damit, meine Wünsche und Anforderungen zu klären und zu dokumentieren.
Was gehört nicht ins Lastenheft?
Um diese Frage zu beantworten ist es sehr hilfreich, sich ein paar Gedanken dazu zu machen, was in ein Lastenheft gehört. Ein Lastenheft ist eine technische Beschreibung eines Systems. Damit beschreibt es die Anforderung an ein System, die nach erfolgreichem Abschluss eines Entwicklungsprojektes übrig blieben.
Das bedeutet, in einem Lastenheft beschreibe ich nicht die Anforderung an ein Projekt. Anforderungen wie beispielsweise Termine, Entwicklungsbudget, Ansprechpartner, Prozessvorgaben usw. gehören somit zu einem Projekt. Sie sind so lange wichtig, wie das Entwicklungsprojekt läuft. Ist das Entwicklungsprojekt abgeschlossen, sind diese Anforderung irrelevant. Diese Anforderungen gehören somit in ein Projekthandbuch oder Projektauftrag.
Sollte ein Ansprechpartner in einer Anforderung eines Lastenhefts auftauchen, so muss bewertet werden, ob und wie diese Anforderung getestet werden kann. Dazu könnte der Testmanager einen Anruf bei der entsprechenden Person einplanen. Was aber, wenn diese Person an dem Tag des Tests nicht erreichbar ist? Dann würde der Testfall und das Testszenario fehlschlagen. Ist damit die Abnahme gefährdet? Sieht man es ganz korrekt: Ja! Oder die Freigabe wird unter Einschränkungen erteilt.
Was gehört ins Lastenheft?
Im Gegensatz dazu beschreibe ich in einem technischen Lastenheft die Anforderung an ein System, die vorhanden sein müssen, wenn das Projekt abgeschlossen ist. Das bedeutet, ich beschreibe alle technischen Anforderungen, wie beispielsweise funktionale und nicht-funktionale Anforderungen. Das können Anforderungen sein an die Funktionen des Systems, Anforderungen an Reaktionszeiten des Systems oder Anforderungen an sicherheitsrelevante Punkte des Systems sein.
Schlusspunkt
Jedes Projekt benötigt ein Lastenheft zur Aufnahme der technischen Anforderungen und einen Projektauftrag für die Anforderungen und Randbedingungen an das Projekt.
Für das Lastenheft empfehle ich (= Kundenebene = „Wünsch-dir-was“ des Kunden oder Produktmanagements) pragmatisch zu bleiben. Das bedeutet, dass
- lasse weg, was schon mal beschrieben wurde
- lege die Grundsteine für die Traceability schon mit dem Lastenheft
- trenne zwischen Projekt- und Systemanforderungen
Wichtig: Weglassen heißt nicht komplett weglassen, sondern nur, das, was du mit Sinn und Verstand nicht brauchst. Lasse aber definitiv nicht gesamte Bereiche im Lastenheft weg, sonst kommst du in Situationen, dass du nachher nicht mehr nachvollziehen kannst, was da eigentlich gewollt wurde, wenn nicht das Gewünschte herauskommt. Fokussiere dich auf das Neue im Lastenheft, beschreibe dies und erwähne Bekanntes aus vergangenen Projekten als Hinweis für das Pflichtenheft.
Somit ist der Unterschied zwischen Lastenheft und Pflichtenheft der, dass ein Lastenheft die Wünsche des Kunden beschreibt und ein Pflichtenheft die Antwort des Projektes darstellt.
Ich brauche ein professionelles Lastenheft
Du möchtest das Risiko in Deinem Projekt signifikant senken?
Vereinbare einen Termin mit mir und ich helfe Dir mit meinem erprobten Prozess. Du erhältst in 2 Wochen ein Lastenheft.
