Was gehört in ein App-Pflichtenheft?

Ziel und Zielgruppe der App, der vollständige Funktionsumfang mit allen Bildschirmen und Zuständen, nicht-funktionale Anforderungen wie Leistung und Datenschutz, Design-Vorgaben, benötigte Schnittstellen zu externen Diensten, die Zielplattform und klare Abnahmekriterien. Je konkreter jeder Punkt, desto präziser das Angebot, das Sie zurückbekommen, und desto weniger Nachträge entstehen später im Projekt.

Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?

Das Lastenheft beschreibt aus Ihrer Sicht, was Sie brauchen, das Pflichtenheft beschreibt aus Sicht des Anbieters, wie er es umsetzen wird. In der Praxis werden die Begriffe oft vermischt. Wichtig ist nicht die Bezeichnung, sondern dass ein Dokument existiert, das Anforderungen und Umsetzung so klar festhält, dass beide Seiten dasselbe erwarten.

Brauche ich ein Pflichtenheft für meine App?

Für jedes ernsthafte Projekt ja. Ohne schriftliche Anforderungen bekommen Sie ungenaue Angebote, die später als Nachträge teurer werden, und im Streitfall steht Aussage gegen Aussage. Ein Pflichtenheft muss nicht perfekt sein, aber es sollte die zentralen Funktionen, Bildschirme und Bedingungen festhalten. Oft entsteht es gemeinsam mit dem Anbieter in einer Discovery-Phase.

Wie ausführlich muss ein Pflichtenheft sein?

So ausführlich, dass ein Anbieter ohne Rückfragen ein belastbares Angebot erstellen kann, aber nicht so starr, dass kein Raum für bessere Lösungen bleibt. Beschreiben Sie das Was und Warum jeder Funktion genau, lassen Sie beim Wie Spielraum. Ein gutes Pflichtenheft für ein MVP umfasst oft nur wenige klare Seiten, kein hundertseitiges Dokument.

Kann ich das Pflichtenheft vom Entwickler erstellen lassen?

Ja, und oft ist das die beste Lösung. Ein erfahrener Anbieter erstellt in einer bezahlten Discovery-Phase gemeinsam mit Ihnen ein Pflichtenheft, das technische Realität und Ihre Ziele verbindet. Das Ergebnis gehört Ihnen und kann auch für Angebote anderer Anbieter genutzt werden. Bestehen Sie darauf, dass dieses Dokument und der Code Ihr Eigentum sind.

App Pflichtenheft: Aufbau, Inhalt und kostenlose Vorlage

Kurze Antwort

Ein App-Pflichtenheft beschreibt, was die App leisten soll, für wen und unter welchen Bedingungen. Es enthält Ziel und Zielgruppe, den Funktionsumfang mit allen Zuständen, nicht-funktionale Anforderungen, Design-Vorgaben, Schnittstellen, Plattform und Abnahmekriterien. Ein klares Pflichtenheft führt zu präziseren Angeboten, weniger Nachträgen und einem faireren Vertrag. Die Vorlage weiter unten liefert die Struktur; füllen Sie sie mit Ihren echten Anforderungen. Wenn Sie zuerst die Kosten einschätzen wollen, hilft unser Beitrag zu den Kosten einer App-Entwicklung.

Warum ein Pflichtenheft bares Geld wert ist

Viele App-Projekte starten mit einer E-Mail und einer groben Idee. Das Ergebnis sind Angebote, die weit auseinanderliegen, weil jeder Anbieter etwas anderes hineinliest. Ein Pflichtenheft löst genau das: Es gibt allen Anbietern dieselbe Grundlage, sodass Sie Angebote vergleichen, die sich auf dasselbe beziehen.

Der zweite Nutzen zeigt sich im Projektverlauf. Der häufigste Grund für Nachträge und Streit ist, dass Umfang nie schriftlich festgehalten wurde. Steht eine Funktion im Pflichtenheft, ist klar, dass sie zum Preis gehört. Steht sie nicht drin, ist klar, dass sie ein bezahlter Zusatz ist. Diese Klarheit schützt beide Seiten und macht die Zusammenarbeit ruhiger, weil niemand im Nachhinein aus dem Gedächtnis rekonstruieren muss, was einmal versprochen war.

