Lastenheft-Vorlage für IT-Projekte: Gliederung und Textbausteine

Die meisten frei verfügbaren Lastenheft-Vorlagen scheitern an derselben Stelle: Sie liefern eine Kapitelnummerierung, aber keine Antwort darauf, was in ein Kapitel gehört und wie man es formuliert. Ein Lastenheft mit zwölf leeren Überschriften ist kein Lastenheft.

Diese Vorlage für IT-Projekte ist deshalb anders aufgebaut: Zu jedem Kapitel steht, welche Frage es beantwortet, ein konkretes Formulierungsbeispiel und der Fehler, der dort typischerweise gemacht wird. Sie können die Gliederung direkt übernehmen und die Beispiele als Muster für Ihre eigenen Formulierungen nutzen. Was der Unterschied zwischen Lastenheft und Pflichtenheft ist und wie beide zusammenspielen, erklärt der Ratgeber Lastenheft & Pflichtenheft erstellen.

Die Lastenheft-Vorlage: Gliederung im Überblick

Kapitel	Beantwortet die Frage	Umfang
1. Ausgangslage & Anlass	Warum machen wir dieses Projekt?	½–1 Seite
2. Ziele & Erfolgskriterien	Woran messen wir Erfolg?	½–1 Seite
3. Ist-Zustand	Was gibt es heute?	1–3 Seiten
4. Nutzergruppen & Rollen	Wer arbeitet damit?	½–1 Seite
5. Funktionale Anforderungen	Was muss das System können?	3–20 Seiten
6. Nicht-funktionale Anforderungen	Wie gut muss es das können?	1–3 Seiten
7. Schnittstellen	Womit muss es sprechen?	1–3 Seiten
8. Daten & Migration	Was zieht mit um?	½–2 Seiten
9. Rahmenbedingungen & Vorgaben	Was ist gesetzt?	½–1 Seite
10. Abgrenzung	Was ist ausdrücklich nicht Teil?	¼–½ Seite
11. Mitwirkung & Organisation	Was liefern wir selbst?	½ Seite
12. Termine, Budget & Angebotsformalitäten	Bis wann, wofür, wie einreichen?	½ Seite

Eine gesetzlich vorgeschriebene Gliederung gibt es nicht. Die Begriffe selbst sind allerdings in der DIN 69901-5 definiert: Das Lastenheft beschreibt die vom Auftraggeber festgelegte Gesamtheit der Forderungen an Lieferungen und Leistungen, das Pflichtenheft die vom Auftragnehmer daraus erarbeiteten Realisierungsvorgaben. Wer sich an dieser Aufteilung orientiert, vermeidet den häufigsten Fehler – nämlich als Auftraggeber bereits Lösungen zu beschreiben.

Die zwölf Kapitel im Detail

1. Ausgangslage und Anlass

Zweck: Anbieter verstehen, warum es das Projekt gibt. Das beeinflusst jede spätere Entscheidung.

Beispiel: „Unsere Auftragsabwicklung läuft seit 2011 über eine selbst entwickelte Access-Datenbank. Sie ist nicht mehrbenutzerfähig, aus dem Homeoffice nicht erreichbar und wird nur von einer Person betreut, die 2027 in den Ruhestand geht. Pro Monat entstehen rund 20 Stunden manueller Nacharbeit."

Typischer Fehler: Der Anlass fehlt ganz. Ohne ihn kann kein Anbieter beurteilen, welche Kompromisse akzeptabel sind.

2. Ziele und Erfolgskriterien

Zweck: Messbar machen, wann das Projekt erfolgreich war.

Beispiel: „Ziel 1: Die manuelle Nacharbeit sinkt von 20 auf unter 5 Stunden pro Monat. Ziel 2: Alle 14 Mitarbeitenden im Vertrieb können gleichzeitig und ortsunabhängig arbeiten. Ziel 3: Auswertungen, die heute 2 Tage brauchen, stehen tagesaktuell zur Verfügung."

Typischer Fehler: Ziele wie „mehr Effizienz" oder „moderne Oberfläche". Nicht messbar, also nicht abnahmefähig.

3. Ist-Zustand

Zweck: Grundlage für die Aufwandsschätzung. Der Ist-Zustand entscheidet über den Preis mehr als die Wunschliste.

Inhalt: eingesetzte Systeme mit Version, Datenmengen (Anzahl Datensätze je Bereich), Zahl der Nutzenden, bestehende Schnittstellen, heutiger Prozessablauf in Schritten, bekannte Probleme.

Typischer Fehler: Nur die Probleme beschreiben, nicht die Mengen. „Viele Kunden" ist keine Angabe; „38.000 Kundendatensätze, davon rund 6.000 aktiv" ist eine.

