Lastenheft App schreiben 2027: Vorlage und Beispiel

Was ein Lastenheft für eine App ist und wie es sich vom Briefing unterscheidet

Das Lastenheft ist ein Dokument, in dem steht, was die App können muss und woran Sie erkennen, dass sie fertig ist. Es lesen gleich drei Personen: Sie, die Designerin und der Entwickler. Verstehen alle drei den Text gleich, verschwindet die häufigste Ursache für Streit in Projekten: „Ich dachte, das ist enthalten.“

Verwechseln Sie drei Dokumente nicht. Das Briefing beantwortet „Wozu?“ und „Für wen?“: Ziel, Zielgruppe, Markt, Budget. Das Lastenheft beantwortet „Was genau muss funktionieren?“: Bildschirme, Aktionen, Regeln, Daten. Der Kostenvoranschlag beantwortet „Wie viel und bis wann?“ und entsteht erst auf Basis des Lastenhefts. In Deutschland ist oft auch vom Pflichtenheft die Rede: Das schreibt in der Regel der Dienstleister als Antwort auf Ihr Lastenheft und legt darin fest, wie er Ihre Anforderungen umsetzt. Für eine Website haben wir das Briefing im Artikel „Lastenheft und Briefing für die Website“ behandelt. Bei einer App kommen mehr Anforderungen hinzu: Smartphone, App-Stores, Push-Mitteilungen, Betrieb ohne Internet.

Die gute Nachricht: Sie müssen kein Lastenheft wie ein Ingenieur mit 80 Seiten schreiben. 3–6 Seiten einfacher Text nach der Vorlage unten genügen. Technische Details ergänzt der Dienstleister selbst, aber er kann nicht für Sie erfinden, was Ihr Unternehmen braucht.

Ein weiterer Nutzen: Mit einem Lastenheft erhalten Sie vergleichbare Angebote. Wenn fünf Agenturen dasselbe Dokument bewerten, lassen sich die Preise fair nebeneinanderlegen. Bewertet jede ihre eigene Version Ihrer Idee, gibt es nichts zu vergleichen.

Lastenheft App Vorlage: die 10 Abschnitte

Kopieren Sie diese Liste in ein Dokument und füllen Sie jeden Punkt aus, und sei es nur mit ein, zwei Sätzen. Ein leerer Abschnitt ist eine Frage, die Sie trotzdem klären müssen, nur später und teurer.

1. Ziel und messbares Ergebnis. Ein Satz: „Kunden buchen selbst, und 30 % der Buchungen kommen über die App.“ Ohne Zahl geht es auch, dann schreiben Sie, woran Sie den Erfolg erkennen.
2. Nutzer und Rollen. Wer nutzt die App: Kunde, Mitarbeiter, Administrator, Kurier? Jede Rolle hat eigene Bildschirme und Rechte.
3. Plattformen. iOS, Android oder beide; ob ein Tablet nötig ist; ob eine Website genügt, die sich wie eine App auf dem Telefon installieren lässt (PWA), oder ob Sie die App-Stores brauchen. Sind Sie unsicher, vergleichen Sie zuerst App, Website und PWA nach Kosten und Aufgaben.
4. Bildschirmplan. Liste aller Bildschirme mit Pfeilen dazwischen: Anmeldung, Startseite, Katalog, Detailseite, Warenkorb, Profil. Eine Handskizze zum Abfotografieren reicht.
5. Abläufe. Schritt für Schritt, was der Mensch tut: „öffnet die App, wählt eine Leistung, wählt die Uhrzeit, bezahlt, erhält eine Erinnerung“.
6. Funktionen mit Prioritäten. Drei Spalten: „ohne das kein Start“, „wäre schön“, „später“. Dieser Abschnitt ist für das Budget der wichtigste.
7. Daten und Anbindungen. Wo Nutzer und Bestellungen gespeichert werden und mit welchen Systemen die App spricht: Zahlung, CRM, Buchhaltung, Karten, E-Mail, Messenger.
8. Nichtfunktionale Anforderungen. Geschwindigkeit, Betrieb ohne Internet, Sprachen, Sicherheit, Barrierefreiheit (mehr dazu unten).
9. Veröffentlichung und Konten. Auf wessen Namen die Entwicklerkonten laufen, wer die Beschreibung für die Stores schreibt, in welchen Ländern die App erscheint.
10. Abnahme und Etappen. Wie das Ergebnis geprüft wird, wie viele Korrekturrunden es gibt und wie die Zahlung nach Etappen aufgeteilt wird.

Ergänzen Sie jeden Punkt um Beispiele von Apps, die Ihnen gefallen, und eine Zeile dazu, was genau. „Ich will es wie bei Uber“ sagt nichts, aber „Ich möchte, dass die Karte mit den Punkten aussieht wie bei Uber und die Anmeldung per Telefonnummer läuft“ sagt alles.

App Anforderungen: funktional und nichtfunktional

