Definition Lastenheft / Anforderungskatalog

Ein Lastenheft – auch Anforderungskatalog oder Requirements Document genannt – ist ein strukturiertes Dokument, in dem ein Auftraggeber alle Anforderungen an ein Produkt, ein System oder eine Dienstleistung schriftlich festhält. Es beschreibt aus Auftraggeberperspektive das „Was" und „Wozu": Was soll das Ergebnis leisten? Welche Ziele sollen damit erreicht werden? Welche Rahmenbedingungen müssen erfüllt sein? Das Lastenheft dient in der Angebotsphase als zentrale Ausschreibungsgrundlage: Auftraggeber senden es an mehrere potenzielle Auftragnehmer, die daraufhin vergleichbare Angebote erstellen. So werden Äpfel mit Äpfeln verglichen – Angebote lassen sich inhaltlich, qualitativ und preislich fair gegenüberstellen. Besonders verbreitet ist das Lastenheft in der Webentwicklung, der Softwareentwicklung, im IT-Projektmanagement und bei der Auswahl von Agenturen oder Dienstleistern für komplexe Marketingprojekte.

Lastenheft und Pflichtenheft werden häufig verwechselt, erfüllen aber grundlegend unterschiedliche Funktionen im Projektprozess:

• Lastenheft (erstellt vom Auftraggeber): Beschreibt die Anforderungen und Ziele aus der Perspektive des Auftraggebers – also das „Was soll erreicht werden?" und „Wozu wird das Produkt gebraucht?". Es ist bewusst technologieneutral gehalten und beschreibt Ergebnisse, keine Lösungswege. Das Lastenheft existiert, bevor ein Auftragnehmer ausgewählt wird.
• Pflichtenheft (erstellt vom Auftragnehmer): Der Auftragnehmer antwortet auf das Lastenheft mit dem Pflichtenheft. Darin beschreibt er konkret, wie er die Anforderungen des Auftraggebers technisch und organisatorisch umsetzen wird. Es enthält Lösungsarchitekturen, eingesetzte Technologien, Meilensteine und Verantwortlichkeiten.

Die Faustregel lautet: Das Lastenheft definiert das Problem, das Pflichtenheft definiert die Lösung. Erst wenn beide Dokumente vorliegen und abgestimmt sind, bilden sie die verbindliche Grundlage für einen Projektvertrag. In agilen Projekten werden diese klassischen Dokumente häufig durch User Stories und Product Backlogs ersetzt, das Grundprinzip der Anforderungsdokumentation bleibt jedoch dasselbe.

Es gibt keine gesetzlich vorgeschriebene Struktur, jedoch definiert die DIN-Norm 69905 einen bewährten Rahmen. Ein vollständiges Lastenheft enthält typischerweise folgende Abschnitte:

• Ist-Zustand und Ausgangssituation: Beschreibung des aktuellen Zustands – welche Systeme, Prozesse oder Tools sind bereits im Einsatz? Was funktioniert nicht zufriedenstellend?
• Zielsetzung und Projektziele: Was soll mit dem Projekt konkret erreicht werden? Ziele sollten messbar formuliert sein (z. B. „Ladezeit der Website unter 2 Sekunden", „Conversion Rate um 20 % steigern").
• Beschreibung des gewünschten Produkts oder der Leistung: Funktionale Anforderungen – was soll das System oder Produkt können? Im Webbereich z. B. Seitenzahl, Funktionsmodule, CMS-Typ, Sprachversionen.
• Technische Anforderungen: Betriebssysteme, Browser-Kompatibilität, Serverumgebung, Schnittstellen zu bestehenden Systemen (ERP, CRM, Shopsystem).
• Qualitäts- und Leistungsanforderungen: Serverauslastung, Verfügbarkeit (Uptime), Skalierbarkeit, Sicherheitsstandards, Datenschutzkonformität (DSGVO).
• Anforderungen an den Auftragnehmer: Zertifizierungen (z. B. ISO 9001), Referenzprojekte, Teamgröße, Kommunikationsprozesse, Standort.
• Projektmanagement-Anforderungen: Gewünschte Projektmethodik (Wasserfall, agil, Scrum), Berichtspflichten, Meilensteine, Abnahmekriterien.
• Vertragsrahmen: Budget-Rahmen (optional), Zeitplan, Gewährleistungsregelungen, Sanktionen bei Fristüberschreitung, Regelungen zu Urheberrechten und Quellcode-Übergabe.

