Lastenheft vs. Pflichtenheft

Lastenheft und Pflichtenheft  – Eine Definition

Oft herrscht Verwirrung zwischen den beiden Begriffen – oftmals werden sie für das gleiche Dokument gehalten. Dabei besteht ein klarer Unterschied zwischen den beiden.

Was ist ein Lastenheft?

Das Lastenheft spiegelt die Sicht des Auftraggebers, also des Kunden, wider. Im Lastenheft definiert dieser seine gesamten Anforderungen an das Projekt bzw. Produkt. Der Auftragnehmer nutzt das Lastenheft dann als Grundlage für die Anfertigung des Pflichtenhefts.

• Wird vom Auftraggeber erstellt
• Beinhaltet alle Anforderungen, die an das Produkt gestellt werden
• Stellt die Basis dar für das Angebot des Anbieters und bildet damit die Grundlage für das Pflichtenheft
• Aus Sicht des Kunden

Vom Lastenheft zum Pflichtenheft

Das Pflichtenheft beschreibt die Auftragnehmer-Seite. Hier wird festgehalten, wie das Problem des Kunden gelöst werden soll. Dafür werden alle technischen Anforderungen festgehalten: Welche Funktionen werden eingeführt und wie werden diese umgesetzt? Bevor es an die Umsetzung geht, muss das Pflichtenheft vom Auftraggeber abgesegnet werden.

• Wird hauptsächlich vom Software-Anbieter verfasst und bildet den Lösungsansatz
• Alle Anforderungen werden auf technischer Basis festgehalten: Welche Funktionen werden eingeführt und wie werden diese umgesetzt
• Wird vom Auftraggeber abgesegnet, bevor es an die Umsetzung geht
• Aus Sicht des Dienstleisters

Was genau steht im Lastenheft?

Es ist wichtig, die Anforderungen so präzise wie möglich zu definieren. Nur so können Preis und Zeitaufwand zuverlässig geschätzt werden – außerdem erhalten Sie nur bei optimaler Anforderungsdefinition genau das Produkt erhalten, welches am besten für die Erreichung Ihrer Ziele geeignet ist.

Aus diesem Grund gibt es einige Punkte, die fest in jedem Lastenheft verankert sein sollten:

• Konzept & Rahmenbedingungen
• Ausgangssituation
• Ist-Zustand
• Soll-Zustand bzw. Zielsetzung
• Projektbeteiligte
• Funktionale Anforderungen
• Nichtfunktionale Anforderungen
• Schnittstellen
• Lieferumfang
• Abnahmekriterien

Tipp

Weiterhin wird unterschieden zwischen Projektanforderungen und Systemanforderungen. Projektanforderungen (Budget, Systemanforderungen, Kapazitäten) sind, im Gegensatz zu den Systemanforderungen, erst nach Projektabschluss hinfällig und sollten deshalb gesondert formuliert werden.

Sind Lasten- und Pflichtenhefte noch zeitgemäß?

Der größte Vorteil von klassischen Lasten- und Pflichtenheften ist die große Planungs- und Budgetsicherheit. Der Auftraggeber weiß ganz genau, was er geliefert bekommt und wie viel er am Ende dafür zahlen muss.

Das funktioniert insbesondere dann gut, wenn zu erwarten ist, dass der Projektrahmen für einen langen Zeitraum unverändert bleibt – eine Annahme, die heute nur noch selten zutrifft.

Das Problem klassischer Lastenhefte

Die Welt, wie wir sie heute kennen, zeichnet sich vor allem durch wachsende Komplexität und stetigen Wandel aus. Dadurch kann es zu Planungsunsicherheiten kommen. Die Konzeption, Planung und Umsetzung eines Projektes kann mehrere Monate in Anspruch nehmen, innerhalb derer sich wichtige Rahmenbedingungen ändern können. Bereits im Entwicklungsprozess kann sich herauskristallisieren, dass das Produkt, in der Form, wie es zu Beginn geplant wurde, nicht mehr die beste Lösung darstellt.

Besonders bei Softwareprojekten diese Problematik allgegenwärtig. Erfahrungsgemäß wird selten exakt die Lösung entwickelt, die anfangs noch geplant wurde – und das ist auch gut so!

Häufig kommt es während der Umsetzung zu einem Lernprozess, in welchem neue Erkenntnisse zum Ausdefinieren eines Produktes beitragen können. Insofern kann es äußerst nachteilig für Auftraggeber sein, alle Anforderungen an ein Produkt bereits vor der Umsetzung fest zu definieren und als Auftragsgrundlage zu nehmen.

Projekte, die klassisch auf dem Lasten- und Pflichtenheft-Prinzip beruhen, sind mit dieser Herangehensweise nicht flexibel genug. Das Management muss schnell auf sich ändernde Rahmenbedingungen reagieren können.

Wie kann man den Entwicklungsprozess flexibel gestalten?

Um den oben genannten Lernprozess angemessen in den Entwicklungsprozess integrieren zu können, kommt häufig agiles Arbeiten zum Einsatz.

Die agile Softwareentwicklung erfolgt in kleinen Schritten, sogenannten Entwicklungssprints. In kurzen Entwicklungsphasen von einer Woche bis einem Monat werden neue Entwicklungen und Erkenntnisse direkt mit den Kunden geteilt und besprochen. Ziel ist es, schnell zu einer ersten Lösung, oft ein MVP (Minimal Viable Product) zu gelangen. Auf diese Weise können neue Learnings stetig in den Entwicklungsprozess integriert werden.

