Häufige Fallstricke im Requirements Management (und wie man sie vermeidet)

Mit zunehmender Vernetzung von Produkten und kürzeren Entwicklungszyklen werden die Kosten eines schlechten Anforderungsmanagements immer schwieriger tragbar. Unklare Anforderungen können teure Nacharbeiten verursachen, Zeitpläne verzögern, Beschaffungsrisiken erhöhen und Produkte hervorbringen, die Verifikationstests bestehen, aber dennoch die Kundenanforderungen nicht erfüllen. Wenn Unternehmen die häufigsten Fallstricke kennen und die Vorgehensweisen verstehen, mit denen reife Systems-Engineering-Teams sie vermeiden, können sie Risiken reduzieren und gleichzeitig die Entwicklungszeit verkürzen.

Zentrale Erkenntnisse

• Mehrdeutige Anforderungen führen zu kostspieligen Fehlanpassungen. Klare, quantitative und testbare Anforderungen verhindern Nacharbeit und Missverständnisse.
• Isolierte Tools und nicht miteinander verbundene Artefakte erschweren es, die Auswirkungen von Anforderungsänderungen nachzuverfolgen. Automatisierte, durchgängige Rückverfolgbarkeit ist entscheidend, um Änderungen zuverlässig zu managen.
• Scope Creep (Gold-Plating) erhöht die Kosten ohne echten Mehrwert. Das Hinzufügen von „Nice-to-have“-Funktionen steigert Komplexität, Verifikationsaufwand und Kosten, ohne das Kernergebnis des Produkts häufig zu verbessern.

1. Vage Anforderungen führen zu teurem Rätselraten

„Niedriger Stromverbrauch.“ „Hohe Zuverlässigkeit.“ „Schnelle Reaktionszeit.“

Diese Formulierungen finden sich häufig in Anforderungsdokumenten, können für unterschiedliche Ingenieure jedoch Unterschiedliches bedeuten. Wenn Anforderungen auf qualitativer Sprache beruhen, ohne definierte Einheiten, Bereiche oder Verifikationsmethoden, entstehen früh Interpretationslücken, die sich über Subsysteme hinweg fortpflanzen. Das Ergebnis ist eine Divergenz, die oft erst bei der Integration sichtbar wird, wenn Teams feststellen, dass sie auf Basis unterschiedlicher Annahmen gearbeitet haben.

Das Mars Climate Orbiter ist das klassische Beispiel. Eine Abweichung bei den technischen Einheiten (imperial vs. metrisch) wurde bei der Schnittstellenverifikation nicht erkannt, wodurch die Raumsonde etwa 170 km unter der geplanten Eintrittshöhe eintrat und ein Schaden von 327 Millionen US-Dollar entstand. Das eigentliche Problem war nicht die technische Kompetenz, sondern die Art und Weise, wie Schnittstellenanforderungen systemübergreifend spezifiziert, interpretiert und validiert wurden.

Auf praktischer Ebene ist das Muster weniger dramatisch, strukturell jedoch identisch. Eine Anforderung wie „der Sensor soll stromsparend sein“ ist nicht grundsätzlich falsch; sie ist jedoch nicht verifizierbar. Sie lässt zu viel Interpretationsspielraum. Eine Anforderung wie „der Sensor darf im aktiven Betrieb nicht mehr als 1 W und im Standby-Modus nicht mehr als 0,01 W verbrauchen, gemessen unter definierten Betriebsbedingungen“ beseitigt Mehrdeutigkeit, indem sie messbare Zielwerte und Testbedingungen vorgibt.

Zwei Firmware-Teams am selben Sensorknoten interpretieren „niedriger Stromverbrauch“ unabhängig voneinander. Das eine entwickelt für etwa 800 mW, das andere plant mit etwa 200 mW. Beide Designs erfüllen die Anforderung lokal, doch bei der Integration zeigt sich eine Diskrepanz bei den Annahmen auf Systemebene.

Das Problem ist nicht, dass ein Team falschliegt; das Problem ist, dass die Anforderung mehrere gültige Interpretationen zuließ, ohne eine Angleichung zu erzwingen.

2. Isolierte Tools zerstören die Rückverfolgbarkeit

Rückverfolgbarkeit scheint kein Problem zu sein. Bis sie es ist — und das wird meist im denkbar ungünstigsten Moment entdeckt: bei einem Audit in einer späten Projektphase, bei einer Kundenprüfung oder wenn ein Test fehlschlägt und niemand schnell beantworten kann, welche Anforderung damit eigentlich verifiziert werden sollte.

