Lastenheft erstellen: Aufbau, Inhalt und Beispiel für Embedded-Projekte

Kurz erklärt: Ein Lastenheft ist das Anforderungsdokument des Auftraggebers. Es legt fest, was ein Produkt leisten muss und unter welchen Bedingungen, aber nicht, wie es technisch umgesetzt wird. Bei Embedded-Projekten gehören Umgebungsbedingungen, Schnittstellen, Normen, Lebensdauer und Update-Strategie dazu. Das Wie beschreibt der Auftragnehmer danach im Pflichtenheft.

Viele Embedded-Projekte scheitern nicht an der Technik, sondern an Anforderungen, die niemand aufgeschrieben hat. Der Temperaturbereich fehlt, die Update-Strategie ist offen, und die Abnahme wird zur Verhandlungssache. Solche Lücken fallen oft erst im Test oder im Feld auf, also dann, wenn Änderungen am meisten kosten.

Dieser Leitfaden zeigt, wie Sie ein Lastenheft erstellen, das für Hardware und Firmware trägt. Sie bekommen eine Mustergliederung, sechs Kapitel, die in generischen Vorlagen fehlen, sieben Arbeitsschritte, Formulierungsbeispiele und einen Beispiel-Auszug für ein typisches Gerät.

Was ist ein Lastenheft?

Die gängige Lastenheft-Definition stammt aus der DIN 69901-5. Sie beschreibt das Lastenheft als „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers“ (REFA-Lexikon). Das Lastenheft beantwortet also das Was und das Wozu. Das Wie und Womit bleibt offen.

Im Projektalltag heißt das Dokument auch Anforderungskatalog, Anforderungsspezifikation oder Kundenspezifikation. Auf Englisch sind je nach Umfeld Requirements Specification, Customer Requirements Specification oder im Projektgeschäft Statement of Work üblich. Die Richtlinie VDI/VDE 3694 führt das Begriffspaar Lastenheft/Pflichtenheft im englischen Titel als System requirement/specification (DIN Media).

Für jede Anforderung gilt: so offen wie möglich und nur so genau, wie es für Angebot und Abnahme nötig ist. Wer zu früh eine Lösung festschreibt, verschenkt das Know-how des Auftragnehmers.

Lastenheft und Pflichtenheft: die Abgrenzung

Das Lastenheft schreibt der Auftraggeber, lösungsneutral und aus Sicht der Anwendung. Auf dieser Basis erstellt der Auftragnehmer das Pflichtenheft und legt darin fest, wie er die Anforderungen umsetzt, meist mit Systemarchitektur, Schnittstellenspezifikation und Aufwandsschätzung. In der Praxis werden die Begriffe oft vermischt. Entscheidend ist, dass beide Fragen getrennt beantwortet werden: Was soll das Gerät können, und wie wird es gebaut?

Wann im Projekt entsteht das Lastenheft?

Das Lastenheft steht am Anfang, nach der Produktidee und vor der Anfrage bei Anbietern. Auf seiner Basis holen Sie Angebote ein, der beauftragte Partner schreibt das Pflichtenheft, danach folgen Entwicklung, Test und Abnahme. Im V-Modell ist das Lastenheft der Einstieg in den linken Ast, und die Abnahme auf dem rechten Ast prüft genau gegen diese Anforderungen.

Damit bleibt das Lastenheft über das ganze Projekt ein Referenzdokument. Ändert sich eine Anforderung, ändern sich Pflichtenheft, Testfälle und oft auch Preis und Termin mit.

Warum das Lastenheft bei Embedded-Projekten über Kosten entscheidet

Ein Fehler in den Anforderungen wird mit jeder Projektphase teurer. Eine NASA-Studie hat das 2004 für komplexe Hardware/Software-Systeme beziffert (Stecklein et al., NASA Technical Reports Server). Kostet die Behebung in der Anforderungsphase eine Einheit, sind es im Design 3 bis 8 und in der Fertigung 7 bis 16 Einheiten. In Integration und Test steigt der Faktor auf 21 bis 78, im Betrieb auf 29 bis über 1.500.

Bei Embedded-Geräten ist dieser Effekt besonders spürbar. Ist die Platine gefertigt oder das Gerät im Feld, bedeutet eine vergessene Anforderung oft ein neues Layout, einen weiteren Prüfdurchlauf oder einen Serviceeinsatz beim Kunden.

Das Project Management Institute kommt zu einem ähnlichen Befund: 47 Prozent der erfolglosen Projekte verfehlen ihre Ziele wegen ungenauen Anforderungsmanagements (PMI Pulse of the Profession, 2014).

Ein sauberes Lastenheft wirkt deshalb an drei Stellen:

