Lastenheft: Definition, Inhalt & Pflichtenheft

Ein Lastenheft ist ein Dokument aus Sicht des Auftraggebers, das beschreibt, was eine geplante Lösung leisten soll: Ziele, fachliche Anforderungen, Rahmenbedingungen und oft auch Kriterien für spätere Abnahmen. Es fokussiert den Problem- und Wunschraum und soll Angebote vergleichbar machen. Technische Umsetzungsdetails gehören typischerweise eher in ein Pflichtenheft des Anbieters.

Das Lastenheft formuliert aus Kundensicht die Ziele und Anforderungen – das „was und wofür“. Das Pflichtenheft beschreibt aus Sicht des Auftragnehmers die geplante Lösung und Umsetzung – das „wie“. In klassischen Abläufen folgt das Pflichtenheft oft dem Lastenheft; in agilen Projekten können die Inhalte in Backlogs und Spezifikationen aufgeteilt werden, behalten aber ähnliche Rollen.

Üblich sind unter anderem Ausgangslage und Ziele, Stakeholder, ein Prozessüberblick, funktionale Anforderungen mit Prioritäten (Muss/Soll/Kann), Daten und Schnittstellen, nicht-funktionale Vorgaben wie Verfügbarkeit, Reporting, Rollout sowie Abnahme- und Testkriterien. Je nach Branche kommen regulatorische Randbedingungen dazu. Wichtig ist, dass Anforderungen möglichst überprüfbar formuliert sind.

Für das Lastenheft liefern HR/People Ops den fachlichen Kern, IT Architektur- und Sicherheitsaspekte, Datenschutz die datenschutzrechtliche Einordnung; Einkauf oder Projektleitung halten oft Fristen und Formate ein. Das Pflichtenheft verfasst der Anbieter oder Systemintegrator – mit Verweis auf das freigegebene Lastenheft. Eine klare RACI-Matrix verhindert, dass Reviews hängen bleiben oder doppelte Textversionen kursieren.

Ein Lastenheft ist nicht automatisch „Gesetz“. Rechtswirkungen entstehen erst, wenn es vertraglich einbezogen wird – etwa als Anlage, Leistungsbeschreibung oder Referenz in Ausschreibung und Angebot. Dann können Abweichungen vertragliche Folgen haben. Im Einzelfall solltest du das mit Recht und Einkauf klären; dieser Artikel ersetzt keine anwaltliche Beratung.

Ja, als Rahmendokument für Ziele und Anforderungen bleibt es relevant – auch wenn agile Teams Details eher in User Stories und Akzeptanzkriterien pflegen. Viele Organisationen kombinieren ein schlankes Lastenheft für Vertrag und Governance mit iterativer Ausarbeitung. Entscheidend ist nicht das Format allein, sondern ob Scope, Qualität und Abnahme nachvollziehbar geregelt sind.

Formuliere testbare Kriterien statt vager Adjektive. Statt „benutzerfreundlich“ besser messbare Abläufe, Rollen und Grenzfälle benennen. Nutze Prioritäten (Muss/Soll/Kann), eindeutige Begriffe und – wo sinnvoll – Akzeptanzkriterien je Modul oder Epic. So werden spätere Tests und Abnahmen weniger interpretationssabhängig und Change Requests leichter begründbar.

Ein Software-Lastenheft für HR fasst fachliche Vorgaben für Systeme wie Personalverwaltung, Zeiterfassung, Abwesenheiten, Payroll-Schnittstellen oder digitale Personalakten zusammen. Es beschreibt Prozesse, Rollen, Datenflüsse, Integrationen und Reporting – nicht die konkrete Parametrisierung, die oft erst in der Realisierung festgelegt wird. Zum Einordnen von Dokumentation und Zugriffen siehe auch den Lexikonbeitrag zur Personalakte Inhalt.

Im Lastenheft sollten Zwecke, betroffene Datenkategorien, Zugriffs- und Aufbewahrungsanforderungen sowie Anforderungen an Nachweise (z. B. Protokolle) aus fachlicher Sicht stehen. Die technische Umsetzung folgt im Pflichtenheft oder in Architekturkonzepten. Tiefergehende Datenschutzfolgenabschätzungen sind separate Verfahren; Grundlagen liefert der Lexikonbeitrag zur DSGVO.

Sinnvoll ist es vor der detaillierten Anbieterauswahl oder spätestens vor verbindlichen Leistungsbeschreibungen in Vertrag und Budget. So werden Ziele, Scope und Ausschlüsse gemeinsam geschärft. In agilen Projekten kann ein schlankes Lastenheft die Release- und Budgetreferenz bleiben, während Details iterativ nachgereicht werden – wichtig ist eine klare Entscheidung, welche Teile verbindlich sind.

Je nach Organisation nutzen Teams Product Backlogs mit Akzeptanzkriterien, Service-Blueprints, RfP-Kataloge oder domänenspezifische Standards. In regulierten Bereichen bleibt ein formales Dokument oft unverzichtbar. Entscheidend ist, dass Anforderungen versioniert, abgestimmt und gegen Tests spielbar bleiben – unabhängig vom Medium.

Im internationalen Sprachgebrauch steht häufig requirements specification oder requirements document für die kundenseitige Beschreibung des Bedarfs. Es gibt keine 1:1-Übersetzung, die in jedem Unternehmen identisch verwendet wird; in Ausschreibungen solltest du deshalb Glossare und Definitionen festlegen, damit alle Beteiligten dieselben Begriffe meinen.

Das Lastenheft liefert die Abnahmekriterien aus fachlicher Sicht: Welche Funktionen und Qualitäten müssen in welcher Form nachweisbar erfüllt sein? Darauf bauen Testpläne, Piloten und Übergaben auf. Ohne klare, testbare Anforderungen werden Abnahmen schnell zu Interpretationsstreitigkeiten zwischen Fachbereich und Anbieter.

Nicht zwingend unter genau diesem Namen – aber ein vergleichbares, freigegebenes Anforderungs- und Scope-Dokument ist in fast allen mittleren und großen Projekten sinnvoll. Kleine Standard-SaaS-Einführungen können mit Checklisten und Workshops auskommen, sobald Risiko, Stakeholder-Zahl und Individualisierung überschaubar bleiben. Wächst Komplexität oder Mitbestimmung, lohnt sich die Formalisierung früh.