Wer eine individuelle Webanwendung entwickeln lassen will, steht früher oder später vor derselben Frage: Was muss ich dem Entwickler eigentlich genau übergeben, damit er ein belastbares Angebot abgeben kann? Die Antwort heißt Lastenheft. Ein gut geschriebenes Lastenheft ist die Grundlage für realistische Angebote, sauberen Projektablauf und am Ende für eine Anwendung, die das tut, was Sie wirklich brauchen. In diesem Artikel zeigen wir, was in ein Lastenheft gehört, wie ausführlich es sein muss und welche Fehler in der Praxis besonders teuer werden.
Lastenheft vs. Pflichtenheft: Was ist der Unterschied?
Die beiden Begriffe werden oft synonym verwendet, sind aber etwas Unterschiedliches. Das Lastenheft schreibt der Auftraggeber. Es beschreibt das Was – also Anforderungen, Ziele und Rahmenbedingungen. Das Pflichtenheft schreibt der Auftragnehmer. Es beschreibt das Wie – also die technische Umsetzung dieser Anforderungen.
Im Lastenheft steht: "Wir brauchen eine Funktion, mit der Außendienstler offline Aufträge erfassen können." Im Pflichtenheft steht: "Wir setzen das um über eine Progressive Web App mit IndexedDB-Cache und automatischer Synchronisation beim nächsten Online-Status."
Die 9 Pflicht-Bestandteile eines Lastenhefts
Ein vollständiges Lastenheft enthält neun klar abgegrenzte Abschnitte. Fehlt einer davon, wird das Projekt entweder unterboten (mit teuren Change Requests später) oder das Angebot fällt erschreckend hoch aus, weil der Anbieter Sicherheitszuschläge einbaut.
Ausgangssituation und Ziele
Was machen Sie heute? Was soll die neue Anwendung anders machen? Welches Business-Problem wird gelöst? Wer profitiert (Geschäftsführung, Anwender, Kunden)? Eine bis zwei Seiten reichen.
Zielgruppe und Anwendungsfälle
Wer benutzt die Anwendung? Wie oft? In welcher Umgebung (Büro, Außendienst, mobil)? Welche IT-Kompetenz haben die Anwender? Mindestens 3-5 konkrete Anwendungsfälle, die das System unterstützen muss.
Funktionale Anforderungen
Was muss die Anwendung tun? Hier kommt die Liste der eigentlichen Funktionen. Pro Funktion: Was passiert wann, welche Eingaben, welche Ausgaben, welche Sonderfälle.
Nicht-funktionale Anforderungen
Wie schnell muss die Anwendung sein? Wie viele gleichzeitige Anwender? Welche Verfügbarkeit (z.B. 99,5 %)? Welche Browser-Unterstützung? Mehrsprachigkeit? Barrierefreiheit?
Schnittstellen
Mit welchen anderen Systemen muss die Anwendung sprechen? ERP, CRM, Buchhaltung, Active Directory, Microsoft 365, externe Dienste? Welche Daten fließen in welche Richtung?
Daten
Welche Datenarten werden verarbeitet? Welche Mengen (heute und in 3-5 Jahren)? Welche Datenschutz-Anforderungen (DSGVO, Branchenregeln)? Datenhaltung in Deutschland / EU?
Rollen und Berechtigungen
Welche Rollen gibt es (Admin, Anwender, Lesezugriff, externe Partner)? Was darf welche Rolle? Mehrstufige Freigaben?
Design und Bedienkonzept
Gibt es Corporate-Design-Vorgaben (Logo, Farben, Schriften)? Welche Bedien-Logik? Mockups vorhanden oder Teil des Projekts?
Rahmenbedingungen
Budget (Größenordnung reicht), Zeitschiene, Wartung, Hosting, Schulung, gewünschte Lizenz- / Quellcode-Übergabe. Auch: Welche Entscheidungen sind bereits getroffen (z.B. Technologie-Präferenzen), welche sind offen?
Funktionale Anforderungen: Wie konkret muss es sein?
Der häufigste Fehler in Lastenheften liegt hier: zu schwammig formuliert. Ein Satz wie "Die Anwendung soll Aufträge verwalten können" reicht nicht. Was ein Entwickler braucht, ist konkreter.
| Schlecht formuliert | Gut formuliert |
|---|---|
| "Aufträge verwalten" | "Mitarbeiter im Innendienst legen Aufträge an, weisen sie einem Außendienstler zu. Der Außendienstler sieht seine Aufträge in einer Liste, kann Status ändern (offen / in Bearbeitung / erledigt) und Notizen ergänzen. Innendienst sieht den Status in Echtzeit." |
| "Kunden suchen" | "Suchfeld mit Volltext über Name, Firmenname, Postleitzahl und Telefonnummer. Treffer ab 3 Zeichen Eingabe, max. 50 Treffer pro Suche, sortiert nach Relevanz." |
| "PDF erzeugen" | "Auf Knopfdruck wird ein PDF im Corporate Design erzeugt, das die ausgewählte Liste / das Dokument als Druckansicht enthält. PDF wird im Browser angezeigt und kann lokal gespeichert werden." |
| "Mehrsprachig" | "Frontend in Deutsch und Englisch. Inhalte selbst mehrsprachig pflegbar (DE + EN). Erweiterbar auf weitere Sprachen ohne Code-Anpassung." |
Beschreiben Sie Funktionen aus Anwendersicht, nicht aus technischer Sicht. "Außendienstler erfasst Auftrag offline und sieht ihn nach Verbindung wieder online" ist besser als "die App soll IndexedDB nutzen".
Priorisierung: Was ist Pflicht, was ist Wunsch?
Jede Anforderung sollte priorisiert werden. So weiß der Entwickler, was zwingend in die erste Version muss und was später kommen kann – das hilft bei Budget- und Termin-Realismus.
- Pflicht (Must) – ohne diese Funktion ist die Anwendung wertlos
- Wichtig (Should) – die Anwendung funktioniert auch ohne, aber ein deutlicher Mehrwert geht verloren
- Wunsch (Could) – wäre schön, ist aber nicht kritisch
- Verschoben (Won't) – wird bewusst NICHT in dieser Version umgesetzt
Diese Priorisierung heißt MoSCoW (Must / Should / Could / Won't). Sie hat sich in der Praxis bewährt und macht für jeden Beteiligten sichtbar, was in der ersten Version garantiert dabei sein muss.
Wo Lastenhefte in der Praxis scheitern
Aus 15+ Jahren Projekterfahrung sehen wir immer wieder dieselben Schwächen in Lastenheften:
- Zu detailliert auf Technik fokussiert ("PHP 8.3 mit Laravel und React") statt auf Fachlichkeit
- Funktionale Anforderungen ohne Anwendungsfälle – nur Stichwortlisten
- Keine Priorisierung, alles ist gleich wichtig – Projekt wächst unkontrolliert
- Mengen- und Last-Angaben fehlen (10 Anwender oder 10.000?)
- Schnittstellen werden nur erwähnt, aber nicht beschrieben ("Anbindung an Buchhaltung" – welche?)
- Kein Bezug zu Datenschutz und Datenhoheit
- Verantwortlichkeiten fehlen (wer testet, wer schult, wer betreibt?)
- Kein Hinweis auf Wachstum / Zukunftsbedarf der Anwendung
⚠️ Wichtig: Ein Lastenheft mit 80 Seiten Technik-Details, aber ohne klare Anwendungsfälle, ist schlechter als ein 8-seitiges Lastenheft mit konkreten Use-Cases. Entwickler können Technik wählen – sie können aber nicht raten, was die Anwender wirklich tun müssen.
Wie ausführlich muss ein Lastenheft sein?
Es gibt keine feste Seitenzahl. Als Faustregel: Je größer das Projekt, je mehr Schnittstellen und je mehr Rollen, desto ausführlicher. Typische Größen aus unserer Praxis:
| Projektgröße | Lastenheft-Umfang | Bearbeitungszeit beim Auftraggeber |
|---|---|---|
| Kleine Webapp, 1-2 Module | 5-15 Seiten | 1-3 Tage |
| Mittlere Webapp, 4-8 Module, eine Schnittstelle | 20-40 Seiten | 1-2 Wochen |
| Größere Webapp, Multi-Rollen, mehrere Schnittstellen | 50-100 Seiten | 4-8 Wochen |
| Unternehmens-Anwendung mit ERP-Integration | 100-300 Seiten | 8-16 Wochen, oft mit externer Begleitung |
Wenn das Lastenheft selbst zum Projekt wird (mehrere Monate Arbeit), empfehlen wir, es iterativ zu erstellen: erst grobe Struktur, dann Details für die wichtigsten Module, danach Vergabe-Reife. Statt Wasserfall-artig erst alles schreiben und dann ausschreiben.
Was im Lastenheft NICHT stehen muss
Genauso wichtig wie das, was ins Lastenheft gehört, ist das, was nicht hineingehört – sonst wird es überfrachtet und der Entwickler verliert den Blick aufs Wesentliche:
- Konkrete Technologie-Wahl (PHP vs. Java, React vs. Vue) – außer es gibt zwingende Gründe (z.B. bestehende Infrastruktur)
- Konkrete Datenbank-Schemata oder Tabellen-Strukturen
- UI-Mockups bis ins letzte Pixel – Wireframes reichen meist
- Detailierte Algorithmen oder Code-Strukturen
- Server-Konfigurationen, OS-Versionen, Webserver-Setup
- Projekt-Methodik des Entwicklers (Scrum, Kanban, etc.) – das ist dessen Sache
Wer schreibt das Lastenheft – intern oder mit Beratung?
Zwei Wege funktionieren in der Praxis:
Intern geschrieben
Wenn jemand im Unternehmen genug Zeit und fachlichen Überblick hat. Vorteil: Tiefe Detailkenntnis. Nachteil: Oft fehlt der Außenblick – relevante Dinge werden als selbstverständlich vorausgesetzt.
Mit externer Begleitung
Ein Berater interviewt Stakeholder, strukturiert die Anforderungen und schreibt das Lastenheft. Vorteil: neutraler Blick, schnellere Ergebnisse. Nachteil: Kosten, Abhängigkeit vom Berater bei späteren Fragen.
Kombiniert (Empfehlung)
Das Unternehmen liefert Inhalte und Anwendungsfälle, ein externer Berater strukturiert und formuliert. Beste Mischung aus Insider-Wissen und Außenperspektive.
Häufige Fragen vor und während der Erstellung
Was eine externe Lastenheft-Begleitung kostet
Als Richtwerte für eine externe Begleitung in Südbaden:
- Kleines Projekt (1-2 Module): 2.000-5.000 € für komplettes Lastenheft inkl. Interviews
- Mittleres Projekt (4-8 Module): 5.000-12.000 € mit 2-3 Wochen Beratungszeit
- Größeres Projekt: nach Aufwand, oft 15.000-40.000 € verteilt über 6-12 Wochen
Bei einem 80.000-€-Entwicklungsprojekt machen 5.000 € Lastenheft 6 % der Investition aus – sie verhindern aber typisch 20-40 % Change-Request-Aufwand während der Entwicklung. Das ist eine der besten Investitionen im gesamten Projektzyklus.
Fazit: Ein gutes Lastenheft ist die halbe Miete
Ein durchdachtes Lastenheft kostet Zeit und kostet Geld – beides bezahlt sich vielfach zurück. Es ist die Grundlage für verlässliche Angebote, sauberen Projektablauf und Anwendungen, die das tun, was wirklich gebraucht wird. Wer hier spart, zahlt im Projektverlauf das Vielfache.
Wenn Sie eine Webanwendung planen und Unterstützung beim Lastenheft brauchen – melden Sie sich. Wir begleiten Unternehmen aus Freiburg und der Region bei der Anforderungsanalyse, schreiben verständliche Lastenhefte und übernehmen auf Wunsch auch die anschließende Entwicklung.