Lastenheft für Industriesoftware: Aufbau, Kapitel und Vorlage zum Ausfüllen

Ein Lastenheft für Industriesoftware beschreibt, was die Software im Werk leisten muss – nicht, wie sie gebaut wird. Von einer allgemeinen Lastenheft-Vorlage unterscheidet es sich durch vier Kapitel, die dort fehlen: Maschinenanbindung, Schnittstellen zu ERP und MES, Betrieb im Schichtbetrieb und messbare Abnahme. Dieser Beitrag liefert Kapitelstruktur, Formulierungshilfen und eine Lastenheft-Vorlage für Industriesoftware zum Kopieren – eingeordnet an der Richtlinie VDI/VDE 3694.

Lastenheft oder Pflichtenheft? Die Abgrenzung in drei Sätzen

Das Lastenheft schreibt der Auftraggeber, und es beschreibt, was er braucht: Ziele, Anforderungen, Rahmenbedingungen. Das Pflichtenheft schreibt der Auftragnehmer als Antwort darauf, und es beschreibt, wie er die Anforderungen umsetzt: Lösung, Architektur, Mengengerüst, Testverfahren. Das Lastenheft steht vor der Anfrage, das Pflichtenheft nach dem Angebot und vor der Beauftragung. So weit die Lastenheft-Definition; DIN 69901-5 fasst das Lastenheft laut REFA-Lexikon als die „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages“.

Was ein Pflichtenheft nicht ist: eine Kopie des Lastenhefts, in der ‚Der Auftragnehmer muss' durch ‚Das System wird' ersetzt wurde. Ein brauchbares Pflichtenheft nimmt zu jeder Anforderung Stellung – erfüllt, teilweise erfüllt mit Begründung, nicht erfüllt mit Alternative – und ergänzt, was der Auftraggeber nicht wissen kann: Architektur, Datenmodell, Testkonzept. Pflichtenheft-Inhalt und Lastenheft-Aufbau spiegeln sich, sind aber nicht deckungsgleich. VDI/VDE 3694 legt in ihrer frei zugänglichen Einleitung dieselbe Reihenfolge fest: Der Auftraggeber erstellt das Lastenheft vollständig und widerspruchsfrei, der Auftragnehmer erstellt darauf das Pflichtenheft.

Warum Standardvorlagen bei Industriesoftware nicht reichen

Eine Standardvorlage reicht nicht, weil sie für Software geschrieben ist, die nur mit Menschen und Datenbanken spricht – nicht mit Steuerungen, Prüfständen und einem ERP, das seit 15 Jahren läuft. Die verbreiteten Lastenheft-Beispiele aus Business-Portalen kennen Kapitel wie Zielgruppe, Funktionen und Design. Sie kennen keine Anlagenliste, keine Abtastrate und keine Regel dafür, was die Software tut, wenn eine Linie vom Netz geht. Was in ihnen fehlt:

• —Steuerungslandschaft: welche Steuerungen (S7-300, S7-1500, Beckhoff, Rockwell, proprietäre Maschinensteuerungen) mit welchem Baujahr, welchen Protokollen und welchen freien Ports.
• —Zeitverhalten: Abtastraten, Quelle des Zeitstempels, zulässige Verzögerung zwischen Ereignis und Anzeige.
• —Brownfield-Anlagen ohne Schnittstelle und die Entscheidung: nachrüsten, manuell erfassen oder ausklammern.
• —Betriebsmodell: on-premise im Werk, EU-Rechenzentrum oder Cloud des Anbieters – und wem die Daten gehören.
• —Nachweis- und Aufbewahrungspflichten aus Qualitätsmanagement, Steuerrecht und Kundenaudits.
• —Verhalten bei Anlagen- und Netzausfall: Pufferung, Wiederanlauf, Nachmeldung, doppelte Buchungen.
• —Abnahme im laufenden Betrieb, weil es für die Linie keine Testumgebung gibt.

