Lastenheft für Software erstellen: Vorlage fürs MVP

Zwei Entwickler lesen denselben Satz: „Nutzer sollen Termine buchen können.” Der eine baut in 20 Stunden ein Formular mit Datumsauswahl. Die andere kalkuliert 150 Stunden, weil sie an Zeitzonen, Doppelbuchungen, Stornofristen und wiederkehrende Termine denkt. Beide haben den Satz richtig verstanden. Das Problem ist der Satz.

Ein Lastenheft ist der Versuch, solche Sätze zu vermeiden. Es kostet dich zwei, drei Tage Arbeit. Ohne es kostet dich jedes Missverständnis Stunden zum vollen Satz.

Lastenheft und Pflichtenheft

Die Begriffe sind in der DIN 69901-5 zum Projektmanagement festgelegt. Das Lastenheft enthält die Anforderungen des Auftraggebers an die Lieferungen und Leistungen. Das Pflichtenheft ist die Antwort des Auftragnehmers: wie er diese Anforderungen umsetzen will.

Für dich als Gründer heißt das: Du schreibst das Lastenheft. Du beschreibst das Was und Warum, nicht das Wie. „Die Datenbank soll PostgreSQL sein” gehört nur hinein, wenn es einen echten Grund gibt, etwa weil dein Mitgründer sie schon betreibt. Sonst lässt du die Technik offen und bekommst Vorschläge.

Das Lastenheft wird oft Teil des Vertrags. Bei einem Werkvertrag nach § 631 BGB schuldet der Auftragnehmer ein Ergebnis, und das Lastenheft legt fest, welches. Nach § 640 BGB folgt die Abnahme, also deine Erklärung, dass das Werk im Wesentlichen vertragsgemäß ist. Was im Lastenheft unklar bleibt, ist später schwer einzufordern.

Vorlage: neun Abschnitte für ein MVP-Lastenheft

• 1. Ausgangslage: Wer hat welches Problem, belegt mit Zahlen oder Zitaten aus Interviews.
• 2. Ziel: Was soll nach dem Launch messbar anders sein, in einem Satz.
• 3. Nutzerrollen: Wer benutzt das System, mit welchen Rechten.
• 4. User Stories: Was jede Rolle tun können muss, jeweils mit Akzeptanzkriterien.
• 5. Nichtfunktionale Anforderungen: Datenschutz, Geräte und Browser, Ladezeiten, Barrierefreiheit.
• 6. Schnittstellen: Zahlungsdienst, E-Mail, bestehende Systeme.
• 7. Abgrenzung: Was ausdrücklich nicht Teil des MVP ist.
• 8. Rahmen: Budget, Termine, Ansprechpartner, Hosting, wem Code und Zugänge gehören.
• 9. Abnahme: Wie und auf welcher Umgebung geprüft wird.

Abschnitt 1 wird gern weggelassen, weil er nach Prosa klingt. Er ist aber der Grund, warum gute Entwickler bessere Vorschläge machen. Wer versteht, dass Physiotherapiepraxen vor allem unter kurzfristigen Absagen leiden, baut eine Warteliste mit, auch wenn niemand danach gefragt hat. Die Zitate dafür hast du aus deinen Kundeninterviews.

User Stories mit Akzeptanzkriterien

Der Kern des Lastenhefts sind die Anforderungen. Bewährt hat sich die Form der User Story: „Als [Rolle] möchte ich [Handlung], damit [Nutzen].” Der Nutzen ist der wichtigste Teil. Er erlaubt dem Entwickler, eine einfachere Lösung vorzuschlagen, die denselben Zweck erfüllt.

Jede Story braucht Akzeptanzkriterien. Das sind prüfbare Bedingungen, ab wann die Story fertig ist. Ein Beispiel:

Als Patientin möchte ich einen freien Termin online buchen, damit ich nicht während der Sprechzeiten anrufen muss.

Akzeptanzkriterien: Angezeigt werden nur Termine der nächsten 28 Tage. Ein gebuchter Termin verschwindet sofort für andere. Ich erhalte innerhalb von fünf Minuten eine Bestätigung per E-Mail. Eine Stornierung ist bis 24 Stunden vorher über einen Link in der Mail möglich. Danach zeigt der Link einen Hinweis mit der Telefonnummer der Praxis.

Fünf Sätze, und plötzlich ist aus „Termine buchen” etwas geworden, das zwei Entwickler ähnlich kalkulieren. Die Randfälle stehen drin, die Grenzen auch.

Sortiere die Stories nach Priorität. Eine einfache Einteilung reicht: muss ins MVP, sollte ins MVP, später. Alles in der dritten Gruppe kommt in Abschnitt 7.

Nichtfunktionale Anforderungen nicht vergessen

Das sind die Anforderungen, die keine Funktion beschreiben, sondern Eigenschaften. Sie werden am häufigsten vergessen und sind später am teuersten nachzurüsten.

Datenschutz steht vorn. Verarbeitet die Software Gesundheitsdaten, gelten nach Art. 9 DSGVO besonders strenge Regeln. Das beeinflusst Hosting, Verschlüsselung und Zugriffskonzepte. Schreib auch hinein, wo die Daten liegen sollen, etwa „ausschließlich in Rechenzentren in der EU”.

Dann Geräte und Browser. „Funktioniert auf aktuellen Versionen von Chrome, Firefox, Safari und Edge sowie auf Smartphones ab Bildschirmbreite 360 Pixel” ist eine prüfbare Anforderung. „Responsiv” ist keine.