4. Nutzergruppen und Rollen

Zweck: Zahl und Art der Rollen bestimmen den Aufwand für Rechteverwaltung und Oberflächen erheblich.

Beispiel: „Innendienst (14 Personen, täglich, erfassen Aufträge), Außendienst (6 Personen, mobil, lesen und ergänzen), Geschäftsführung (2 Personen, wöchentlich, nur Auswertungen), Administration (1 Person, verwaltet Stammdaten und Rechte)."

Typischer Fehler: Rollen ohne Häufigkeit und Gerät. Ob jemand täglich am Schreibtisch oder monatlich am Telefon arbeitet, ändert die Lösung.

5. Funktionale Anforderungen

Zweck: Das Herzstück. Beschreiben Sie, was möglich sein muss – nicht, wie es technisch umgesetzt wird.

Beispiel: „A-012 (MUSS): Das System muss Aufträge aus einer CSV-Datei importieren können. Fehlerhafte Zeilen müssen mit Zeilennummer und Fehlergrund ausgewiesen werden, der Rest wird importiert. Prüfkriterium: Ein Import mit 500 Zeilen, davon 3 fehlerhaft, importiert 497 Datensätze und zeigt 3 benannte Fehler."

Typischer Fehler: Anforderungen ohne Nummer, ohne Priorität und ohne Prüfkriterium. Alle drei brauchen Sie später für Angebotsvergleich und Abnahme.

6. Nicht-funktionale Anforderungen

Zweck: Sie treiben den Aufwand oft stärker als die Funktionen selbst und werden am häufigsten vergessen.

Inhalt: Antwortzeiten (mit Messpunkt), Verfügbarkeit, gleichzeitige Nutzung, Browser und Geräte, Barrierefreiheit, Datenschutz und Protokollierung, Mehrsprachigkeit, Betriebsort der Daten, Sicherungs- und Wiederherstellungszeiten.

Beispiel: „NF-03: Die Auftragsliste mit 500 Einträgen muss innerhalb von 2 Sekunden vollständig dargestellt sein, gemessen im Firmennetz auf einem Standardarbeitsplatz."

Typischer Fehler: „Das System muss schnell und sicher sein." Nicht prüfbar, also wertlos.

7. Schnittstellen

Zweck: Jede Schnittstelle ist ein eigenes Risiko. Listen Sie alle auf – auch Dateiablagen und manuelle Exporte.

Beispiel: „S-02: Übergabe von Rechnungsdaten an die Buchhaltungssoftware [Produkt, Version]. Heute: manueller CSV-Export, 2× pro Woche. Ziel: automatisch, täglich. Ansprechpartner beim Hersteller ist benannt, eine Schnittstellendokumentation liegt vor."

Typischer Fehler: Schnittstellen erwähnen, aber nicht sagen, ob eine Dokumentation existiert und wer beim Fremdsystem zuständig ist. Genau daran scheitern Zeitpläne.

8. Daten und Migration

Zweck: Klären, was übernommen wird – und in welcher Qualität es vorliegt.

Beispiel: „Zu migrieren: Kunden (38.000), Aufträge ab 2020 (112.000), Artikel (4.200). Bekannte Qualitätsprobleme: Dubletten bei Kunden geschätzt 5 %, Datumsangaben teilweise als Text. Historische Aufträge vor 2020 werden nicht migriert, sondern archiviert."

Typischer Fehler: „Die Daten werden übernommen." Ohne Mengen und Qualitätsangabe kann niemand den Aufwand schätzen (siehe Datenmigration).

9. Rahmenbedingungen und Vorgaben

Zweck: Alles, was gesetzt ist und nicht zur Diskussion steht.

Inhalt: vorhandene Infrastruktur, verpflichtende Standards, Betriebsort der Daten, bestehende Lizenzen, interne IT-Richtlinien, regulatorische Anforderungen.

Typischer Fehler: Eine Technologie vorschreiben, ohne dass es dafür einen Grund gibt. Damit schließen Sie unnötig Anbieter aus und verlieren gute Vorschläge.

10. Abgrenzung

Zweck: Das kürzeste und wirksamste Kapitel. Es verhindert Missverständnisse in Angeboten.

Beispiel: „Nicht Teil des Projekts: Ablösung der Buchhaltungssoftware, Einführung eines Dokumentenmanagements, Schulung über die genannten zwei Tage hinaus, Betrieb der Infrastruktur."

Typischer Fehler: Weglassen. Ohne Abgrenzung kalkulieren Anbieter unterschiedliche Umfänge – und Sie vergleichen anschließend Angebote für verschiedene Projekte.

