Lastenheft erstellen: Definition, Aufbau, Beispiele & kostenlose Word-Vorlage

Lastenheft (kurz erklärt): Das Lastenheft ist ein vom Auftraggeber erstelltes Anforderungsdokument, das alle fachlichen und technischen Anforderungen an ein Projekt beschreibt – also was geliefert werden soll und wofür, nicht wie es technisch umgesetzt wird. Es ist die Grundlage für Ausschreibung, Angebot und das spätere Pflichtenheft des Auftragnehmers (vgl. DIN 69901).

Wer ein Software-, ERP- oder IT-Projekt vergibt, ohne die eigenen Anforderungen sauber zu dokumentieren, bezahlt das später doppelt: in Form von Change-Requests, verlorenen Wochen und Streit am Projektende. Ein gutes Lastenheft verhindert genau diese Missverständnisse zwischen Auftraggeber und Auftragnehmer. Es ist die Planungsgrundlage, die aus einer Idee ein vergleichbares Angebot macht – und im Streitfall die Brücke zum Werkvertrag.

In diesem Ratgeber zeigen wir dir, wie du ein Lastenheft praxistauglich aufbaust, was hineingehört, wie es sich vom Pflichtenheft abgrenzt und wie du es in der agilen Welt einsetzt. Zusätzlich bekommst du eine kostenlose Word-Vorlage mit allen zehn Bausteinen, MUSS-/SOLL-/KANN-Markierung und Feldern für Akzeptanzkriterien.

Was ist ein Lastenheft?

Das Lastenheft ist ein Anforderungsdokument, in dem der Auftraggeber alle Anforderungen an ein Produkt, eine Software oder ein Projekt zusammenfasst. Es beschreibt die Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers – aus Sicht des Auftraggebers, lösungsneutral und nachvollziehbar.

Lastenheft – die offizielle Definition (DIN 69901)

Nach DIN 69901-5 ist das Lastenheft „die vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages“. Synonyme Begriffe sind Anforderungsdokument, Anforderungskatalog, Anforderungsspezifikation oder im Vergabekontext Leistungsbeschreibung. Auch die VDI-Richtlinie 2519 beschreibt das Vorgehen zur Erstellung von Lasten- und Pflichtenheft im technischen Kontext.

Was ist der Zweck eines Lastenhefts?

Ein Lastenheft erfüllt vier zentrale Aufgaben:

• Klarheit schaffen: Es zwingt das Unternehmen, eigene Erwartungen und Projektziele präzise zu formulieren.
• Vergleichbarkeit herstellen: Mehrere Softwareanbieter erhalten dieselbe Grundlage und können vergleichbare Angebote abgeben.
• Risiken senken: Unklare Vorstellungen werden früh sichtbar – nicht erst im Abnahmetest.
• Rechtliche Basis bilden: Das Lastenheft wird Teil des Vertrags und ist gemeinsam mit dem Pflichtenheft die Grundlage für die Abnahme.

Wer schreibt das Lastenheft? — Verantwortung des Auftraggebers

Das Lastenheft erstellt immer der Auftraggeber – also das Unternehmen, das die Leistung einkauft oder intern in Auftrag gibt. In der Praxis übernimmt das die Projektleitung gemeinsam mit dem Fachbereich, der IT und ggf. einem externen Berater. Wichtig: Beteilige die relevanten Stakeholder früh – Vertrieb, Buchhaltung, Datenschutz, Betrieb und Endanwender. Was später benutzt wird, sollte vorher mitgesprochen haben.

Lastenheft vs. Pflichtenheft — der wichtigste Unterschied

Die häufigste Verwechslung im Anforderungsmanagement ist die zwischen Lastenheft und Pflichtenheft. Kurz gesagt: Das Lastenheft beschreibt das WAS und WOFÜR aus Sicht des Auftraggebers, das Pflichtenheft das WIE und WOMIT aus Sicht des Auftragnehmers.

Tabelle: Lastenheft vs. Pflichtenheft im Direktvergleich

Wann wird aus einem Lastenheft ein Pflichtenheft?