Die Folge fehlender Kapitel sind Nachträge – nicht aus nachlässiger Kalkulation, sondern weil die Punkte erst bei der Integration sichtbar werden: wenn sich zeigt, dass die älteste Presse nur einen seriellen Anschluss hat und das ERP Stücklisten nur nachts exportiert. Diese Nachträge treffen auf knapper werdende Budgets: Laut KfW-Digitalisierungsbericht Mittelstand 2025 (KfW Research, Meldung vom 23. April 2026) haben zuletzt nur 30 % der mittelständischen Unternehmen Digitalisierungsprojekte durchgeführt, und die Digitalisierungsausgaben entwickeln sich rückläufig. Wer eines der verbleibenden Projekte startet, hat wenig Spielraum für Überraschungen im dritten Monat.

Vor dem Lastenheft steht eine Vorfrage: ob der Prozess überhaupt Individualsoftware braucht oder ein Standardprodukt genügt. Die Kriterien dafür stehen in Standardsoftware oder Individualsoftware – die Entscheidungsmatrix; welche Prozesse in Fertigung und Instandhaltung typischerweise individuell gelöst werden, zeigen die zwölf Anwendungsfälle für Individualsoftware. Das Lastenheft setzt danach an – wenn feststeht, dass gebaut wird, aber noch nicht, was genau.

Lastenheft-Aufbau: die zehn Kapitel im Überblick

Ein Lastenheft für Industriesoftware braucht zehn Kapitel; die ersten vier beschreiben den Betrieb, die übrigen sechs die Software. Die Reihenfolge ist keine Formsache: Wer mit funktionalen Anforderungen beginnt, beschreibt Lösungen, bevor das Problem steht. Tabelle 02 nennt je Kapitel den Zweck und den Fehler, der dort in der Praxis am häufigsten passiert.

Für Automatisierungssysteme gibt es eine eigene Richtlinie: VDI/VDE 3694 ‚Lastenheft/Pflichtenheft für den Einsatz von Automatisierungssystemen' der VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik, gültige Ausgabe April 2014, 24 Seiten. Ihr frei einsehbares Inhaltsverzeichnis gliedert das Lastenheft in acht Abschnitte: Einführung in das Projekt, Ausgangssituation (Istzustand), Aufgabenstellung (Sollzustand), Anforderungen für die Kommunikationsschnittstellen, an die Systemtechnik, für Systementwicklung, -inbetriebnahme und -einsatz, an die Qualität und an die Projektabwicklung. Die zehn Kapitel oben folgen dieser Logik, trennen aber Maschinenanbindung und IT-Schnittstellen, weil in Softwareprojekten unterschiedliche Personen dafür zuständig sind.

Kapitel Maschinenanbindung: was hineingehört

In das Kapitel Maschinenanbindung gehört zuerst eine Anlagenliste – eine Zeile je Maschine mit Steuerungstyp, Baujahr, vorhandenem Anschluss, Protokoll und der Person, die den Zugriff freigibt. Diese Tabelle ist das wertvollste Blatt des Lastenhefts: Sie bestimmt den Aufwand für die Anbindung, und nur der Betreiber kann sie ausfüllen. Tabelle 03 zeigt das Format mit fiktiven Beispielzeilen.

Nach der Liste folgen die Anforderungen – je Punkt eine Formulierungshilfe, die Sie an Ihre Anlagen anpassen:

• —Protokolle: ‚Die Anbindung nutzt je Anlage das in der Anlagenliste genannte Protokoll (OPC UA, S7, Modbus TCP, MQTT). Proprietäre Protokolle sind nur zulässig, wenn der Hersteller die Spezifikation offenlegt.' Die Wahl zwischen den beiden großen Optionen erklärt OPC UA oder MQTT – der Entscheidungsleitfaden für die Maschinenanbindung.
• —Abtastrate und Zeitstempel: ‚Zustandssignale werden mindestens sekündlich erfasst, Zählerstände mindestens je Takt. Jeder Messwert trägt den Zeitstempel der Quelle, ersatzweise den gekennzeichneten Empfangszeitstempel.'
• —Anlagen ohne Schnittstelle: ‚Für Anlagen ohne Schnittstelle bietet der Auftragnehmer je Anlage eine Nachrüstoption mit Kosten an; bis zur Entscheidung erfolgt die Erfassung manuell am Terminal.' Die Optionen beschreibt Maschinendaten nachrüsten: vier Wege für Anlagen ohne Schnittstelle.
• —Rückwirkungsfreiheit: ‚Der Zugriff ist lesend und darf Zykluszeit, Verfügbarkeit und Sicherheitsfunktionen der Steuerung nicht beeinflussen; der Nachweis erfolgt vor Freigabe an der ersten Anlage.' Klären Sie vorher schriftlich mit dem Maschinenlieferanten, ob der Zugriff die Gewährleistung berührt.
• —Netzsegmentierung: ‚Die Software greift aus einer eigenen Netzzone auf das Produktionsnetz zu; Office-IT und Steuerungsnetz bleiben getrennt.' Das ist keine Kür: Der IT-Grundschutz-Baustein IND.2.1 des BSI (Edition 2023) fordert in der Basis-Anforderung A6, dass ICS-Komponenten von der Office-IT getrennt werden müssen.
• —Zugriff und Freigabe: ‚Je Anlage ist benannt, wer den Zugriff freigibt und wer die Zugangsdaten verwaltet. Ohne Freigabe beginnt keine Anbindung.'