In einem Anforderungsdokument stehen meist zwei Arten von Einträgen. Funktionale Anforderungen beschreiben, was die App tut: „Der Nutzer kann einen Termin bis spätestens 2 Stunden vorher verschieben.“ Nichtfunktionale Anforderungen beschreiben, wie gut sie das tut: schnell, sicher, verständlich, in den gewünschten Sprachen. Gerade die zweiten werden am häufigsten vergessen, und dann wird gestritten.

Beispiel: Buchungs-App für einen Salon

Rolle „Kunde“: Registrierung per Telefonnummer mit Code per SMS. Leistungskatalog mit Preis und Dauer. Auswahl von Mitarbeiter und freier Uhrzeit. Anzahlung per Karte. Erinnerung einen Tag vorher und 2 Stunden vorher. Stornierung kostenlos bis 24 Stunden vor dem Termin. Rolle „Administrator“: Dienstplan der Mitarbeiter, Terminliste, Rückerstattungen, Versand von Aktionen.

Das ist der funktionale Teil. Dazu kommt der nichtfunktionale:

• Geschwindigkeit. Der Startbildschirm öffnet sich ohne spürbare Verzögerung auf einem durchschnittlichen, fünf Jahre alten Smartphone.
• Verbindung. Was sieht der Kunde ohne Internet: den letzten Termin oder eine Fehlermeldung? Ein vollwertiger Offline-Modus kostet extra.
• Sprachen und Währungen. Wie viele Oberflächensprachen, in welcher Währung die Preise stehen, wie Datumsangaben aussehen.
• Sicherheit und Daten. Welche personenbezogenen Daten gespeichert werden, wer sie sieht und wie ein Mensch sein Konto löscht. Für Nutzer in Ihrem Land gilt in der EU die DSGVO; die Anforderungen klären Sie bitte mit Ihrer Rechtsberatung.
• Barrierefreiheit. Große Schrift, Kontrast, Beschriftungen für Screenreader. Das ist Komfort und zugleich Anforderung einiger Märkte; in der EU gibt es dazu eigene Vorgaben.
• Geräte. Ab welcher iOS- und Android-Version die App unterstützt wird und auf welchen Bildschirmen getestet wird.

Vergessen Sie den „unsichtbaren“ Teil nicht: Die meisten Apps haben ein Admin-Panel, in dem das Team Inhalte und Bestellungen verwaltet. Im Lastenheft bekommt es einen eigenen Abschnitt, sonst ist die App am Ende fertig, aber niemand kann sie steuern.

Was ins Lastenheft zu App Store und Google Play gehört

Die Veröffentlichung ist eine eigene Etappe mit eigenen Regeln, und nicht nur wir beeinflussen sie. Deshalb sollten Sie einige Punkte schon im Lastenheft festhalten.

• Entwicklerkonten. Apple verlangt 99 US-Dollar im Jahr, Google Play einmalig 25 US-Dollar. Wir veröffentlichen die App auf Ihrem Konto, also notieren Sie, wer es anlegt und wer die Zugänge verwahrt.
• Fertige Version zur Prüfung. Nach den Regeln von Apple (Abschnitt 2.1, „App Completeness“) wird eine vollständige Version eingereicht: ohne Platzhalter und provisorische Seiten, mit funktionierenden Links und, falls es eine Anmeldung gibt, mit Demozugang für den Prüfer. Auch der Server muss in diesem Moment laufen. Im Lastenheft wird daraus ein Abnahmepunkt: „Testkonto und Beschreibung für den Prüfer liegen bereit.“
• Tests für Google Play. Für neue private Entwicklerkonten verlangt Google einen geschlossenen Test: mindestens 12 Tester, die 14 Tage in Folge angemeldet sind, erst danach wird die Veröffentlichung für alle freigegeben. Planen Sie diese zwei Wochen ein oder legen Sie ein Organisationskonto an; die aktuellen Bedingungen finden Sie in der Google-Play-Hilfe.
• Texte und Bilder für die Stores. Beschreibung, Screenshots, Datenschutzerklärung, Altersfreigabe. Wer sie schreibt und in welchen Sprachen.
• Zahlungen. Verkauft die App digitale Güter oder Abos, gelten die Regeln und Gebühren der Stores. Für physische Waren und Dienstleistungen gelten andere Regeln. Notieren Sie, was Sie verkaufen, der Dienstleister nennt Ihnen das passende Modell.

Die Prüfdauer der Stores liegt nicht in unserer Hand, deshalb versprechen wir nie ein genaues Datum für die Veröffentlichung. Mehr zu den Schritten selbst im Artikel Mobile App erstellen: von der Idee bis zum App Store.

Fünf Fehler im Lastenheft, die Dauer und Preis in die Höhe treiben