• Angebote werden vergleichbar. Alle Anbieter kalkulieren gegen dieselben Anforderungen. Erst dann lassen sich auch Festpreise seriös vergleichen.
• Die Abnahme wird objektiv. Jede Anforderung hat ein Prüfkriterium, über das niemand mehr diskutieren muss.
• Änderungen werden sichtbar. Was nicht im Lastenheft steht, ist eine Änderung mit Preis und Termin und kein Missverständnis.

Aufbau und Inhalt: So ist ein Lastenheft gegliedert

Ein Lastenheft für ein Embedded-Projekt lässt sich in zehn Kapitel gliedern. Die Mustergliederung unten können Sie direkt als Vorlage für Ihr eigenes Lastenheft übernehmen. Die rechte Spalte zeigt, was bei Hardware und Firmware zusätzlich zählt.

Für Automatisierungssysteme liefert die Richtlinie VDI/VDE 3694 in der aktuellen Ausgabe 2014-04 einen ausführlichen Gliederungsvorschlag für Lasten- und Pflichtenhefte (DIN Media). Die internationale Referenz für Anforderungen an Systeme und Software ist die ISO/IEC/IEEE 29148, die Lasten- und Pflichtenhefte gleichermaßen abdeckt.

Praxistipp: Geben Sie jeder Anforderung eine eindeutige ID, etwa LH-F-01 für funktionale oder LH-U-01 für Umgebungsanforderungen. Über diese IDs verweisen Pflichtenheft, Testfälle und Abnahmeprotokoll später aufeinander.

Was gehört nicht ins Lastenheft?

Nicht hinein gehören Lösungen, die der Auftragnehmer besser beurteilen kann: Bauteilwahl, Schaltungsdetails, Softwarearchitektur oder die Wahl des Betriebssystems. Ebenso wenig gehören Projektinterna des Auftragnehmers hinein, etwa seine Teamstruktur oder Werkzeuge. Ausnahme sind echte Randbedingungen wie eine vorgegebene Plattform aus einer bestehenden Produktfamilie. Kennzeichnen Sie diese als Randbedingung und begründen Sie sie.

Was Standardvorlagen fehlt: sechs Kapitel für Hardware und Firmware

Viele frei verfügbare Lastenheft-Vorlagen stammen von Anbietern für ERP-, CRM- oder Projektsoftware. Für ein Embedded-Gerät fehlen dort genau die Punkte, die später am teuersten werden.

Umgebungsbedingungen und Lebensdauer

Legen Sie fest, wo und wie lange das Gerät arbeitet: Temperaturbereich in Betrieb und Lagerung, Luftfeuchte, Vibration, Schutzart und EMV-Umgebung. Nennen Sie außerdem die geplante Einsatzdauer im Feld, zum Beispiel 15 Jahre. Sie bestimmt Bauteilwahl, Update-Strategie und Ersatzteilhaltung.

Bauteilverfügbarkeit und Obsoleszenz

Elektronische Bauteile werden oft abgekündigt, lange bevor ein Industrieprodukt ausläuft. Schreiben Sie ins Lastenheft, wie lange das Gerät lieferbar und reparierbar bleiben muss. Dann kann der Auftragnehmer Bauteile mit Langzeitverfügbarkeit wählen und eine Abkündigungsstrategie einplanen. Legen Sie auch fest, ob ein späteres Redesign erlaubt ist oder ob Form, Passung und Funktion unverändert bleiben müssen.

Update-Strategie über die Lebensdauer

Klären Sie, ob und wie die Firmware im Feld aktualisiert wird: vor Ort über eine Service-Schnittstelle, per Fernzugriff oder gar nicht. Legen Sie fest, was bei einem abgebrochenen Update passieren muss und wer Updates freigibt. Für Geräte im Anwendungsbereich des Cyber Resilience Act ist die Update-Fähigkeit keine Komfortfunktion mehr, denn Schwachstellen müssen über den gesamten Lebenszyklus behandelt werden.

Cybersecurity: Cyber Resilience Act und RED

Hat Ihr Gerät digitale Elemente und eine Datenverbindung, fällt es sehr wahrscheinlich unter den Cyber Resilience Act (CRA). Seit dem 11. September 2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen, ab dem 11. Dezember 2027 die übrigen Pflichten (EU-Kommission). Für das Lastenheft heißt das: Supportzeitraum für Sicherheitsupdates, Software-Stückliste (SBOM), Schwachstellenmanagement und Update-Fähigkeit als Anforderungen aufnehmen.

Kommuniziert das Gerät per Funk über das Internet, gelten seit dem 1. August 2025 zusätzlich die Cybersecurity-Anforderungen der Funkanlagenrichtlinie RED. Die harmonisierten Normen EN 18031-1 bis -3 konkretisieren sie (SCHUTZWERK). Stand dieser Angaben: September 2026.

Funktionale Sicherheit als Ziel, nicht als Lösung

