Lastenheft & Pflichtenheft erstellen: Anleitung für Ihr Softwareprojekt

Wenn Sie ein Softwareprojekt an eine Agentur oder einen Dienstleister vergeben, entscheidet ein Dokument über einen großen Teil des späteren Erfolgs: die schriftliche Beschreibung dessen, was gebaut werden soll. In der klassischen Projektwelt heißen die beiden zentralen Dokumente Lastenheft und Pflichtenheft. Sie werden häufig verwechselt oder synonym verwendet – dabei erfüllen sie unterschiedliche Aufgaben und werden von unterschiedlichen Parteien erstellt. Dieser Leitfaden erklärt den Unterschied, zeigt eine bewährte Gliederung, ordnet die agile Alternative ein und erläutert, warum ein sauberes Lastenheft Ihre Angebote vergleichbar macht und den Vertrag absichert.

Lastenheft und Pflichtenheft: Der entscheidende Unterschied

Die Faustregel ist einfach und lässt sich in einem Satz merken: Das Lastenheft beschreibt das Was aus Sicht des Auftraggebers, das Pflichtenheft beschreibt das Wie aus Sicht des Auftragnehmers. Sie als Unternehmen oder Gründer formulieren im Lastenheft, welches Problem gelöst werden soll und welche Anforderungen das Ergebnis erfüllen muss – ohne die technische Umsetzung vorwegzunehmen. Die Agentur antwortet mit dem Pflichtenheft und beschreibt konkret, mit welchen technischen Mitteln, in welcher Architektur und in welchen Schritten sie die im Lastenheft genannten Anforderungen erfüllen wird.

Diese Rollenteilung hat einen praktischen Grund. Sie kennen Ihr Geschäft, Ihre Zielgruppe und Ihre Prozesse am besten – also beschreiben Sie die fachlichen Ziele. Der Dienstleister kennt die technischen Möglichkeiten und Risiken am besten – also übersetzt er Ihre Ziele in eine umsetzbare Lösung. Das Pflichtenheft ist damit gleichzeitig ein Nachweis, dass der Anbieter Ihre Anforderungen wirklich verstanden hat. Weicht das Pflichtenheft vom Lastenheft ab, sollten Sie das früh erkennen und klären, bevor die erste Zeile Code entsteht.

Merkmal	Lastenheft	Pflichtenheft
Wer erstellt es?	Auftraggeber (Sie)	Auftragnehmer (Agentur)
Inhalt	Das Was: Ziele, Anforderungen	Das Wie: Lösung, Umsetzung
Perspektive	Fachlich, ergebnisorientiert	Technisch, lösungsorientiert
Zeitpunkt	Vor der Ausschreibung	Als Antwort auf das Lastenheft
Zweck	Angebote vergleichbar machen	Umsetzung verbindlich festhalten

Warum die Dokumente den Projekterfolg absichern

Softwareprojekte scheitern selten an fehlendem technischem Können, sondern häufig an Missverständnissen darüber, was eigentlich gebaut werden sollte. Ein schriftliches Lastenheft zwingt Sie, Ihre eigenen Erwartungen zu präzisieren – oft merken Auftraggeber erst beim Schreiben, dass zentrale Punkte noch gar nicht durchdacht sind. Für den Anbieter ist das Dokument die Grundlage einer belastbaren Aufwandsschätzung. Ohne klare Anforderungen kann niemand seriös kalkulieren, und Sie erhalten Angebote, die Sie nicht vergleichen können, weil jeder Anbieter etwas anderes annimmt.

Im Streitfall ist das Dokument außerdem der Maßstab, an dem sich die Vertragserfüllung messen lässt. Wenn zum Projektende die Frage aufkommt, ob eine Funktion geschuldet war oder nicht, gibt ein sauber formuliertes Lastenheft die Antwort. Damit ist es weit mehr als eine Formalie: Es ist die gemeinsame Referenz, auf die sich beide Seiten während des gesamten Projekts berufen können. Wie Sie darüber hinaus einen kompakten Projektüberblick für die Anbieterauswahl erstellen, lesen Sie im Ratgeber zum Briefing für die Digitalagentur.

Typische Gliederung eines Lastenhefts