11. Mitwirkung und Organisation

Zweck: Sichtbar machen, was Sie selbst beitragen. Das erhöht die Qualität der Angebote spürbar.

Beispiel: „Projektverantwortliche: [Name], erreichbar mit 1 Tag pro Woche, Vertretung: [Name]. Testdaten werden von uns bereitgestellt. Fachliche Rückfragen werden innerhalb von 3 Arbeitstagen beantwortet. Abnahmetests führen wir mit 3 Personen durch."

12. Termine, Budget und Angebotsformalitäten

Zweck: Vergleichbarkeit herstellen.

Beispiel: „Angebotsfrist: [Datum]. Gewünschter Projektstart: [Datum]. Produktivsetzung spätestens: [Datum]. Budgetrahmen: [Spanne]. Bitte gliedern Sie das Angebot nach den Kapiteln 5 bis 8 und weisen Sie den Aufwand je Position in Personentagen aus. Bitte nennen Sie die laufenden Kosten nach Projektende getrennt."

Typischer Fehler: Kein Budgetrahmen. Die Sorge, dadurch teurer einzukaufen, ist meist unbegründet – ohne Rahmen kalkulieren Anbieter ins Blaue.

Anforderungen richtig formulieren: Satzschablone und Priorisierung

Die Qualität eines Lastenhefts hängt weniger an der Gliederung als an der Formulierung der einzelnen Anforderungen. Zwei Werkzeuge genügen.

Die Satzschablone. Jede Anforderung nach demselben Muster: [Kennung] Das System [muss/soll/kann] [Bedingung] [Objekt] [Tätigkeit]. Beispiel: „A-023: Das System muss beim Speichern eines Auftrags ohne Kundennummer eine Fehlermeldung anzeigen und den Auftrag nicht speichern." Das klingt hölzern und ist genau deshalb prüfbar.

Die Priorisierung. Drei Stufen genügen: MUSS (ohne diese Anforderung ist das Ergebnis unbrauchbar), SOLL (wichtig, aber verschiebbar), KANN (wünschenswert). Entscheidend ist die Disziplin: Wenn mehr als die Hälfte der Anforderungen MUSS ist, wurde nicht priorisiert. Genau diese Einstufung erlaubt es Anbietern, Ihnen eine bezahlbare erste Ausbaustufe vorzuschlagen – und Ihnen, Angebote sinnvoll zu vergleichen. Mehr dazu in Anforderungen richtig definieren.

Wie umfangreich muss ein Lastenheft sein?

Projektgröße	Umfang	Aufwand intern	Anforderungen
bis 25.000 €	3–6 Seiten	1–3 Tage	15–30
25.000 – 100.000 €	10–20 Seiten	5–10 Tage	40–100
über 100.000 €	25–60 Seiten	15–30 Tage	100–300

Diese Zeit ist die günstigste Investition im ganzen Projekt: Jede Anforderung, die vor Vertragsschluss geklärt wird, kostet einen Bruchteil dessen, was ihre Klärung während der Entwicklung kostet. Wenn intern die Kapazität fehlt, ist eine bezahlte Vorstudie durch einen Dienstleister eine Option – lassen Sie sich das Ergebnis dann so übergeben, dass Sie damit auch bei anderen Anbietern ausschreiben können.

Vorlage benutzen – aber nicht abschreiben

Drei Hinweise zum Umgang mit jeder Lastenheft-Vorlage, auch dieser:

• Leere Kapitel streichen. Ein Kapitel „Mehrsprachigkeit: entfällt" ist besser als eines mit Platzhaltertext – aber ein gestrichenes Kapitel ist ehrlicher als beides.
• Keine Lösungen vorschreiben. Sobald Sie Datenbanktechnologien oder Bedienkonzepte festlegen, nehmen Sie Anbietern die Möglichkeit, es besser zu machen – und übernehmen die Verantwortung für die Entscheidung.
• Von jemandem gegenlesen lassen, der nicht beteiligt war. Jede Stelle, an der diese Person nachfragen muss, ist eine Stelle, an der ein Anbieter falsch kalkuliert.

Was rechtlich daran hängt: Wird das Lastenheft Vertragsbestandteil, definiert es bei einem Werkvertrag den geschuldeten Erfolg und damit den Maßstab für die Abnahme. Ein Kostenanschlag ist dagegen im Zweifel nicht zu vergüten und nicht verbindlich, solange nichts anderes vereinbart ist – die Abgrenzung zwischen Kostenanschlag und verbindlichem Angebot gehört deshalb in den Vertrag. In Österreich enthält § 1170a ABGB eine eigene Regelung zum Kostenvoranschlag und zu dessen beträchtlicher Überschreitung.

