Zurück zum Wiki

Lastenheft

Das Lastenheft ist eines der zentralen Dokumente jedes professionellen IT- und Softwareprojekts. Es beschreibt die vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers. Vereinfacht gesagt: Das Lastenheft beantwortet die Fragen „Was soll gemacht werden?" und „Wofür?" — aus Sicht des Bestellers, noch bevor klar ist, wie genau die Lösung technisch umgesetzt wird.

Die maßgebliche Definition liefert die Norm DIN 69901-5 (Projektmanagement — Begriffe). Danach ist das Lastenheft die „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrags". Diese Definition ist deshalb so wichtig, weil sie das Lastenheft eindeutig der Auftraggeber-Seite zuordnet — und es damit klar vom Pflichtenheft abgrenzt, das der Auftragnehmer erstellt.

Lastenheft vs. Pflichtenheft: Die fundamentale Unterscheidung

In der Praxis werden Lastenheft und Pflichtenheft regelmäßig verwechselt oder synonym verwendet — ein Fehler, der zu erheblichen Missverständnissen zwischen Auftraggeber und Dienstleister führen kann. Die saubere Trennung nach DIN 69901-5 ist deshalb mehr als akademische Begriffsklauberei: Sie definiert, wer welche Verantwortung trägt.

  • Lastenheft (Auftraggeber): beschreibt das Was und Wofür. Es enthält die Anforderungen, Ziele und Rahmenbedingungen aus fachlicher Sicht — bewusst lösungsneutral, ohne technische Vorgaben.
  • Pflichtenheft (Auftragnehmer): beschreibt das Wie und Womit. Es ist die Antwort des Dienstleisters auf das Lastenheft und legt die konkrete technische Realisierung fest.

Bildlich gesprochen: Der Auftraggeber formuliert im Lastenheft seine Wünsche und Bedingungen („Ich brauche einen Onlineshop, der 10.000 Bestellungen am Tag verarbeitet und an mein ERP angebunden ist"), und der Auftragnehmer antwortet im Pflichtenheft mit dem konkreten Realisierungskonzept („Wir setzen dafür Shopware mit einer Middleware-Anbindung an SAP via REST-API um"). Wer beide Dokumente sauber trennt, schafft die Grundlage für eine belastbare vertragliche Abnahme.

Was gehört in ein Lastenheft? Aufbau und typische Inhalte

Ein gutes Lastenheft ist vollständig, widerspruchsfrei und so präzise wie möglich — und gleichzeitig lösungsneutral formuliert. Es schreibt also keine konkrete Technologie vor, sondern beschreibt die Anforderungen so, dass mehrere Anbieter darauf ein vergleichbares Angebot abgeben können. Bewährt hat sich folgende Grobstruktur:

Typische Gliederung eines Lastenhefts

AbschnittInhalt
1. Ausgangssituation & ZielsetzungWarum gibt es das Projekt? Welches Geschäftsziel wird verfolgt?
2. Ist-ZustandBestehende Systeme, Prozesse, Schnittstellen, Datenbestände
3. Soll-ZustandGewünschtes Ergebnis aus fachlicher Sicht
4. Funktionale AnforderungenWas das System fachlich leisten muss (Muss-/Soll-/Kann-Kriterien)
5. Nicht-funktionale AnforderungenPerformance, Sicherheit, Verfügbarkeit, Skalierbarkeit, Barrierefreiheit
6. RahmenbedingungenBudget, Termine, rechtliche Vorgaben, technische Restriktionen
7. AbnahmekriterienWoran wird der Projekterfolg gemessen?

Besonders wichtig ist die Priorisierung der Anforderungen — häufig mit der bewährten Klassifizierung in Muss-Kriterien (unverzichtbar), Soll-Kriterien (wichtig, aber verhandelbar) und Kann-Kriterien (wünschenswert). Diese Gewichtung hilft dem Auftragnehmer, ein realistisches Angebot zu kalkulieren, und gibt dem Projekt einen klaren Fokus, wenn Budget oder Zeit knapp werden.