Sobald der Auftragnehmer das Lastenheft erhalten hat, übersetzt er die fachlichen Anforderungen in ein technisches Umsetzungskonzept – das Pflichtenheft (in einigen Branchen auch Systemspezifikation genannt, z. B. in der Medizintechnik nach IEC 62304). Der Auftraggeber prüft und freigibt, danach ist das Pflichtenheft die verbindliche Umsetzungsgrundlage.

Merksatz und typische Missverständnisse

Merksatz: Das Lastenheft ist die Last des Auftraggebers, das Pflichtenheft die Pflicht des Auftragnehmers. Ein häufiges Missverständnis ist, dass eines der beiden Dokumente „ausreicht“. In der Praxis ergänzen sie sich – das Lastenheft bringt das Was, das Pflichtenheft das Wie. Wer beides verwechselt, riskiert, dass technische Lösungen schon vorgegeben werden, bevor sie überhaupt geprüft wurden.

Brauche ich beides — auch für kleine Projekte?

Bei kleineren Software- oder Web-Projekten reicht oft ein schlankes Lastenheft mit eingebetteten Akzeptanzkriterien, ohne ein eigenes Pflichtenheft. Wichtig ist nicht die Form, sondern dass beide Seiten dasselbe Verständnis von Scope, Abnahme und Rahmenbedingungen haben.

Was gehört in ein Lastenheft? — Aufbau & 10-Punkte-Struktur

Ein praxistaugliches Lastenheft folgt einer klaren Gliederung. Diese zehn Bausteine haben sich für IT-, Software- und Digitalisierungsprojekte bewährt – sie sind genau so in der kostenlosen Word-Vorlage angelegt.

Lastenheft erstellen — in 7 Schritten zum fertigen Dokument

Die Lastenhefterstellung ist kein einmaliger Schreibakt, sondern ein strukturierter Prozess. Dieser 7-Schritte-Plan funktioniert für klassische Software-Beschaffung genauso wie für agile Vorhaben.

Lastenheft-Vorlage kostenlos: Word-Download für IT- & Software-Projekte

Damit du nicht bei Null anfangen musst, stellen wir dir eine vollständige Word-Vorlage für dein Lastenheft kostenlos zur Verfügung. Die Vorlage ist konsequent auf IT-, Software- und Digitalisierungsprojekte zugeschnitten und folgt genau der 10-Punkte-Struktur aus diesem Ratgeber.

Was die Vorlage enthält

• Deckblatt mit Projekt-Kopfdaten, Versionshistorie und Freigabefeldern
• Automatisches Inhaltsverzeichnis
• Alle zehn Bausteine als fertige Kapitel mit Erklär-Hinweisen
• Anforderungstabelle mit Spalten ID, Beschreibung, Quelle, MUSS/SOLL/KANN, Akzeptanzkriterium
• NFR-Block mit Beispielen für Performance, Security, DSGVO, Verfügbarkeit
• Glossar-Block für Fachbegriffe und Abkürzungen
• Anhang für Skizzen, Datenmodelle, Prozessdiagramme

So nutzt du die Word-Vorlage in 5 Minuten

1. Word-Vorlage herunterladen und unter neuem Projektnamen speichern.
2. Deckblatt-Felder ausfüllen (Projekttitel, Auftraggeber, Version, Datum, Freigeber).
3. Inhaltsverzeichnis nach dem Bearbeiten aktualisieren (Word: F9).
4. Anforderungen in die vorbereitete Tabelle eintragen und mit MUSS/SOLL/KANN priorisieren.
5. Review-Termin mit Stakeholdern setzen, Änderungen in der Versionshistorie dokumentieren.

Word-Vorlage vs. Excel-Variante — wann welches Format?

Die Word-Vorlage ist die richtige Wahl, wenn du Anforderungen, Kontext und Begründungen zusammen dokumentieren willst – also für das klassische Lastenheft als Vertragsanlage. Eine Excel-Variante ist dann sinnvoll, wenn du mehrere Hundert Einzelanforderungen filtern, sortieren oder per Scoring bewerten möchtest. In der Praxis nutzen viele Projekte beides: Word für das Dokument, Excel als Anforderungsliste im Anhang.

