Lastenheft für die App-Entwicklung: Anforderungen richtig definieren

Wer eine App entwickeln lässt, ohne die Anforderungen sauber zu definieren, bezahlt doppelt: erst für Missverständnisse, dann für Nacharbeit. Ein gutes Lastenheft ist das günstigste Risikomanagement im gesamten Projekt. Dieser Artikel zeigt, was in ein Lastenheft für die App-Entwicklung gehört, wie Sie Anforderungen präzise formulieren und warum das auch in agilen Projekten funktioniert.

Ein Beispiel, das so oder ähnlich ständig vorkommt: Ein mittelständischer Energieversorger möchte eine Service-App für seine Kunden, mit Zählerstandserfassung, Rechnungsübersicht und Tarifwechsel. Die Anfrage an drei Agenturen besteht aus zwei Absätzen E-Mail-Text. Die Angebote kommen zurück: 30.000 Euro, 95.000 Euro, 180.000 Euro. Die Spanne entsteht nicht, weil die Anbieter so unterschiedlich kalkulieren. Sie entsteht, weil jeder Anbieter etwas anderes anbietet. Der erste plant ein schlankes MVP mit Weboberfläche im App-Rahmen. Der zweite eine Cross-Platform-App, die an die bestehende Abrechnungssoftware angebunden wird. Der dritte zwei native Apps samt neuem Backend und Admin-Portal. Alle drei Angebote sind seriös; vergleichbar ist keines davon. Genau dieses Problem löst ein Lastenheft.

Warum ohne Lastenheft kein Angebot vergleichbar ist

Das Lastenheft beschreibt die Gesamtheit der Forderungen des Auftraggebers an die Lieferungen und Leistungen des Auftragnehmers; so definiert es die Projektmanagement-Norm DIN 69901-5. Ältere Fachartikel zitieren an dieser Stelle noch die DIN 69905 von 1997, deren Begriffsdefinitionen sind inzwischen in der DIN 69901-5 aufgegangen. Entscheidend ist die Rollenverteilung: Das Lastenheft wird vom Auftraggeber erstellt. Dritte können bei der Erstellung mitwirken, im Einzelfall sogar der spätere Auftragnehmer; die inhaltliche Verantwortung bleibt aber beim Auftraggeber.

Im Projektablauf steht das Lastenheft ganz am Anfang, noch vor der eigentlichen Entwicklung. Es erfüllt drei Funktionen zugleich. Erstens ist es die Grundlage für Ausschreibung und Angebotsvergleich: Nur wenn alle Anbieter denselben Anforderungskatalog beantworten, lassen sich Angebote nebeneinanderlegen. Zweitens ist es Vertragsgrundlage; Leistungsumfang und Abnahmekriterien lassen sich später nur einfordern, wenn sie vorher dokumentiert wurden. Drittens ist es ein Kommunikationsinstrument: Die Arbeit am Lastenheft zwingt die Beteiligten im eigenen Haus, sich zu einigen, was die App eigentlich leisten soll. Viele Widersprüche zwischen Fachbereich, IT und Geschäftsführung tauchen hier zum ersten Mal auf, und zwar zum günstigsten Zeitpunkt, an dem man sie klären kann. Dieser Klärungseffekt wirkt auch nach innen: Wer Anforderungen schriftlich präzisieren muss, durchdenkt sie zwangsläufig, entdeckt Lücken und stillschweigende Annahmen im eigenen Bild der App und versteht das eigene Vorhaben am Ende deutlich besser, als es zwei Absätze E-Mail-Text je erzwingen würden.

Lastenheft vs Pflichtenheft: Was ist der Unterschied?