Kapitel Schnittstellen zu ERP, MES und Bestandssystemen

Das Kapitel Schnittstellen beantwortet für jedes Datenobjekt fünf Fragen: Richtung, führendes System, Stammdaten-Mapping, Verhalten beim Ausfall der Gegenstelle – und wer die Schnittstelle bereitstellt. Die fünfte Frage fehlt in fast jedem Lastenheft und entscheidet über Budget und Termin. Ein ERP-Anbieter, der eine Exportschnittstelle als Beratungsprojekt mit sechs Wochen Vorlauf anbietet, bestimmt Ihren Zeitplan stärker als jede Zeile Code.

Die Frage nach dem führenden System klingt akademisch und ist es nicht. Heißen Arbeitsplätze im ERP anders als im MES, braucht die neue Software eine Mapping-Tabelle – und jemanden, der sie pflegt. Legen Sie fest, wer das ist, und legen Sie fest, dass jede Gegenstelle ein Testsystem mit realistischen Testdaten stellt; ohne ERP-Testmandant wird gegen die Produktion getestet. Welche Integrationsmuster zwischen MES und ERP wann tragen, steht in MES-ERP-Schnittstelle: welches Integrationsmuster wann trägt.

Ausfall und Wiederanlauf verdienen je Schnittstelle einen eigenen Absatz. Formulierungshilfe: ‚Fällt die Gegenstelle aus, puffert die Software Meldungen lokal mindestens 24 Stunden und überträgt sie nach Wiederanlauf in Originalreihenfolge. Jede Meldung trägt einen eindeutigen Schlüssel; die Gegenstelle verwirft Duplikate. Der Zustand jeder Schnittstelle ist am Terminal sichtbar.' Wer das nicht schreibt, bekommt bei der ersten Netzstörung doppelte Buchungen im ERP – und die Diskussion, ob das ein Mangel ist.

Nichtfunktionale Anforderungen, die in der Fertigung nicht fehlen dürfen

Nichtfunktionale Anforderungen legen fest, wie gut die Software das Geforderte tun muss – und sie sind in der Fertigung strenger als im Büro. Ein Terminal, das drei Sekunden auf die Auftragsliste wartet, wird nach zwei Wochen umgangen; eine Wartung dienstags um 10 Uhr trifft im Dreischichtbetrieb die Frühschicht. Jede Anforderung braucht deshalb eine Zahl oder eine überprüfbare Aussage, kein Adjektiv.

Zwei Punkte werden regelmäßig unterschätzt. Erstens die Datenhoheit: Wer den Hosting-Ort offenlässt, bekommt die Cloud des Anbieters, weil sie für ihn am günstigsten ist – und diskutiert zwei Jahre später über Exportformate. Zweitens die Aufbewahrung: § 147 Abs. 3 AO staffelt die Fristen nach Unterlagenart – zehn Jahre für Bücher, Aufzeichnungen, Inventare und Jahresabschlüsse, acht Jahre für Buchungsbelege, sechs Jahre für die übrigen aufbewahrungspflichtigen Unterlagen. Welche Daten Ihrer Software darunterfallen, klären Buchhaltung und Steuerberatung – aber die Frage gehört ins Lastenheft, nicht erst in den Betrieb.

Abnahmekriterien formulieren, die messbar sind