Es gibt keine gesetzlich vorgeschriebene Struktur, aber eine bewährte Gliederung hat sich in der Praxis etabliert. Sie müssen nicht jeden Punkt ausführlich füllen – wichtiger ist, dass die relevanten Bereiche bewusst durchdacht wurden. Die folgende Struktur eignet sich für die meisten Web-, App- und Softwareprojekte:

• Ausgangssituation und Ziele: Welches Problem soll gelöst werden? Was ist der geschäftliche Nutzen? Was ist ausdrücklich nicht Teil des Projekts (Scope-Abgrenzung)?
• Zielgruppe und Nutzergruppen: Wer wird das System verwenden – Endkunden, interne Mitarbeiter, Administratoren? Welche Erwartungen haben diese Gruppen?
• Funktionale Anforderungen: Was muss das System können? Am besten als nummerierte, überprüfbare Liste (z. B. „Der Nutzer kann sich per E-Mail registrieren.").
• Nicht-funktionale Anforderungen: Performance, Sicherheit, Datenschutz, Barrierefreiheit, Verfügbarkeit, unterstützte Browser und Geräte.
• Schnittstellen: Welche bestehenden Systeme (ERP, CRM, Zahlungsanbieter, Warenwirtschaft) müssen angebunden werden?
• Rahmenbedingungen: Budgetrahmen, gewünschter Zeitplan, gesetzliche Vorgaben, vorhandene Technologievorgaben.
• Abnahmekriterien: Woran erkennen beide Seiten, dass eine Anforderung erfüllt ist?

Formulieren Sie funktionale Anforderungen möglichst überprüfbar und eindeutig. Ein Satz wie „Die Suche soll schnell sein" ist wertlos, weil niemand ihn objektiv prüfen kann. Besser: „Ergebnisse einer Suchanfrage werden bei bis zu 10.000 Datensätzen in unter zwei Sekunden angezeigt." Wie Sie Anforderungen systematisch und messbar erheben, vertieft der Ratgeber zum Definieren von Software-Anforderungen.

Was ins Pflichtenheft gehört

Das Pflichtenheft des Anbieters greift jede Anforderung des Lastenhefts auf und beschreibt die geplante Umsetzung. Typische Inhalte sind die technische Architektur, der geplante Technologie-Stack, das Datenmodell, die Umsetzung der Schnittstellen, ein Zeit- und Meilensteinplan sowie die konkrete Ausgestaltung der Abnahmekriterien. Ein gutes Pflichtenheft macht auch Annahmen und offene Punkte transparent – etwa wenn eine Anforderung im Lastenheft mehrdeutig war und der Anbieter eine bestimmte Auslegung getroffen hat.

Die agile Alternative: Product Backlog statt starrem Pflichtenheft

Das klassische Modell aus Lasten- und Pflichtenheft geht davon aus, dass sich alle Anforderungen zu Projektbeginn vollständig festlegen lassen. Bei vielen Softwareprojekten trifft das nicht zu: Anforderungen werden erst im Verlauf klarer, der Markt ändert sich, und Nutzerfeedback verschiebt Prioritäten. Für solche Vorhaben ist ein agiles Vorgehen oft besser geeignet. Statt eines starren Pflichtenhefts arbeiten Teams dann mit einem Product Backlog – einer priorisierten, lebenden Liste von Anforderungen, die als User Stories formuliert sind.

Der Scrum Guide beschreibt Scrum als Rahmenwerk, das auf den drei Säulen Transparenz, Inspektion und Adaption beruht. Die Arbeit erfolgt in Sprints – festen Zeiträumen von einem Monat oder weniger, in denen ein nutzbares Inkrement entsteht. Statt zu Projektbeginn alles zu spezifizieren, wird das Backlog kontinuierlich verfeinert und neu priorisiert. Das Lastenheft verliert dabei nicht seine Berechtigung: Auch agile Projekte brauchen zu Beginn eine klare Produktvision und grobe Ziele. Nur die detaillierte, unveränderliche Vorabspezifikation weicht der schrittweisen Verfeinerung. Welches Modell zu Ihrem Vorhaben passt, erläutert der Vergleich agiler und klassischer Vorgehensmodelle.

In der Praxis ist auch eine Mischform verbreitet: Ein Lastenheft dient als fachliche Grundlage für Ausschreibung und Vertrag, die konkrete Umsetzung erfolgt aber agil in Sprints. Wichtig ist, dass beide Seiten dasselbe Vorgehensmodell vereinbaren, denn es beeinflusst Vertragsform, Preismodell und Abnahme.

Verbindung zum Werkvertrag

Rechtlich betrachtet ist das Lastenheft eng mit der Frage verbunden, welches Werk geschuldet wird. Beim Werkvertrag nach § 631 BGB verpflichtet sich der Auftragnehmer zur Herstellung eines konkret vereinbarten Werks – der Auftraggeber schuldet die Vergütung. Entscheidend ist, dass das geschuldete Werk klar definiert ist, denn nur dann lässt sich beurteilen, ob es mangelfrei erbracht wurde. Genau diese Definition liefert ein präzises Lastenheft beziehungsweise das darauf aufbauende Pflichtenheft.

Beim Werkvertrag steht der geschuldete Erfolg im Vordergrund, während der Dienstvertrag nach § 611 BGB nur die Tätigkeit selbst schuldet. Für Festpreisprojekte mit klar abgegrenztem Umfang wird häufig der Werkvertrag gewählt, für laufende agile Zusammenarbeit eher ein dienstvertragliches Modell. Die Zusammenhänge vertieft der Ratgeber zu Werk- und Dienstvertrag in der Softwareentwicklung. Je unschärfer das Lastenheft, desto schwieriger ist im Werkvertrag die Frage zu beantworten, ob eine Leistung erbracht wurde oder ob es sich um eine nachträgliche Zusatzforderung handelt. Dieser Beitrag ersetzt keine Rechtsberatung im Einzelfall.

Häufige Fehler beim Erstellen

Einige Muster tauchen immer wieder auf und lassen sich leicht vermeiden, wenn man sie kennt:

• Lösung statt Ziel beschreiben: Wenn Sie im Lastenheft bereits die technische Umsetzung vorschreiben, verschenken Sie das Know-how des Anbieters und binden sich möglicherweise an eine schlechtere Lösung.
• Unüberprüfbare Formulierungen: Begriffe wie „benutzerfreundlich", „modern" oder „performant" ohne messbare Kriterien führen zu Streit bei der Abnahme.
• Scope nicht abgrenzen: Was nicht ausdrücklich ausgeschlossen ist, wird von jedem Anbieter anders eingeschätzt – benennen Sie explizit, was nicht Teil des Projekts ist.
• Nicht-funktionale Anforderungen vergessen: Datenschutz, Sicherheit und Performance werden oft übersehen und später teuer nachgerüstet.
• Keine Priorisierung: Wenn alle Anforderungen gleich wichtig erscheinen, kann bei Budget- oder Zeitdruck nicht sinnvoll gekürzt werden.

Wie das Dokument die Vergleichbarkeit von Angeboten erhöht

Ein klarer Nutzen eines Lastenhefts zeigt sich in der Anbieterauswahl. Wenn Sie mehreren Agenturen dasselbe Dokument vorlegen, kalkulieren alle auf derselben Grundlage – und ihre Angebote werden vergleichbar. Ohne gemeinsame Basis erhalten Sie Preise, die zwischen unausgesprochen unterschiedlichen Leistungsumfängen schwanken, und der billigste Anbieter ist oft nur derjenige, der am wenigsten eingeplant hat. Wie Sie eingehende Angebote strukturiert gegenüberstellen, zeigt der Ratgeber zum Vergleichen von Agentur-Angeboten.

Als grobe Orientierung: In der DACH-Region liegt der Stundensatz für Softwareentwicklung laut Marktdaten des Freelancer-Kompass im Bereich von rund 90 € pro Stunde, mit erheblicher Streuung nach Technologie und Seniorität. Ein präzises Lastenheft hilft, die geschätzten Aufwände hinter solchen Sätzen realistisch einzuordnen.

Schritt für Schritt zum fertigen Lastenheft

In der Praxis entsteht ein gutes Lastenheft nicht in einem Zug, sondern in mehreren Durchgängen. Beginnen Sie mit einer groben Sammlung der Ziele und des Problems, das die Software lösen soll – oft genügt dafür ein moderierter Workshop mit den wichtigsten Beteiligten. Erst danach gliedern Sie die Sammlung in die oben genannten Kapitel und füllen sie schrittweise. Widerstehen Sie der Versuchung, sofort ins Detail zu gehen: Eine tragfähige Grobstruktur ist wertvoller als ein einzelnes ausformuliertes Kapitel, während andere Bereiche noch leer bleiben.

Lassen Sie das fertige Dokument von einer Person gegenlesen, die nicht an der Erstellung beteiligt war. Was für die Autoren selbstverständlich klingt, ist für Außenstehende oft mehrdeutig – und genau diese Mehrdeutigkeiten führen später zu Missverständnissen mit dem Anbieter. Ein zweiter Blick deckt zudem Lücken auf, etwa bei Schnittstellen oder rechtlichen Rahmenbedingungen. Planen Sie außerdem einen Puffer für Rückfragen der angefragten Agenturen ein: Gute Anbieter stellen präzise Fragen zum Lastenheft, und diese Fragen sind ein wertvolles Signal dafür, wie gründlich ein Anbieter arbeitet. Ob ein Freelancer oder eine Agentur besser zu Ihrem Vorhaben passt, erläutert der Vergleich von Agentur und Freelancer.

Denken Sie schon beim Schreiben an das Preismodell. Ein sehr präzises, stabiles Lastenheft ist die Grundlage für ein Festpreisangebot, während ein bewusst offen gehaltener Anforderungsrahmen eher zur Abrechnung nach Aufwand passt. Welches Modell für Ihr Projekt sinnvoll ist, vergleicht der Ratgeber zu Festpreis und Abrechnung nach Aufwand. Diese Weichenstellung sollten Sie treffen, bevor Sie das Lastenheft an mehrere Anbieter versenden.

Häufige Fragen

Brauche ich für jedes Softwareprojekt ein Lastenheft?

Nicht zwingend in voller Ausführlichkeit, aber eine strukturierte schriftliche Anforderungsbeschreibung ist praktisch immer sinnvoll. Selbst bei kleinen Projekten hilft eine kompakte Liste von Zielen und Anforderungen, Missverständnisse zu vermeiden und Angebote vergleichbar zu machen. Der Aufwand sollte zur Projektgröße passen.

Wer schreibt das Pflichtenheft – ich oder die Agentur?

Das Pflichtenheft erstellt der Auftragnehmer, also die Agentur oder der Dienstleister. Es ist deren Antwort auf Ihr Lastenheft und beschreibt, wie sie Ihre Anforderungen technisch umsetzen wollen. Sie prüfen das Pflichtenheft und stellen sicher, dass es Ihre Anforderungen vollständig und richtig abbildet.

Widerspricht ein Lastenheft dem agilen Vorgehen?

Nein. Auch agile Projekte brauchen zu Beginn eine klare Vision und grobe Ziele – nur die detaillierte, unveränderliche Vorabspezifikation entfällt. Statt eines starren Pflichtenhefts arbeiten agile Teams mit einem priorisierten Product Backlog, das laufend verfeinert wird. Ein Lastenheft als fachliche Grundlage bleibt trotzdem nützlich.

Wie detailliert muss ein Lastenheft sein?

So detailliert, dass ein Anbieter seriös kalkulieren kann und Missverständnisse unwahrscheinlich werden – aber nicht so detailliert, dass Sie die technische Lösung vorwegnehmen. Konzentrieren Sie sich auf überprüfbare funktionale Anforderungen, nicht-funktionale Kriterien, Schnittstellen und eine klare Scope-Abgrenzung.

Was passiert bei Änderungen nach Vertragsschluss?

Änderungen am vereinbarten Umfang sollten über einen definierten Change-Prozess laufen, der Auswirkungen auf Zeit und Budget dokumentiert. Ein klares Lastenheft ist die Referenz, um zu unterscheiden, was ursprünglich geschuldet war und was eine kostenpflichtige Erweiterung darstellt.

Passende Agentur finden: Sie haben Ihr Lastenheft erstellt und suchen den passenden Umsetzungspartner? Vergleichen Sie neutral Anbieter für Softwareentwicklung und IT-Beratung auf Deine-Agenturen.com und starten Sie Ihr Projekt auf einer soliden Grundlage.