Ein neues IT-System soll eingeführt werden, eine Maschine wird beschafft oder ein Dienstleister soll beauftragt werden. Bevor irgendjemand anfängt zu programmieren, zu bauen oder zu beraten, braucht es ein klares Dokument: das Lastenheft. Es ist der Grundstein jeder erfolgreichen Beauftragung und stellt sicher, dass Auftraggeber und Auftragnehmer dasselbe Verständnis von den Anforderungen haben.
Trotzdem wird das Lastenheft in der Praxis erstaunlich oft stiefmütterlich behandelt. Die Folgen sind gravierend: Missverständnisse, Nachträge, Budgetüberschreitungen und Projekte, die am tatsächlichen Bedarf vorbeigehen. In diesem Artikel zeigen wir dir, wie du ein professionelles Lastenheft erstellst, geben dir eine fertige Vorlage zum Übernehmen und illustrieren den Aufbau anhand eines konkreten Praxisbeispiels.
Was ist ein Lastenheft?
Das Lastenheft (englisch: Requirements Specification oder Statement of Requirements) ist ein Dokument, das die Gesamtheit aller Anforderungen des Auftraggebers an ein Projekt, ein Produkt oder eine Dienstleistung beschreibt. Es beantwortet die zentrale Frage: Was soll erreicht werden?
Die DIN 69901-5 definiert das Lastenheft als die „Gesamtheit der Anforderungen des Auftraggebers an die Lieferungen und Leistungen eines Auftragnehmers". Dabei geht es bewusst um das Was, nicht um das Wie. Das Lastenheft beschreibt die gewünschten Ergebnisse und Funktionen aus Sicht des Auftraggebers, ohne eine technische Lösung vorzuschreiben.
Kernprinzip: Das Lastenheft beschreibt Anforderungen lösungsneutral. Es definiert, was das System können soll, nicht wie es technisch umgesetzt wird. Die technische Lösung gehört ins Pflichtenheft des Auftragnehmers.
Ein gutes Lastenheft dient mehreren Zwecken gleichzeitig: Es ist Ausschreibungsgrundlage, Vertragsbestandteil, Kommunikationsinstrument zwischen Fach- und IT-Seite sowie Basis für die spätere Abnahme. Ohne Lastenheft fehlt die messbare Grundlage, um am Ende zu beurteilen, ob das gelieferte Ergebnis den Erwartungen entspricht.
Lastenheft vs. Pflichtenheft: Wer erstellt was?
Eine der häufigsten Verwechslungen im Projektmanagement betrifft den Unterschied zwischen Lastenheft und Pflichtenheft. Beide Dokumente sind eng miteinander verzahnt, haben aber grundlegend verschiedene Perspektiven und Verantwortlichkeiten.
| Kriterium | Lastenheft | Pflichtenheft |
|---|---|---|
| Erstellt von | Auftraggeber (Fachseite) | Auftragnehmer (Umsetzer) |
| Perspektive | Was soll erreicht werden? | Wie wird es umgesetzt? |
| Inhalt | Anforderungen, Ziele, Rahmenbedingungen | Technische Lösung, Architektur, Umsetzungsdetails |
| Sprache | Fachlich, lösungsneutral | Technisch, lösungsspezifisch |
| Zeitpunkt | Vor der Ausschreibung / Beauftragung | Nach Beauftragung, vor Umsetzung |
| Verbindlichkeit | Grundlage für Angebote und Verträge | Grundlage für Abnahme und Tests |
| Norm | DIN 69901-5 | DIN 69901-5, VDI/VDE 3694 |
In der Praxis ist der Prozess wie folgt: Der Auftraggeber erstellt das Lastenheft und verschickt es als Ausschreibungsunterlage oder gibt es dem internen Umsetzungsteam. Der Auftragnehmer analysiert das Lastenheft und erstellt darauf basierend das Pflichtenheft, in dem er beschreibt, wie er die Anforderungen technisch umsetzen will. Das Pflichtenheft wird dann vom Auftraggeber freigegeben, bevor die eigentliche Umsetzung beginnt.
Aufbau eines Lastenhefts: Die 10 Kapitel
Ein vollständiges Lastenheft folgt einer bewährten Gliederung. Die folgenden zehn Kapitel bilden die Standardstruktur, die du für die meisten Projekte verwenden kannst. Je nach Projektart und Branche kannst du einzelne Kapitel erweitern oder anpassen.
1. Einführung und Zielsetzung
Das erste Kapitel gibt den Kontext: Warum wird dieses Projekt gestartet? Was ist der Anlass, welches Problem soll gelöst werden? Hier gehören auch der Projektname, die Dokumentenversion und die Ansprechpartner hinein. Der Leser soll nach diesem Kapitel verstehen, worum es geht und warum das Vorhaben wichtig ist.
2. Ausgangssituation / Ist-Zustand
Beschreibe den aktuellen Zustand: Welche Systeme, Prozesse oder Strukturen existieren heute? Welche Probleme und Schwachstellen gibt es? Ohne eine ehrliche Analyse des Ist-Zustands lassen sich Anforderungen nicht sinnvoll formulieren. Dieser Abschnitt schafft die Basis, auf der alle weiteren Anforderungen aufbauen.
3. Soll-Zustand und Ziele
Hier beschreibst du den gewünschten Zielzustand. Wie soll die Welt nach erfolgreicher Umsetzung aussehen? Formuliere die Ziele nach dem SMART-Prinzip: spezifisch, messbar, attraktiv, realistisch und terminiert. Vermeide vage Formulierungen wie „Das System soll benutzerfreundlich sein" und schreibe stattdessen konkret, was Benutzerfreundlichkeit in diesem Kontext bedeutet.
4. Funktionale Anforderungen
Das Herzstück des Lastenhefts: Welche Funktionen muss das System, Produkt oder die Dienstleistung bieten? Jede Anforderung sollte eine eindeutige ID haben (z.B. FA-001), eine klare Beschreibung und eine Priorität (Muss, Soll, Kann). Funktionale Anforderungen beschreiben, was das System tun soll, beispielsweise: „Das System muss es ermöglichen, Bestellungen nach Datum, Status und Kundennummer zu filtern (FA-012)."
5. Nicht-funktionale Anforderungen
Neben den Funktionen gibt es Qualitätsanforderungen: Performance (z.B. Antwortzeiten unter 2 Sekunden), Verfügbarkeit (z.B. 99,5 % Uptime), Sicherheit (z.B. Zwei-Faktor-Authentifizierung), Skalierbarkeit (z.B. bis 10.000 gleichzeitige Nutzer) und Usability (z.B. Bedienbar ohne Schulung). Diese Anforderungen werden in der Praxis häufig vergessen, sind aber entscheidend für die Nutzerzufriedenheit.
6. Rahmenbedingungen und Schnittstellen
Welche technischen, organisatorischen und rechtlichen Rahmenbedingungen gibt es? Muss das System in eine bestehende IT-Landschaft integriert werden? Welche Schnittstellen sind erforderlich (z.B. zu ERP, CRM, E-Mail)? Gibt es regulatorische Anforderungen wie DSGVO, Branchenstandards oder interne Compliance-Vorgaben? Hier gehören auch Einschränkungen wie die vorgegebene Betriebsumgebung hinein.
7. Abnahmekriterien
Definiere messbare Kriterien, anhand derer am Ende geprüft wird, ob die Anforderungen erfüllt sind. Ohne klare Abnahmekriterien endet jedes Projekt in endlosen Diskussionen darüber, ob das Ergebnis „gut genug" ist. Idealerweise formulierst du für jede Muss-Anforderung ein konkretes Abnahmekriterium mit Testfall.
8. Zeitrahmen und Meilensteine
Wann soll das Projekt starten, wann soll es fertig sein? Gibt es Zwischentermine oder externe Deadlines (z.B. regulatorische Fristen, Messen, saisonale Anforderungen)? Definiere die wichtigsten Meilensteine und den gewünschten Zeitrahmen. Beachte: Das Lastenheft gibt den Zeitrahmen vor, der Auftragnehmer prüft im Pflichtenheft die Machbarkeit.
9. Budget und Ressourcen
Gib einen Budgetrahmen vor oder zumindest eine Größenordnung. Ohne Budgetinformation kann kein Auftragnehmer ein realistisches Angebot abgeben. Beschreibe auch, welche internen Ressourcen zur Verfügung stehen (z.B. ein Projektleiter, Testressourcen, Infrastruktur). Manche Organisationen geben das Budget bewusst nicht preis, um marktgerechte Angebote zu erhalten. In diesem Fall solltest du zumindest die Budgetklasse angeben.
10. Anhänge und Glossar
Sammle hier ergänzende Dokumente: Prozessdiagramme, Screenshots des Ist-Systems, Datenmodelle, Glossar für Fachbegriffe. Ein Glossar ist besonders wichtig, wenn Auftraggeber und Auftragnehmer aus verschiedenen Fachdomänen kommen. Jeder Begriff sollte einheitlich definiert sein, um Missverständnisse zu vermeiden.
Lastenheft Vorlage: Praktisches Muster zum Übernehmen
Die folgende Vorlage kannst du als Ausgangspunkt für dein eigenes Lastenheft verwenden. Passe die Inhalte an dein Projekt an und ergänze fehlende Informationen. Die Struktur orientiert sich an den oben beschriebenen zehn Kapiteln.
Lastenheft-Vorlage
1. Einführung und Zielsetzung
Projektname: [Name des Projekts] Version: [1.0] | Datum: [TT.MM.JJJJ] | Autor: [Name, Abteilung] Anlass und Motivation: [Warum wird das Projekt gestartet? Welches Problem soll gelöst werden?] Projektziel: [Was soll am Ende erreicht sein? SMART formulieren.]2. Ausgangssituation (Ist-Zustand)
Aktuelle Systeme / Prozesse: [Beschreibung der bestehenden Lösung] Probleme und Schwachstellen: [Was funktioniert heute nicht oder schlecht?] Betroffene Nutzergruppen: [Wer arbeitet mit dem aktuellen System?]3. Soll-Zustand und Ziele
Zielzustand: [Wie soll die Lösung nach Umsetzung aussehen?] Erfolgskriterien: [Woran wird der Erfolg messbar gemacht?]4. Funktionale Anforderungen
- FA-001: [Anforderung] | Priorität: Muss / Soll / Kann
- FA-002: [Anforderung] | Priorität: Muss / Soll / Kann
- FA-003: [Anforderung] | Priorität: Muss / Soll / Kann
5. Nicht-funktionale Anforderungen
- NFA-001: Performance: [z.B. Antwortzeit < 2 Sekunden]
- NFA-002: Verfügbarkeit: [z.B. 99,5 % Uptime]
- NFA-003: Sicherheit: [z.B. Verschlüsselung, Authentifizierung]
- NFA-004: Skalierbarkeit: [z.B. bis X gleichzeitige Nutzer]
6. Rahmenbedingungen und Schnittstellen
Technische Rahmenbedingungen: [Bestehende IT-Landschaft, Betriebssysteme, Browser] Schnittstellen: [ERP, CRM, E-Mail, externe APIs] Regulatorische Anforderungen: [DSGVO, Branchenstandards, Compliance]7. Abnahmekriterien
Kriterium 1: [Messbare Bedingung für die Abnahme] Kriterium 2: [Messbare Bedingung für die Abnahme] Testverfahren: [Wie wird geprüft? Wer prüft?]8. Zeitrahmen und Meilensteine
Projektstart: [TT.MM.JJJJ] | Geplantes Ende: [TT.MM.JJJJ] Meilenstein 1: [Beschreibung] bis [TT.MM.JJJJ] Meilenstein 2: [Beschreibung] bis [TT.MM.JJJJ]9. Budget und Ressourcen
Budgetrahmen: [Betrag oder Größenordnung] Interne Ressourcen: [Projektleiter, Fachexperten, Testteam]10. Anhänge und Glossar
Anhang A: [Prozessdiagramme, Screenshots, Datenmodelle] Glossar: [Fachbegriffe und ihre Definitionen]Lastenheft Beispiel: Mitarbeiterportal
Um den Aufbau greifbar zu machen, zeigen wir hier einen Auszug aus einem realistischen Lastenheft für die Einführung eines Mitarbeiterportals in einem mittelständischen Unternehmen mit 500 Mitarbeitern.
Lastenheft: Einführung Mitarbeiterportal (Auszug)
1. Einführung
Die Müller GmbH (500 Mitarbeiter, 3 Standorte) plant die Einführung eines zentralen Mitarbeiterportals. Ziel ist die Digitalisierung aller HR-Self-Service-Prozesse und die Verbesserung der internen Kommunikation. Aktuell laufen Urlaubsanträge, Krankmeldungen und Gehaltsabrechnungen über Papierformulare und E-Mail, was zu hohem Verwaltungsaufwand und langen Bearbeitungszeiten führt.
2. Ist-Zustand
Urlaubsanträge: Papierformular, Durchlaufzeit 3-5 Werktage. Krankmeldungen: Per E-Mail an Vorgesetzten und HR, keine zentrale Erfassung. Gehaltsabrechnungen: Per Post, Kosten ca. 8.400 EUR/Jahr. Interne News: Per E-Mail-Verteiler, keine Bestätigung ob gelesen.
3. Soll-Zustand und Ziele
Alle HR-Self-Service-Prozesse sollen über ein zentrales, web-basiertes Portal abgewickelt werden. Mitarbeiter sollen eigenständig Urlaubsanträge stellen, Krankmeldungen einreichen, Gehaltsabrechnungen abrufen und persönliche Daten pflegen können.
- Ziel 1: Reduktion der manuellen HR-Verwaltungsaufgaben um 60%
- Ziel 2: Durchlaufzeit für Urlaubsanträge unter 24 Stunden
- Ziel 3: Papierlose Abwicklung aller Standardprozesse bis Q4 2026
- Ziel 4: Mitarbeiterzufriedenheit mit HR-Services von 3,2 auf 4,5 (Skala 1-5)
4. Funktionale Anforderungen (Auszug)
- FA-001: Das Portal muss eine digitale Urlaubsantragstellung mit Genehmigungsworkflow ermöglichen. | Priorität: Muss
- FA-002: Mitarbeiter müssen ihre Gehaltsabrechnungen der letzten 24 Monate als PDF abrufen können. | Priorität: Muss
- FA-003: Das Portal muss eine News-Sektion mit Lesebestätigung bieten. | Priorität: Soll
- FA-004: Vorgesetzte müssen Abwesenheitsübersichten ihres Teams einsehen können. | Priorität: Muss
- FA-005: Mitarbeiter müssen persönliche Daten (Adresse, Bankverbindung) selbst ändern können, mit Freigabe durch HR. | Priorität: Soll
5. Nicht-funktionale Anforderungen (Auszug)
- NFA-001: Seitenladezeit maximal 3 Sekunden bei 100 gleichzeitigen Nutzern.
- NFA-002: Responsive Design für mobile Nutzung (Smartphone/Tablet).
- NFA-003: DSGVO-konforme Datenhaltung, Serverstandort Deutschland.
- NFA-004: Single Sign-On über bestehendes Active Directory.
6. Rahmenbedingungen und Schnittstellen
- Integration in bestehendes Active Directory (Microsoft Entra ID) für Single Sign-On
- Schnittstelle zum SAP-HR-Modul für Stammdaten-Synchronisation
- Schnittstelle zum Lohnabrechnungssystem DATEV für Gehaltsabrechnungen
- E-Mail-Benachrichtigungen über Microsoft Exchange Server
- DSGVO-konforme Datenhaltung, Serverstandort Deutschland
- Hosting: Cloud (SaaS) oder On-Premises, Entscheidung im Pflichtenheft
7. Abnahmekriterien
- Alle Muss-Anforderungen (FA-001, FA-002, FA-004) funktionsfähig und getestet
- Erfolgreicher Pilotbetrieb mit 50 Nutzern über 4 Wochen ohne kritische Fehler
- Seitenladezeit unter 3 Sekunden bei 100 gleichzeitigen Nutzern (Lasttest)
- Positives Ergebnis eines externen DSGVO-Audits
- Schulung von mindestens 10 HR-Key-Usern abgeschlossen
8. Zeitrahmen und Meilensteine
- Projektstart: Februar 2026
- Meilenstein 1: Konzeptfreigabe und Anbieterauswahl bis April 2026
- Meilenstein 2: Pilotbetrieb mit 50 Nutzern (Standort München) bis Juni 2026
- Meilenstein 3: Rollout auf alle 3 Standorte bis August 2026
- Go-Live: September 2026 (Q3)
- Hypercare-Phase: 4 Wochen intensiver Support nach Go-Live
9. Budget und Zeitrahmen
Budgetrahmen: 80.000-120.000 EUR (einmalig) zzgl. max. 1.500 EUR/Monat laufende Kosten. Gewünschter Go-Live: Q3 2026. Meilenstein 1: Konzeptfreigabe bis April 2026. Meilenstein 2: Pilotbetrieb mit 50 Nutzern bis Juni 2026.
Dieses Beispiel zeigt, wie konkret und messbar Anforderungen formuliert werden sollten. Jede Anforderung hat eine ID, eine klare Beschreibung und eine Priorität. Der Auftragnehmer kann auf dieser Basis ein belastbares Angebot erstellen.
5 typische Fehler beim Lastenheft
Die folgenden Fehler begegnen uns in der Praxis immer wieder. Vermeide sie, um dein Projekt von Anfang an auf ein solides Fundament zu stellen.
-
Lösung statt Anforderung beschreiben Der häufigste Fehler: Das Lastenheft beschreibt eine technische Lösung statt einer fachlichen Anforderung. Statt „Das System nutzt eine PostgreSQL-Datenbank" sollte es heißen: „Das System muss Daten persistent speichern und innerhalb von 2 Sekunden abrufen können." Die Wahl der Datenbank ist Sache des Auftragnehmers.
-
Nicht-funktionale Anforderungen vergessen Funktionale Anforderungen bekommen meist genug Aufmerksamkeit. Aber Performance, Sicherheit, Skalierbarkeit und Usability werden regelmäßig vergessen. Das rächt sich spätestens im Betrieb, wenn das System zwar funktioniert, aber unerträglich langsam ist oder Sicherheitslücken hat.
-
Unklare oder mehrdeutige Formulierungen Begriffe wie „benutzerfreundlich", „schnell" oder „modern" sind subjektiv und nicht messbar. Jede Anforderung muss so formuliert sein, dass zwei verschiedene Personen sie gleich verstehen. Nutze Zahlen, Beispiele und klare Definitionen. Wenn du „schnell" meinst, schreibe „Antwortzeit unter 2 Sekunden bei 95 % aller Anfragen."
-
Stakeholder nicht einbinden Das Lastenheft wird oft von einer einzelnen Person geschrieben, ohne die tatsächlichen Nutzer und Stakeholder zu befragen. Das führt zu Anforderungen, die am realen Bedarf vorbeigehen. Führe Interviews mit allen relevanten Nutzergruppen und lass das Lastenheft vor der Finalisierung reviewen.
-
Keine Priorisierung der Anforderungen Wenn alle Anforderungen gleich wichtig sind, ist keine wichtig. Ohne Priorisierung (Muss/Soll/Kann) kann der Auftragnehmer bei Budgetengpässen oder Zeitdruck nicht sinnvoll entscheiden, was zuerst umgesetzt wird. Die MoSCoW-Methode (Must, Should, Could, Won't) hat sich in der Praxis bewährt.
Vom Lastenheft zum Projektplan: KI-gestützte Weiterverarbeitung
Das Lastenheft ist erstellt, die Anforderungen sind klar formuliert. Doch was kommt danach? Der nächste Schritt ist die Überführung der Anforderungen in einen konkreten Projektplan mit Phasen, Aufgaben, Meilensteinen und Zeitrahmen. Genau hier kommt künstliche Intelligenz ins Spiel.
PathHub AI kann deine Anforderungen aus dem Lastenheft automatisch in einen strukturierten Projektplan übersetzen. Die KI analysiert die funktionalen und nicht-funktionalen Anforderungen, erkennt Abhängigkeiten und erstellt einen realistischen Zeitplan mit Phasen und Arbeitspaketen. Das spart nicht nur Zeit, sondern vermeidet auch die typischen Fehler bei der manuellen Überführung: vergessene Anforderungen, unrealistische Zeitschätzungen und fehlende Abhängigkeiten.
Praxis-Tipp: Beschreibe dein Projekt in PathHub AI so detailliert wie möglich, am besten mit den Kerninhalten deines Lastenhefts. Je mehr Kontext die KI hat, desto präziser wird der generierte Projektplan mit Budget, Zeitrahmen und Stakeholder-Analyse.
Der Vorteil gegenüber der manuellen Planung: Die KI berücksichtigt Erfahrungswerte aus tausenden von Projekten und schätzt Aufwände realistischer ein, als es ein einzelner Projektleiter könnte. Natürlich ersetzt das nicht die menschliche Überprüfung, aber es liefert eine fundierte Basis, auf der du aufbauen kannst. Mehr dazu erfährst du in unserem Artikel über die Erstellung von Projektplänen.
Häufig gestellte Fragen
Das Lastenheft wird vom Auftraggeber erstellt und beschreibt, WAS gewünscht wird (Anforderungen aus Kundensicht). Das Pflichtenheft wird vom Auftragnehmer erstellt und beschreibt, WIE die Anforderungen umgesetzt werden (technische Lösung). Das Lastenheft ist die Grundlage für das Pflichtenheft. Beide Dokumente zusammen bilden die vertragliche Basis für ein Projekt.
Der Umfang hängt von der Projektgröße ab. Für kleine Projekte reichen 5-10 Seiten, für mittlere Projekte 15-30 Seiten und für Großprojekte können es 50 oder mehr Seiten sein. Wichtiger als die Seitenzahl ist die Vollständigkeit und Eindeutigkeit: Alle Anforderungen müssen klar, messbar und nachvollziehbar beschrieben sein. Lieber ein kurzes, präzises Lastenheft als ein umfangreiches, das voller vager Formulierungen steckt.
Das Lastenheft wird grundsätzlich vom Auftraggeber erstellt, also von der Organisation oder Fachabteilung, die das Projekt beauftragt. In der Praxis unterstützen oft Requirements Engineers, Business Analysten oder externe Berater bei der Erstellung. Wichtig ist, dass die Fachseite die inhaltliche Verantwortung behält und alle relevanten Stakeholder einbezogen werden, um keine Anforderungen zu übersehen.
Die DIN 69901-5 definiert das Lastenheft als die „Gesamtheit der Anforderungen des Auftraggebers an die Lieferungen und Leistungen eines Auftragnehmers". Für Automatisierungsprojekte gibt die VDI/VDE 3694 eine zusätzliche Gliederungsempfehlung. In der Softwareentwicklung orientiert sich der Aufbau häufig an IEEE 830 (Software Requirements Specification). In der Praxis verwenden die meisten Organisationen eine eigene, an die Branche angepasste Vorlage.