Word- vs. PDF-Lastenheft — welche Datei verschickst du an den Anbieter?

Intern und für Reviews: Word, damit Stakeholder Änderungen vorschlagen können. Für die Anbieter-Ausschreibung: PDF mit Versionsnummer, damit alle Bieter exakt dieselbe Grundlage haben. Word und PDF gleichzeitig zu verteilen, führt fast immer zu Versionsverwirrung.

Lastenheft Beispiele aus der Praxis

Theorie hilft – Beispiele helfen mehr. Diese Auszüge zeigen, wie konkrete Anforderungen, NFRs und Akzeptanzkriterien aussehen sollten.

Beispiel-Use-Case: UC-03 Ticket-Erstellung (Software-Projekt)

Auslöser: Ein Endkunde meldet per E-Mail oder Webformular ein Problem. Akteure: Endkunde, Service-Agent. Ablauf: (1) Eingang automatisch erfassen, (2) Kategorie und Priorität setzen, (3) Ticket dem zuständigen Team zuweisen, (4) Empfangsbestätigung an Endkunden senden. Ergebnis: Ticket im System mit ID, Status „Neu“, Eingangs-Zeitstempel und automatischer Bestätigungsmail.

Beispiel funktionale Anforderung (F-XX-Format)

Beispiel nicht-funktionale Anforderung (NFR-XX, messbar)

Beispiel Akzeptanzkriterium im Given/When/Then-Format

Given  ein Service-Agent ist eingeloggt und befindet sich auf dem Ticket-Board
When   er ein Ticket per Drag-&-Drop von „Neu" nach „In Bearbeitung" zieht
Then   ändert sich der Status auf „In Bearbeitung",
       der Statuswechsel wird im Verlauf protokolliert,
       und der Endkunde erhält eine Benachrichtigung.

Branchen-Spotlight: Lastenheft im Maschinenbau (Auszug)

Im Maschinenbau dreht sich das Lastenheft stark um technische Funktionsanforderungen, Toleranzen, Werkstoffe und Schnittstellen zur bestehenden Fertigung. Hinzu kommen normative Anforderungen (z. B. Maschinenrichtlinie 2006/42/EG) und Sicherheitsfunktionen. Ein Beispiel-Lastenheft Maschinenbau enthält neben den fachlichen Anforderungen oft 3D-Modelle, Schaltpläne und Dokumentationspflichten.

Branchen-Spotlight: Lastenheft für ERP-Einführung (Auszug)

Bei einer ERP-Einführung beschreibt das Lastenheft typischerweise die End-to-End-Prozesse (Order-to-Cash, Purchase-to-Pay, Record-to-Report), Mandantenstruktur, Zahl der User, Schnittstellen zu DATEV/Lohn/CRM/Shop, Reporting-Anforderungen und Datenmigration. Genau dieser Bereich generiert die größte Streuung in Anbieter-Angeboten – ein detailliertes ERP-Lastenheft macht Angebote vergleichbar.

Branchen-Spotlight: Lastenheft für eine Website / Webanwendung (Auszug)

Für eine Webanwendung gehören in das Lastenheft: Zielgruppen, Sitemap, Designanforderungen (CI, Barrierefreiheit nach WCAG), Content-Management (Redakteur-Workflow), SEO-Grundlagen, Performance- und Core-Web-Vitals-Ziele, DSGVO-konformes Tracking, Hosting und Backup. Auch hier gilt: konkret und messbar statt „modern und schnell“.

Lösungsneutral formulieren — was/wofür statt wie/womit

Der häufigste handwerkliche Fehler im Lastenheft: Der Auftraggeber gibt schon Lösungen vor, statt Anforderungen zu beschreiben. Das schränkt Anbieter ein und kostet Innovationspotenzial.

Typische Anti-Patterns

