Lastenheft App: Was vor der Entwicklung hinein muss

Ein Lastenheft für eine App beschreibt, wer sie nutzt, welche Aufgaben sie übernimmt und wann eine Funktion als fertig gilt. Hinein gehören der schriftliche Funktionsumfang, die benötigten Daten und die Verbindungen zu bestehenden Systemen. Auch Serverstandort, externe Dienste und Zuständigkeiten nach dem Start solltest du darin festhalten.

Kurz gesagt: Beschreibe vollständige Arbeitsabläufe statt Stichwörter wie „Login“ oder „Kalender“. Trenne den vereinbarten Startumfang von späteren Wünschen und halte fest, wie die fertigen Funktionen geprüft werden. Datenverarbeitung und Betrieb gehören von Anfang an dazu.

Stand: Oktober 2026. Die Hinweise zu Datenschutz und Verträgen ersetzen keine Rechtsberatung. Kläre rechtliche Fragen mit einem Anwalt oder der zuständigen Datenschutzstelle.

Warum brauchst du ein Lastenheft für deine App?

Ein Lastenheft verhindert, dass du und dein Entwicklungspartner unter derselben Funktion verschiedene Dinge verstehen. Es liefert die Grundlage für Angebot und Umsetzung sowie die spätere Abnahme.

„Kunden können Termine buchen“ klingt eindeutig. Muss dein Büro jede Anfrage bestätigen? Dürfen Kunden ihre Buchung selbst verschieben? Wird der Termin auch in euren bestehenden Kalender eingetragen?

Die Antworten verändern den Entwicklungsaufwand. Fehlen sie, muss jemand während der Umsetzung entscheiden. Dann entsteht womöglich eine Buchungsfunktion, die technisch funktioniert, aber zusätzliche Arbeit im Büro verursacht.

Du brauchst dafür keine Programmierkenntnisse. Du musst erklären können, wie dein Betrieb arbeitet und was sich durch die App ändern soll.

Prüfe vorab, ob vorhandene Software den gewünschten Ablauf bereits abbildet. Für eine gewöhnliche Terminbuchung ist eine Eigenentwicklung meist schwer zu rechtfertigen. Der Ratgeber Individualsoftware oder Standardsoftware hilft dir bei dieser Entscheidung.

Lastenheft, Pflichtenheft und Angebot: Was steht wo?

Das Lastenheft beschreibt üblicherweise, was du brauchst. Das Pflichtenheft beschreibt, wie der Auftragnehmer diese Anforderungen umsetzen will.

In der Praxis werden die Begriffe unterschiedlich verwendet. Frage deshalb konkret: Welches Dokument hält den vereinbarten Umfang fest, und auf welchen Stand bezieht sich das Angebot?

Bei mawu heißt diese Grundlage Anforderungsdokument. Wir halten darin den Funktionsumfang schriftlich fest. Gegen dieses Dokument wird später getestet und abgenommen.

Für ein kleines Projekt brauchst du keine Dokumentensammlung mit mehrfach beschriebenen Funktionen. Du brauchst einen eindeutigen Stand, den beide Seiten kennen und freigeben.

Lastenheft App: Welche Inhalte gehören hinein?

Dein Lastenheft muss den heutigen Ablauf, die künftigen Nutzer und die gewünschten Funktionen beschreiben. Genauso deutlich muss darin stehen, was zum Start nicht enthalten ist.

Beginne mit den folgenden Punkten. Alltagssprache reicht dafür aus.

Ausgangslage und Ziel

Beschreibe, wie die Arbeit heute läuft. Beispiel: Terminanfragen kommen per WhatsApp an. Das Büro überträgt sie in den Kalender und stimmt Änderungen telefonisch ab.

Das Ziel könnte lauten: Kunden sollen freie Termine selbst anfragen können. Das Büro bestätigt oder verwirft diese Anfragen an einer Stelle.

„Weniger Verwaltungsaufwand“ allein ist zu vage. Der beschriebene Ablauf zeigt dagegen, welche Arbeitsschritte die App übernehmen soll.

Nutzergruppen und Zugriffsrechte

Halte fest, wer welche Informationen sehen und bearbeiten darf. Ein Kunde sieht seine eigenen Termine. Ein Mitarbeiter bearbeitet die Buchungen seines Standorts.

Eine Rolle ist eine Nutzergruppe mit festgelegten Zugriffsrechten. Beschreibe auch, wer Konten anlegen, Daten exportieren oder Einträge löschen darf. Diese Rechte ergeben sich nicht automatisch aus der Bezeichnung „Mitarbeiter“.

Geräte und Einsatzort

