Software-Anforderungen richtig definieren: Lastenheft vs. Pflichtenheft

“Schick uns mal dein Lastenheft.” Wer bei Software-Projekten anfragt, hört den Satz häufig. Und weiß oft nicht genau, was der Unterschied zum Pflichtenheft ist, wer was schreibt und wann beides überhaupt sinnvoll ist. Besonders weil der Begriff “Lastenheft” sich in der Praxis längst gewandelt hat, je nachdem, ob du in einem Konzern, bei einer Agentur oder in einem agilen Entwicklerteam sitzt.

Hier die klare Einordnung: Was beide Dokumente unterscheidet, was tatsächlich reingehört und wann du besser eine andere Form wählst.

Die klassische Definition

Der Unterschied ist im Kern einfach, auch wenn die Praxis ihn gerne verwischt. Beide Begriffe sind in der DIN 69901-5 (Projektmanagement-Norm) definiert.

Lastenheft. Geschrieben vom Auftraggeber. Beantwortet die Frage: Was will ich und wofür? Es beschreibt das Problem, das Ziel, die fachlichen Anforderungen, die Rahmenbedingungen. Es ist die Grundlage, auf der Anbieter ein Angebot machen können.

Pflichtenheft. Geschrieben vom Auftragnehmer, auf Basis des Lastenhefts. Beantwortet die Frage: Wie und womit setzen wir das um? Es enthält die konkrete technische Lösung, Architektur, eingesetzte Technologien, Schnittstellen, Zeitplan.

Anders gesagt: Das Lastenheft ist die Wunschliste, das Pflichtenheft ist der Bauplan. Ohne Lastenheft keine saubere Ausschreibung, ohne Pflichtenheft keine verbindliche Umsetzungsgrundlage.

Was ins Lastenheft gehört

Ein gutes Lastenheft für ein Softwareprojekt hat etwa fünf bis zwanzig Seiten. Kürzer wird es zu vage, länger zu unübersichtlich. Die wichtigsten Punkte:

Ausgangssituation und Ziel. Wer bist du, was läuft heute, was willst du verändern? Zwei Absätze, konkret. Ohne Marketing-Sprache.

Zielgruppe und Nutzer. Wer arbeitet mit der Software? Kunden, Innendienst, Buchhaltung, Externe? Mit welchen Geräten, auf welchen Kanälen?

Fachliche Anforderungen. Das Herzstück. Was muss die Software können? Strukturiert nach Modulen oder Use-Cases. Zum Beispiel: “Rechnungen aus dem Shop an DATEV exportieren, einmal täglich als CSV.”

Nicht-funktionale Anforderungen. Performance, Verfügbarkeit, Datenschutz, Skalierung, Sprachen, Barrierefreiheit. Wird oft vergessen und später zum Problem.

Schnittstellen und Systeme. Welche bestehenden Systeme müssen angebunden werden? Mit welchen Versionen? Wer ist dort Ansprechpartner?

Rahmenbedingungen. Budget, Zeitrahmen, Compliance, IT-Sicherheit, rechtliche Vorgaben wie DSGVO oder branchenspezifische Normen.

Priorisierung. Was ist ein Muss, was ein Sollte, was ein Kannste-gern-machen? Die saubere Priorisierung nach der MoSCoW-Logik (Must, Should, Could, Won’t) spart später Diskussionen.

Was ins Pflichtenheft gehört

Das Pflichtenheft ist die technische Antwort auf das Lastenheft. Wir als Agentur schreiben es nach einem Kickoff und ersten Workshops. Typische Bestandteile:

• Architekturskizze und Technologiestack
• Detaillierte Umsetzung der fachlichen Anforderungen, Anforderung für Anforderung
• Datenmodell und Schnittstellen-Spezifikation
• Zeitplan mit Meilensteinen
• Testkonzept und Abnahmekriterien
• Annahmen und Voraussetzungen (z.B. “Kunde stellt VPN-Zugang bis KW 12 bereit”)

Das Pflichtenheft wird mit der Unterschrift beider Seiten zum verbindlichen Bestandteil des Werkvertrags. Abweichungen laufen später als Change-Request.

Wer schreibt was

In der reinen Lehre: Auftraggeber schreibt Lastenheft, Auftragnehmer schreibt Pflichtenheft. In der Praxis sieht es oft anders aus.

