Lastenheft und Pflichtenheft für Software: Unterschied, Aufbau und Vorlage

Das Lastenheft beschreibt, was eine Software aus Sicht des Auftraggebers leisten soll. Das Pflichtenheft beschreibt, wie der Auftragnehmer diese Anforderungen umsetzt. Das eine schreibt das Unternehmen, das eine Software braucht, das andere die Agentur oder das Entwicklungsteam, das sie baut. Beide Dokumente zusammen bilden die Grundlage für Offerte, Umsetzung und Abnahme.

So weit die Lehrbuchdefinition, wie sie auch die deutsche Projektmanagement-Norm DIN 69901-5 festhält und wie sie viele Ausschreibungen prägt. In der Praxis stellt sich aber eine zweite Frage: Wie viel davon braucht ein KMU wirklich? Wer für ein erstes digitales Produkt ein vierzigseitiges Lastenheft schreibt, verbringt Wochen mit Annahmen, die sich im ersten Test mit echten Nutzern oft als falsch herausstellen. Dieser Artikel zeigt beides: den sauberen Aufbau zum Übernehmen und die ehrliche Einordnung, wann weniger mehr ist.

Der Unterschied in einer Tabelle

Die wichtigste Regel steckt in der zweiten Zeile: Ein Lastenheft sagt nicht, wie etwas gebaut wird. Wer im Lastenheft bereits Programmiersprachen, Datenbanken oder Bildschirmlayouts festlegt, nimmt dem Umsetzer genau die Arbeit ab, für die er bezahlt wird, und verbaut oft die bessere Lösung.

Vorlage: Gliederung eines Lastenhefts

Die folgende Gliederung hat sich für Software- und Web-App-Projekte in KMU bewährt. Jedes Kapitel hat eine Leitfrage. Wenn Sie die Frage in wenigen Sätzen beantworten können, ist das Kapitel fertig.

1. Ausgangslage. Wie läuft der Ablauf heute, und was stört daran? Beschreiben Sie den Ist-Zustand ehrlich, inklusive Excel-Listen, Zettel und doppelter Erfassung.
2. Ziele. Was soll nach dem Projekt anders sein? Formulieren Sie messbar: «Offerten in einem Tag statt in einer Woche» ist ein Ziel, «moderne Software» nicht.
3. Nutzergruppen. Wer arbeitet mit dem System, und was braucht jede Gruppe? Eine kurze Persona pro Gruppe hilft mehr als eine Liste von Abteilungen.
4. Kernablauf. Welcher eine Ablauf muss von Anfang bis Ende funktionieren? Beschreiben Sie ihn als Folge von Schritten, ähnlich einem User Flow.
5. Funktionale Anforderungen. Was muss das System können, priorisiert in «muss», «soll» und «kann»? Ohne Priorität ist jede Liste ein Wunschzettel.
6. Nicht-funktionale Anforderungen. Wie schnell, wie sicher, wie verfügbar? Dazu gehören Datenschutz nach DSG, Speicherort der Daten, Barrierefreiheit und die Geräte, auf denen es laufen muss.
7. Schnittstellen. Welche bestehenden Systeme müssen angebunden werden: Buchhaltung, E-Mail, Kalender, Zahlungsanbieter, CRM?
8. Rahmenbedingungen. Budgetrahmen, Termine, interne Ansprechpersonen, Betrieb und Wartung nach dem Livegang.
9. Abgrenzung. Was gehört ausdrücklich nicht zum Projekt? Dieses Kapitel fehlt fast immer und verhindert die meisten Streitfälle.
10. Abnahme. Woran erkennen beide Seiten, dass das Projekt fertig ist?

Was ins Pflichtenheft gehört

Das Pflichtenheft übernimmt die Gliederung des Lastenhefts und beantwortet jede Anforderung mit einer Umsetzung. Typische Inhalte sind:

• Systemarchitektur: Aufbau der Anwendung, Hosting, Datenhaltung und Speicherort.
• Funktionen im Detail: pro Anforderung, wie sie umgesetzt wird, mit Ausnahmen und Fehlerfällen.
• Datenmodell: welche Daten gespeichert werden, wer sie sehen und ändern darf.
• Schnittstellen: technische Beschreibung jeder Anbindung, inklusive Verantwortlichkeiten.
• Tests und Abnahmekriterien: wie geprüft wird, ob eine Anforderung erfüllt ist.
• Projektplan: Etappen, Lieferungen und Mitwirkungspflichten des Auftraggebers.

Ein gutes Pflichtenheft ist für den Auftraggeber lesbar. Wenn Sie es nicht verstehen, können Sie es nicht freigeben, und dann ist es für die Abnahme wertlos. Bestehen Sie darauf, dass jede technische Entscheidung in einem Satz begründet wird.

Beispiel: Kundenportal für einen fiktiven Hauswartungsbetrieb

Ein durchgespieltes Beispiel macht den Unterschied greifbar. Der Betrieb ist erfunden, die Situation typisch: Ein Hauswartungsunternehmen mit zwölf Mitarbeitenden betreut Liegenschaften für Verwaltungen. Aufträge kommen per Telefon und E-Mail, Rapporte werden auf Papier geschrieben und abends abgetippt, Verwaltungen fragen ständig nach dem Stand.

Auszug aus dem Lastenheft:

• Ziel: Verwaltungen sehen den Stand ihrer Aufträge selbst, ohne anzurufen. Rapporte sind am Tag des Einsatzes verfügbar.
• Nutzergruppen: Liegenschaftsverwaltungen (Auftrag erteilen, Stand sehen, Rapport abrufen), Mitarbeitende vor Ort (Auftrag sehen, Rapport mit Fotos erfassen), Büro (Aufträge zuteilen, abrechnen).
• Kernablauf: Verwaltung meldet Auftrag → Büro teilt zu → Mitarbeiter erfasst Rapport mit Fotos vor Ort → Verwaltung sieht Rapport im Portal.
• Muss: Auftrag melden, Status sehen, Rapport mit Fotos. Soll: Benachrichtigung bei Statuswechsel. Kann: Rechnungen im Portal.
• Abgrenzung: keine Lohnbuchhaltung, keine Lagerverwaltung, keine eigene App im Store in Version 1.

Antwort im Pflichtenheft (Auszug):

• Web-App, auf dem Handy installierbar, damit Mitarbeitende den Rapport vor Ort erfassen können.
• Login pro Verwaltung; jede Verwaltung sieht nur ihre Liegenschaften.
• Fotos werden beim Upload verkleinert und pro Auftrag gespeichert, Daten in einem Rechenzentrum in der Schweiz.
• Statuswechsel lösen eine E-Mail an die Verwaltung aus; Push für das Büro bei neuen Aufträgen.
• Abnahme: Ein Auftrag läuft mit einer Testverwaltung vollständig durch, inklusive Rapport mit drei Fotos.

Bemerkenswert ist, was im Lastenheft fehlt: Es steht kein Wort über Programmiersprachen, Farben oder Menüs. Und trotzdem kann jeder Anbieter auf dieser Grundlage eine vergleichbare Offerte machen. Wie ein solches Portal in der Praxis aussieht, beschreibt unser Artikel zum Kundenportal für KMU.

Wann für ein MVP weniger mehr ist

Das klassische Lastenheft stammt aus einer Welt, in der Software einmal gebaut und dann jahrelang betrieben wurde. Für ein neues digitales Produkt, dessen Erfolg noch nicht feststeht, ist dieser Ansatz oft zu schwer. Jede Anforderung, die vor dem ersten Nutzertest geschrieben wird, ist eine Annahme. Und Annahmen sind am günstigsten, solange sie auf einer Seite stehen, nicht in vierzig.

Für ein MVP empfehlen wir deshalb eine verkürzte Form, die auf zwei bis fünf Seiten passt:

Das ist kein Freibrief für Ungenauigkeit. Der Kernablauf muss präzise beschrieben sein, sonst lässt sich der Umfang nicht schätzen. Aber alles, was erst nach dem ersten Test entschieden werden kann, gehört in die Abgrenzung statt in die Anforderungen. Wie sich ein solcher Kernablauf in einzelne Anforderungen zerlegen lässt, die Entwickler und Auftraggeber gleich verstehen, zeigt unser Artikel zu User Stories.

Das Pflichtenheft gemeinsam erarbeiten

In kleineren Projekten ist die strikte Trennung zwischen Lastenheft und Pflichtenheft selten sinnvoll. Wirksamer ist eine kurze, gemeinsame Anforderungsphase, die oft Discovery-Phase genannt wird. Darin klären Auftraggeber und Umsetzer in wenigen Workshops den Kernablauf, die Nutzergruppen und die Grenzen. Das Ergebnis ist ein Dokument, das beide Rollen erfüllt: Es sagt, was erreicht werden soll, und es sagt, wie.

Fragen, die im Lastenheft offen bleiben würden, werden so im Gespräch geklärt. Technische Möglichkeiten, die der Auftraggeber nicht kennt, kommen früh auf den Tisch. Und die Offerte am Ende beruht auf einem gemeinsamen Verständnis statt auf zwei Interpretationen desselben Dokuments.

Bei DLM Digital beginnt jedes Softwareprojekt mit genau dieser Klärung. Für individuelle Software halten wir das Ergebnis schriftlich fest, bevor eine Zeile Code entsteht. Für ein neues Produkt zielen wir auf einen Kernablauf, der sich als Prototyp oder MVP ab CHF 10'000 bauen und an echten Nutzern prüfen lässt; der Ablauf ist auf der Seite Prototyp und Validierung beschrieben. Welche Faktoren den Preis eines grösseren Vorhabens bestimmen, erklärt die Seite Software-Kosten in der Schweiz; ob Festpreis oder Abrechnung nach Aufwand besser passt, unser Artikel Festpreis oder Aufwand?.

Checkliste vor dem Versand

Bevor Sie ein Lastenheft an Anbieter schicken, prüfen Sie es mit diesen Fragen:

• Ist jedes Ziel so formuliert, dass sich später prüfen lässt, ob es erreicht wurde?
• Ist der Kernablauf als Folge von Schritten beschrieben, von Anfang bis Ende?
• Ist jede Anforderung mit «muss», «soll» oder «kann» priorisiert?
• Stehen Datenschutz und Speicherort der Daten drin?
• Gibt es eine Abgrenzung mit mindestens fünf Punkten?
• Ist ein Budgetrahmen genannt? Ohne ihn schätzt jeder Anbieter einen anderen Umfang.
• Würde eine Person ausserhalb Ihres Betriebs verstehen, worum es geht?

Fazit

Lastenheft und Pflichtenheft sind kein Selbstzweck. Sie existieren, damit Auftraggeber und Umsetzer dasselbe meinen, wenn sie über ein Projekt sprechen. Für ein grösseres, klar umrissenes Vorhaben lohnt sich der saubere Aufbau mit allen Kapiteln. Für ein neues Produkt ist ein präzise beschriebener Kernablauf mit klarer Abgrenzung der bessere Start, weil er schneller zu einem Test mit echten Nutzern führt und damit zu Anforderungen, die nicht mehr auf Annahmen beruhen.