Ein Lastenheft für ein Webprojekt – etwa einen Website-Relaunch, eine neue E-Commerce-Plattform oder eine Web-App – zu erstellen, erfordert eine strukturierte Vorgehensweise:

• 1. Stakeholder einbeziehen: Alle internen Beteiligten (Marketing, IT, Geschäftsführung, Vertrieb) sollten ihre Anforderungen einbringen, bevor das Dokument finalisiert wird. Nachträgliche Änderungen sind teuer.
• 2. Ist-Analyse durchführen: Bestehende Website analysieren – Stärken, Schwächen, technische Schulden, Nutzungsdaten aus Analytics – um den Ausgangspunkt klar zu definieren.
• 3. Anforderungen priorisieren: Nicht alle Anforderungen sind gleich wichtig. Eine Priorisierung nach „Muss / Soll / Kann" (MoSCoW-Methode) hilft Auftragnehmern, realistisch zu kalkulieren.
• 4. Konkret und messbar formulieren: Vage Formulierungen wie „die Website soll modern wirken" sind wertlos. Besser: „Die Website soll im Google PageSpeed Insights-Test einen Score von mindestens 90 (mobile) erreichen."

Typische Fehler: Zu vage Zieldefinitionen, fehlende technische Anforderungen (z. B. keine Angabe zur Hosting-Umgebung), kein definiertes Budget (führt zu unrealistischen Angeboten), Lastenheft ohne Einbeziehung der IT-Abteilung sowie das Verwechseln von Lastenheft und Pflichtenheft – also das Hineinschreiben von Lösungsvorschlägen statt Anforderungen.

Das klassische Lastenheft nach DIN 69905 ist ein Instrument des traditionellen, plangetriebenen Projektmanagements (Wasserfallmodell). Es eignet sich besonders dann, wenn Anforderungen stabil und vollständig definierbar sind, mehrere Anbieter verglichen werden sollen oder ein formaler Ausschreibungsprozess (z. B. öffentliche Vergabe) vorgeschrieben ist. In agilen Projekten – insbesondere bei Softwareentwicklung nach Scrum oder Kanban – wird das starre Lastenheft durch flexiblere Formate ersetzt:

• User Stories: Kurze, nutzerorientierte Anforderungsbeschreibungen im Format „Als [Nutzerrolle] möchte ich [Funktion], damit [Nutzen]." Sie sind bewusst offen für Detailklärung im Projektverlauf.
• Product Backlog: Eine priorisierte Liste aller bekannten Anforderungen und Features, die iterativ ergänzt und verfeinert wird – das lebende Äquivalent zum statischen Lastenheft.
• Definition of Done (DoD): Legt fest, wann eine Anforderung als vollständig umgesetzt gilt – funktional vergleichbar mit den Abnahmekriterien im Lastenheft.

Viele Projekte kombinieren beide Ansätze: Ein schlankes Lastenheft für die initiale Ausschreibung und Anbieterauswahl, gefolgt von agiler Projektdurchführung mit User Stories und Sprints.

Ein Lastenheft entfaltet erst dann rechtliche Wirkung, wenn es explizit Bestandteil eines Vertrages wird – etwa als Anlage zu einem Werk- oder Dienstleistungsvertrag. In diesem Fall definiert es verbindlich, welche Leistungen der Auftragnehmer zu erbringen hat, und bildet die Grundlage für die Abnahme sowie für eventuelle Mängelansprüche. Wichtige rechtliche Aspekte im Überblick:

• Abnahmegrundlage: Weicht das gelieferte Ergebnis von den im Lastenheft definierten Anforderungen ab, kann der Auftraggeber die Abnahme verweigern oder Nachbesserung verlangen.
• Haftung bei Unklarheiten: Vage oder widersprüchliche Anforderungen im Lastenheft können im Streitfall zu Lasten des Auftraggebers ausgelegt werden – präzise Formulierungen schützen beide Seiten.
• Änderungsmanagement (Change Requests): Anforderungen, die nach Vertragsschluss hinzukommen oder geändert werden, sind in der Regel nicht vom ursprünglichen Angebot abgedeckt und müssen als kostenpflichtige Change Requests vereinbart werden.
• Urheberrecht und Quellcode: Das Lastenheft sollte regeln, wer nach Projektabschluss die Nutzungsrechte an entwickeltem Code, Design und Dokumentation erhält – ein häufig übersehener, aber rechtlich relevanter Punkt.

Hinweis: Dieser Inhalt dient der allgemeinen Information. Für rechtssichere Vertragsgestaltung empfiehlt sich die Konsultation eines auf IT-Recht spezialisierten Rechtsanwalts.