• „Wir brauchen ein modernes, schnelles System.“ — schwammig, nicht prüfbar.
• „Es muss in React umgesetzt werden.“ — Lösungsvorgabe statt Anforderung.
• „Details liefern wir später nach.“ — verschiebt Verantwortung.
• „Wir hätten gern alles, was Tool XY kann.“ — keine Priorisierung, kein Scope.

Faustregeln für die richtige Detailtiefe

Beschreibe Außenverhalten statt Innenleben, Geschäftsregeln statt Bildschirmlayout, Ergebnisse statt Algorithmen. Wenn du an der Stelle, an der dir nichts mehr einfällt, drei „Warum“-Fragen stellen kannst, bist du tief genug.

Wie detailliert muss ein Lastenheft sein?

So detailliert, dass zwei verschiedene Anbieter auf gleicher Basis vergleichbare Angebote schreiben können. Für ein klassisches Mittelstandsprojekt sind 15–40 Seiten ein realistischer Korridor. Mehr ist nicht automatisch besser – Klarheit schlägt Umfang.

Ist ein Lastenheft heute noch zeitgemäß? — Lastenheft & Agile / User Stories

Die mit Abstand häufigste Frage von Projektleitern lautet inzwischen: Brauche ich überhaupt noch ein Lastenheft, wenn wir agil arbeiten? Die kurze Antwort: Ja, aber in schlankerer Form – und es heißt dann oft nicht mehr „Lastenheft“, sondern Vision, Produktziel, Backlog oder Anforderungskatalog.

Lastenheft vs. User Story — wo liegt der Unterschied?

Ein klassisches Lastenheft beschreibt das Gesamt-Soll vor dem Projektstart. Eine User Story beschreibt eine einzelne, kleine Anforderung in Nutzersicht („Als Service-Agent möchte ich … damit …“) und entsteht iterativ. User Stories ersetzen das Lastenheft nicht – sie operationalisieren es im Sprint.

Agiles Lastenheft: schlanker Anforderungskatalog statt 80-Seiten-Dokument

Ein agiles Lastenheft ist kein Widerspruch in sich. Es liefert die Vision, die Top-Prozesse, die nicht-funktionalen Anforderungen und die Rahmenbedingungen – also alles, was sich während der Umsetzung kaum ändert. Funktionale Details landen dagegen im Backlog und werden pro Sprint verfeinert.

Wann ein klassisches Lastenheft trotz Scrum sinnvoll bleibt

Immer dann, wenn (a) extern beauftragt wird und Verträge nötig sind, (b) Compliance- oder Norm-Anforderungen dokumentiert werden müssen, (c) mehrere Anbieter verglichen werden, (d) das Projekt budgetär gedeckelt ist. In diesen Fällen ist das Lastenheft die Vertragsgrundlage – Scrum regelt die Umsetzung dahinter.

Hybrid-Ansatz: Lastenheft + Backlog koexistieren lassen

Der pragmatische Weg: Das Lastenheft beschreibt Ziele, Scope, NFRs, Schnittstellen, Constraints verbindlich. Das Backlog verfeinert funktionale Anforderungen iterativ. Beides ist über ID-Verweise (F-XX ↔ Backlog-Item) verbunden. So bleibt der Vertrag stabil – und die Umsetzung flexibel.

Rechtliche Wirkung — ist das Lastenheft bindend?

Eine der hartnäckigsten Fragen: Ist ein Lastenheft rechtlich bindend? Die Antwort hängt davon ab, wie es in den Vertrag eingebunden wird.

Vertragliche Einbindung des Lastenhefts

Wird das Lastenheft im Werk- oder Dienstvertrag als Anlage aufgeführt, wird es zum Vertragsbestandteil und damit verbindlich. Ohne diese Referenz hat es höchstens dokumentarischen Charakter. Empfehlung: Lastenheft mit Versionsnummer als Vertragsanlage benennen und beide Parteien zur Schriftform bei Änderungen verpflichten.

Lastenheft, Pflichtenheft & Werkvertrag (BGB)