Wie definiert man agile Anforderungen?

Das Ziel ist zu lernen, was man wirklich braucht, um die gesetzten Ziele zu erreichen. Dies ist nicht immer deckungsgleich mit dem, was zu Beginn von der Lösung erwünscht worden ist.

In einem agilen Prozess wird das Lernen durch eine interaktive Vorgehensweise in Sprints ermöglicht, wodurch neue Erkenntnisse in den nächsten Sprints integriert werden können. Das kann bedeuten, dass im Vorfeld gesetzte Anforderungen an Bedeutung verlieren und deren Umsetzung möglicherweise nicht mehr sinnvoll ist.

Ist eine genaue Planung in agilen Prozessen also gar nicht mehr notwendig?

Doch! Agiles Arbeiten ist nicht gleichzusetzen mit planlosem Arbeiten. Es kann trotzdem sinnvoll sein, ein Lastenheft anzulegen und sich ausgiebig Gedanken zu den wichtigsten Anforderungen zu machen. Lediglich die Form des Lastenhefts kann sich vom klassischen unterscheiden.

Das agile Lastenheft

Im agilen Lastenheft werden im Gegensatz zum klassischen Lastenheft nicht alle Aspekte ins kleinste Detail ausformuliert. Bereits vorhandene Anforderungen werden gesammelt und eine erste Version des Lastenhefts erstellt.

Auf Grundlage der ersten Version wird bereits mit der Umsetzung begonnen, in deren Zuge weitere Anforderungen hinzukommen. Darauf entstehen in der Folge weitere, genauer definierte Versionen des Lastenhefts.

Vorteile des agilen Lastenheftes

• Die Umsetzung beginnt früher, die sonst lange Vorlaufphase bis zur Fertigstellung des Lastenheftes wird umgangen
• Auf geänderte Rahmenbedingungen kann schnell reagiert werden
• Es werden nur jene Anforderungen formuliert, die am Ende auch umgesetzt werden
• Aus neuen Learnings, welche im Prozess entstehen können

Agiles Projektmanagement mit SCRUM

Scrum kommt aus der Softwareentwicklung und ist die wohl bekannteste agile Arbeitsmethode. Die Entwicklung findet in kurzen, 1- bis 2-wöchigen Sprints statt. Nach jedem Sprint können die Ergebnisse getestet und die Anforderungen für den nächsten Sprint angepasst werden.

Bei Scrum wird vollständig auf die Erstellung von Lastenheft und Pflichtenheft verzichtet. Stattdessen wird mit einem Backlog sowie mit User-Stories gearbeitet.

Backlog statt Lastenheft

• in dem Backlog werden Tasks für den nächsten Sprint angelegt
• der Backlog lässt sich als kleines, flexibles Lastenheft und Pflichtenheft verstehen, denn dort werden die Anforderungen als auch die Lösungsansätze definiert
• weiterhin hilft die regelmäßige Erstellung von User-Stories, die Anforderungen zu präzisieren und zu aktualisieren

User Stories

User-Stories (oder Anwendererzählungen) bestehen aus wenigen Sätzen, die beschreiben, was ein Nutzer mit einem Produkt bzw. einem Softwarefeature machen will oder muss. Sie zeigt, welchen Wert das Produkt oder eine Funktion für den Nutzer hat.

Lastenheft und Leistungsbeschreibung: Was ist der Unterschied?

Bei öffentlichen Ausschreibungen oder im Bauprojektmanagement wird oftmals von der Leistungsbeschreibung gesprochen. In dieser wird im Einzelnen definiert, was beschafft werden soll. Sie ist das Schlüsseldokument im Vergabeverfahren, denn auf Ihrer Basis werden die Angebote erstellt. Insofern ist die Leistungsbeschreibung gleichzusetzen mit dem Lastenheft.

Allerdings ist anzumerken, dass die allgemeinen Anforderungen an die Leistungsbeschreibung in § 121 des Gesetzes gegen Wettbewerbsbeschränkungen (GWB) festgelegt sind. Dort heißt es unter anderem:

"In der Leistungsbeschreibung ist der Auftragsgegenstand so eindeutig und erschöpfend wie möglich zu beschreiben, sodass die Beschreibung für alle Unternehmen im gleichen Sinne verständlich ist und die Angebote miteinander verglichen werden können. Die Leistungsbeschreibung enthält die Funktions- oder Leistungsanforderungen oder eine Beschreibung der zu lösenden Aufgabe, deren Kenntnis für die Erstellung des Angebots erforderlich ist, sowie die Umstände und Bedingungen der Leistungserbringung."

Fazit – Lastenheft und Pflichtenheft

Das klassische Lastenheft und Pflichtenheft stellt vor allem in der Entwicklung von Software nur noch selten die optimale Lösung dar. Deshalb lösen agile Entwicklungsmethoden immer häufiger klassische Lasten- und Pflichtenhefte ab.

Wie unterstützt Sie itPortal24?

Besonders wenn kein oder wenig IT-Know-how vorhanden ist, kann die Erstellung eines präzisen Lastenhefts eine große Herausforderung darstellen. Wir unterstützen unsere Kunden bei der Anforderungsanalyse sowie bei der Definition von Anforderungen. Wir stellen sicher, dass Lasten- als auch Pflichtenhefte im Sinne des Kunden kommuniziert werden.