Kurz gefasst

Eine brauchbare Lastenheft-Vorlage für IT-Projekte hat zwölf Kapitel, von denen vier regelmäßig fehlen: Ist-Zustand mit Mengenangaben, nicht-funktionale Anforderungen, Abgrenzung und eigene Mitwirkung. Formulieren Sie jede Anforderung nach derselben Satzschablone, geben Sie ihr eine Kennung, eine Priorität und ein Prüfkriterium. Beschreiben Sie das Was, nicht das Wie. Und rechnen Sie mit ein bis zehn Tagen eigener Arbeit je nach Projektgröße – es ist die günstigste Zeit, die Sie im gesamten Projekt investieren.

Häufige Fragen

Gibt es eine verbindliche Lastenheft-Vorlage?

Nein. Die DIN 69901-5 definiert den Begriff, schreibt aber keine Gliederung vor. Die zwölf Kapitel oben haben sich in IT-Projekten bewährt; entscheidend ist nicht ihre Reihenfolge, sondern dass die Inhalte vorkommen – insbesondere Ist-Zustand, nicht-funktionale Anforderungen und Abgrenzung.

Wie lang sollte ein Lastenheft für ein IT-Projekt sein?

So kurz wie möglich, so lang wie nötig: 3 bis 6 Seiten für kleine Vorhaben, 10 bis 20 Seiten im mittleren Bereich, 25 bis 60 Seiten für große Projekte. Als Maßstab taugt die Zahl der Anforderungen besser als die Seitenzahl. Ein 60-seitiges Dokument mit 20 prüfbaren Anforderungen ist schwächer als ein 8-seitiges mit 40.

Wer schreibt das Lastenheft – wir oder die Agentur?

Grundsätzlich der Auftraggeber: Es beschreibt Ihren Bedarf, und nur Sie kennen ihn. Wenn intern Kapazität oder Erfahrung fehlt, können Sie die Erstellung als eigenständige, bezahlte Vorleistung vergeben – idealerweise an jemanden, der nicht anschließend die Umsetzung anbietet, oder mit der klaren Vereinbarung, dass Sie das Ergebnis frei für eine Ausschreibung verwenden dürfen.

Brauche ich ein Lastenheft, wenn wir agil arbeiten wollen?

Ja, aber in anderer Tiefe. Für die Beauftragung brauchen Sie Ziele, Rahmenbedingungen, Rollen, Schnittstellen und die groben Funktionsbereiche – die feine Ausarbeitung entsteht dann laufend im Product Backlog. Ohne dieses Grundgerüst kann niemand ein Angebot kalkulieren, auch nicht für ein agiles Vorgehen.

Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?

Das Lastenheft beschreibt die Forderungen des Auftraggebers, das Pflichtenheft die daraus abgeleiteten Realisierungsvorgaben des Auftragnehmers. Kurz: Das eine ist die Frage, das andere die verbindliche Antwort. Wie das Pflichtenheft entsteht, beschreibt Pflichtenheft erstellen.

Sollte man das Budget im Lastenheft nennen?

Ja, als Rahmen. Ohne ihn erhalten Sie Angebote, die um den Faktor fünf auseinanderliegen, weil jeder Anbieter einen anderen Zuschnitt unterstellt. Ein Korridor („zwischen 60.000 und 90.000 €") lenkt den Vorschlag, ohne den Preis zu diktieren – und spart allen Beteiligten eine Verhandlungsrunde.

Wie geht man mit Anforderungen um, die sich später ändern?

Über ein vereinbartes Änderungsverfahren, nicht über Verhandlungen im Einzelfall. Legen Sie im Vertrag fest, wer Änderungen beantragt, wer sie bewertet, wie der Mehraufwand geschätzt wird und wer freigibt. Änderungen sind normal – ungeregelte Änderungen sind der häufigste Grund für Streit über die Schlussrechnung.

Weiterführende Ratgeber

• Lastenheft & Pflichtenheft erstellen – Unterschied, Zusammenspiel und agile Alternative
• Pflichtenheft erstellen – der Gegenpart des Auftragnehmers
• Anforderungen richtig definieren – User Stories, Akzeptanzkriterien, Priorisierung
• Das perfekte Briefing für Ihre Digitalagentur – die kürzere Variante für kleinere Vorhaben
• Angebote vergleichen – wofür Sie das Lastenheft anschließend brauchen
• Software-Abnahme & Qualitätssicherung – aus Anforderungen werden Abnahmekriterien

Anbieter im Verzeichnis: Softwareentwicklung, IT-Beratung.