Ein Abnahmekriterium ist messbar, wenn es vier Angaben enthält: Prüfverfahren, Prüfdaten, Toleranz und die Person, die prüft. ‚Die ERP-Schnittstelle funktioniert' erfüllt keine davon. ‚Die 500 Rückmeldungen des Testdatensatzes T-03 erscheinen innerhalb von 60 Sekunden vollständig und ohne Duplikat im ERP-Testmandanten; geprüft von der Leitung Arbeitsvorbereitung anhand des Abgleichprotokolls' erfüllt alle vier. Tabelle 05 gibt je Schnittstellentyp eine Musterformulierung mit fiktiven Werten.

Für Software, die in eine laufende Linie eingreift, findet die Abnahme im Betrieb statt, nicht im Labor. Legen Sie deshalb Zeitraum (etwa zwei Produktionswochen), Anlagen und Rückfallregeln fest. Teilabnahmen je Ausbaustufe – erst Anbindung, dann Erfassung, dann ERP-Rückmeldung – verkürzen die Zeit, in der beide Seiten auf ein Gesamtergebnis warten. Für Restmängel gilt eine Klassifizierung (verhindert den Betrieb, behindert den Betrieb, kosmetisch) mit einer Frist je Klasse. Ohne diese Regel wird jede Abnahme zur Verhandlung.

Typische Fehler im Lastenheft und ihre Korrektur

Die häufigsten Fehler in einem Lastenheft für Software sind keine Wissenslücken, sondern Abkürzungen: Die Lösung wird beschrieben, weil sie schon im Kopf ist; die Priorität fehlt, weil alles wichtig scheint; die Vorlage wird übernommen, weil sie fertig ist. Tabelle 06 nennt sechs davon mit der Korrektur in einem Satz.

Lastenheft-Vorlage für Industriesoftware: Gliederung kopieren und in vier Schritten ausfüllen

Die Vorlage unten ist die Gliederung aus Tabelle 02 als Textgerüst – ohne Formular, ohne Registrierung, zum Kopieren in Word, Confluence oder eine Markdown-Datei. Die Platzhalter in eckigen Klammern ersetzen Sie durch Ihre Angaben. Löschen Sie, was für Ihr Projekt nicht gilt, aber halten Sie in den Nicht-Zielen fest, warum.

LASTENHEFT [Projektname] – Version [1.0], Stand [Datum], Ansprechpartner [Name, Rolle]

1  Ausgangslage, Ziele und Nicht-Ziele
   1.1 Ausgangslage: [Welches Problem, seit wann, mit welchen Kosten?]
   1.2 Ziele mit Messgröße: [z. B. Rückmeldezeit je Auftrag von 20 min auf 2 min]
   1.3 Nicht-Ziele: [Was ausdrücklich nicht Teil von Stufe 1 ist]
2  Systemkontext
   2.1 Kontextdiagramm: [Software in der Mitte; ERP, MES, Anlagen, Rollen außen]
   2.2 Beteiligte Rollen: [Werker, Schichtleitung, AV, Instandhaltung, IT, QS]
3  Ist-Prozess
   3.1 Ablauf heute je Rolle: [inkl. Excel-Listen, Zettel, Zurufe]
   3.2 Sonderfälle und Störungen: [Nacharbeit, Eilaufträge, Anlagenausfall]
4  Soll-Prozess
   4.1 Zielablauf je Schritt: [Auslöser – Rolle – Tätigkeit – Ergebnis]
5  Funktionale Anforderungen (nummeriert, Muss/Soll/Kann)
   F-001 [Rolle] muss [Fähigkeit], damit [Zweck].          Priorität: Muss
6  Daten
   6.1 Datenobjekte und führendes System: [Auftrag – ERP; Zustand – Software]
   6.2 Mengen: [Anlagen, Nutzer je Schicht, Datensätze je Tag, Wachstum 5 Jahre]
   6.3 Historisierung und Aufbewahrung: [je Datenobjekt Dauer und Grund]
7  Maschinenanbindung
   7.1 Anlagenliste: [Maschine | Steuerung | Baujahr | Anschluss/Protokoll | Freigabe durch]
   7.2 Abtastrate, Zeitstempel, Rückwirkungsfreiheit, Netzsegmentierung
   7.3 Anlagen ohne Schnittstelle: [nachrüsten / manuell erfassen / ausklammern]