Ein Pflichtenheft ist also kein bürokratisches Ritual, sondern das Dokument, auf das Sie sich verlassen, wenn etwas unklar wird, und irgendwann wird immer etwas unklar. Gerade bei einem Festpreis ist es die Grundlage, die bestimmt, was zum vereinbarten Preis gehört und was ein bezahlter Zusatz ist. Fehlt diese Grundlage, wird jede Änderung zur Verhandlung, und Verhandlungen mitten im Projekt gehen selten zu Ihren Gunsten aus.

Die Kapitel eines guten Pflichtenhefts

Ein brauchbares Pflichtenheft für eine App gliedert sich in klare Abschnitte. Die folgende Struktur können Sie direkt als Vorlage verwenden:

Kapitel	Was hineingehört
Ziel und Zweck	Welches Problem löst die App, was ist der Geschäftszweck
Zielgruppe	Wer nutzt die App, in welcher Situation
Funktionsumfang	Alle Funktionen und Bildschirme, mit Zuständen
Nicht-funktionale Anforderungen	Leistung, Sicherheit, Datenschutz, Skalierung
Design-Vorgaben	Stil, Marke, Referenzen, Barrierefreiheit
Schnittstellen	Externe Dienste, APIs, bestehende Systeme
Plattform und Technik	iOS, Android, Versionen, Geräte
Abnahmekriterien	Woran wird gemessen, dass etwas fertig ist
Zeitrahmen und Budget	Grober Rahmen, wichtige Termine

Nicht jedes Kapitel muss lang sein. Für ein MVP reichen oft wenige klare Sätze pro Abschnitt. Entscheidend ist, dass keines fehlt, denn jedes ausgelassene Kapitel ist eine spätere Diskussion.

Der wichtigste Teil: Funktionsumfang mit Zuständen

Das Kapitel, das über die Angebotsqualität entscheidet, ist der Funktionsumfang. Der häufigste Fehler ist, Funktionen als Stichworte aufzulisten: “Login”, “Chat”, “Zahlungen”. Diese Kurzform verbirgt den eigentlichen Umfang.

“Login” bedeutet in Wahrheit Login mit Apple, E-Mail, Passwort-Reset, Verifizierung und Konto-Löschung, die laut den App Store Review Guidelines verpflichtend ist, sobald Ihre App Konten anlegt. Beschreiben Sie deshalb jede Funktion vollständig und denken Sie an die Zustände: Was zeigt ein Bildschirm, wenn er leer ist, wenn er lädt, wenn ein Fehler auftritt und wenn er gefüllt ist? Diese vier Zustände pro Bildschirm sind die eigentliche Arbeit und der häufigste blinde Fleck in einem Pflichtenheft. Zwanzig Bildschirme sind so gesehen nicht zwanzig, sondern sechzig bis achtzig zu gestaltende Zustände, und genau diese Rechnung erklärt, warum ein Angebot höher ausfällt, als eine kurze Feature-Liste vermuten ließ.

Je genauer Sie hier sind, desto präziser das Angebot und desto weniger Nachträge. Beschreiben Sie das Was und Warum jeder Funktion genau, lassen Sie beim Wie aber Spielraum, damit der Anbieter die beste technische Lösung wählen kann.

Funktionen priorisieren: Muss, Soll, Kann

Ein Pflichtenheft, das alle Funktionen gleich behandelt, zwingt den Anbieter, alles einzupreisen, und macht ein günstiges MVP unmöglich. Priorisieren Sie deshalb jede Funktion, damit ein sinnvoller erster Umfang entstehen kann:

Priorität	Bedeutung	Beispiel
Muss	Ohne diese Funktion startet die App nicht	Registrierung, Kernaktion, Bezahlung
Soll	Wichtig, aber für den Start verschiebbar	Push-Benachrichtigungen, Filter
Kann	Wünschenswert, spätere Version	Gamification, Empfehlungen, Themes