Die beiden Begriffe werden im Alltag oft vermischt, dabei ist die Trennung einfach. Das Lastenheft beantwortet die Fragen „was“ und „wofür“ aus Sicht des Auftraggebers. Das Pflichtenheft beantwortet „wie“ und „womit“: Es enthält die vom Auftragnehmer erarbeiteten Realisierungsvorgaben auf Basis des Lastenhefts und sollte vom Auftraggeber abgenommen werden, bevor die Umsetzung beginnt. Für die Erstellung beider Dokumente gibt es mit der VDI-Richtlinie 2519 Blatt 1 eine branchenübergreifende Orientierung. In der Softwareentwicklung war lange die IEEE-830-Spezifikation (Software Requirements Specification) verbreitet, die allerdings nicht zwischen Lasten- und Pflichtenheft trennt; ihr Nachfolger ist die ISO/IEC/IEEE 29148, aktuell in der Fassung von 2018.

Aus dieser Trennung folgt die wichtigste Regel für Ihr Lastenheft: Beschreiben Sie Anforderungen, keine Lösungen. Detailvorgaben zur technischen Umsetzung engen den Lösungsraum ein, bevor die Lösungssuche begonnen hat. „Die App muss mit React Native gebaut werden“ ist eine Lösungsvorgabe. Die eigentliche Anforderung dahinter lautet meist: „Die App muss auf iOS und Android erscheinen, und Budget wie Team erlauben nur eine gemeinsame Codebasis.“ Formuliert man es so, kann der Anbieter React Native, Flutter oder Kotlin Multiplatform vorschlagen und die Wahl fachlich begründen. Ob eine Technologievorgabe trotzdem sinnvoll ist, etwa weil Ihr Team später selbst weiterentwickeln soll, ist eine bewusste Entscheidung; sie gehört dann mit Begründung in die Richtlinien für Technologieentscheidungen, nicht versteckt in die Funktionsbeschreibung.

Was in ein Lastenheft für App-Entwicklung gehört

Als Grundgerüst hat sich der Gliederungsvorschlag von Helmut Balzert bewährt, der sich auf das Wesentliche konzentriert: Zielbestimmung, Produkteinsatz, Produktfunktionen, Produktdaten, Produktleistungen, Qualitätsanforderungen und Ergänzungen. Für ein App-Projekt übersetzt sich das so:

Zielbestimmung: Welche messbaren Ziele soll die App erreichen? Beim fiktiven Energieversorger etwa: 30 Prozent der Zählerstände werden nach zwölf Monaten über die App gemeldet, die Anrufe im Service-Center sinken entsprechend. Solche Ziele entscheiden später darüber, welche Features ins MVP gehören und welche warten können.

Produkteinsatz und Zielgruppen: Wer nutzt die App, in welchem Kontext, auf welchen Geräten? Hier gehören die Zielplattformen hinein (iOS, Android, gegebenenfalls Tablet oder Web) samt der ältesten zu unterstützenden Betriebssystemversionen; beides hat direkte Auswirkungen auf Aufwand und Architektur.

Produktfunktionen: Die Kernfunktionen aus Nutzersicht, ohne Detailtiefe. Registrierung und Login, Zählerstandserfassung mit Kamera, Rechnungsarchiv, Push-Benachrichtigungen, Tarifwechsel. Sekundäre Funktionen und Sonderfälle gehören nicht hierher; sie entstehen später in der Feinspezifikation. Wenn die App ihre Funktionen auch Sprachassistenten und System-KI anbieten soll, lohnt ein Blick in unseren Artikel App Intents.

Produktdaten: Welche Daten müssen dauerhaft gespeichert werden, und wo? Kundendaten, Verträge, Zählerstände liegen üblicherweise im Backend, nicht im Gerät. Personenbezogene Daten sollten Sie hier bereits kennzeichnen; das spart in der Datenschutzabstimmung später Wochen.

Produktleistungen: Anforderungen an Zeit, Datenumfang und Genauigkeit einzelner Hauptfunktionen, zum Beispiel Antwortzeiten der Schnittstellen oder ein Mengengerüst wie 50.000 registrierte Nutzer und 5.000 gleichzeitige Zugriffe am Monatsende, wenn die Abrechnungen kommen.