Im Werkvertrag nach § 631 BGB schuldet der Auftragnehmer einen Erfolg – nämlich die im Lastenheft und Pflichtenheft beschriebene Leistung. Das Pflichtenheft konkretisiert dabei den vom Lastenheft umrissenen Erfolg. Mängel werden am gemeinsam vereinbarten Soll gemessen. Wer rechtssicher dokumentieren will, lässt beide Dokumente von beiden Parteien unterschreiben.

Normbezug: DIN 69901, DIN 69905, VDI 2519

• DIN 69901-5: Begriffe im Projektmanagement, inkl. Lastenheft-Definition.
• DIN 69905 (zurückgezogen, in der Praxis weiterhin oft zitiert): historische Definition Lastenheft/Pflichtenheft.
• VDI-Richtlinie 2519: empfohlenes Vorgehen für Lasten- und Pflichtenheft-Erstellung im technischen Umfeld.

Eine zwingende gesetzliche Norm gibt es nicht – die genannten Richtlinien sind aber faktischer Branchenstandard.

Lastenheft-Checkliste „Ready for Anbieterbriefing“

Bevor du dein Lastenheft an Anbieter herausgibst, prüfe diese zehn Punkte:

• ☐ Projektüberblick und Ausgangssituation in 1–2 Seiten verständlich?
• ☐ Top-3-Projektziele mit messbaren KPIs hinterlegt?
• ☐ Scope und MVP klar abgegrenzt, „Out-of-Scope“ explizit benannt?
• ☐ Alle Stakeholder mit Rolle und Ansprechpartner gelistet?
• ☐ Funktionale Anforderungen mit ID und MUSS/SOLL/KANN priorisiert?
• ☐ NFRs mit konkreten Zahlen (Performance, Verfügbarkeit, Security)?
• ☐ Schnittstellen, Datenmigration und Datenformate beschrieben?
• ☐ Rahmenbedingungen (Hosting, Browser, Compliance) gesetzt?
• ☐ Abnahmekriterien und Lieferumfang verbindlich definiert?
• ☐ Glossar, Versionsnummer und Freigabe-Feld eingetragen?

Häufigste Fehler vor dem Versand: widersprüchliche Prioritäten, fehlende NFRs, vage Schnittstellenbeschreibungen, kein Ansprechpartner pro Anforderung, „wird später ergänzt“-Platzhalter.

Vom Lastenheft zur passenden Anbieter-Shortlist

Ein fertiges Lastenheft ist nicht das Ziel – es ist der Startpunkt für die Anbieterauswahl. Wer hier strukturiert vorgeht, spart Wochen.

Anbieter-Auswahlprozess in 5 Schritten

1. Longlist erstellen (10–20 potenzielle Anbieter, branchen- und größenpassend).
2. RFI / Kurzfragebogen verschicken, Erstantworten in 7–10 Tagen einsammeln.
3. Shortlist auf 3–5 Anbieter eingrenzen, Lastenheft inkl. NDA verschicken.
4. Angebote vergleichen anhand eines Scoring-Modells (siehe unten).
5. Pitch / Workshop mit den Top-2, Entscheidung im Auswahlgremium.

Scoring-Kriterien

• Fachliche Passung (Coverage MUSS-/SOLL-Anforderungen)
• NFR-Fähigkeit (Performance, Security, Verfügbarkeit)
• Integrationskompetenz (Schnittstellen, bestehende Systeme)
• Branchen- und Methoden-Erfahrung
• TCO über 3 Jahre (Lizenz, Implementierung, Betrieb, Support)
• Soft Factors (Team, Kommunikation, Referenzen)

IT-Concierge-Service: Lastenheft + Vorqualifizierung kombinieren

Wenn dir die Zeit für den vollen Auswahlprozess fehlt, übernimmt unser IT-Concierge-Service die Vorqualifizierung passender Anbieter auf Basis deines Lastenhefts. Du erhältst eine geprüfte Shortlist statt einer Google-Trefferliste – und sparst dir den RFI-Versand. Wer den passenden Partner schneller braucht, kann zusätzlich den IT-Lotse (KI-Matching) nutzen.