Soll die Anwendung auf dem Smartphone laufen oder im Browser? Nutzt das Büro sie am Schreibtisch, während Außendienstmitarbeiter unterwegs Daten erfassen?

Wenn Mitarbeiter auch ohne Empfang arbeiten müssen, gehört das ins Lastenheft. Offline-Nutzung bedeutet, dass bestimmte Funktionen ohne Internetverbindung verfügbar bleiben. Lege fest, welche das sind und wann gespeicherte Änderungen übertragen werden sollen.

Grenzen der ersten Version

Kennzeichne jede Funktion als erforderlich für den Start, für später vorgesehen oder ausdrücklich ausgeschlossen. Bei einer Termin-App könnte die Buchungsanfrage zum Start gehören, eine Warteliste dagegen noch nicht.

Spätere Ideen sind kein beauftragter Umfang. Halte sie getrennt fest, damit sie nicht versehentlich im Angebot oder in der Abnahme landen.

Wie beschreibst du eine Funktion verständlich?

Beschreibe eine Funktion vom ersten Klick bis zum Ergebnis. Ergänze die Regeln und mindestens die naheliegenden Fehlerfälle.

„Kalender integrieren“ sagt zu wenig. Eine Terminanfrage lässt sich dagegen so beschreiben:

1. Ein angemeldeter Kunde wählt einen Standort und eine Leistung.
2. Die App zeigt passende freie Termine.
3. Der Kunde wählt einen Termin und sendet die Anfrage ab.
4. Das Büro bestätigt die Anfrage oder lehnt sie ab.
5. Der Kunde sieht den Status in der App und erhält eine E-Mail.

Jetzt folgen die Regeln: Bleibt ein angefragter Termin für andere Kunden buchbar? Wie kurzfristig darf eine Anfrage eingehen? Wer darf eine bestätigte Buchung stornieren?

Beschreibe auch, was schiefgehen kann. Wird der Termin vor dem Absenden anderweitig vergeben, muss die App das anzeigen. Der Kunde soll einen anderen Termin wählen können, ohne seine übrigen Angaben erneut einzutippen.

Daran lässt sich später prüfen, ob die Funktion wie vereinbart arbeitet. Einfache Skizzen helfen zusätzlich, wenn sich die Reihenfolge der Ansichten mit Worten schwer erklären lässt.

Was musst du zu Daten und Schnittstellen festhalten?

Notiere, welche Daten die App verarbeitet, woher sie kommen und wohin sie übertragen werden. Eine Schnittstelle ist eine technische Verbindung, über die Systeme Daten austauschen.

Für eine Kalenderanbindung brauchst du mehr als den Namen des Kalenderprogramms. Soll die App nur freie Zeiten lesen? Soll sie Buchungen eintragen und spätere Änderungen übernehmen?

Lege fest, welches System bei widersprüchlichen Angaben maßgeblich ist. Verschiebt das Büro einen Termin im Kalender, muss klar sein, was mit der Buchung in der App passiert.

Auch fehlgeschlagene Übertragungen brauchen einen Ablauf. Wer sieht, dass eine Buchung nicht im Kalender angekommen ist? Kann diese Person die Übertragung erneut auslösen?

Sollen bestehende Daten übernommen werden, beschreibe deren Zustand. Kundenkontakte aus Excel können doppelte Einträge oder fehlende E-Mail-Adressen enthalten. Halte fest, wer diese Daten bereinigt und wie unvollständige Datensätze behandelt werden.

Serverstandort und externe Dienste

Benenne den vorgesehenen Serverstandort und die beteiligten Drittdienste. Das sind externe Anbieter, die beispielsweise E-Mails versenden oder die Anmeldung verwalten. Dokumentiere, welche Daten an diese Anbieter gehen.

Bei mawu steht der Serverstandort vor der Umsetzung im Anforderungsdokument. Die beteiligten Drittdienste werden im Angebot benannt. Bei der Verarbeitung personenbezogener Daten gehört ein AV-Vertrag zum Angebot, also ein Vertrag zur Auftragsverarbeitung.

Halte außerdem fest, welche Daten gelöscht oder aufbewahrt werden sollen und wer darauf zugreifen darf. Lass die rechtlichen Vorgaben dafür fachlich klären. Der Entwicklungspartner braucht konkrete Anforderungen, um diese Abläufe umzusetzen.

Welche Anforderungen fehlen häufig neben den Funktionen?

Dein Lastenheft sollte beschreiben, unter welchen Bedingungen die App zuverlässig arbeiten muss. Dazu gehören unterstützte Geräte und das Verhalten bei Verbindungsabbrüchen.

