Lastenheft (Was das Unternehmen vom System verlangt)

Lastenheft ist die Zusammenstellung der Forderungen eines Auftraggebers an ein System, das er beschaffen oder erstellen lassen will: Sie sagt, was das System können soll, für welche Betriebsteile und Nutzer, in welchem Umfang und woran die Erfüllung gemessen wird.

Wozu es dient

Das Lastenheft legt den Bedarf fest, bevor Anbieter verglichen werden, und wird damit zum Maßstab für Angebot, Pflichtenheft und Abnahme. Die Enzyklopädie der Wirtschaftsinformatik ordnet das Lastenheft einer sehr frühen Projektphase zu; es dient dort auch der Frage, ob das Vorhaben tragfähig und wünschenswert ist (Stichwort Lastenheft, Universität Potsdam). Wer die Forderungen erst nach den Produktvorführungen sammelt, beschreibt am Ende das System des Anbieters statt den eigenen Bedarf (redaktionelle Einschätzung).

Wer es schreibt

Das Lastenheft verantwortet der Auftraggeber; die Anforderungen sind aus seiner Sicht beschrieben. Das IREB-Glossar zum Requirements Engineering führt „Lastenheft“ als Anforderungsspezifikation des Kunden und hält in der Anmerkung fest, dass sie üblicherweise vom Kunden geliefert wird. Für ein ERP heißt das: eine Person führt das Dokument, jede beteiligte Abteilung liefert ihre Anforderungen und zeichnet sie ab (Anforderungsworkshops mit den Fachbereichen). Systembeschreibungen und Textbausteine des Anbieters können als Anhang dienen; die Liste der Forderungen selbst bleibt beim Betrieb (redaktionelle Einschätzung).

Die Abgrenzung zum Pflichtenheft ist in der Literatur nicht einheitlich. Die Enzyklopädie der Wirtschaftsinformatik nennt beide Begriffe teils synonym; nach Balzert entsteht das Lastenheft früher und bleibt gröber, weil es sich auf die grundlegenden Eigenschaften des Produkts konzentriert. Für das Pflichtenheft hält dieselbe Quelle fest, dass es als Bestandteil eines Vertrags dienen können soll und die Grundlage der späteren Abnahme bildet.

Der Aufbau: neun Abschnitte

Die folgende Gliederung ist eine eigene Vorlage für ein ERP-Lastenheft (Stand 14. Oktober 2026), kein Wortlaut einer Norm.

Abschnitt	Was darin steht
1. Anlass und Ziel	heutiges System, Anlass des Wechsels, Ziel in einem Satz
2. Geltungsbereich	Gesellschaften, Standorte, Länder, Betriebsteile und Nutzergruppen, die abgedeckt werden sollen
3. Mengengerüst	Artikel, Kunden, Belege und Aufträge je Monat, Nutzerzahl, Sprachen
4. Anforderungen	je Anforderung Kennung, Priorität, prüfbarer Wortlaut und Testfall
5. Daten und Übernahme	Felder, Nummernkreise, Altdaten, Testdaten
6. Schnittstellen	welche Systeme, Richtung, Format, Takt
7. Betrieb und Technik	Betriebsart (Cloud oder eigener Server), Verfügbarkeit, Sicherung, Berechtigungen
8. Nachweise und Abnahme	Testfälle und der Zustand, der als erfüllt gilt
9. Rollen, Termine, Anhang	Ansprechpartner beider Seiten, Meilensteine, Budgetrahmen, Glossar, Prozessbilder

Als Priorität verwendet dieser Artikel die Dreiteilung Muss, Soll und Kann; das Vorgehen beim Sortieren beschreibt Anforderungen priorisieren. Jede einzelne Anforderung soll eindeutig, vollständig, verständlich und prüfbar sein; für das Dokument als Ganzes kommen Konsistenz, Redundanzfreiheit und Verfolgbarkeit hinzu (CPRE-Lehrplan, Abschnitt 3.8).

Eine Anforderung, die sich prüfen lässt

„Das System muss den Lagerbestand zuverlässig führen“ ist kein prüfbarer Satz: „zuverlässig“ nennt keinen Zustand, den man nachzählen kann. Die folgende Fassung nennt Größe, Einheit, Richtung und den Test. Erfundenes Beispiel (Beispielrechnung) für einen Handelsbetrieb mit Stückzahlen.

Feld	Eintrag
Kennung	F-120
Priorität	Muss
Anforderung	Das System muss bei der Buchung eines Wareneingangs den Lagerbestand des Artikels um die gebuchte Menge erhöhen und die Änderung mit Datum, Menge und Belegnummer im Bestandsjournal festhalten.
Testfall	Anfangsbestand 40 Stück, Wareneingang 12 Stück: Der Artikel zeigt danach 52 Stück, und das Journal enthält eine Zeile mit +12 und der Belegnummer WE-4711.
Herkunft	Wareneingang im Lager, aufgenommen im Workshop vom 12. Mai 2026
Weiterverfolgt unter	derselben Kennung F-120 im Pflichtenheft und im Abnahmetest

Prüfen Sie in der Abnahme genau diese Zeile: Stimmen Menge, Beleg und Datum, ist die Anforderung erfüllt, sonst nicht. Damit der Nachweis später trägt, geben Sie dieselbe Kennung im Abnahmetest an; der CPRE-Lehrplan führt die Verfolgbarkeit als Qualitätskriterium für ein Dokument mit mehreren Anforderungen (Abschnitt 3.8). Ob der Standard des geprüften Systems die Anforderung abdeckt, ordnet danach die Fit-Gap-Analyse ein.

Standardbasis und Verbindlichkeit

DIN 69901-5:2009-01 ist der Begriffsteil des DIN-Regelwerks zum Projektmanagement; DIN Media führt ihn mit Ausgabedatum Januar 2009 als aktuelle Ausgabe. VDI/VDE 3694:2014-04 trägt den Titel „Lastenheft/Pflichtenheft für den Einsatz von Automatisierungssystemen“ und gibt nach dem dort veröffentlichten Kurzreferat einen Gliederungsvorschlag für Lasten- und Pflichtenhefte. Beide Regelwerke sind kostenpflichtig und werden hier deshalb nur benannt.

Beide Regelwerke stammen von deutschen Normungsorganisationen und sind kein Gesetz; in Deutschland, Österreich und der Schweiz werden ihre Vorgaben erst verbindlich, wenn ein Vertrag, eine Regelung oder eine Weisung sie in Bezug nimmt. VDI/VDE 3694 ist zudem für Automatisierungssysteme geschrieben und damit kein ERP-eigenes Regelwerk; der VDI führt eine Überarbeitung als Projekt mit möglichem Erscheinungsdatum April 2027. Welche Pflichten das System abbilden muss, ist eine eigene Frage und steht unter Gesetzliche Pflichten als ERP-Anforderung.

Nicht zu verwechseln mit

• Pflichtenheft: beschreibt die Anforderungen systematisch und soll als Vertragsbestandteil sowie als Grundlage der Abnahme dienen (Enzyklopädie der Wirtschaftsinformatik).
• Ist-Aufnahme: hält die heutigen Abläufe fest; sie steht vor dem Lastenheft (Ist-Prozesse aufnehmen).
• Fit-Gap-Analyse: stellt die fertigen Anforderungen dem Standard eines geprüften Systems gegenüber.
• Systembeschreibung des Anbieters: beschreibt dessen Produkt; sie ersetzt die Liste der eigenen Forderungen nicht.