Nicht verbundene Systeme (Anforderungen in einer Tabellenkalkulation, Designentscheidungen in einem Wiki, Tests in einem separaten Tool, Code in der Versionsverwaltung ohne explizite Verknüpfungen) machen Änderungsmanagement zu einer manuellen Abgleichsaufgabe. Wenn sich eine Anforderung mitten im Zyklus ändert (und das wird sie), müssen Ingenieure systemübergreifend nach allen nachgelagerten Artefakten suchen, die davon betroffen sind. Einige werden übersehen. Das Ergebnis sind „Zombie“-Testfälle: Verifikationsverfahren, die weiterhin gegen Anforderungen laufen, die vor Monaten geändert wurden oder gar nicht mehr existieren. Veraltete Dokumentation, obsolete Testverfahren und Designannahmen, die ihre ursprünglichen Anforderungen überleben, sammeln sich unbemerkt an, bis etwas schiefläuft.

Moderne Engineering-Umgebungen begegnen diesem Problem, indem sie Live-Verknüpfungen zwischen Anforderungen, Designartefakten, Testplänen, Softwareständen und Verifikationsnachweisen aufrechterhalten. Mit dem Altium Requirements Portal können Teams beispielsweise diese durchgängige Rückverfolgbarkeit herstellen und Anforderungen mit nachgelagerten Design- und Verifikationsaktivitäten verbinden. Wenn sich eine Anforderung ändert, können Teams die Auswirkungen über den gesamten Entwicklungslebenszyklus hinweg schnell bewerten und sicherstellen, dass betroffene Artefakte geprüft und aktualisiert werden.

In der Praxis bedeutet das, dass Ingenieure sofort erkennen können, welche Subsysteme, Testfälle oder Designdokumente Aufmerksamkeit benötigen, wenn sich eine Anforderung ändert. So können Teams früher und mit größerer Sicherheit reagieren.

3. „Gold-Plating“ bläht den Umfang auf, ohne Mehrwert zu schaffen

Gold-Plating macht aus wünschenswerten Zusatzfunktionen verpflichtende Anforderungen. Jede einzelne wirkt für sich betrachtet gerechtfertigt. Zusammen treiben sie jedoch Kosten und Verifikationsaufwand in die Höhe, ohne den eigentlichen Zweck voranzubringen.

Das Problem verschärft sich, weil goldplattierte Anforderungen unsichtbar werden, sobald sie niedergeschrieben sind. Sie sehen genauso aus wie legitime Funktionalität. Sie erzeugen denselben Designaufwand, dieselbe Testlast und dieselben Dokumentationsanforderungen wie tatsächlich notwendige Funktionen. Und weil sie von jemandem mit legitimer fachlicher Stellung hinzugefügt wurden (etwa einem Ingenieur, der einen realen Randfall erkannt hat), werden sie selten hinterfragt.

Stringente Organisationen vermeiden dies, indem sie eine durchgehende Sichtverbindung zwischen Engineering-Aufgaben und übergeordneten Zielen aufrechterhalten. Jede Anforderung muss ihre Existenz dadurch rechtfertigen, dass sie einen übergeordneten Kundenbedarf, ein Betriebsziel, eine regulatorische Verpflichtung oder ein Leistungsziel auf Systemebene unterstützt.

4. Über-Spezifikation kann zu einem versteckten Kostentreiber werden

Während Gold-Plating unnötige Funktionalität hinzufügt, fügt Über-Spezifikation unnötige Einschränkungen hinzu. Engineering-Teams bauen naturgemäß Margen ein, um Risiken zu reduzieren, doch Probleme entstehen, wenn stark konservative Annahmen dauerhaft in der gesamten Anforderungsbasis verankert werden, ohne ihre nachgelagerten Auswirkungen zu bewerten.

Ein häufiges Beispiel ist die Spezifikation hochzuverlässiger, temperaturerweiterter Komponenten für kontrollierte kommerzielle Umgebungen. Technisch zwar überlegen, löst dies jedoch versteckte Folgekosten aus: spezialisierte Tests, längere Vorlaufzeiten, höhere Stückpreise und einen Verifikationsaufwand auf Verteidigungsniveau.

Bei plattformbasierten oder iterativen Entwicklungsprogrammen potenziert sich dieser Schaden schnell. Verifikationsaktivitäten für unveränderte Anforderungen auf einer etablierten Plattformbasis zu wiederholen, ist reiner Overhead. Es belastet den Zeitplan, liefert jedoch keinerlei neue Informationen.

5. Anforderungen ohne Input aus Fertigung und Lieferkette erzeugen nachgelagerte Risiken

Engineering-Teams schreiben Spezifikationen naturgemäß innerhalb ihres eigenen Fachgebiets: Leistungsanforderungen werden durch Simulation getrieben, Schnittstellen durch die Architektur geformt und Umgebungsbedingungen durch den Anwendungsfall bestimmt. Was häufig fehlt, ist der frühe funktionsübergreifende Input, der festlegt, ob diese Spezifikationen tatsächlich gebaut, beschafft und skaliert werden können.