Diese einfache Einteilung hat einen großen Effekt: Sie erlaubt dem Anbieter, ein MVP nur aus den Muss-Funktionen zu schnüren, das Sie früh veröffentlichen und mit echten Nutzern testen. Die Soll- und Kann-Funktionen finanzieren Sie dann mit dem, was Sie aus der ersten Version gelernt haben. Ein Pflichtenheft ohne Priorisierung führt dagegen oft zu einem überladenen, teuren ersten Wurf, der Monate später als nötig erscheint.

Nicht-funktionale Anforderungen nicht vergessen

Ein Bereich, der oft fehlt und teuer wird, sind die nicht-funktionalen Anforderungen: alles, was die App können muss, ohne eine sichtbare Funktion zu sein. Dazu gehören:

Leistung. Wie schnell muss die App reagieren, wie viele Nutzer gleichzeitig?
Sicherheit und Datenschutz. Welche Daten werden erhoben, wie geschützt, welche gesetzlichen Vorgaben gelten?
Barrierefreiheit. Soll die App den Barrierefreiheits-Richtlinien von Apple folgen, etwa für VoiceOver und große Schrift?
Verfügbarkeit und Skalierung. Muss die App Lastspitzen aushalten, in welchen Regionen laufen?

Diese Punkte beeinflussen den Aufwand erheblich, tauchen aber in einer reinen Feature-Liste nie auf. Wer sie im Pflichtenheft nennt, bekommt ein ehrlicheres Angebot und vermeidet, dass sie später als teure Überraschung nachkommen.

Design, Schnittstellen und Abnahme

Drei weitere Kapitel runden das Dokument ab. Bei den Design-Vorgaben genügt oft, den gewünschten Stil, Ihre Marke und zwei bis drei Referenz-Apps zu nennen, deren Qualität Sie anstreben. Ein Anbieter, der an den Human Interface Guidelines von Apple arbeitet, liefert eine App, die iPhone-Nutzer sofort verstehen. Sie müssen kein fertiges Design mitbringen; im Gegenteil ist es oft besser, dem Anbieter die gestalterische Freiheit zu lassen und nur den Rahmen aus Marke, Ton und Referenzen vorzugeben, damit ein stimmiges Ergebnis entstehen kann statt einer Sammlung Ihrer Einzelwünsche.

Bei den Schnittstellen listen Sie jeden externen Dienst und jedes bestehende System, das die App anbinden soll: Zahlungsdienstleister, Karten, ein bestehendes Warenwirtschaftssystem. Jede Schnittstelle bringt eigene Abläufe und Fehlerfälle mit und gehört deshalb ins Dokument. Nennen Sie zu jeder Schnittstelle auch, wer sie bereitstellt und ob Sie bereits Zugänge haben, denn fehlende Zugangsdaten oder ein noch nicht ausgewählter Zahlungsdienstleister sind ein häufiger Grund für Verzögerungen. Ist eine Schnittstelle noch offen, markieren Sie das ausdrücklich, damit der Anbieter den Aufwand als Annahme kennzeichnen und später präzisieren kann.

Die Abnahmekriterien legen fest, woran gemessen wird, dass etwas fertig ist. Ohne sie bleibt “fertig” Auslegungssache. Ein guter Anbieter testet auf echten Geräten und stellt eine Beta über TestFlight bereit, an der Sie die Abnahme durchführen. Formulieren Sie die Abnahmekriterien möglichst überprüfbar: “Ein Nutzer kann sich registrieren, einen Termin buchen und eine Bestätigung erhalten” ist ein klares Kriterium, “die App funktioniert gut” ist keines. Je konkreter die Kriterien, desto weniger Raum bleibt am Ende für Streit darüber, ob eine Funktion wirklich fertig ist.

So nutzen Sie die Vorlage richtig

Die Struktur oben ist Ihre kostenlose Vorlage. Um sie in ein brauchbares Pflichtenheft zu verwandeln:

