Bevor ein Softwareprojekt beauftragt wird, steht eine Frage im Raum, die über Budget, Zeitplan und Nerven entscheidet: Was genau soll am Ende dabei herauskommen? Das Lastenheft beantwortet sie aus Sicht des Auftraggebers, das Pflichtenheft aus Sicht des Auftragnehmers. Wer beide Dokumente sauber trennt, vergleicht später Angebote, die wirklich vergleichbar sind, und streitet seltener über das, was „eigentlich klar war".
Dieser Leitfaden klärt die Begriffe, zeigt den Aufbau beider Hefte und führt Schritt für Schritt durch das Schreiben eines Lastenhefts. Am Ende findest du eine Vorlage zum Download.
Eine Abgrenzung vorweg: Es geht hier um Software- und Digitalprojekte (Individualsoftware, Onlineshops, Apps, Schnittstellen). Im Maschinen- und Anlagenbau gelten dieselben Begriffe, aber teils andere Norm-Details. Die hier genutzte Definition folgt DIN 69901-5, der Norm für Projektmanagement-Begriffe.
Lastenheft vs. Pflichtenheft: der Unterschied in einem Satz
Die DIN 69901-5 definiert das Lastenheft als die »vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrags«. Vereinfacht: das Was und das Wofür. Der Auftraggeber schreibt es, bevor er ausschreibt.
Das Pflichtenheft beschreibt dieselbe Norm als die »vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts«. Vereinfacht: das Wie und das Womit. Der Auftragnehmer schreibt es als Antwort und legt damit fest, wie er die Forderungen technisch lösen will.
Die Reihenfolge ist also fest: erst Lastenheft, dann Pflichtenheft. Das eine ist die Frage, das andere die verbindliche Antwort.
| Kriterium | Lastenheft | Pflichtenheft |
|---|---|---|
| Beantwortet | Was? Wofür? | Wie? Womit? |
| Erstellt von | Auftraggeber (du) | Auftragnehmer (Agentur/Dienstleister) |
| Zeitpunkt | Vor der Ausschreibung | Nach Auftragsklärung, vor Umsetzung |
| Detailgrad | Forderungen, Ziele, Rahmen | Konkrete technische Lösung |
| Zweck | Angebote vergleichbar machen | Umsetzung verbindlich festlegen |
| Rechtliche Rolle | Grundlage der Ausschreibung | Wird oft Vertragsbestandteil |
Eine verbreitete Eselsbrücke: Das Lastenheft ist die Last, die der Auftraggeber dem Auftragnehmer aufbürdet. Das Pflichtenheft ist die Pflicht, die der Auftragnehmer daraus für sich ableitet und annimmt.
Was gehört ins Lastenheft?
Ein Lastenheft muss nicht dick sein, aber vollständig. Es beschreibt Forderungen ergebnisoffen, also ohne die Lösung schon vorwegzunehmen. „Das System muss Bestellungen automatisch an die Buchhaltung übergeben" gehört ins Lastenheft. „Das System nutzt eine REST-Schnittstelle zu DATEV" ist bereits eine Lösungsvorgabe und damit eine Frage fürs Pflichtenheft. Diese Grenze ist der häufigste Stolperstein überhaupt, und sie zieht sich durch den ganzen Rest dieses Texts.
Diese Bestandteile sollte ein belastbares Lastenheft enthalten:
- Ausgangssituation und Ziel. Warum gibt es das Projekt? Welches Problem löst die Software, welches Geschäftsziel steht dahinter? Ein, zwei Absätze, kein Roman.
- Ist-Zustand. Welche Systeme, Prozesse und Daten existieren heute? Was davon bleibt, was wird abgelöst?
- Soll-Zustand und funktionale Anforderungen. Was muss die Lösung können? Hier liegt das Herzstück. Jede Anforderung bekommt eine eindeutige Nummer, eine klare Beschreibung und eine Priorität (etwa Muss, Soll, Kann).
- Nicht-funktionale Anforderungen. Performance, Verfügbarkeit, Sicherheit, Datenschutz, Skalierbarkeit, Barrierefreiheit. Konkret heißt das zum Beispiel: „Das System trägt 200 gleichzeitige Nutzer, ohne dass eine Antwort länger als zwei Sekunden braucht." Genau diese Punkte stehen selten auf der ersten Wunschliste und werden am Ende teuer nachgerüstet.
- Schnittstellen. Mit welchen Systemen muss die Lösung sprechen? ERP, Warenwirtschaft, CRM, Payment, Versand. Beispiel: „Anbindung an das bestehende Warenwirtschaftssystem per nächtlichem Batch-Export." Nennen, nicht ausspezifizieren, denn das Wie ist Sache des Auftragnehmers.
- Rahmenbedingungen. Budget-Korridor, Zeitrahmen, rechtliche Vorgaben (DSGVO, branchenspezifische Auflagen), gewünschte oder ausgeschlossene Technologien.
- Abnahmekriterien. Woran wird gemessen, ob das Ergebnis stimmt? Etwa: „Ein Testkunde durchläuft Bestellung, Zahlung und Rechnungsversand fehlerfrei im Echtsystem." Wer „fertig" nicht definiert, verhandelt es später unter Zeitdruck und meist zu seinen Ungunsten.
Der wichtigste Teil sind die funktionalen Anforderungen, und genau dort wird am häufigsten geschludert. Eine gute Anforderung ist prüfbar. „Die Suche soll schnell sein" ist nicht prüfbar. „Suchergebnisse erscheinen bei bis zu 50.000 Artikeln in unter 500 Millisekunden" ist es. Den Unterschied zwischen diesen beiden Sätzen zu verstehen, ist der halbe Weg zu einem brauchbaren Lastenheft.
Was gehört ins Pflichtenheft?
Das Pflichtenheft greift jede Forderung des Lastenhefts auf und beantwortet sie konkret. Der Auftragnehmer zeigt darin, dass er das Lastenheft verstanden hat, und legt die technische Realisierung verbindlich fest. Das Prinzip ist simpel: Zu jeder Anforderung im Lastenheft gehört genau eine Antwort im Pflichtenheft.
Typische Bestandteile:
- Lösungskonzept je Anforderung: Wie wird Anforderung Nr. 12 technisch umgesetzt?
- Systemarchitektur: eingesetzte Technologien, Komponenten, Datenmodell, Infrastruktur.
- Schnittstellenspezifikation: konkrete Protokolle, Datenformate, Endpunkte.
- Mengengerüst und Lastannahmen: mit welchen Daten- und Nutzermengen gerechnet wird.
- Test- und Abnahmekonzept: wie nachgewiesen wird, dass jede Anforderung erfüllt ist.
- Projektplan: Phasen, Meilensteine, Liefertermine, Verantwortlichkeiten.
Bleibt eine Lastenheft-Forderung im Pflichtenheft unbeantwortet, ist das ein Warnsignal, kein Detail. Es bedeutet entweder, der Anbieter hat die Anforderung übersehen, oder er hat sie bewusst nicht eingeplant. Beides willst du vor der Beauftragung wissen, nicht danach.
Wichtig für die Vertragsgestaltung: Das Pflichtenheft wird in vielen Projekten Vertragsbestandteil. Was darin steht, ist geschuldete Leistung. Was nicht darin steht, ist es im Zweifel nicht. Deshalb lohnt es sich, das Pflichtenheft des Dienstleisters genauso ernst zu lesen, wie er dein Lastenheft liest.
Lastenheft schreiben: Schritt für Schritt
Das Lastenheft schreibst du als Auftraggeber selbst, denn nur du kennst deine Prozesse. Ein bewährter Ablauf:
Schritt 1 — Ziele und Rahmen festhalten. Beginne mit dem Warum, nicht mit Funktionen. Ein Projekt ohne klares Geschäftsziel produziert ein Lastenheft, das sich später beliebig erweitern lässt. Genau das treibt Aufwand und Kosten.
Schritt 2 — Stakeholder einsammeln. Sprich mit den Menschen, die täglich mit der Lösung arbeiten werden. Die Fachabteilung kennt Anforderungen, die der Geschäftsführung gar nicht bewusst sind. Diese Runde erspart dir später die teuersten Änderungen.
Schritt 3 — Anforderungen sammeln und strukturieren. Erst breit sammeln, dann ordnen. Gruppiere nach Themen, vergib eindeutige Nummern und formuliere jede Anforderung als prüfbaren Satz.
Schritt 4 — Priorisieren. Nicht alles ist gleich wichtig. Eine simple Muss/Soll/Kann-Einteilung (oder MoSCoW: Must, Should, Could, Won't) macht aus einer Wunschliste eine entscheidbare Grundlage. Der Test: Wenn alles „Muss" ist, ist nichts mehr „Muss" — dann entscheidet im Engpass still das Budget, statt dass du es tust.
Schritt 5 — Nicht-funktionale Anforderungen ergänzen. Gehe die Liste bewusst durch: Datenschutz, Sicherheit, Performance, Verfügbarkeit, Barrierefreiheit, Wartbarkeit. Diese Punkte stehen selten auf der ersten Wunschliste und entscheiden trotzdem über die Qualität.
Schritt 6 — Gegenlesen lassen. Gib das Lastenheft einer Person, die nicht beteiligt war. Versteht sie, was gebaut werden soll, verstehen es auch die Anbieter. Versteht sie es nicht, kommen unvergleichbare Angebote zurück.
Eine grobe Orientierung zum Umfang: Für ein mittelgroßes Individual-Softwareprojekt umfasst ein brauchbares Lastenheft erfahrungsgemäß etwa 10 bis 30 Seiten. Das ist kein Normwert, sondern eine Faustregel. Deutlich kürzer heißt meist zu vage, deutlich länger heißt oft, dass schon Lösungen mitspezifiziert wurden, die ins Pflichtenheft gehören.
Die Fehler, die in der Praxis am meisten kosten
Beim Schreiben von Lastenheften wiederholen sich dieselben Stolperstellen. Sie sind alle vermeidbar, wenn man sie kennt:
Der teuerste Fehler ist, die Lösung statt der Anforderung zu beschreiben. Wer im Lastenheft schon die Technologie vorgibt, verschenkt das Know-how der Anbieter und schließt bessere Lösungen aus, bevor sie überhaupt vorgeschlagen werden. Beschreibe das Ziel, nicht den Weg.
Fast genauso häufig sind unprüfbare Anforderungen. „Benutzerfreundlich", „modern", „performant" sind Wünsche, keine Anforderungen. Was nicht messbar ist, ist nicht abnehmbar, und am Ende streitet ihr darüber, ob das Ergebnis „modern genug" ist, ohne je eine gemeinsame Messlatte gehabt zu haben.
Ein dritter Klassiker: nicht-funktionale Anforderungen vergessen. Sicherheit und Datenschutz erst kurz vor dem Go-live zu entdecken, bedeutet im schlimmsten Fall, dass Teile der Architektur neu gebaut werden müssen. Das ist der teuerste Zeitpunkt für eine Erkenntnis, die ins Lastenheft gehört hätte.
Wer nicht priorisiert, verliert im Konflikt die Entscheidungsgrundlage. Ohne Muss/Soll/Kann wird im Budget-Engpass nach Bauchgefühl gestrichen, und gestrichen wird dann oft das Falsche.
Und schließlich: Abnahmekriterien offenlassen. Wenn „fertig" nicht definiert ist, verschiebt sich der Projektabschluss so lange, bis eine Seite nachgibt. Das kostet selten nur Geld, sondern auch das Vertrauen zwischen Auftraggeber und Dienstleister.
Brauche ich das im agilen Projekt überhaupt noch?
Eine berechtigte Frage, denn klassische Lasten- und Pflichtenhefte stammen aus dem Wasserfall-Denken: alles vorab spezifizieren, dann bauen. Agile Vorgehen (Scrum, Kanban) arbeiten stattdessen mit Product Backlog, Epics und User Stories, die sich über die Laufzeit verfeinern.
Die ehrliche Antwort: Es kommt auf die Vertragsform an, konkret auf zwei Fälle.
Bei einem Werkvertrag mit fixem Funktionsumfang brauchst du ein belastbares Lastenheft. Der Anbieter schuldet ein definiertes, mangelfreies Ergebnis, also muss er kalkulieren können, und du musst Angebote vergleichen können. Ohne klare Anforderungsbasis ist beides nicht möglich.
Bei einem agilen Vorgehen auf Basis eines Dienstvertrags (dediziertes Team, Abrechnung nach Aufwand) verschiebt sich der Detailgrad. Statt eines vollständigen Pflichtenhefts genügt oft eine Produktvision plus grob priorisierter Backlog, der sprintweise konkretisiert wird. Aber selbst dann lohnt ein schlankes Lastenheft: Es klärt Geschäftsziel, Rahmen und die nicht-funktionalen Anforderungen, die auch agil nicht verhandelbar sind. Datenschutz wird nicht „im nächsten Sprint" erfunden.
Eine Präzisierung, die in der Praxis oft durcheinandergeht: Das Vergütungsmodell (Festpreis oder Abrechnung nach Aufwand) bestimmt die Vertragsart nicht zwingend. Auch ein Werkvertrag kann nach Aufwand vergütet werden, auch ein Festpreis kann auf einem Dienstvertrag liegen. Entscheidend ist, ob ein Erfolg oder eine Tätigkeit geschuldet wird, nicht der Preis.
Kurz: Das Dokument heißt im agilen Kontext anders und ist schlanker, aber die Denkarbeit dahinter, also Ziel, Anforderungen und Prioritäten zu klären, fällt nicht weg. Wer sie überspringt, verlagert sie nur in spätere Projektphasen, in denen Korrekturen ungleich aufwändiger sind. Wer früh Klarheit über Ziele und Prozesse schaffen will, profitiert von einer strukturierten Anforderungs- und Prozessanalyse zu Projektbeginn.
Vorlage: Lastenheft & Pflichtenheft
Damit du nicht bei null anfängst, stellen wir eine Vorlage bereit, die die oben beschriebene Struktur als ausfüllbares Gerüst enthält: Zielbeschreibung, Ist-/Soll-Zustand, eine vorbereitete Anforderungstabelle mit Nummerierung und Priorisierung, ein Block für nicht-funktionale Anforderungen sowie Abnahmekriterien. → Vorlage herunterladen
So nutzt du sie am besten:
- Lösche, was für dein Projekt nicht passt. Eine Vorlage ist ein Startpunkt, kein Pflichtformular.
- Fülle zuerst Ziele und Rahmen aus, dann die Anforderungen. Die Reihenfolge hält den Fokus.
- Halte jede Anforderung prüfbar. Wenn du sie nicht testen könntest, formuliere sie um.
Wenn du dein Lastenheft anschließend gegen eine erfahrene Sicht prüfen lassen willst, bevor du ausschreibst, hilft ein Blick von außen oft mehr als die zehnte interne Runde. Genau dafür ist eine Erstberatung zur Software-Architektur gedacht, bei der wir Anforderungen und Individual-Software-Lösungswege gemeinsam durchgehen.
Fazit
Lastenheft und Pflichtenheft sind kein Bürokratie-Ritual, sondern das Werkzeug, mit dem du ein Softwareprojekt steuerbar machst. Das Lastenheft klärt, was du brauchst, und macht Angebote vergleichbar. Das Pflichtenheft hält fest, wie der Anbieter es löst, und wird zur Messlatte der Abnahme. Sauber getrennt bedeutet das: vergleichbare Angebote und deutlich weniger Streit darüber, was „eigentlich vereinbart war". Die Mühe vorab ist immer kleiner als die Kosten eines Projekts, das auf einem Missverständnis gebaut wurde.
Lade dir die Vorlage herunter, fülle Ziele und die wichtigsten Anforderungen aus, und du hast in wenigen Stunden eine Grundlage, mit der du seriöse Angebote einholen kannst.
Häufige Fragen
Wer schreibt das Lastenheft, wer das Pflichtenheft? Das Lastenheft schreibt der Auftraggeber, weil nur er seine Ziele und Prozesse kennt. Das Pflichtenheft schreibt der Auftragnehmer als verbindliche Antwort darauf.
Was ist der Unterschied zwischen Lastenheft und Pflichtenheft? Das Lastenheft beschreibt das Was und Wofür (die Forderungen), das Pflichtenheft das Wie und Womit (die konkrete technische Umsetzung). Erst Lastenheft, dann Pflichtenheft.
Brauche ich beide Dokumente? Bei einem Werkvertrag mit definiertem Funktionsumfang ja. Bei agilem Vorgehen ersetzt ein priorisierter Backlog oft das Pflichtenheft, ein schlankes Lastenheft (Ziele, Rahmen, nicht-funktionale Anforderungen) bleibt trotzdem sinnvoll.
Wie lang sollte ein Lastenheft sein? Es gibt keinen Normwert. Als grobe Orientierung sind für ein mittelgroßes Individual-Softwareprojekt etwa 10 bis 30 Seiten realistisch. Entscheidend ist Vollständigkeit und Prüfbarkeit, nicht der Umfang.