Kann ein Fehler Menschen gefährden, gehört die geforderte Sicherheitsintegrität ins Lastenheft, etwa SIL 2 nach IEC 61508. Im Bahnumfeld gilt für Software die EN 50716. Nennen Sie die bekannten Gefährdungen und die Norm, nach der nachgewiesen werden muss. Das Sicherheitskonzept selbst entwickelt der Auftragnehmer im Pflichtenheft.

Schnittstellen und Bussysteme

Beschreiben Sie jede Schnittstelle nach außen: Feldbus oder Netzwerk, Protokoll, Datenrate, Stecker, Versorgung und wer auf der Gegenseite sitzt. Werden Hardware und Firmware getrennt vergeben, verlieren Projekte an unklaren Schnittstellen besonders viel Zeit. Legen Sie außerdem fest, wer welche Schnittstelle dokumentiert und testet.

Lastenheft für Software und Firmware

Lastenhefte für Business-Software beschreiben Masken, Prozesse und Benutzerrollen. Bei Firmware zählen andere Fragen: Echtzeitverhalten, Startzeit nach dem Einschalten, Verhalten bei Spannungseinbruch, Diagnose und Fehlerspeicher. Formulieren Sie diese Punkte als messbare Anforderungen und nicht als Vorgabe für eine bestimmte Implementierung.

Typisch sind etwa eine maximale Zeit bis zur Betriebsbereitschaft, ein definierter Wiederanlauf nach Spannungsausfall und ein Fehlerspeicher, der über die Service-Schnittstelle auslesbar ist. Dazu kommt die Konfiguration: Welche Parameter darf der Betreiber ändern, welche nur der Service, und was passiert mit den Einstellungen nach einem Update?

Lastenheft erstellen in sieben Schritten

So erstellen Sie ein Lastenheft, mit dem ein Entwicklungspartner belastbar kalkulieren kann. Die Reihenfolge zählt: erst der Kontext, dann die Anforderungen, zuletzt die Prüfkriterien.

1. Stakeholder und Einsatzkontext klären. Sprechen Sie nicht nur mit der Entwicklung, sondern auch mit Service, Vertrieb, Produktion und wenn möglich mit Anwendern. Jede Gruppe kennt Anforderungen, die sonst erst im Feld auftauchen.
2. Systemgrenzen und Schnittstellen festlegen. Zeichnen Sie das Gerät als Kasten und alles, womit es verbunden ist, drumherum. Was innerhalb der Grenze liegt, liefert der Auftragnehmer, alles außerhalb beschreibt das Lastenheft als Umgebung.
3. Anforderungen erheben und priorisieren. Schreiben Sie jede Anforderung einzeln und nummeriert auf und ordnen Sie sie als Muss, Soll oder Kann ein. Muss-Anforderungen sind Ausschlusskriterien, Soll und Kann machen Angebote unterscheidbar.
4. Nicht-funktionale und regulatorische Anforderungen ergänzen. Gehen Sie die Kapitel 5 und 6 der Mustergliederung gezielt durch: Umgebung, Lebensdauer, EMV, Normen, Security. Diese Punkte gehen am leichtesten verloren, weil sie im Alltag selbstverständlich wirken.
5. Für jede Anforderung ein Abnahmekriterium festlegen. Fragen Sie bei jeder Zeile: Woran erkennen wir bei der Abnahme, dass sie erfüllt ist? Die Kriterien bilden später die Grundlage für Test und Verifikation.
6. Review mit allen Beteiligten. Lassen Sie das Dokument von Entwicklung, Service und Produktion gegenlesen, idealerweise auch von jemandem, der das Projekt nicht kennt. Unklare Stellen fallen Außenstehenden sofort auf.
7. Versionieren und Änderungen steuern. Frieren Sie eine Version für die Angebotsphase ein. Jede spätere Änderung bekommt eine neue Version mit Datum, Grund und Auswirkung auf Kosten und Termine.

Anforderungen richtig formulieren

Eine gute Anforderung ist eindeutig, messbar und prüfbar. Sie beschreibt ein Ergebnis, keine Lösung. Bewährt hat sich ein fester Satzbau: Das Gerät muss, soll oder kann unter Bedingung X das Ergebnis Y liefern.

Achtung: Wörter wie „robust“, „schnell“, „benutzerfreundlich“ oder „möglichst“ sind Warnsignale. Sie lassen sich nicht prüfen und führen bei der Abnahme zu Diskussionen.

Muss, Soll, Kann: richtig priorisieren

Die Priorität entscheidet, wie Anbieter kalkulieren und wie Sie Angebote bewerten. Muss-Anforderungen sind Ausschlusskriterien: Erfüllt ein Angebot eine davon nicht, fällt es heraus. Soll-Anforderungen gewichten Sie in der Bewertung, Kann-Anforderungen sind Extras mit eigenem Preis.