Funktionale vs. nicht-funktionale Anforderungen

Eine häufige Schwäche von Lastenheften ist die Vernachlässigung der nicht-funktionalen Anforderungen. Während funktionale Anforderungen beschreiben, was ein System tut (z. B. „Der Kunde kann seine Bestellung stornieren"), legen nicht-funktionale Anforderungen fest, wie gut es das tut: Antwortzeiten unter 200 Millisekunden, eine Verfügbarkeit von 99,9 Prozent, DSGVO-Konformität oder Barrierefreiheit nach BFSG. Gerade diese Kriterien entscheiden später über Zufriedenheit und Betriebskosten — und gehören deshalb zwingend ins Lastenheft.

Realbeispiel: Lastenheft für eine Shopware-Migration

Ein mittelständischer B2B-Großhändler betreibt seit Jahren einen Onlineshop auf Basis von Shopware 5. Der Support läuft aus, die Performance leidet, und neue Funktionen lassen sich kaum noch wirtschaftlich umsetzen. Das Unternehmen entscheidet sich für eine Migration auf Shopware 6 und beauftragt eine Digitalagentur. Bevor das Projekt startet, erstellt der Auftraggeber ein Lastenheft mit folgenden Eckpunkten:

  • Ziel: Migration des bestehenden B2B-Shops auf eine zukunftssichere Plattform mit erweiterten B2B-Funktionen.
  • Muss-Anforderung: Übernahme aller 45.000 Artikel inklusive Staffelpreisen und kundenindividuellen Preislisten.
  • Muss-Anforderung: Anbindung an das vorhandene ERP-System per Schnittstelle, Datenabgleich mindestens stündlich.
  • Soll-Anforderung: Self-Service-Portal für Bestandskunden mit Bestellhistorie und Angebotsfunktion.
  • Nicht-funktional: Ladezeit der Produktseiten unter 1,5 Sekunden, Barrierefreiheit gemäß BFSG bis Juni 2025.
  • Rahmenbedingung: Go-Live spätestens vier Monate vor Auslaufen des Shopware-5-Supports.

Auffällig: Das Lastenheft nennt das Zielprodukt (Shopware 6), schreibt aber nicht vor, wie die ERP-Anbindung technisch realisiert wird oder welche Middleware zum Einsatz kommt. Diese Entscheidungen trifft der Auftragnehmer und dokumentiert sie im Pflichtenheft. So bleibt das Lastenheft vergleichbar — und mehrere Agenturen können ein Angebot abgeben.

Warum ein gutes Lastenheft Projekte rettet

Studien zu gescheiterten IT-Projekten nennen seit Jahrzehnten denselben Hauptgrund: unklare oder sich ständig ändernde Anforderungen. Ein sorgfältig erstelltes Lastenheft ist die wirksamste Versicherung gegen genau dieses Risiko. Es zwingt den Auftraggeber, seine Anforderungen vor Projektbeginn zu durchdenken, statt sie erst im laufenden Projekt zu entdecken — wenn Änderungen ein Vielfaches kosten. Besonders wichtig ist ein sauberes Lastenheft, wenn du individuelle Softwareentwicklung beauftragst – es macht Angebote vergleichbar, bevor die erste Zeile Code entsteht.

Darüber hinaus erfüllt das Lastenheft mehrere konkrete Funktionen:

  • Ausschreibungsgrundlage: Mehrere Anbieter erhalten dieselbe, vergleichbare Anforderungsbasis und können seriöse, vergleichbare Angebote abgeben.
  • Vertragsbestandteil: Das Lastenheft wird häufig vertraglich verankert und bildet die Grundlage für die spätere Abnahme.
  • Kommunikationsanker: Es schafft ein gemeinsames Verständnis zwischen Fachabteilung, IT und Dienstleister.
  • Scope-Schutz: Es macht sichtbar, was vereinbart war und was als Change Request gesondert beauftragt werden muss.

In agilen Projekten ist das klassische, monolithische Lastenheft seltener — hier treten häufig Product Backlogs, Epics und User Stories an seine Stelle. Doch auch im agilen Kontext bleibt der Kerngedanke gültig: Der Auftraggeber muss seine fachlichen Anforderungen und Ziele formulieren, bevor das Team sie umsetzt. Die Form ändert sich, die Substanz bleibt. Weiterführende Informationen zum normativen Hintergrund bietet der Eintrag Lastenheft bei Wikipedia.

Normativer Hintergrund: DIN 69901 und VDI 2519

Der Begriff Lastenheft ist im deutschsprachigen Raum normativ klar verankert. Die schon zitierte DIN 69901-5 ist Teil der DIN-69901-Normenreihe zum Projektmanagement und liefert die heute gebräuchliche Definition. Ergänzend hat die Richtlinie VDI/VDE 2519 Blatt 1 über Jahre den Aufbau und die Inhalte von Lasten- und Pflichtenheften beschrieben und damit eine praktische Schablone für Industrie- und Softwareprojekte geliefert. Beide Quellen ziehen dieselbe Grenze: Das Lastenheft gehört dem Auftraggeber, das Pflichtenheft dem Auftragnehmer.

Historisch stammt das Begriffspaar aus dem deutschen Maschinen- und Anlagenbau und ist von dort in die Softwareentwicklung gewandert. Diese Herkunft erklärt, warum das Lastenheft in deutschen Mittelstandsprojekten bis heute einen festen Platz hat, während international eher von Requirements Specification oder Statement of Work (SoW) gesprochen wird. Wichtig für die Praxis: Der englische Begriff specification deckt je nach Kontext mal das Lastenheft, mal das Pflichtenheft ab — bei internationalen Projekten lohnt sich daher eine explizite Klärung, wer welches Dokument verantwortet.

Vom Lastenheft zum Angebot: der typische Ablauf

In einem klassischen Projekt steht das Lastenheft am Anfang einer klar definierten Kette von Schritten. Diese Reihenfolge zu kennen, hilft, das Dokument richtig einzuordnen:

  1. Bedarfsanalyse: Der Auftraggeber ermittelt intern seinen Bedarf und seine Ziele.
  2. Lastenheft-Erstellung: Die Anforderungen werden lösungsneutral dokumentiert und priorisiert.
  3. Ausschreibung: Das Lastenheft geht an mehrere potenzielle Auftragnehmer.
  4. Angebot & Pflichtenheft: Jeder Anbieter erarbeitet auf Basis des Lastenhefts sein Realisierungskonzept und sein Angebot.
  5. Vergabe: Der Auftraggeber wählt den Anbieter mit dem überzeugendsten Pflichtenheft und Preis-Leistungs-Verhältnis aus.
  6. Umsetzung & Abnahme: Realisierung gegen das Pflichtenheft, Abnahme gegen die Abnahmekriterien des Lastenhefts.

Gerade weil das Lastenheft die Ausschreibungsgrundlage bildet, muss es ohne Anbieter-Wissen lesbar und vergleichbar sein. Ein Lastenheft, das nur eine einzige technische Lösung zulässt, verfehlt diesen Zweck und nimmt dem Auftraggeber die Möglichkeit, Angebote überhaupt zu vergleichen.

Häufige Fehler beim Lastenheft

Aus der Projektpraxis kristallisieren sich immer wieder dieselben Stolperfallen heraus, die ein Lastenheft entwerten:

  • Zu früh technisch werden: Wer schon im Lastenheft eine bestimmte Datenbank oder ein Framework vorschreibt, schränkt die Lösungsvielfalt unnötig ein und verschenkt das Know-how des Dienstleisters.
  • Unpriorisierte Wunschlisten: Ein Lastenheft ohne Muss-/Soll-/Kann-Gewichtung führt zu überteuerten Angeboten, weil jeder Nebenwunsch wie eine Kernforderung kalkuliert wird.
  • Fehlende Abnahmekriterien: Ohne messbare Kriterien lässt sich am Projektende nicht objektiv feststellen, ob die Leistung erbracht wurde.
  • Widersprüche und Lücken: Anforderungen, die sich gegenseitig ausschließen, fallen oft erst im Projekt auf — dann ist die Korrektur teuer.

Lastenheft in der Praxis: Tipps für den Mittelstand

Für mittelständische Unternehmen, die zum ersten Mal ein größeres Software- oder E-Commerce-Projekt vergeben, ist das Lastenheft oft Neuland. Einige praxiserprobte Empfehlungen erleichtern den Einstieg:

  • Fachabteilung einbeziehen: Die besten Anforderungen kommen von den Menschen, die später mit dem System arbeiten — nicht allein aus der IT oder der Geschäftsführung.
  • In Zielen denken, nicht in Lösungen: „Wir wollen die Retourenquote senken" ist als Ziel wertvoller als „Wir brauchen ein Retouren-Plugin".
  • Konkrete Mengengerüste angeben: Artikelzahl, Bestellvolumen, Nutzerzahlen und Datenmengen helfen dem Anbieter, realistisch zu kalkulieren.
  • Rechtliche Anforderungen früh klären: DSGVO, Barrierefreiheit (BFSG) und branchenspezifische Vorgaben gehören ins Lastenheft, nicht erst in die Abnahme.
  • Externe Unterstützung erwägen: Eine erfahrene Digitalagentur kann auch bei der Erstellung des Lastenhefts beraten — gerade wenn intern das Methodenwissen fehlt.

Ein gut gemachtes Lastenheft ist kein bürokratischer Selbstzweck, sondern ein Investment, das sich über die gesamte Projektlaufzeit auszahlt: in vergleichbaren Angeboten, klaren Erwartungen und einer reibungsärmeren Zusammenarbeit mit dem Dienstleister.

FAQ zum Lastenheft

Wer schreibt das Lastenheft?
Das Lastenheft wird vom Auftraggeber erstellt — also vom Unternehmen, das die Leistung bestellt. Es beschreibt dessen Anforderungen aus fachlicher Sicht. Die Antwort darauf, das Pflichtenheft, kommt vom Auftragnehmer.

Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?
Das Lastenheft beschreibt das Was und Wofür aus Auftraggebersicht (lösungsneutral). Das Pflichtenheft beschreibt das Wie und Womit aus Auftragnehmersicht (konkrete Realisierung).

Ist ein Lastenheft rechtlich verpflichtend?
Nein, gesetzlich vorgeschrieben ist es nicht. In der Praxis wird es jedoch häufig zum Vertragsbestandteil gemacht und bildet dann die verbindliche Grundlage für die Abnahme der Leistung.

Wie lang sollte ein Lastenheft sein?
So lang wie nötig, so kurz wie möglich. Entscheidend ist nicht der Umfang, sondern die Vollständigkeit, Widerspruchsfreiheit und Priorisierung der Anforderungen. Kleine Projekte kommen mit wenigen Seiten aus, komplexe Vorhaben benötigen mehr.

Braucht man im agilen Projekt noch ein Lastenheft?
Oft tritt im agilen Umfeld ein priorisiertes Product Backlog mit User Stories an die Stelle des klassischen Lastenhefts. Der Grundgedanke — der Auftraggeber formuliert seine fachlichen Anforderungen — bleibt jedoch bestehen.

Praxis-Leitfaden: Wie du ein Lastenheft Schritt für Schritt schreibst – inklusive Aufbau, Beispielen und kostenloser Vorlage zum Download – zeigt unser Leitfaden: Lastenheft & Pflichtenheft schreiben.

Weiterführende Artikel