8  Schnittstellen zu ERP, MES und Bestandssystemen
   8.1 Schnittstellenmatrix: [Objekt | Richtung | führendes System | Ausfallverhalten | Bereitstellung]
   8.2 Testsystem und Testdaten der Gegenstellen: [wer stellt bereit, ab wann]
9  Nichtfunktionale Anforderungen und Betrieb
   9.1 Verfügbarkeit, Wartungsfenster, Antwortzeiten: [Zahlen]
   9.2 Bedienbarkeit, Sprachen, Rollen und Rechte
   9.3 Protokollierung, Datensicherung, Wiederanlauf
   9.4 Hosting-Ort, Datenhoheit, Exportformat, Rechte am Quellcode
   9.5 Schulung und Dokumentation
10 Abnahme, Rahmenbedingungen und Termine
   10.1 Abnahmekriterien: [Kriterium | Prüfverfahren | Prüfdaten | Toleranz | Prüfer]
   10.2 Ausbaustufen und Teilabnahmen
   10.3 Budgetrahmen, Termine, Mitwirkungspflichten des Auftraggebers
   10.4 Angebotsform: [Festpreis je Stufe / Aufwand mit Deckel; geforderte Angebotsstruktur]
Anhang: Begriffe, Abkürzungen, Normen und Richtlinien, mitgeltende Unterlagen

1. 01

   Systemkontext zeichnen

   Ein Blatt, die Software in der Mitte, außen jedes System und jede Rolle mit Datenaustausch. Was auf dem Blatt fehlt, fehlt später im Angebot. Dauer: eine Stunde mit IT und Fachbereich.

2. 02

   Ist-Prozess mit den Beteiligten aufnehmen

   Lassen Sie sich den Ablauf an der Linie zeigen, nicht erzählen, und notieren Sie jede Liste, jeden Zettel und jeden Zuruf. Der gelebte Prozess weicht vom dokumentierten fast immer ab – und die Software muss den gelebten ablösen.

3. 03

   Anforderungen formulieren und priorisieren

   Je Anforderung ein Satz nach dem Muster ‚Rolle muss Fähigkeit, damit Zweck', nummeriert, mit Muss/Soll/Kann. Was in Stufe 1 nicht kommt, wandert in Kapitel 1.3 zu den Nicht-Zielen.

4. 04

   Anlagenliste und Schnittstellenmatrix ergänzen

   Füllen Sie Tabelle 03 und 04 für Ihr Werk aus, holen Sie je Anlage die Freigabe und je Gegenstelle die Zusage eines Testsystems ein. Erst dann geht das Lastenheft an die Anbieter.

Ein so ausgefülltes Lastenheft macht Angebote vergleichbar, weil jeder Anbieter dieselben Anlagen, Mengen und Abnahmekriterien kalkuliert. Verlangen Sie im Angebot eine Stellungnahme je Anforderung (erfüllt, teilweise, nicht erfüllt mit Alternative) und eine Kostenaufteilung nach Ihren Ausbaustufen – dann zeigt der Vergleich nicht nur den Preis, sondern auch, wer das Lastenheft gelesen hat. Welche Kostenblöcke Sie erwarten sollten, steht in Was kostet Individualsoftware in der Industrie?.

Fazit: vier Kapitel entscheiden über das Projekt

Ein Lastenheft für Industriesoftware unterscheidet sich von einer Bürovorlage durch vier Kapitel: Maschinenanbindung mit Anlagenliste, Schnittstellen mit führendem System und Ausfallverhalten, nichtfunktionale Anforderungen mit Zahlen statt Adjektiven und Abnahmekriterien mit Prüfverfahren und Prüfer. Wer diese Kapitel füllt, verschiebt die teuren Entdeckungen vom dritten Projektmonat in die zweite Woche des Schreibens – dorthin, wo sie noch nichts kosten. VDI/VDE 3694 liefert den Rahmen, die Vorlage oben die Arbeitsfassung.

Der nächste Schritt ist kein Angebot, sondern ein Nachmittag an der Linie mit einem leeren Kontextdiagramm. Wenn Sie beim Ausfüllen hängen bleiben – meist bei Steuerungstypen oder beim führenden System –, hilft ein Blick von außen: ralwo unterstützt im Rahmen der individuellen Softwareentwicklung für die Industrie auch schon bei der Spezifikation, damit das Lastenheft steht, bevor die erste Zeile Code entsteht.