Barrierefreiheit ist seit dem 28. Juni 2025 für viele Angebote an Verbraucher keine Kür mehr. Seitdem gilt das Barrierefreiheitsstärkungsgesetz unter anderem für Dienstleistungen im elektronischen Geschäftsverkehr. Kleinstunternehmen, die Dienstleistungen anbieten, sind nach § 3 Abs. 3 BFSG ausgenommen, aber ob das auf dich zutrifft und wie lange, solltest du vor dem Bau klären.

Die teuersten Fehler im Lastenheft

Lösungen statt Probleme beschreiben. „Wir brauchen eine App” legt den Weg fest, bevor jemand geprüft hat, ob eine Web-Anwendung billiger und schneller wäre.

Keine Abgrenzung. Ohne Abschnitt 7 wird alles, was du im Projekt nachschiebst, zur Diskussion darüber, ob es „eigentlich schon gemeint” war.

Keine Abnahmekriterien. Dann wird die Abnahme zur Geschmacksfrage, und Geschmacksfragen enden selten gut.

Zu viel auf einmal. Wenn das Lastenheft für ein MVP länger wird als zehn Seiten, ist meist nicht das Dokument zu ausführlich, sondern das Produkt zu groß. Streich, bevor du Angebote einholst. Was die Streichliste spart, zeigt die Rechnung zu den Kosten eines MVP.

Werkvertrag oder Dienstvertrag?

Wie verbindlich das Lastenheft wird, hängt am Vertragstyp. Beim Werkvertrag nach § 631 BGB schuldet der Auftragnehmer ein fertiges Ergebnis. Er trägt das Risiko, wenn es länger dauert, und lässt sich das über einen Festpreis mit Aufschlag bezahlen. Das Lastenheft ist dann die Messlatte, an der alles hängt.

Beim Dienstvertrag nach § 611 BGB schuldet er die Arbeit, nicht den Erfolg. Abgerechnet wird nach Stunden. Das passt besser zu einem MVP, dessen Umfang sich nach den ersten Tests ändern wird, verlangt aber, dass du das Projekt eng begleitest. Hier dient das Lastenheft als gemeinsame Orientierung und als Startpunkt für die Priorisierung.

Viele Projekte mischen beides: einen Festpreis für einen klar beschriebenen ersten Meilenstein, danach Abrechnung nach Aufwand mit monatlicher Obergrenze. Welche Variante du wählst, solltest du im Lastenheft unter Rahmenbedingungen festhalten. Die vertragliche Feinarbeit gehört zu einem Anwalt.

Wer das Lastenheft schreiben sollte

Du. Nicht die Agentur, nicht ein Berater, den du dafür bezahlst. Das Lastenheft zwingt dich, Entscheidungen zu treffen, die sonst später im Projekt fallen, dann aber unter Zeitdruck und auf deine Kosten.

Hilfe holen darfst du trotzdem. Ein erfahrener Entwickler, der eine Stunde draufschaut, findet die Stellen, an denen sich Aufwand versteckt. Und ein Mitgründer mit technischem Hintergrund, falls du einen hast, sollte es mitschreiben, nicht nur abnicken.

Vom Lastenheft zum Angebot

Schick das Lastenheft an zwei bis drei Anbieter und bitte um eine Aufschlüsselung der Stunden pro User Story. So siehst du, wo die Einschätzungen auseinandergehen, und kannst nachfragen. Große Unterschiede bei einer einzelnen Story deuten fast immer auf eine Unklarheit im Text hin.

Wer schon ein No-Code-MVP betreibt, hat es leichter. Die bestehende Version ist die beste Spezifikation, und Screenshots mit Anmerkungen ersetzen viele Seiten Text.

Bei Studios wie OnlineBuilders und den meisten erfahrenen Teams ist ein gutes Lastenheft die Grundlage für ein belastbares Angebot. Ein schlechtes führt zu hohen Risikoaufschlägen oder zu Nachträgen.

Nächster Schritt: Nimm die Gliederung oben, schreib für deine drei wichtigsten Funktionen je eine User Story mit mindestens drei Akzeptanzkriterien und lass sie von jemandem lesen, der dein Projekt nicht kennt. Jede Rückfrage zeigt eine Lücke.

Häufige Fragen

Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?

Das Lastenheft schreibt der Auftraggeber: Was soll die Software leisten? Das Pflichtenheft schreibt der Auftragnehmer als Antwort darauf: Wie wird das umgesetzt? Beide Begriffe sind in der DIN 69901-5 zum Projektmanagement definiert.

Wie lang sollte ein Lastenheft für ein MVP sein?

Fünf bis zehn Seiten reichen meist. Länger wird es, wenn Schnittstellen zu anderen Systemen oder besondere rechtliche Anforderungen dazukommen. Ein Lastenheft mit 60 Seiten für ein MVP ist ein Zeichen, dass der Umfang zu groß ist.

Brauche ich ein Lastenheft, wenn ich agil entwickeln lasse?

Ja, nur in anderer Form. Auch agile Teams brauchen ein Ziel, Nutzerrollen und einen priorisierten Rückstand an User Stories. Das Lastenheft wird dann zum Startpunkt des Backlogs statt zum starren Vertragsanhang.

Gehört das Design ins Lastenheft?

Skizzen oder ein Klickdummy helfen enorm, weil sie Missverständnisse früh sichtbar machen. Das fertige visuelle Design gehört aber nicht hinein, das entsteht im Projekt.