Spezifikationen, die auf dem Bildschirm makellos aussehen, können nachgelagert zu erheblichen Reibungsverlusten führen. Enge Toleranzen sind in Prototypenmengen vielleicht erreichbar, in der Serienfertigung jedoch unmöglich. Ebenso führen Komponenten, die blind aus Referenzdesigns übernommen werden, oft zu Single-Source-Abhängigkeiten, langfristigen Obsoleszenzrisiken oder massiven Vorlaufzeitrisiken. Wenn Fertigungs- oder Supply-Chain-Teams diese Probleme aufdecken, sind die Anforderungen oft bereits baselined, das Design ist eingefroren und ihre Behebung kostet deutlich mehr, als es in der Anforderungsphase gekostet hätte.

Zur Minderung dieses Risikos müssen Lieferantentiefe, Fertigbarkeit und Beschaffungsrestriktionen als aktive Engineering-Eingaben behandelt werden und nicht als Logistikthemen nach Abschluss des Designs.

Fazit

Der gemeinsame Nenner, der alle fünf Fallstricke verbindet, ist fehlende Verbindung – zwischen Teams, zwischen Tools und zwischen der Spezifikation und der Realität, die sie beschreiben soll.

• Vage Formulierungen schaffen Lücken zwischen Ingenieuren.
• Isolierte Tools schaffen Lücken zwischen Artefakten.
• Fehlender Input aus dem Betrieb schafft Lücken zwischen Design und Produktion.
• Übersprungene Validierung schafft Lücken zwischen dem Produkt und dem Kunden.

Anforderungsmanagement ist keine Dokumentationsübung, sondern das verbindende Gewebe der Produktentwicklung. Teams, die es als lebendigen, integrierten Workflow statt als vorgelagerte Compliance-Aktivität behandeln, entwickeln schneller, mit größerer Sicherheit und zu geringeren Kosten.

Plattformen wie das Altium Requirements Portal schließen kritische Informationslücken und verwandeln Anforderungen von statischen Dokumenten in einen lebendigen, rückverfolgbaren Workflow über den gesamten Produktlebenszyklus hinweg.

Sehen Sie, wie das Altium Requirements Portal Ihrem Team helfen kann, die Rückverfolgbarkeit zu automatisieren, Risiken zu reduzieren und Ihre Entwicklungszyklen zu beschleunigen →

Häufige Fragen

Was macht eine Anforderung im Systems Engineering „gut“?

Eine gute Anforderung ist klar, messbar und testbar. Sie enthält definierte Einheiten, Bedingungen und Akzeptanzkriterien, damit verschiedene Teams sie gleich interpretieren. Starke Anforderungen sind außerdem mit einem übergeordneten Ziel verknüpft (Kundenbedarf, Geschäftsziel oder regulatorische Einschränkung), sodass sie sinnvolle Ergebnisse fördern und nicht nur technische Aktivität.

Warum ist Rückverfolgbarkeit im Anforderungsmanagement wichtig?

Rückverfolgbarkeit verbindet Anforderungen mit Design, Code, Tests und Verifikationsergebnissen und macht Änderungsmanagement vorhersehbar. Wenn sich eine Anforderung ändert, ermöglicht Rückverfolgbarkeit den Teams, die nachgelagerten Auswirkungen sofort zu erkennen, veraltete Tests („Zombie“-Artefakte) zu vermeiden und Integrationsfehler zu verhindern, die durch nicht abgestimmte Annahmen entstehen.

Was ist der Unterschied zwischen Verifikation und Validierung?

Verifikation fragt: Haben wir das Produkt gemäß der Spezifikation korrekt gebaut?
Validierung fragt: Haben wir das richtige Produkt gebaut, um reale Nutzeranforderungen zu erfüllen?

Beides ist essenziell. Ein System kann alle Verifikationstests bestehen und dennoch scheitern, wenn die ursprünglichen Anforderungen unvollständig waren oder nicht mit dem realen Einsatz übereinstimmten.

Wie können Teams Scope Creep und eine Über-Spezifikation vermeiden?

Um Scope Creep zu vermeiden, muss sichergestellt werden, dass jede Anforderung auf ein geschäftliches oder missionsbezogenes Ziel zurückgeführt werden kann. Um eine Über-Spezifikation zu verhindern, sollten Teams einen risikobasierten Ansatz verfolgen und strengere Anforderungen nur dort anwenden, wo sie wirklich notwendig sind. Regelmäßige funktionsübergreifende Reviews (Engineering, Fertigung, Lieferkette) helfen dabei, unnötige Komplexität frühzeitig zu erkennen, bevor ihre Behebung kostspielig wird.