Qualitätsanforderungen und Ergänzungen: Zuverlässigkeit, Benutzbarkeit, Effizienz sowie Vorgaben wie Corporate Design, vorhandene Styleguides oder Mockups.

Für App-Projekte kommen Punkte hinzu, die klassische Vorlagen aus der Ära der Desktop-Software nicht abdecken. Dazu gehört erstens die Systemlandschaft: An welche bestehenden Systeme muss die App angebunden werden, über welche Schnittstellen, und wer verantwortet deren Anpassung? In der Praxis entscheidet dieser Punkt häufiger über Budget und Zeitplan als die App selbst. Zweitens der Betrieb: Hosting, Wartung, Monitoring und der Prozess für Updates, denn eine App ist nach dem Launch nicht fertig, sondern erst im Markt. Drittens die Store-Realität: Apple und Google prüfen jede Einreichung gegen ihre Review-Richtlinien; deren Vorgaben, etwa zu Login-Verfahren oder zu In-App-Käufen bei digitalen Gütern, sollten nicht erst beim Release überraschen. Und viertens die Projektrahmenbedingungen: Zeitplan mit Meilensteinen, Budgetrahmen, Ansprechpartner, Testverfahren und Abnahmekriterien.

Nicht-funktionale Anforderungen: der unterschätzte Teil

Die meisten Lastenhefte beschreiben Funktionen ausführlich und Qualitäten gar nicht. Dabei entscheiden die nicht-funktionalen Anforderungen darüber, ob sich die App gut anfühlt und ob sie rechtssicher betrieben werden kann. Vier Bereiche verdienen besondere Aufmerksamkeit.

Performance und Offline-Fähigkeit: Muss die App ohne Netzverbindung nutzbar sein, und wenn ja, welche Funktionen? Eine Zählerstandserfassung im Keller ohne Empfang ist ein realistisches Szenario. Offline-Fähigkeit nachträglich einzubauen ist teuer, weil sie die Datenarchitektur betrifft.

Sicherheit und Datenschutz: Die DSGVO verlangt Datensparsamkeit und klare Verantwortlichkeiten. Ins Lastenheft gehören der gewünschte Hosting-Standort, Anforderungen an Verschlüsselung und Authentifizierung sowie der Hinweis, welche Daten besonders schutzbedürftig sind.

Barrierefreiheit: Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz (BFSG), die deutsche Umsetzung des European Accessibility Act. Es verpflichtet unter anderem Apps im elektronischen Geschäftsverkehr, also etwa Shops, Buchungsfunktionen, Bankdienste und Apps im Personenverkehr, zur Barrierefreiheit; ausgenommen sind bei Dienstleistungen nur Kleinstunternehmen mit weniger als zehn Beschäftigten und höchstens zwei Millionen Euro Jahresumsatz. Als technische Orientierung dienen in der Praxis die Web Content Accessibility Guidelines (WCAG). Wer diese Anforderung erst nach dem Release entdeckt, baut teuer um; im Lastenheft kostet sie einen Absatz.

Skalierbarkeit und Wartbarkeit: Wächst die Nutzerzahl planbar oder in Spitzen? Soll Ihr eigenes Team später weiterentwickeln können? Beides beeinflusst Architekturentscheidungen, die sich später kaum revidieren lassen.

Anforderungen formulieren, die tragen

Ein Lastenheft ist nur so gut wie seine einzelnen Anforderungen. Drei Handwerksregeln machen den Unterschied.

Erstens: messbar statt vage. Jede Anforderung sollte so formuliert sein, dass sich objektiv prüfen lässt, ob sie erfüllt ist.

Vage:     „Die App muss schnell starten."
Messbar:  „Der Kaltstart bis zur bedienbaren Startseite dauert auf einem
           drei Jahre alten Mittelklasse-Gerät höchstens zwei Sekunden."

Zweitens: priorisieren. Nicht jede Anforderung ist gleich wichtig, und ein Lastenheft, in dem alles „Muss“ ist, ist keines. Bewährt hat sich die Unterscheidung nach MoSCoW (Must have, Should have, Could have, Won’t have). Sie schafft die Grundlage für ein sinnvolles MVP und verhindert, dass Nice-to-have-Features das Budget der Kernfunktionen aufzehren.