1. Keine Prioritäten. Wenn alles „sehr wichtig“ ist, enthält die Schätzung alles, und die erste Version startet nach einem halben Jahr statt nach zwei Monaten. Teilen Sie die Funktionen in „Pflicht“, „wäre schön“ und „später“.
2. Keine Abnahmekriterien. „Schön und bequem“ lässt sich nicht prüfen. „Ein Termin entsteht in höchstens vier Fingertipps“ schon.
3. Admin-Panel und Rollen vergessen. Die App für den Kunden ist das halbe Produkt. Die andere Hälfte ist das Werkzeug Ihres Teams.
4. Unklare Anbindungen. „Mit dem CRM verbinden“ bedeutet bei verschiedenen Systemen unterschiedlich viel Arbeit. Nennen Sie das System und beschreiben Sie, welche Daten wohin fließen.
5. Kein Verantwortlicher. Wenn drei Personen auf Ihrer Seite entscheiden, bremsen die Abstimmungen das Projekt. Bestimmen Sie eine Person, die „Ja“ oder „Nein“ sagt.

Eine weitere häufige Falle: das Lastenheft für das fertige „ideale Produkt“ zu schreiben. Besser beschreiben Sie die erste Version, die Ihre Idee an echten Menschen testet, und separat alles, was Sie ergänzen, wenn sie funktioniert. Wie so eine erste Version aussieht und was sie kostet, erklärt der Artikel MVP: Was es ist und was der Start kostet.

Prüfen Sie, ob Ihr Lastenheft angebotsreif ist

Gehen Sie die kurze Checkliste unten durch. Sie zeigt, ob Sie das Dokument an Dienstleister schicken können oder zuerst Lücken schließen sollten. Antworten Sie bei den meisten Punkten mit „Nein“, ist das nicht schlimm: Einen Teil der Fragen können Sie gemeinsam mit dem Dienstleister klären, und dazu sind wir bereit.

Wer das Lastenheft schreiben sollte: Sie, der Dienstleister oder beide

Es gibt drei praktikable Wege, und die Wahl hängt davon ab, wie klar Ihre Idee ist.

• Sie schreiben selbst nach der Vorlage. Passt, wenn die Idee einfach ist und Sie Ihre Zielgruppe kennen. Holen Sie mehrere Angebote ein und vergleichen Sie sie.
• Der Dienstleister schreibt nach Ihrem Briefing. Bequem, aber bedenken Sie: Je detaillierter das Dokument, desto genauer der Kostenvoranschlag. Ein kostenloses Lastenheft wird oft zum „Lastenheft für unseren Preis“. Fragen Sie deshalb, wem es gehört, falls Sie sich für ein anderes Team entscheiden.
• Bezahlte Vorarbeit. Bei komplexen Produkten (Rollen, Zahlungen, mehrere Systeme) machen wir das als eigene Etappe: die Architektursession für €3.500. Ergebnis sind Produktkarte, Kostenvoranschlag und Plan der ersten Version. Dieser Betrag wird auf das Projekt angerechnet, und die Karte bleibt in jedem Fall bei Ihnen, auch wenn Sie danach ein anderes Team wählen.

Brauchen Sie Bildschirme statt nur Text, ergänzen Sie Design und Prototyp ab €1.990: Ein klickbarer Prototyp auf dem Telefon erklärt die Idee besser als zehn Seiten Beschreibung. In den fertigen App-Paketen ist das Design bereits enthalten.

Wem Sie Dokument und Projekt anvertrauen, besprechen wir im Artikel Webagentur finden: So wählen Sie ohne Fehlgriff; dieselben Fragen passen auch für App-Entwickler. Was die App selbst kostet, lesen Sie im Artikel Was kostet eine App?.

Was Sie in Ihrer Situation wählen sollten

• Die Idee ist einfach: ein Ablauf, eine Rolle. Füllen Sie die Vorlage selbst aus, schicken Sie sie an zwei bis drei Teams und vergleichen Sie die Antworten. Eine App für iOS und Android kostet bei uns ab €10.900, die genaue Summe ergibt sich nach dem Lastenheft im Kostenvoranschlag.
• Es gibt mehrere Rollen, Zahlung, Anbindungen. Schreiben Sie nicht alles blind: Beginnen Sie mit der Architektursession und erhalten Sie das Lastenheft als Produktkarte samt Kostenvoranschlag.
• Sie sind nicht sicher, ob Sie überhaupt eine App brauchen. Vielleicht genügt eine Website auf dem Telefon oder eine Telegram Mini App. Vergleichen Sie Varianten und Kosten, bevor Sie das Dokument schreiben.
• Es gibt schon ein Lastenheft von einer anderen Agentur. Zeigen Sie es uns und anderen Anbietern: ein Dokument, mehrere Angebote. Wie Sie die Antworten fair vergleichen, erklärt der Artikel Angebote für Webdesign und Software vergleichen.
• Sie müssen so schnell wie möglich starten. Beschreiben Sie nur die Pflichtfunktionen und verschieben Sie den Rest in die zweite Version.

Die Zusammenarbeit läuft auf Wunsch in Ihrer Stadt oder komplett aus der Ferne. Schreiben Sie uns kurz, was Sie vorhaben, und wir sagen Ihnen, welcher Weg zu Ihrer Idee passt.