Unternehmen, die eine kundenspezifische Embedded Systems entwickeln lassen möchten, stehen häufig vor derselben Frage: Wie beschreibt man die Anforderungen an ein neues Gerät oder Board so, dass ein Entwicklungsdienstleister damit arbeiten kann? In vielen Fällen existiert bereits eine technische Idee, etwa ein Sensorboard, eine Steuerung oder eine spezielle Embedded-Plattform. Was jedoch fehlt, ist eine strukturierte Beschreibung dieser Idee – dafür braucht es ein Embedded Systems Lastenheft.
Das klassische Instrument dafür ist das Lastenheft. Es beschreibt, welche Anforderungen ein Kunde an ein Produkt stellt und bildet die Grundlage für die Zusammenarbeit mit dem Entwicklungspartner. In der Praxis haben sich dabei zwei unterschiedliche Ansätze etabliert: ein textbasiertes Lastenheft und ein grafik- beziehungsweise blockbasiertes Lastenheft. Beide Formen verfolgen denselben Zweck, unterscheiden sich jedoch deutlich in ihrer Herangehensweise.
Inhalt
Was ist ein Lastenheft?
Ein Lastenheft ist ein Dokument, in dem die Anforderungen an eine kundenspezifische Elektronik beschrieben werden. Es definiert, welche Funktionen, Eigenschaften und Rahmenbedingungen ein Produkt erfüllen soll. Das Lastenheft wird in der Regel vom Auftraggeber erstellt und dient als Ausgangspunkt für Angebot, Projektplanung und technische Umsetzung.
Der wichtigste Grundsatz lautet: Das Lastenheft beschreibt das „Was“, nicht das „Wie“. Die konkrete Umsetzung wird später im Pflichtenheft beschrieben, das typischerweise vom Entwicklungsdienstleister erstellt wird. Dort wird festgelegt, mit welcher Architektur, welchen Komponenten und welchen Entwicklungsprozessen die Anforderungen umgesetzt werden.
In der Praxis ist ein Lastenheft jedoch kein starres Dokument. Viele Projekte beginnen auch mit einer kurzen Beschreibung oder einem Gespräch. Dennoch hilft eine strukturierte Spezifikation, Missverständnisse zu vermeiden und den Entwicklungsrahmen klar abzustecken.
Zwei typische Formen von Lastenheften
Bei Elektronikprojekten lassen sich zwei grundsätzliche Formen von Lastenheften beobachten. Welche davon verwendet wird, hängt stark vom Umfeld und von der Organisation des Auftraggebers ab.
Das textbasierte Lastenheft
Der klassische Ansatz ist ein strukturiertes Dokument mit textlich formulierten Anforderungen. Dieses Format ist besonders in regulierten Branchen verbreitet, beispielsweise in der Luftfahrt, im Bahnsektor, in der Medizintechnik oder in sicherheitskritischen Anwendungen.
In solchen Projekten steht nicht nur die Funktion im Vordergrund, sondern auch der Prozess. Anforderungen werden formal beschrieben, versioniert und nachvollziehbar dokumentiert. Typischerweise enthält ein solches Lastenheft:
- eine Projektbeschreibung und Zielsetzung
- eine Liste funktionaler Anforderungen
- nichtfunktionale Anforderungen (z. B. Lebensdauer, Umweltbedingungen, Sicherheit)
- Schnittstellenbeschreibungen
- Normen und regulatorische Vorgaben
- Randbedingungen wie Termine oder Budget
- Dokumentations- und Nachweisanforderungen
Der Vorteil dieses Ansatzes liegt in der Nachvollziehbarkeit. Anforderungen lassen sich später eindeutig auf Tests, Validierung und Dokumentation zurückführen.
Das block- und grafikbasierte Lastenheft
In vielen Industrieprojekten, insbesondere im Maschinenbau, der Elektro- und Sensortechnik oder in der Werkzeugindustrie entsteht die Spezifikation anders. Hier steht die technische Lösung stärker im Mittelpunkt als der formale Prozess.
Statt eines langen Textdokuments werden häufig Blockdiagramme, Skizzen oder Architekturentwürfe erstellt. Diese beschreiben beispielsweise:
- die funktionalen Baugruppen eines Boards
- Signalflüsse zwischen Komponenten
- Kommunikationsschnittstellen
- die Einbindung in eine Maschine oder Anlage
- eine mögliche Softwarestruktur
Ein typisches Beispiel ist ein Blockdiagramm eines Embedded-Systems mit Mikrocontroller, Sensorik, Aktorik, Kommunikationsschnittstellen und Spannungsversorgung. Auch mechanische Einbausituationen oder bestehende Hardwareplattformen werden oft grafisch dargestellt.
Dieser Ansatz ist pragmatischer und technikgetriebener. Er eignet sich besonders dann, wenn die zentrale Frage lautet: Welche Funktion soll das Board erfüllen und wie fügt es sich in das Gesamtsystem ein?
Wie umfangreich muss ein Lastenheft sein?
Es gibt keine feste Regel für den Umfang eines Lastenhefts. In manchen Projekten umfasst es mehrere hundert Seiten, in anderen Fällen besteht es aus wenigen Seiten oder sogar nur aus einer Präsentation.
Wichtig ist vor allem, dass zentrale Fragen beantwortet werden:
- Welche Funktion soll die Elektronik erfüllen?
- In welchem System wird sie eingesetzt?
- Welche Schnittstellen existieren?
- Welche Umweltbedingungen sind relevant?
- Welche Normen oder Standards müssen eingehalten werden?
Ein Embedded Systems Lastenheft sollte ausreichend präzise sein, um den Handlungsrahmen der Entwicklung festzulegen. Gleichzeitig sollte es nicht so detailliert sein, dass es die technische Lösung bereits vollständig vorgibt. Die konkrete Architektur entsteht häufig erst im Dialog zwischen Kunde und Entwicklungsdienstleister.
In fünf Schritten zum Embedded Systems Lastenheft
Unabhängig davon, ob ein textbasierter oder grafischer Ansatz gewählt wird, lässt sich die Erstellung eines Lastenhefts in einige grundlegende Schritte gliedern.
1. Zweck und Ziel definieren
Am Anfang steht die Frage, warum die Elektronik entwickelt werden soll. Geht es um ein neues Produkt, eine Erweiterung eines bestehenden Systems oder um den Ersatz einer veralteten Plattform? Die Zielsetzung bestimmt maßgeblich die späteren Anforderungen.
2. Anforderungen sammeln
Im nächsten Schritt werden alle Anforderungen an das System gesammelt. Dazu gehören sowohl funktionale Anforderungen (z. B. Messfunktionen, Regelalgorithmen, Kommunikationsschnittstellen) als auch nichtfunktionale Anforderungen wie:
- Temperaturbereich
- Lebensdauer
- Vibrationsfestigkeit
- Sicherheitsanforderungen
- Update- oder Wartungsmechanismen
Gerade bei Elektronik spielt auch die Einsatzumgebung eine wichtige Rolle.
3. Anforderungen strukturieren
Die gesammelten Anforderungen werden anschließend strukturiert. Typische Kategorien sind:
- elektrische Eigenschaften
- mechanische Randbedingungen
- Softwarefunktionen
- Kommunikationsschnittstellen
- Normen und Zertifizierungen
Eine Priorisierung der Anforderungen kann ebenfalls sinnvoll sein, um den Entwicklungsumfang besser zu steuern.
4. Dokument erstellen
Nun wird aus den gesammelten Informationen das eigentliche Lastenheft erstellt. Dies kann entweder in Form eines strukturierten Dokuments oder als Kombination aus Text, Tabellen und Diagrammen erfolgen.
Ein möglicher Aufbau umfasst:
- Projektübersicht
- Zielsetzung
- Systembeschreibung
- funktionale Anforderungen
- nichtfunktionale Anforderungen
- Randbedingungen
- Anhänge mit Zeichnungen, Blockdiagrammen oder Datenblättern
Unternehmen verzetteln sich oft bei der Frage nach dem Werkzeug oder dem Export. Sie arbeiten mit Software wie Polarion oder IBM DOORS. Dabei ist jede Form eines Dokuments grundsätzlich recht. Entscheidend ist die klare Kommunikation des Erwartungsrahmens. Wir empfehlen daher die Dokumentation von systemischen Anforderungen in Word oder Confluence.
5. Überprüfung und Freigabe
Bevor das Dokument an den Entwicklungspartner übergeben wird, sollte es intern abgestimmt werden. Häufig nehmen mehrere Fachbereiche daran teil, etwa Entwicklung, Produktmanagement oder Systemengineering.
Nach der Freigabe dient das Embedded Systems Lastenheft als Grundlage für die weitere Projektplanung und für die Erstellung des Pflichtenhefts.
Lastenheft oder Dialog?
Auch wenn ein Lastenheft ein hilfreiches Werkzeug ist, stellt es keine zwingende Voraussetzung für eine Anfrage dar. Viele Projekte beginnen mit einer Idee, einer Skizze oder einer kurzen Beschreibung.
In solchen Fällen entsteht die Spezifikation oft gemeinsam im Gespräch. Der Kunde beschreibt seine Anforderungen, der Entwicklungsdienstleister ergänzt technische Perspektiven und mögliche Architekturen. Erst danach wird eine strukturierte Spezifikation erstellt.
Ob textbasiertes Dokument oder technisches Blockdiagramm: Entscheidend ist, dass die grundlegende Idee verständlich beschrieben ist. Auf dieser Basis kann ein Elektronikprojekt strukturiert geplant und umgesetzt werden.
