Lastenheft für eine App: was der Auftraggeber vor dem ersten Angebot aufschreibt

Ein Lastenheft beschreibt aus Sicht des Auftraggebers, was eine Anwendung leisten soll: welche Aufgaben sie unterstützt, wer sie nutzt, welche Daten sie verarbeitet und unter welchen Bedingungen sie laufen muss. Es sagt nicht, wie die Umsetzung technisch aussieht. Damit macht es Angebote vergleichbar und schafft die Grundlage für die spätere Prüfung.

Was ein Lastenheft ist

Der Begriff stammt aus der Industrie und ist in der DIN 69901-5 beschrieben. Gemeint ist die Gesamtheit der Anforderungen, die der Auftraggeber an die Lieferungen und Leistungen eines Auftragnehmers stellt. Bei einer App oder Webanwendung sind das Abläufe, Rollen, Daten, Schnittstellen, Geräte und Anforderungen an Betrieb, Sicherheit und Datenschutz.

Das Dokument muss nicht umfangreich sein. Für ein internes Werkzeug mit einem überschaubaren Ablauf reichen oft wenige Seiten. Entscheidend ist nicht die Länge, sondern dass jemand, der den Betrieb nicht kennt, danach versteht, welches Problem gelöst werden soll.

Geschrieben wird es von denen, die das Problem kennen, nicht von denen, die es lösen sollen. In der Praxis sind das meist eine verantwortliche Person aus der Fachabteilung und zwei oder drei Mitarbeiter, die den Ablauf täglich erledigen. Die IT ergänzt Schnittstellen und Sicherheitsvorgaben. Ein Dienstleister kann beim Formulieren helfen, sollte die Anforderungen aber nicht allein festlegen, weil er sonst beschreibt, was er am liebsten baut.

Anforderungen und Antwort des Auftragnehmers

Auf die Anforderungen antwortet der Auftragnehmer mit einem Pflichtenheft oder einer technischen Konzeption. Darin steht, wie er die Anforderungen umsetzen will: welche Bildschirme, welches Datenmodell, welche Technik, welche Schnittstellen. Das eine Dokument beschreibt das Was, das andere das Wie.

In kleineren Projekten verschmelzen beide oft zu einer Leistungsbeschreibung im Angebot. Das ist kein Mangel, solange die Trennung im Kopf erhalten bleibt: Der Auftraggeber verantwortet, dass seine Anforderungen stimmen, der Auftragnehmer, dass seine Lösung sie erfüllt.

Aufbau eines Lastenhefts für eine App

1. Ausgangslage und Ziel. Wie der Ablauf heute läuft, wo er hakt und woran man erkennt, dass die neue Anwendung ihn verbessert hat.
2. Nutzer und Rollen. Wer arbeitet mit der Anwendung, wie oft, an welchem Gerät, mit welchen Rechten.
3. Abläufe. Die wichtigsten Vorgänge als Schrittfolge, einschließlich der Sonderfälle: fehlende Angaben, Freigabe abgelehnt, Verbindung weg.
4. Daten. Welche Daten entstehen, woher vorhandene Bestände kommen, wie lange sie aufbewahrt werden und ob personenbezogene Daten dabei sind.
5. Schnittstellen. An welche Systeme angebunden wird, zum Beispiel Warenwirtschaft, CRM oder Buchhaltung, und in welche Richtung Daten fließen.
6. Rahmenbedingungen. Geräte und Browser, Betrieb ohne Netz, Barrierefreiheit, Sprachen, Anforderungen der IT-Sicherheit.
7. Abgrenzung. Was ausdrücklich nicht dazugehört. Dieser Abschnitt verhindert mehr Missverständnisse als jeder andere.

Anforderungen prüfbar formulieren

Eine Anforderung ist gut, wenn man später eindeutig sagen kann, ob sie erfüllt ist. Drei Beispiele zeigen den Unterschied:

• Statt »Die App soll schnell sein«: »Die Auftragsliste lädt mit hundert Einträgen auf einem durchschnittlichen Firmen-Telefon ohne spürbare Wartezeit, geprüft im Pilotbetrieb.«
• Statt »Einfache Bedienung«: »Eine neue Mitarbeiterin erfasst ohne Schulung einen Auftrag mit Foto.«
• Statt »Offline-fähig«: »Aufträge lassen sich ohne Netz erfassen und werden übertragen, sobald die Verbindung zurück ist; bei widersprüchlichen Änderungen gilt der zuletzt gespeicherte Stand im Büro.«

Solche Sätze lassen sich später bei der Abnahme abhaken. Wer unsicher ist, ob ein Ablauf in der Praxis funktioniert, prüft ihn vorher mit einem Klickdummy.

Typische Fehler

• Lösungen statt Anforderungen. »Wir brauchen eine Tabelle mit zwölf Spalten« beschreibt eine Oberfläche, nicht das Ziel. Besser ist: »Die Disposition sieht auf einen Blick, welche Aufträge heute offen sind.«
• Wunschliste ohne Prioritäten. Ohne Einteilung in unverzichtbar und wünschenswert enthalten alle Angebote alles, und die Preise werden unvergleichbar.
• Die Nutzer fehlen. Ein Lastenheft, das nur in der Geschäftsführung entstanden ist, beschreibt den Ablauf, wie er sein sollte, nicht wie er ist.
• Datenschutz am Ende. Ob personenbezogene Daten verarbeitet werden, entscheidet über Architektur und Verträge und gehört in die erste Fassung.

Wie wir mit Anforderungen arbeiten

Liegt ein Anforderungsdokument vor, lesen wir es vor dem ersten Gespräch und markieren Stellen, die sich nicht prüfen lassen. Liegt keines vor, schreiben wir die Anforderungen im Gespräch gemeinsam auf. In beiden Fällen stehen am Ende prüfbare Sätze im Angebot, die Grundlage für den Werkvertrag sind. Mehr zur Umsetzung steht auf der Seite App-Entwicklung.