Drittens: nachverfolgbar. Geben Sie jeder Anforderung eine eindeutige ID. Diese Traceability zahlt sich doppelt aus: Im Angebot kann der Anbieter je Anforderung Aufwand und Lösungsweg angeben, und im Test lässt sich jede Abnahme auf eine Anforderung zurückführen. Abnahmekriterien lassen sich dafür präzise als Szenarien formulieren, etwa im Gherkin-Format:

Szenario: Zählerstand ohne Netzverbindung erfassen
  Angenommen der Nutzer hat keine Internetverbindung
  Wenn er einen Zählerstand speichert
  Dann wird der Wert lokal gespeichert
  Und bei der nächsten Verbindung automatisch übertragen

Dazu gehört ein geregelter Umgang mit Änderungen: Neue Anforderungen werden dokumentiert, bewertet und bewusst aufgenommen oder abgelehnt. Ohne diesen Prozess wächst der Projektumfang unbemerkt; das als Scope Creep bekannte Phänomen ist einer der häufigsten Gründe für gesprengte Budgets.

In sechs Schritten zum Lastenheft

Für die Erstellung hat sich ein Vorgehen in sechs Schritten bewährt:

1. Stakeholder sammeln: Holen Sie alle Beteiligten an einen Tisch: Fachbereich, IT, Support, Marketing, Datenschutz. Sammeln Sie Anforderungen zunächst ungefiltert.
2. Strukturieren: Ordnen Sie die Sammlung entlang einer Gliederung, etwa der oben beschriebenen nach Balzert, ergänzt um die App-spezifischen Punkte.
3. Priorisieren: Trennen Sie Must-haves von Nice-to-haves, bevor über Budgets gesprochen wird.
4. Präzise formulieren: Messbare Kriterien, eindeutige IDs, klare Sprache ohne interpretierbare Begriffe wie „nutzerfreundlich“ oder „performant“.
5. Review: Lassen Sie das Dokument von allen Stakeholdern prüfen und freigeben. Ein externer Entwicklungspartner kann hier bereits Machbarkeit und Vollständigkeit spiegeln.
6. Leben lassen: Behandeln Sie das Lastenheft als lebendes Dokument mit Versionsständen und Änderungshistorie, nicht als einmal beschlossene Steintafel.

Zum Umfang eine ehrliche Ansage: Für eine typische Business-App sind zehn bis zwanzig konzentrierte Seiten mehr wert als hundert, die niemand liest. Wireframes und Skizzen im Anhang ersetzen viele Seiten Text, denn über ein Bild wird schneller gestritten und schneller Einigkeit erzielt als über einen Absatz.

Lastenheft mit KI erstellen

Auch KI-Assistenten können die Erstellung sinnvoll unterstützen, wenn Sie sie richtig einsetzen. Drei Einsatzmuster haben sich bewährt. Beim Brainstorming lassen Sie sich zu Ihrer App-Idee Anforderungen, Nutzerrollen und Sonderfälle vorschlagen, an die Ihr Team noch nicht gedacht hat; die Ergebnisse sind Rohmaterial für Schritt 1, keine fertigen Anforderungen. Bei der Qualitätsprüfung geben Sie Ihren Entwurf hinein und lassen ihn gezielt kritisieren: Welche Anforderungen sind vage oder nicht messbar formuliert, wo verstecken sich Lösungsvorgaben, welche Punkte widersprechen einander? Und in der Anbieterrolle lässt sich simulieren, welche Rückfragen ein Entwicklungspartner zu Ihrem Lastenheft stellen würde; jede dieser Fragen markiert eine Lücke im Dokument. Zwei Regeln gehören dazu: Nutzen Sie für vertrauliche Projektinhalte nur Dienste, deren Datenschutz- und Vertraulichkeitszusagen Ihr Unternehmen geprüft hat, und behandeln Sie jeden KI-Vorschlag als Entwurf, den ein Mensch fachlich bewertet. Die Verantwortung für das Lastenheft bleibt beim Auftraggeber.