„Die App muss schnell sein“ lässt sich schlecht abnehmen. Beschreibe die Nutzungssituation: Ein Mitarbeiter öffnet unterwegs über mobiles Internet die Terminliste. Vereinbare dafür eine messbare Zielzeit und die Bedingungen des Tests.

Diese Fragen helfen, weitere Lücken zu finden:

• Auf welchen Geräten und Betriebssystemen soll die App getestet werden?
• Was passiert mit Eingaben, wenn beim Speichern die Verbindung abbricht?
• Welche Daten werden gesichert, und wie wird die Wiederherstellung getestet?
• Welche Anforderungen gelten für die barrierefreie Bedienung?
• Wer erhält eine Meldung, wenn ein Vorgang scheitert?

Du musst keine technische Lösung vorgeben. Beschreibe die Folgen für deinen Betrieb: Können Mitarbeiter bei einem Ausfall weiterarbeiten, oder steht die Terminvergabe still?

Wie formulierst du prüfbare Abnahmekriterien?

Abnahmekriterien halten fest, woran du eine korrekt umgesetzte Funktion erkennst. Schreibe sie zusammen mit der jeweiligen Anforderung auf, nicht erst kurz vor dem Start.

Für die Termin-App könnte ein Kriterium lauten: „Nach der Bestätigung sieht der Kunde Datum, Uhrzeit und Standort seiner Buchung.“ Ein weiteres: „Mitarbeiter ohne Freigabe für einen Standort können dessen Buchungen weder öffnen noch ändern.“

Teste auch abgewiesene Eingaben und fehlende Berechtigungen. Kann ein Kunde eine Anfrage ohne erforderliche Kontaktdaten absenden? Kann ein gesperrtes Konto noch Termine buchen?

Bestimme, wer auf deiner Seite testet und Rückmeldungen bündelt. Wenn Büro und Geschäftsführung unterschiedliche Abläufe wünschen, muss jemand die Entscheidung treffen dürfen.

Wie die Anforderungen durch das gesamte Projekt geführt werden, erklärt der Ratgeber zum Ablauf einer App-Entwicklung.

Was gehört zu Übergabe, Betrieb und Änderungen?

Das Lastenheft sollte festhalten, was du nach der Veröffentlichung erhältst und wer die App betreibt. Eine fertige Anwendung allein klärt noch keine Zuständigkeiten bei Störungen.

Lege fest, auf wen Hosting und Store-Konten laufen. Hosting bezeichnet den Betrieb der Anwendung auf Servern. Store-Konten werden für die Veröffentlichung in den jeweiligen App-Stores benötigt.

Zur Übergabe gehören die benötigten Zugänge, eine Einweisung und die vereinbarte Dokumentation. Halte auch die Übergabe des Quellcodes fest. Der Quellcode ist die bearbeitbare Grundlage der Software, die ein späterer Entwicklungspartner für Änderungen benötigt.

Nutzungsrechte werden vertraglich geregelt. Die passenden Fragen dazu findest du im Ratgeber Wem gehört der Code?.

Kläre für den Betrieb, wer Fehlermeldungen entgegennimmt und Updates einspielt. Vereinbarte Reaktionszeiten gehören ebenfalls dokumentiert. „Wir kümmern uns dann“ ist dafür zu unbestimmt.

Für Änderungen am Umfang gilt ein einfacher Ablauf: Wunsch aufschreiben, Auswirkungen auf Aufwand und Termin bewerten, Umsetzung freigeben. Bewahre frühere Dokumentstände auf. So bleibt nachvollziehbar, was ursprünglich vereinbart war und später ergänzt wurde.

Wie detailliert muss dein erster Entwurf sein?

Dein erster Entwurf muss die Arbeit im Betrieb verständlich machen, aber keine technische Architektur festlegen. Die nötige Länge hängt davon ab, wie viele unterschiedliche Abläufe und Regeln deine App abbildet.

Der Klärungsbedarf steigt etwa durch verschiedene Zugriffsrechte, externe Systeme oder Offline-Nutzung. Eine lange Liste von Funktionsnamen ersetzt diese Klärung nicht. Erst die Regeln hinter den Funktionen machen den Aufwand einschätzbar.

Ob eine bestimmte Datenbank passt, kann dein Entwicklungspartner beurteilen. Dass Mitarbeiter im Keller eines Gebäudes Daten erfassen müssen, obwohl dort kein Empfang besteht, musst du ihm sagen.

Schreibe als nächsten Schritt einen typischen Arbeitsablauf vollständig auf, einschließlich eines Fehlerfalls. Nimm diese Beschreibung ins Anforderungsgespräch mit und ergänze von dort aus die übrigen Abläufe.