Lastenheft und Pflichtenheft in einem Satz
| Lastenheft | Pflichtenheft |
|---|
Was und wozu?
Anforderungen, Ziele, Funktionen und Randbedingungen. | Wie?
Technische Umsetzung, Lösungsansatz, Konkretisierung und Nachweis. |
| Ausgangspunkt ist typischerweise die Sicht des Auftraggebers. | Ausgangspunkt ist typischerweise die geplante Realisierung durch den Auftragnehmer. |
| Beschreibt den benötigten Leistungs- und Funktionsrahmen. | Übersetzt diesen Rahmen in ein konkreteres technisches Vorgehen. |
Wichtig für die Praxis
Die Dokumentnamen allein schaffen noch keine Klarheit. Entscheidend ist, welche Inhalte tatsächlich vereinbart sind, welcher Stand freigegeben wurde und wie Änderungen behandelt werden.
Was gehört typischerweise ins Lastenheft?
Das Lastenheft sollte dem Entwicklungspartner ermöglichen, Aufgabe und Ziel zu verstehen, ohne die technische Lösung unnötig vorwegzunehmen. Typische Inhalte sind:
- Projektziel und gewünschtes Ergebnis,
- Nutzer, Anwendung und Hauptfunktionen,
- Muss-, Soll- und Wunsch-Anforderungen,
- Schnittstellen und Bauraum,
- Lasten und Umgebungsbedingungen,
- Normen und regulatorische Rahmenbedingungen,
- Stückzahlen, Fertigungsrahmen und Zielkosten,
- Termine und Meilensteine,
- bekannte Risiken und offene Punkte,
- Abnahmekriterien beziehungsweise Nachweise.
Eine ausführliche Checkliste dazu enthält unser Beitrag „Lastenheft Produktentwicklung: Was ein externer Entwicklungspartner wirklich braucht“.
Was gehört typischerweise ins Pflichtenheft?
Das Pflichtenheft konkretisiert die geplante Umsetzung. Je nach Projekt kann es beispielsweise enthalten:
- gewähltes technisches Lösungsprinzip,
- System- und Funktionsarchitektur,
- technische Schnittstellen und Aufteilung von Baugruppen,
- Werkstoffe und Fertigungsprinzipien,
- Berechnungs- und Validierungsstrategie,
- geplante Prototypenstufen,
- technische Nachweise und Prüfungen,
- Liefergegenstände und Dokumentation,
- Projektmeilensteine und Reviews.
In einer frühen Konzeptphase sind viele dieser Punkte noch nicht endgültig. Das Pflichtenheft kann deshalb mit dem Entwicklungsfortschritt konkretisiert werden, sofern Verantwortlichkeiten und Freigabestände eindeutig geregelt sind.
Beispiel: „Das Gehäuse muss dicht sein“
| Ebene | Beispiel |
|---|
| Kundenbedarf | Das Produkt soll im vorgesehenen Einsatz zuverlässig gegen Wasser geschützt sein. |
| Lastenheft | Definierte Umgebungs- und Dichtheitsanforderung, Einsatztemperatur, Schnittstellen und gegebenenfalls geforderte Schutzart. |
| Pflichtenheft | Vorgesehenes Dichtkonzept, Dichtungsgeometrie, Werkstoff, Fügeschnittstellen und geplante Verifikation. |
| Konstruktion / Nachweis | CAD-Geometrie, Toleranzen, Musterbau und Dichtheitsprüfung entsprechend dem vereinbarten Konzept. |
Beispiel: Mechanische Baugruppe
Der Auftraggeber fordert beispielsweise eine Baugruppe, die eine definierte Last überträgt, in einen vorgegebenen Bauraum passt und bestimmte Schnittstellen einhält. Das sind zunächst Anforderungen.
Der Entwicklungspartner entwickelt daraus ein Lösungsprinzip, dimensioniert Komponenten, definiert Verbindungen und entscheidet, welche Punkte über FEM-Berechnung, Prototyp oder Versuch abgesichert werden. Diese Konkretisierung gehört stärker zur Umsetzungsebene.
Warum die Trennung für externe Entwicklung wichtig ist
1. Lösungsfreiheit bleibt erhalten
Wenn das Lastenheft bereits jedes konstruktive Detail vorschreibt, kann der Entwicklungspartner kaum alternative Konzepte untersuchen.
2. Verantwortlichkeiten werden klarer
Es lässt sich besser unterscheiden, welche Anforderungen vorgegeben wurden und welche technische Lösung daraus entwickelt wurde.
3. Änderungen werden nachvollziehbar
Ändert sich eine Kundenanforderung, kann bewertet werden, welche Teile des Konzepts, der Konstruktion oder der Validierung davon betroffen sind.
4. Abnahme wird objektiver
Wenn Anforderungen und Nachweise sauber verknüpft sind, lässt sich am Ende besser beurteilen, ob die vereinbarte Leistung erfüllt wurde.
Lastenheft unvollständig – darf das Projekt trotzdem starten?
Ja. Gerade bei innovativer Produktentwicklung kennt der Auftraggeber zu Beginn nicht jede technische Anforderung. Ein Entwicklungsprojekt kann sogar gerade deshalb beauftragt werden, um offene Anforderungen und Lösungswege systematisch zu klären.
Wichtig ist eine transparente Kennzeichnung:
- festgelegt: vereinbarte Anforderung,
- offen: muss untersucht oder entschieden werden,
- Annahme: wird vorläufig verwendet und später geprüft,
- Änderung: nach Projektstart neu oder verändert.
Ein unvollständiges Lastenheft ist beherrschbar. Ein scheinbar vollständiges Lastenheft mit versteckten Annahmen ist gefährlicher.
Offene Punkte sollten deshalb sichtbar gemacht und gezielt in die ersten Entwicklungsmeilensteine aufgenommen werden.
Wann reicht ein Engineering-Arbeitspaket statt zweier großer Dokumente?
Bei kleineren, klar abgegrenzten Konstruktionsaufgaben kann eine kompakte Projektdefinition ausreichend sein. Beispielsweise können Ziel, Eingangsdaten, Schnittstellen, Lieferumfang, Termine und Abnahmekriterien in einem Engineering-Arbeitspaket eindeutig festgelegt werden.
Wie solche Pakete strukturiert werden können, beschreiben wir im INSIGHT „Baugruppe extern konstruieren lassen: Engineering-Arbeitspaket“.
Wann sollte stärker formalisiert werden?
Je größer die technische, wirtschaftliche oder regulatorische Tragweite, desto wichtiger wird eine systematische Anforderungs- und Änderungssteuerung. Das gilt insbesondere bei:
- vielen beteiligten Unternehmen oder Fachdisziplinen,
- komplexen technischen Schnittstellen,
- hohen Werkzeug- oder Investitionskosten,
- regulierten Produkten,
- Serienentwicklung mit mehreren Freigabestufen,
- kritischen Sicherheits- oder Funktionsanforderungen.
Die häufigsten Missverständnisse
| Missverständnis | Bessere Sichtweise |
|---|
| „Das Lastenheft muss die Lösung schon enthalten.“ | Es sollte vor allem Ziel, Anforderungen und Randbedingungen eindeutig machen. |
| „Das Pflichtenheft ist nur eine Kopie des Lastenhefts.“ | Es konkretisiert die geplante technische Realisierung. |
| „Nach Freigabe darf sich nichts mehr ändern.“ | Änderungen können notwendig sein, müssen aber kontrolliert bewertet und dokumentiert werden. |
| „Für kleine Projekte braucht man gar keine Spezifikation.“ | Auch kleine Projekte benötigen einen klaren Leistungsumfang und Abnahmekriterien. |
| „Ein gutes CAD-Modell ersetzt Anforderungen.“ | CAD beschreibt Geometrie, aber nicht automatisch alle Funktionen, Lastfälle, Normen und Nachweise. |
Praktische BOLTCAD-Struktur für den Projektstart
Für eine externe Produktentwicklung lässt sich die Zusammenarbeit pragmatisch in drei Ebenen strukturieren:
1. Anforderungen verstehen
Vorhandenes Lastenheft, Skizzen, CAD-Daten und Kundenanforderungen analysieren; offene Punkte und Risiken sichtbar machen.
2. Technische Umsetzung konkretisieren
Funktionsstruktur, Lösungsvarianten, Konzeptentscheidung, Schnittstellen und Validierungsstrategie entwickeln.
3. Konstruktion und Nachweis durchführen
CAD, FEM, Zeichnungen, ISO GPS, Prototypen und Tests entsprechend dem vereinbarten Entwicklungsstand umsetzen.
Diese Vorgehensweise passt zu einer stufenweisen externen Produktentwicklung von Konzept bis Prototyp und verhindert, dass zu früh zu viel Konstruktionsaufwand in ein noch ungeklärtes Konzept fließt.
Produktentwicklung bei BOLTCAD: Wir unterstützen bei Anforderungsanalyse, Funktionsanalyse, Konzeptentwicklung, Siemens-NX-Konstruktion, FEM/ANSYS, ISO GPS und Funktionsprototypen. Mehr dazu auf unserer Leistungsseite Produktentwicklung.
Produktentwicklung aus Hilden bei Düsseldorf
BOLTCAD ENGINEERING kann bereits in einer frühen Projektphase unterstützen, wenn Anforderungen noch nicht vollständig strukturiert sind. Ziel ist eine belastbare technische Aufgabenstellung, bevor unnötig viel Aufwand in Detailkonstruktion und Prototypen fließt. Projekte bearbeiten wir regional in NRW sowie deutschlandweit.
BOLTCAD DIGITALE NULLSERIELasten- und Pflichtenheft strukturieren die Entscheidungsbasis der BOLTCAD Digitalen Nullserie.
Anforderungen und geplante Umsetzung werden sauber getrennt, bevor Varianten, Konstruktion und virtuelle Absicherung unnötig in eine falsche Richtung laufen.
Vorgehensmodell kennenlernen →