Lastenheft und agile Entwicklung: kein Widerspruch

Gegen das Lastenheft wird oft eingewendet, es stamme aus der Wasserfall-Welt: Das Dokument ist fertig, die Unterschriften sind trocken, und trotzdem passt die Lösung am Ende nicht zu den tatsächlichen Bedürfnissen. Der Einwand ist ernst zu nehmen. In dynamischen Projektumfeldern stoßen vollständig vorab spezifizierte Anforderungskataloge an Grenzen; Änderungen führen dann zu Verzögerungen, Mehrkosten oder Produkten, die am Bedarf vorbeigehen. Agile Vorgehensweisen setzen deshalb auf Anforderungen, die iterativ und inkrementell über den Projektverlauf entstehen und als User Stories verfeinert werden.

Daraus folgt aber nicht, dass Sie auf ein Lastenheft verzichten sollten; es folgt nur, dass sein Zuschnitt sich ändert. Auch ein agiles Projekt braucht vor dem ersten Sprint Antworten auf die stabilen Fragen: Welche Ziele verfolgt die App, für wen, mit welchen Muss-Funktionen, auf welchen Plattformen, in welcher Systemlandschaft, mit welchem Budgetrahmen und welchen rechtlichen Anforderungen? Ein schlankes Lastenheft beantwortet genau diese Fragen und lässt das Wie offen. Aus seinen priorisierten Anforderungen entsteht das initiale Product Backlog: Muss-Anforderungen werden zu Epics, Epics werden sprintweise zu User Stories verfeinert. Das Lastenheft bleibt dabei der stabile Rahmen, an dem sich Änderungen messen lassen: Was dem Ziel dient, kommt ins Backlog; was das Ziel verschiebt, ist eine bewusste Entscheidung des Auftraggebers und keine stille Drift. Nur bei stark explorativen Produkten, deren Zielbild sich selbst noch sucht, wäre ein detailliertes Lastenheft verfrüht; dort genügen Vision, Leitplanken und ein Budget für validierende Experimente.

Fazit

Das Lastenheft ist kein Bürokratie-Artefakt aus der Vergangenheit, sondern das günstigste Risikomanagement, das ein App-Projekt kennt. Es macht Angebote vergleichbar, Verträge belastbar und interne Zielkonflikte sichtbar, bevor sie Geld kosten. Wer die eigenen Anforderungen nicht beschreiben kann, delegiert die wichtigsten Produktentscheidungen an die Interpretation des Anbieters; im Zweifel an die des billigsten. Zehn präzise Seiten mit messbaren, priorisierten und nachverfolgbaren Anforderungen reichen dafür aus, und sie funktionieren als Fundament klassischer wie agiler Projekte gleichermaßen.

Sie planen eine App und möchten Ihre Anforderungen auf ein belastbares Fundament stellen? Johnny Bytes entwickelt Apps, Web-Anwendungen und Backends aus einer Hand und unterstützt Sie bereits in der Anforderungsphase: von der Strukturierung Ihres Lastenhefts über die technische Machbarkeitsbewertung bis zum priorisierten Backlog. Sprechen Sie uns an.

Quellen

• Lastenheft: Anforderungen in der Softwareentwicklung richtig definieren (entwickler.de, Dr. Veikko Krypczyk)
• Lastenheft für App Entwicklung (deineseite.at)
• Lastenheft (Wikipedia, mit Definition nach DIN 69901-5)
• Pflichtenheft (Wikipedia)
• Von Lastenheft zur User Story: Requirements Engineering im Wandel (Rexult)
• Barrierefreiheitsstärkungsgesetz gilt ab 28. Juni 2025 (Wettbewerbszentrale)
• ISO/IEC/IEEE 29148:2018 Requirements Engineering (iso.org)