Zum Inhalt springen

Lastenheft und Pflichtenheft: Was braucht ein Webprojekt?

Viele Vorhaben verzögern sich, weil auf ein vollständiges Dokument gewartet wird, das niemand schreiben kann. Dieser Text erklärt die Begriffe, nennt die Fälle, in denen sie wirklich gebraucht werden, und sagt, was sonst genügt.

  • Für wenGeschäftsführung, Projektverantwortliche, Einkauf
  • NiveauProjektplanung
  • Lesezeitetwa 7 Minuten
  • Stand16. Oktober 2026

Das lernen Sie

  • Was Lastenheft und Pflichtenheft jeweils sind
  • Wann sich der Aufwand lohnt — und wann er schadet
  • Welche sechs Angaben für einen verlässlichen Start genügen
  • Wie man mit dem umgeht, was man noch nicht weiß

Zwei Dokumente, zwei Verfasser

Das Lastenheft beschreibt, was der Auftraggeber braucht: die Aufgabe, die Rahmenbedingungen, die Ziele. Es wird von Ihnen geschrieben, in Ihrer Sprache.

Das Pflichtenheft beschreibt, wie der Auftragnehmer es umsetzen will: Lösungsweg, Technik, Abgrenzung. Es entsteht beim Entwickler, auf Grundlage des Lastenhefts, und wird von Ihnen abgenommen.

In der Praxis kommt diese saubere Trennung vor allem bei öffentlichen Ausschreibungen und in regulierten Bereichen vor. In einem mittelständischen Webprojekt entsteht meist ein gemeinsames Dokument — und das ist kein Mangel, sondern angemessen.

Wann sich der Aufwand lohnt

Ein ausgearbeitetes Lastenheft lohnt sich, wenn mindestens einer dieser Punkte zutrifft:

  • Sie holen Angebote von mehreren Anbietern ein und wollen sie vergleichen können.
  • Mehrere Abteilungen müssen sich auf denselben Stand einigen, bevor etwas gebaut wird.
  • Es gelten regulatorische Anforderungen, die nachweisbar erfüllt sein müssen.
  • Das Vorhaben ist groß genug, dass ein Missverständnis Monate kostet.

Wo nichts davon zutrifft, kann ein umfangreiches Dokument sogar schaden: Es bindet Wochen, veraltet während der Umsetzung und erzeugt die Illusion, alles sei geklärt. Die wichtigen Fragen stellen sich trotzdem erst, wenn man die ersten Masken sieht.

Sechs Angaben, die für einen Start genügen

  • Der Ablauf in Ihren Worten, Schritt für Schritt — der echte, nicht der ideale.
  • Wer mit der Software arbeitet und wer welche Entscheidungen trifft.
  • Welche Systeme beteiligt sind, auch Tabellen und Postfächer.
  • Was mit vorhandenen Daten passieren soll.
  • Was ausdrücklich nicht dazugehört.
  • Woran Sie nach einem halben Jahr erkennen würden, dass es sich gelohnt hat.

Der fünfte Punkt wird fast immer vergessen und ist der wertvollste. Er verhindert die Diskussion nach der Abnahme, in der beide Seiten recht haben.

Ein Beispiel aus der Praxis

Was man noch nicht weiß, gehört trotzdem hinein

Kein Lastenheft ist vollständig, und das ist in Ordnung — solange die Lücken benannt sind. Ein Satz wie „Wie mit stornierten Aufträgen in der Jahresauswertung umgegangen wird, ist noch offen" ist mehr wert als ein scheinbar vollständiges Dokument, das diese Frage übergeht.

Ein Entwickler, der eine benannte Lücke sieht, plant dafür eine Entscheidung ein. Eine unbenannte Lücke wird stillschweigend mit einer Annahme gefüllt — und Annahmen fallen in der Abnahme auf, nicht vorher.

Häufige Missverständnisse

Für eine belastbare Einordnung genügen die sechs Angaben oben. Ein Festpreis über einen unscharfen Umfang wäre ohnehin nur ein eingepreistes Risiko.

Detail an der richtigen Stelle hilft. Detail über Dinge, die sich während der Umsetzung ohnehin klären, bindet Zeit und wird später nicht nachgepflegt.

Es ist eine Beschreibung des Lösungswegs. Was vertraglich gilt, regelt der Vertrag — die Beschreibung kann dort in Bezug genommen werden.

Über den Autor

Fabian Lücker ist geschäftsführender Gesellschafter der PHP-Schmiede KG in Rheine und seit 2007 in der Softwareentwicklung tätig. Er verantwortet Entwicklung und Konzeption und schreibt hier über Entscheidungen, die in echten Projekten anfallen.