Halten Sie die Muss-Liste so kurz wie möglich. Jede Muss-Anforderung schränkt den Lösungsraum ein und treibt oft den Preis. Fragen Sie bei jedem Muss: Würden wir das Projekt wirklich stoppen, wenn es fehlt?

Lastenheft-Beispiel: Auszug für einen Zustandssensor

Wie sieht ein Lastenheft aus, das diese Regeln umsetzt? Der folgende Auszug zeigt zehn Anforderungen für ein typisches Gerät aus der Industrieautomation. Es geht um einen funkfähigen Sensor, der Temperatur und Vibration an einem Antrieb überwacht und Daten an die übergeordnete Steuerung meldet. Das Szenario ist typisch, aber bewusst vereinfacht.

An diesen IDs hängt später alles. Das Pflichtenheft verweist darauf, jeder Testfall prüft eine oder mehrere IDs, und das Abnahmeprotokoll hakt sie ab. So entsteht die lückenlose Rückverfolgbarkeit, die Prüfstellen in Zulassungsverfahren sehen wollen.

Für Ihr eigenes Lastenheft übernehmen Sie die Struktur, nicht die Werte. Temperaturbereich, Reaktionszeiten und Lebensdauer ergeben sich aus Ihrem Einsatz. Ein vollständiges Lastenheft für ein solches Gerät enthält deutlich mehr als zehn Anforderungen, folgt aber demselben Muster.

Typische Fehler im Lastenheft und wie Sie sie vermeiden

Diese sieben Fehler machen Lastenhefte für Embedded-Projekte besonders teuer:

• Lösungen statt Anforderungen. Wer Bauteile oder Architektur vorschreibt, nimmt dem Auftragnehmer die Chance auf eine bessere und oft günstigere Lösung. Vorgaben gehören nur hinein, wenn sie eine echte Randbedingung sind.
• Fehlende Umgebungsbedingungen. Ohne Temperaturbereich, Schutzart und EMV-Umgebung kalkuliert jeder Anbieter mit eigenen Annahmen. Die Angebote sind dann nicht vergleichbar.
• Keine Abnahmekriterien. Eine Anforderung ohne Prüfkriterium wird bei der Abnahme zur Verhandlungssache.
• Normen und Security vergessen. Werden Zulassung oder CRA-Pflichten erst spät erkannt, müssen Architektur und Dokumentation nachträglich angepasst werden.
• Keine Obsoleszenz- und Update-Strategie. Ein Gerät, das 15 Jahre im Feld bleiben soll, braucht dafür einen Plan, der schon bei der Bauteilwahl beginnt.
• Vorlagen aus der Softwareeinführung übernommen. ERP- oder CRM-Vorlagen fragen nach Benutzerrollen und Prozessen, nicht nach Echtzeit, Versorgung oder Lebensdauer. Für Hardware bleiben so die wichtigsten Kapitel leer.
• Kein Änderungsmanagement. Werden Anforderungen per E-Mail nachgeschoben, weiß am Ende niemand, welcher Stand gilt. Eine versionierte Fassung mit Änderungshistorie verhindert das.

Lastenheft selbst schreiben oder mit einem Embedded-Partner erstellen?

Grundsätzlich schreibt der Auftraggeber das Lastenheft, denn er kennt Einsatz, Markt und Anwender. Schwierig wird es, wenn im eigenen Haus Embedded-Erfahrung fehlt. Dann bleiben gerade die technischen Kapitel dünn, und die Angebote gehen weit auseinander.

In diesem Fall lohnt eine gemeinsame Anforderungsanalyse für Embedded-Projekte. Bei EmTec starten wir mit strukturierten Interviews, definieren Systemkontext und Schnittstellen und arbeiten die Anforderungen gemeinsam mit Ihnen aus. Das Ergebnis ist nicht auf uns zugeschnitten: Sie können damit mehrere Angebote einholen oder intern weiterentwickeln.

Ein guter Entwicklungspartner liest Ihr Lastenheft kritisch. Er stellt Rückfragen, markiert Widersprüche und bewertet die Machbarkeit, bevor er ein Angebot abgibt. Viele Rückfragen sind dabei kein Makel: Genau in diesem Moment lassen sich Lücken noch günstig schließen.

Fazit

Ein Lastenheft für ein Embedded-Projekt ist mehr als eine Wunschliste. Es legt fest, was das Gerät unter welchen Bedingungen leisten muss, wie lange es im Feld bleibt und woran die Abnahme das erkennt. Wer Umgebung, Lebensdauer, Update-Strategie und Security von Anfang an aufnimmt, bekommt vergleichbare Angebote und vermeidet teure Änderungen in späten Projektphasen.

Unser Rat: Formulieren Sie zu jeder Anforderung sofort das Abnahmekriterium mit. Das ist der schnellste Test, ob Ihr Lastenheft trägt.