Lastenheft und Pflichtenheft: was hineingehört und wer es schreibt

Ein Pflichtenheft beschreibt, wie der Auftragnehmer die Anforderungen des Auftraggebers umsetzt; das Lastenheft beschreibt vorher, was der Auftraggeber braucht und wofür. Beide Dokumente gehören zusammen: Das eine stellt die Aufgabe, das andere antwortet darauf mit einer Lösung. In Softwareprojekten entscheiden sie über die Abnahme.

Lastenheft und Pflichtenheft: der Unterschied

Das Lastenheft kommt vom Auftraggeber und bleibt lösungsneutral: Es nennt Ziel, Rahmenbedingungen und Anforderungen, nicht die Technik. Die Antwort des Auftragnehmers – in der Praxis oft als Spezifikation oder Umsetzungskonzept bezeichnet – beschreibt den Lösungsweg: Architektur, Datenmodell, Masken, Schnittstellen, Annahmen.

Der Reihenfolgefehler ist der häufigste: Wer die Aufgabe schon mit der Lösung formuliert, schneidet Alternativen ab, bevor sie geprüft wurden. Umgekehrt kann ein Auftragnehmer ohne klar formulierte Aufgabe nur raten und kalkuliert den Puffer entsprechend hoch.

Die Begriffe stammen aus der Norm für Entwicklungsprojekte und werden im Alltag häufig vermischt. Für die Zusammenarbeit ist die Bezeichnung zweitrangig; entscheidend ist, dass beide Blickwinkel schriftlich vorliegen und dass erkennbar bleibt, wer welchen Teil verantwortet.

Was ins Lastenheft gehört

• Ausgangslage und Ziel. Welcher Ablauf ist heute wie organisiert, was soll danach anders sein, woran wird das erkannt.
• Beteiligte und Rollen. Wer arbeitet mit dem System, welche Rechte braucht jede Gruppe.
• Fachliche Anforderungen. Vorgänge, Regeln, Sonderfälle, Mengengerüst. Sonderfälle sind wichtiger als der Normalfall, weil sie den Aufwand treiben.
• Nachbarsysteme. Welche Systeme liefern oder empfangen Daten, wer betreibt sie, welche Zugänge existieren.
• Rahmenbedingungen. Datenschutz, Aufbewahrung, Barrierefreiheit, unterstützte Endgeräte, Sprachen.
• Mengengerüst und Wachstum. Wie viele Vorgänge, Nutzer und Datensätze fallen heute an, wie viele in absehbarer Zeit – daran hängen Architektur und Aufwand.
• Was ausdrücklich nicht dazugehört. Ein Absatz, der Streit erspart.

Was ins Pflichtenheft gehört

Das Pflichtenheft übersetzt jede Anforderung in eine Umsetzung und macht offen, was sie voraussetzt – auch das, was es an Mitwirkung des Auftraggebers erwartet:

• Architektur und eingesetzte Technik, mit Begründung der wesentlichen Entscheidungen.
• Datenmodell in Grundzügen: Objekte, Beziehungen, führende Systeme je Datenart.
• Masken und Abläufe je Rolle, inklusive Verhalten bei Fehleingaben.
• Schnittstellen mit Richtung, Auslöser, Feldzuordnung und Verhalten bei Störungen.
• Betrieb: Umgebungen, Auslieferung, Sicherungen, Protokollierung.
• Annahmen und Mitwirkungspflichten – etwa Testzugänge, Inhalte oder Ansprechpartner beim Auftraggeber.

Ein solches Dokument ist die Grundlage für einen Werkvertrag mit Abnahme und für jede belastbare Pauschale, siehe Festpreis oder Tagessatz.

Abnahmekriterien: der wichtigste Abschnitt

Abnahmekriterien machen aus Anforderungen etwas Überprüfbares. Brauchbar sind Formulierungen, die jemand ohne Fachdiskussion nachvollziehen kann:

• Ein Benutzer mit der Rolle Vertrieb legt einen Vorgang an, ändert ihn und schließt ihn ab; das Protokoll weist alle drei Schritte aus.
• Der Import verarbeitet den bereitgestellten Bestand vollständig; Abweichungen erscheinen in einer Fehlerliste mit Grund.
• Die Anbindung liefert für zehn Stichproben dieselben Werte wie das Quellsystem.

Unbrauchbar sind Formeln wie „intuitiv bedienbar“ oder „performant“. Wo eine Eigenschaft wichtig ist, wird sie messbar gemacht – etwa über eine definierte Datenmenge und eine Obergrenze für die Antwortzeit.

Ein praktischer Test für jedes Kriterium: Kämen zwei Personen unabhängig voneinander zum selben Urteil, ob es erfüllt ist? Wenn nicht, fehlt eine Zahl, ein Datenbestand oder ein konkret beschriebener Ablauf.

Beide Dokumente in agilen Projekten

Auch in agilen Vorhaben verschwindet die Aufgabenstellung nicht, sie wird nur anders geschnitten: Ziel, Rahmenbedingungen und Abnahmekriterien werden früh festgehalten, die Detailbeschreibung entsteht je Etappe kurz vor der Umsetzung. Wichtig bleibt, dass jede Etappe einen abnehmbaren Stand hat und Änderungen als solche sichtbar werden. Für einen ersten Versuch genügt oft die Kurzform, siehe MVP-Entwicklung.

Typische Fehler und wie wir sie vermeiden

• Wunschliste statt Aufgabe. Hunderte Einzelfunktionen ohne Priorität lassen sich weder schätzen noch abnehmen.
• Sonderfälle fehlen. Storno, Teillieferung, Nachbuchung, Rückgabe – genau dort steckt der Aufwand.
• Mitwirkung ungeklärt. Fehlen Inhalte, Testdaten oder Zugänge, steht das Projekt still, ohne dass jemand dafür zuständig ist.
• Dokument veraltet. Änderungen werden mündlich vereinbart und nirgends nachgeführt; bei der Abnahme fehlt die Grundlage.

Wir erarbeiten die Aufgabenstellung gemeinsam mit dem Fachbereich, schreiben die Antwort darauf selbst und führen beides bei jeder Änderung nach; die Abnahmekriterien stehen vor dem Start im Angebot. Wie daraus ein Projekt wird, zeigt die Seite Softwareentwicklung.