Viele Mittelstandskunden haben weder die Zeit noch die Kompetenz, ein vollständiges Lastenheft zu erstellen. Wir erleben sehr oft, dass wir das Lastenheft gemeinsam mit dem Kunden entwickeln, in Form von Workshops. Das ist ein eigenes Projekt, für das du ein paar Tage Berater-Aufwand einrechnen musst. Aber es ist vermutlich die am besten investierte Zeit im gesamten Projekt, weil die meisten Softwareprojekte nicht an schlechter Entwicklung scheitern, sondern an schlechten Anforderungen.

Wer ein Lastenheft komplett auslagert, läuft in eine Falle: Der externe Berater schreibt das Dokument in Richtung seines späteren Lieblingsanbieters, oder er versteht deine tatsächlichen Prozesse nicht. Idealerweise ist immer jemand aus deinem Unternehmen federführend beteiligt.

Brauchst du das überhaupt noch?

Die Kritik an der klassischen Lasten-/Pflichtenheft-Logik ist nicht neu. Das Modell stammt aus einer Zeit, in der Softwareprojekte wie Brücken oder Maschinen gebaut wurden: Einmal planen, dann bauen, dann fertig. Moderne Softwareentwicklung läuft anders.

Bei agilen Projekten, die mit Scrum oder Kanban arbeiten, ersetzt das Product Backlog zusammen mit User Stories und Akzeptanzkriterien das Pflichtenheft. Die Anforderungen werden in kurzen Iterationen geschärft, nicht zu Projektbeginn fertig durchgeplant. Das funktioniert dann gut, wenn beide Seiten tatsächlich iterativ arbeiten können.

Wenn du ein Festpreisangebot haben willst, kommst du um ein Lastenheft oder ein vergleichbares Dokument nicht herum. Ohne klar definierten Leistungsumfang kann kein seriöser Anbieter ein Festpreisangebot machen. Die Alternative sind Time-&-Material-Projekte, bei denen die Spezifikation parallel zur Entwicklung entsteht. Günstig sind solche Projekte nur mit einem stabilen Team und engem Austausch, sonst geraten sie schnell aus dem Ruder.

Ein schlankerer Ansatz für den Mittelstand

Viele unserer Kunden wollen weder ein 80-Seiten-Lastenheft schreiben noch komplett agil arbeiten. Für diesen Fall hat sich ein Mittelweg bewährt: das Projektbriefing.

Ein Projektbriefing umfasst 3 bis 8 Seiten und enthält:

• Zielbild und Nutzen in wenigen Absätzen
• Die zehn bis zwanzig wichtigsten Anforderungen, priorisiert
• Grobe Rahmenbedingungen (Budget, Zeitraum, kritische Schnittstellen)
• Was ausdrücklich nicht Teil des Projekts ist

Auf dieser Basis lässt sich ein realistisches Grobangebot erstellen. Die eigentliche Feinspezifikation passiert dann in einer Konzeptphase am Projektbeginn, die als separater Auftrag abgerechnet wird. So vermeidest du, dass Wochen in ein Dokument fließen, nach dem sich später ohnehin niemand mehr richtet.

Die häufigsten Fehler

Aus unserer Erfahrung die typischen Probleme:

Lastenheft als Wunschzettel. Wer alles will, bekommt nichts Vernünftiges. Ohne Priorisierung explodieren Budget und Zeit.

Technische Vorgaben im Lastenheft. Formulierungen wie “wir wollen eine React-Anwendung mit MongoDB” gehören nicht ins Lastenheft, sondern ins Pflichtenheft. Wenn du die Technik vorgibst, verbaust du dir bessere Vorschläge.

Anforderungen ohne Akzeptanzkriterium. “Das System muss schnell sein” ist keine Anforderung, sondern ein Wunsch. Mach sie messbar: “Die Bestellübersicht lädt in unter zwei Sekunden bei 1.000 Bestellungen.”

Lastenheft als Feigenblatt. Manche schreiben das Dokument nur, weil irgendwer es verlangt, und arbeiten dann sowieso anders weiter. Das Ergebnis kann man sich vorstellen.

Wer ein Softwareprojekt sauber aufsetzen will, sollte die Anforderungsphase ernst nehmen. In unseren Projekten läuft das in 80 Prozent der Fälle als gemeinsamer Prozess mit dem Kunden, nicht als reines Dokument-hin-und-her. Wenn du gerade am Anfang eines Vorhabens stehst und unsicher bist, welches Format bei dir passt, sprich uns an. Mehr zu unserer Herangehensweise bei Individueller Softwareentwicklung und Beratung & Betreuung. Eine erste Einschätzung passt in eine Fokus-Session.