Inhalt6
Das Lastenheft hat einen schlechten Ruf, und oft zu Recht: ein langes Dokument, einmal geschrieben, das niemand wieder liest und das Funktionen statt Bedürfnisse beschreibt. Dabei entscheidet gerade dieses Dokument, ob sich drei Angebote vergleichen lassen, ob das Projekt sein Budget hält und ob man bei der Lieferung sagen kann, dass es fertig ist. Was zählt, ist nicht seine Länge, sondern was es zu entscheiden erlaubt.
Kurz gesagt
- Ein nützliches Lastenheft dient drei Dingen: Angebote vergleichen, den ersten Tag festlegen, wissen, wann es fertig ist.
- Es beschreibt Nutzungen und Ergebnisse, keine Funktionsliste und keine ohne Grund vorgegebenen technischen Entscheidungen.
- Sieben Elemente zählen: die Nutzer, der erste Tag, die Daten und Rechte, die Integrationen, die Rahmenbedingungen, das Eigentum, der Betrieb.
- Die Pflichten (personenbezogene Daten, Kontolöschung, Barrierefreiheit) werden von Anfang an hineingeschrieben, wenn sie am wenigsten kosten.
- Ein klickbarer Prototyp ergänzt es: Er zeigt, was Worte schlecht beschreiben.
Wozu ein Lastenheft dient
Ein Lastenheft ist keine Formalität vor der eigentlichen Arbeit. Es leistet drei Dienste, die man während des ganzen Projekts misst.
- Angebote vergleichen. Drei Dienstleister, die dasselbe Dokument lesen, kalkulieren dasselbe. Ohne es kalkuliert jeder seine eigene Vorstellung des Projekts, und der Preisunterschied sagt nichts aus.
- Den ersten Tag festlegen. Überschreitungen entstehen oft durch unterwegs hinzugefügte Funktionen. Ein schriftlich festgelegter Umfang erlaubt es, ohne Konflikt „ja, in der nächsten Version“ zu sagen.
- Wissen, wann es fertig ist. Schriftliche Abnahmekriterien („ein Techniker erfasst einen Einsatz mit drei Fotos in weniger als einer Minute“) machen aus der Lieferung eine Prüfung statt einer Debatte.
Vom Bedarf zum Angebot
- Der Bedarf
Der zu vereinfachende Handgriff, und für wen.
- Der Prototyp
Einige Bildschirme, mit echten Nutzern getestet.
- Das Lastenheft
Was bestätigt wurde, schriftlich festgehalten und abgegrenzt.
- Das Angebot
Jede Entscheidung einzeln beziffert, Betrieb inbegriffen.
Die sieben Elemente, die zählen
1. Wer sie nutzt, und wofür
Die Nutzer, nach Rolle benannt (der Techniker, der Kunde, die Buchhalterin), und für jeden die zwei oder drei Handgriffe, die er ausführen können muss. Ein in einem Satz beschriebener Ablauf („der Kunde lädt ein fehlendes Dokument von seinem Smartphone hoch und erhält eine Bestätigung“) ist mehr wert als eine Liste von vierzig Funktionen.
2. Der erste Tag, und was warten muss
Die kurze Liste dessen, was die App beim Start kann, und die längere Liste dessen, was danach kommt. Diese Entscheidung wiegt am schwersten beim Preis einer App.
Aus der Praxis
Challenge Us: ein Bedarf in einem Satz, am nächsten Tag online
Der Bedarf von Challenge Us, einer App für Gruppenherausforderungen, die wir entwickelt haben, passte in einen Satz: sich in der Gruppe ein Ziel setzen, seinen Tag erfassen, den der anderen live sehen, ohne komplizierte Registrierung. Am 1. September 2026 abgegrenzt, lief ihre erste Version am 2. September im Browser. Die Einzelheiten stehen in der Fallstudie Challenge Us.
3. Die Daten, und wer was sieht
Welche Informationen die App speichert, woher sie kommen und was jede Rolle lesen und ändern darf. Das ist die Grundlage der Sicherheit einer App, und es ermöglicht ein Kundenportal, in dem jeder nur seine eigenen Vorgänge sieht.
4. Die anzubindende Software
Das CRM, das ERP, das Rechnungswerkzeug: für jedes, was in welche Richtung fließt und ob es eine dokumentierte Programmierschnittstelle hat. Das ist oft die unsicherste Zeile eines Angebots; ein gutes Lastenheft erlaubt es dem Dienstleister, das offen zu sagen.
5. Die Nutzungsbedingungen
Die realen Bedingungen: Firmen- oder Privat-Smartphones, fehlendes Netz an manchen Standorten (siehe die Offline-App), Sprachen, erwartete Benachrichtigungen (siehe die Push-Benachrichtigungen), Zahlungen (siehe das Abonnement), KI-Funktionen (siehe KI in einer App). Und der Vertriebsweg: Browser, Stores oder private Verteilung, die PWA oder native App vergleicht.
6. Das Eigentum
Der Code, die Datenbank, die Entwicklerkonten, das Hosting und die Domain auf Ihren Namen, und eine schriftliche Rechteübertragung. So vermeiden Sie, eines Tages eine von ihrem Dienstleister verlassene App übernehmen zu müssen, und das erklärt unter dem eigenen Entwicklerkonto veröffentlichen.
7. Der Betrieb nach dem Start
Wer überwacht, wer korrigiert, in welcher Frist, und die monatlichen Kosten Posten für Posten: Hosting, Datenbank, E-Mails, Store-Konten, vorgeschriebene Updates. Die Einzelheiten stehen im Wartungsbudget einer App.
Die Pflichten, die von Anfang an hineingehören
Manche Anforderungen kosten am Anfang wenig und im Nachhinein viel. Sie gehören ins Lastenheft.
- Datenschutz durch Technikgestaltung. Artikel 25 der DSGVO verlangt, den Datenschutz bei der Gestaltung der Verarbeitung umzusetzen und standardmäßig nur die für jeden Zweck erforderlichen Daten zu verarbeiten, laut dem von der CNIL veröffentlichten Text. Eine Angabe, die man nicht erhebt, muss man nicht schützen.
- Die Kontolöschung. Die Prüfrichtlinien von Apple sind klar: Eine App, die das Anlegen eines Kontos ermöglicht, muss auch dessen Löschung in der App ermöglichen, laut Regel 5.1.1.
- Die Barrierefreiheit. Seit dem 28. Juni 2025 gilt die europäische Barrierefreiheitsrichtlinie für bestimmte Dienstleistungen für Verbraucher, darunter Online-Handel und Bankdienstleistungen. Auch wenn sie Sie nicht betrifft, dient eine für alle lesbare App auch Ihren eiligen Nutzern, in praller Sonne oder einhändig.
Das Wichtigste
Ins Lastenheft geschrieben, lassen sich diese Pflichten beziffern und testen wie alles andere. Erst bei der Veröffentlichung entdeckt, verzögern sie den Start.
Was nicht in ein Lastenheft gehört
Was dem Projekt hilft
In einem Satz beschriebene Abläufe, mit ihrem Nutzer
Ein kurzer erster Tag und die Liste dessen, was warten muss
Prüfbare Abnahmekriterien
Was es belastet
Eine Wunschliste ohne Prioritäten
Technische Vorgaben ohne fachlichen Grund
Aus einer Vorlage kopierte Seiten, die nicht von Ihrem Geschäft sprechen
Eine Technologie vorzugeben, ist nicht verboten, wenn es einen Grund gibt: Ihre Teams pflegen diese Sprache bereits, Ihre IT-Abteilung schreibt ein Hosting vor. Ohne Grund ist es besser, das erwartete Ergebnis zu beschreiben, den Dienstleister vorschlagen zu lassen und dann die Vorschläge zu vergleichen. Wenn ein Werkzeug ohne Entwickler genügen kann, zeigt das Lastenheft auch das: Darum geht es in Low-Code oder Code.
Wo Sie anfangen
Schreiben Sie zuerst auf einer Seite die Nutzer und ihre Handgriffe auf, dann den ersten Tag. Lassen Sie diese Handgriffe auf einem klickbaren Prototyp testen, bevor Sie den Rest ergänzen: Der Prototyp streicht unnötige Funktionen und bringt andere zum Vorschein. Wenn Sie noch zwischen Entwickeln und Kaufen schwanken, füllt sich das Raster Maßanfertigung oder Standardwerkzeug mit denselben Informationen. Für eine App im Außendienst gehen Sie von dem aus, was sie für Ihre Teams ändert; für das Backend von Supabase, Firebase oder eigener Server. Und wenn die Idee ist, alles mit einer KI zu generieren, sagt Vibe Coding, was noch von Menschen zu entscheiden bleibt.
Häufige Fragen
Wie viele Seiten sollte ein Lastenheft für eine App haben?
Es gibt keine richtige Länge. Für eine erste Version genügen oft einige Seiten, wenn sie die Nutzer, ihre Handgriffe, den ersten Tag, die Daten und Rechte, die Integrationen und das Eigentum beschreiben. Ein langes Dokument, das Funktionen ohne Priorität auflistet, hilft weniger als ein kurzes, das entscheidet.
Wer sollte das Lastenheft schreiben?
Das Unternehmen, das die App in Auftrag gibt, kennt den Bedarf, die Nutzer und die Rahmenbedingungen: Es trägt den Inhalt. Ein Dienstleister kann helfen, es zu strukturieren und zu ergänzen, oft in einer Konzeptionsphase. Entscheidend ist, dass die endgültige Fassung von denen bestätigt wird, die die App nutzen werden.
Braucht man für eine kleine App ein Lastenheft?
Ja, auch wenn es nur eine Seite ist. Ohne es lassen sich zwei Angebote nicht vergleichen, und man weiß nicht, wann die App fertig ist. Für eine kleine App beschränkt es sich auf die Nutzer, die Handgriffe des ersten Tages, die Daten und das Eigentum an Code und Konten.
Kann sich das Lastenheft während des Projekts ändern?
Ja, und das ist normal: Die ersten Rückmeldungen der Nutzer verschieben die Prioritäten. Wichtig ist, dass jede Änderung schriftlich festgehalten, beziffert und angenommen wird, bevor sie entwickelt wird. Der erste Tag bleibt kurz, und was hinzukommt, wandert in die nächste Version.
Quellen
- CNIL, DSGVO, Kapitel 4 (neuer Tab)cnil.fr
- App-Store-Prüfrichtlinien, Apple (neuer Tab)developer.apple.com
- Richtlinie (EU) 2019/882, EUR-Lex (neuer Tab)eur-lex.europa.eu
Jim · Gründer von Brain Plus AI
Ebenfalls lesenswert zu web- und mobile-apps
Auswählen und kalkulieren6 Min. Der Leitfaden zum Thema
Was kostet eine App: was den Preis bestimmt
Eine Preisspanne sagt nichts über Ihr Projekt: Was das Angebot für eine App verändert, sind einige präzise Entscheidungen, dazu monatliche Betriebskosten, die separat zu beziffern sind. Hier sind sie.
Auswählen und kalkulieren6 Min.
Business-App: Individualentwicklung oder Standardsoftware?
Eine Standardsoftware ist günstiger, solange Ihre Arbeitsweise in ihre Raster passt. Hier sind die Anzeichen, die für eine Individualentwicklung sprechen, und der Mittelweg, den man oft vergisst.
Verstehen7 Min.
Cyber Resilience Act: eine Schwachstelle binnen 24 Stunden melden
Seit dem 11. September 2026 muss ein Hersteller von Software oder vernetzten Geräten, die in Europa verkauft werden, ausgenutzte Schwachstellen und schwerwiegende Vorfälle binnen 24 Stunden melden. Wer betroffen ist, was zu melden ist und was diese Pflicht einem Unternehmen bringt, das Anwendungen entwickeln lässt oder kauft.