Pflichtenheft schreiben: Anleitung mit Vorlage

Wer eine Pflichtenheft Software Vorlage sucht, braucht meist eine Struktur, die sich sofort füllen lässt. Ein gutes Pflichtenheft ist die Grundlage, auf der später Kostenschätzung, Zeitplan und Abnahme aufbauen. Fehlt es oder bleibt es vage, verhandeln Auftraggeber und Entwickler während des ganzen Projekts über Dinge, die eigentlich vorher hätten geklärt werden müssen.

Lastenheft und Pflichtenheft haben getrennte Rollen

Die Norm DIN 69905 unterscheidet zwischen beiden Dokumenten (wiki.induux.de, 03/2026). Das Lastenheft kommt vom Auftraggeber und beschreibt, was erreicht werden soll, aus fachlicher Sicht, ohne technische Lösung. Das Pflichtenheft kommt vom Auftragnehmer und beschreibt, wie die Anforderungen umgesetzt werden, technisch konkret. Wer beide Dokumente vermischt, bekommt am Ende weder eine klare Zielbeschreibung noch eine belastbare technische Spezifikation.

International orientiert sich die Struktur oft an IEEE 830-1998 als Standard für Software Requirements Specifications, ergänzt in Deutschland durch die VDI-Richtlinie 2519 Blatt 1. Beide liefern keine Pflicht-Vorlage, aber eine bewährte Gliederungslogik, die sich auf die meisten Projekte übertragen lässt.

Die Pflichtenheft Software Vorlage als Kapitelstruktur

Für die Praxis empfiehlt sich eine Gliederung in acht Kapitel, die mit dem Projektumfang mitwächst.

1. Ziel des Projekts. Ein Absatz, der beschreibt, welches Geschäftsproblem gelöst wird und woran der Erfolg gemessen wird.
2. Ist-Zustand. Wie läuft der Prozess heute, mit welchen Systemen, welchen Beteiligten, welchen bekannten Schwachstellen.
3. Soll-Prozesse. Wie soll der Prozess nach der Einführung ablaufen, idealerweise mit einem einfachen Ablaufdiagramm.
4. Funktionale Anforderungen. Jede einzelne Funktion, nummeriert und einzeln überprüfbar, nicht als Fließtext formuliert.
5. Nicht-funktionale Anforderungen. Performance, Verfügbarkeit, Datenschutz, Barrierefreiheit, alles, was die Qualität der Lösung betrifft, ohne eine einzelne Funktion zu sein.
6. Schnittstellen. Welche Bestandssysteme werden angebunden, in welche Richtung fließen Daten, in welchem Format.
7. Abnahmekriterien. Woran erkennt man, dass eine Anforderung erfüllt ist. Ohne diesen Punkt gibt es später keine objektive Abnahme.
8. Glossar. Begriffe, die im Projekt eine spezifische Bedeutung haben, kurz definiert. Gerade bei Fachbegriffen aus der Produktion oder Logistik verhindert das Missverständnisse zwischen IT und Fachabteilung.

Wie umfangreich ein Pflichtenheft sein muss

Der Umfang hängt am Projekt, nicht an einer festen Seitenzahl. Kleine Projekte kommen mit vier bis acht Seiten aus, größere Vorhaben füllen 30 bis 80 Seiten (IgniTech, 12/2025). Ein internes Automatisierungstool braucht nicht dieselbe Tiefe wie eine unternehmensweite Plattform mit mehreren Modulen und Nutzergruppen.

Als Faustregel gilt, dass zwei Entwickler, die das Dokument unabhängig voneinander lesen, zum selben Verständnis der Anforderung kommen müssen (IgniTech, 12/2025). Bleibt Interpretationsspielraum, ist das Dokument noch nicht fertig, unabhängig von der Seitenzahl.

Genau an dieser Stelle entstehen dann oft die Kosten, die im ursprünglichen Angebot fehlten, wie wir im Beitrag zu versteckten Kosten in Softwareprojekten beschreiben. Und wer den Rahmen während des Projekts wachsen lässt, landet schnell beim Thema Scope Creep.

Wer das Pflichtenheft schreiben sollte

In der Praxis entsteht das Pflichtenheft meist im Dialog. Der Auftraggeber liefert das fachliche Wissen aus dem Lastenheft, der Entwicklungspartner übersetzt es in technisch konkrete Anforderungen und stellt Rückfragen, wo Formulierungen mehrdeutig sind. Wird es allein von einer Seite geschrieben, fehlt entweder das technische Verständnis für Machbarkeit oder das fachliche Verständnis für den realen Ablauf.

Häufige Fragen

Was unterscheidet Lastenheft und Pflichtenheft?

Das Lastenheft beschreibt aus Sicht des Auftraggebers, was erreicht werden soll. Das Pflichtenheft beschreibt aus Sicht des Auftragnehmers, wie die Anforderungen technisch umgesetzt werden (DIN 69905, wiki.induux.de, 03/2026). Beide Dokumente ergänzen sich, sie ersetzen sich nicht.

Wie detailliert muss ein Pflichtenheft sein?

So detailliert, dass zwei unabhängige Entwickler zur selben Interpretation kommen (IgniTech, 12/2025). Für kleine Projekte reichen vier bis acht Seiten, größere Vorhaben brauchen 30 bis 80 Seiten, abhängig von der Zahl der Anforderungen und Schnittstellen.

Wer sollte das Pflichtenheft schreiben?

Im besten Fall entsteht es im Dialog zwischen Auftraggeber und Entwicklungspartner. Der Auftraggeber liefert die fachlichen Anforderungen, der Entwicklungspartner übersetzt sie in eine technisch belastbare Spezifikation und prüft sie auf Lücken.

Der nächste Schritt

torck schreibt Pflichtenhefte gemeinsam mit dem Auftraggeber, mit Entwicklungsteams in Maxhütte-Haidhof, Wien und Rabat, die die technische Machbarkeit direkt einschätzen können. Die torck GmbH als deutscher Vertragspartner baut seit Jahren Software für Industrie und Handel. Im Erstgespräch klären wir die ersten Anforderungen an Ihrem konkreten Projekt.