Gehen Sie jedes Kapitel durch und schreiben Sie in eigenen Worten, was für Ihre App gilt. Kurze, klare Sätze schlagen lange, vage Absätze.
Priorisieren Sie die Funktionen in Muss, Soll und Kann. So kann ein Anbieter ein MVP schnüren, das mit den Muss-Funktionen startet.
Markieren Sie offene Fragen ausdrücklich, statt sie zu verschweigen. Ein ehrliches “noch offen” ist besser als eine erfundene Anforderung, die später korrigiert werden muss und das Angebot verfälscht.
Lassen Sie das Dokument gegenlesen, idealerweise von jemandem, der die App später nutzen soll.

Das Ergebnis muss nicht perfekt sein. Ein klares vierseitiges Pflichtenheft für ein MVP ist wertvoller als ein hundertseitiges, das niemand liest. Der Sinn des Dokuments ist nicht Vollständigkeit um ihrer selbst willen, sondern eine gemeinsame Grundlage: Sie und der Anbieter sollen nach der Lektüre dieselbe App vor Augen haben. Sobald das der Fall ist, hat das Pflichtenheft seinen Zweck erfüllt, egal wie kurz es ist.

Die häufigsten Fehler in App-Pflichtenheften

Aus vielen gesichteten Dokumenten wiederholen sich einige Fehler, die Sie leicht vermeiden können:

Funktionen als Stichworte statt als Abläufe. “Chat” ist ein Wort; “Chat mit Verlauf, Benachrichtigungen, Blockierung und Missbrauchsmeldung” ist die echte Anforderung.
Nur der Erfolgsfall beschrieben. Was passiert ohne Internet, mit halb ausgefülltem Formular, bei abgelehnter Zahlung? Die Fehlerfälle sind ein Drittel der Arbeit.
Das Wie vorgeschrieben statt das Was. Wenn Sie die technische Lösung diktieren, nehmen Sie dem Anbieter die Chance, eine bessere zu finden.
Keine Priorisierung. Ohne Muss, Soll und Kann wird jedes MVP zu groß.
Nicht-funktionale Anforderungen ausgelassen. Datenschutz, Leistung und Barrierefreiheit fehlen und kommen später als teure Nachträge.
Kein Abnahmekriterium. Ohne messbare Definition von “fertig” bleibt jede Diskussion offen.

Jeder dieser Fehler kostet später Geld oder Nerven. Ein kurzer Gegencheck des Dokuments gegen diese Liste ist eine der günstigsten Qualitätssicherungen im ganzen Projekt.

Pflichtenheft gemeinsam mit dem Anbieter erstellen

Es gibt einen Fall, in dem Sie das Pflichtenheft nicht allein schreiben müssen: Ein erfahrener Anbieter erstellt es in einer bezahlten Discovery-Phase gemeinsam mit Ihnen. Das hat einen großen Vorteil, denn das Dokument verbindet dann Ihre Ziele mit der technischen Realität, statt Anforderungen zu enthalten, die sich schwer umsetzen lassen.

Bestehen Sie in diesem Fall auf zwei Dingen: Das Pflichtenheft gehört Ihnen und darf auch für Angebote anderer Anbieter genutzt werden, und derselbe Grundsatz gilt später für den Code, dessen Repository ab Tag eins auf Ihren Namen laufen sollte. So bleiben Sie unabhängig und können den Anbieter wechseln, ohne bei null anzufangen, falls die Zusammenarbeit einmal nicht passt.

Genau so arbeiten wir: Ein Team, das Design und Entwicklung unter einem Dach vereint, übersetzt Ihre Idee in ein klares Pflichtenheft und baut sie anschließend, ohne die teure Reibung zwischen getrennten Anbietern. Beispiele finden Sie in unseren Projekten, und in einem kurzen Gespräch erstellen wir mit Ihnen die Grundlage für Ihr Projekt, von der ersten groben Idee bis zum abnahmefertigen Pflichtenheft.