Lessons Learned im Requirements Management: Das U-Boot-Programm S-80

Das U-Boot-Programm S-80 zeigt, warum Anforderungen, Randbedingungen, Designänderungen und Verifizierungsprüfungen in Hardware-Produktentwicklungsprojekten miteinander verknüpft bleiben müssen.

In der Hardware-Produktentwicklung kann eine Designänderung das unmittelbare Problem lösen und gleichzeitig an anderer Stelle im System neue Fragen aufwerfen. Deshalb geht es beim Requirements Management nicht nur darum, zu erfassen, was das Produkt leisten soll, sondern auch darum, zugehörige Randbedingungen, Designentscheidungen und Verifizierungsprüfungen sichtbar zu halten, während sich das Design weiterentwickelt.

Das spanische U-Boot-Programm S-80 veranschaulicht dieses Muster deutlich. Während der Entwicklung stand das Programm vor einer erheblichen Herausforderung in Bezug auf Gewicht und Auftrieb. Das Redesign half, dieses Problem anzugehen, doch die aktualisierten Abmessungen des Schiffs führten zu einem neuen praktischen Problem: Das U-Boot war nun zu lang für den Hafen, den es nutzen sollte.

Hier ist eine übertragbare Erkenntnis für alle Teams, die Hardware-Produkte entwickeln – ganz gleich, ob Sie ein U-Boot oder ein elektronisches Gerät bauen: Wenn Anforderungen, Randbedingungen, Designänderungen und Verifizierungsprüfungen nicht miteinander verknüpft sind, fällt es Teams schwer zu erkennen, was eine Änderung noch beeinflussen könnte.

Wichtige Erkenntnisse

• Anforderungskonflikte treten häufig dann auf, wenn kritische Randbedingungen außerhalb des Workflows liegen, der zur Überprüfung von Designänderungen verwendet wird.
• Teams können dieses Risiko verringern, indem sie Anforderungen verknüpfen mit den Randbedingungen, Designentscheidungen und Verifizierungsprüfungen, die sie beeinflussen.
• Ein vernetzter Requirements-Workflow erleichtert es, zu erkennen, was sich geändert hat, was davon betroffen ist und was überprüft werden muss, bevor Nacharbeit kostspielig wird.

Was im S-80-Programm geschah

Spanien startete das S-80-Programm, um eine neue Klasse von U-Booten zu entwickeln. Während der Entwicklung stand das Programm vor einem schwerwiegenden Problem bei Gewicht und Auftrieb. Das Schiff war schwerer geworden als geplant, was Bedenken aufwarf, ob es nach dem Tauchen noch über genügend Auftriebsreserve verfügen würde, um zuverlässig wieder auftauchen zu können.

Das Design wurde überarbeitet, um dieses Problem zu beheben. Eine der wichtigsten Änderungen war ein längerer Rumpf, der half, die benötigte Auftriebsreserve wiederherzustellen. Diese Überarbeitung veränderte auch die physischen Abmessungen des Schiffs. Das aktualisierte U-Boot musste daraufhin anhand der Infrastruktur überprüft werden, in der es eingesetzt werden sollte, und diese Prüfung deckte ein praktisches Problem auf: Es passte nicht mehr in den Hafen.

Das Infrastrukturproblem fügte einem Programm, das bereits ein großes Redesign erforderlich gemacht hatte, eine weitere Arbeitsebene hinzu. Das Programm wurde letztlich komplexer, dauerte länger und wurde teurer als ursprünglich erwartet.

Das Beispiel erinnert daran, dass jedes Redesign noch eine weitere Frage beantworten muss: Was muss jetzt außerdem noch überprüft werden?

Was Hardware-Teams aus dem Fall S-80 lernen können

Die meisten Hardware-Teams arbeiten in einem kleineren Maßstab als ein U-Boot-Programm, doch dasselbe Muster kann auch in der alltäglichen Produktentwicklung auftreten: Eine Designänderung kann sich auf Größe, Compliance-Anforderungen oder Schnittstellen-Randbedingungen auswirken, die über das Problem hinausgehen, das das Team gerade zu lösen versucht.

Diese Randbedingungen zu kennen, reicht nicht aus. Genau hier ist Requirements Management wichtig: Es hilft Teams, sie sichtbar, verknüpft und überprüfbar zu halten, während sich das Design weiterentwickelt. Für Hardware-Teams läuft das auf drei praktische Gewohnheiten hinaus:

Kritische Randbedingungen sichtbar halten

Kritische Randbedingungen sollten nicht nur in Besprechungsnotizen, Tabellen oder im Gedächtnis einzelner Personen existieren. Sie sollten klar erfasst und, wo möglich, in messbaren Begriffen formuliert werden, damit Teams sie bei Designänderungen überprüfen können.

Anforderungen mit Designentscheidungen verknüpfen

Eine Anforderung ist nützlicher, wenn sie mit dem Systembereich, Block, Designobjekt oder der Engineering-Aktivität verknüpft ist, die sie betrifft. Diese Verbindung hilft Ingenieuren zu verstehen, warum eine Designentscheidung wichtig ist, welche Anforderungen sie unterstützt und was sonst noch betroffen sein könnte, wenn sich das Design ändert.

Rückverfolgbarkeit nutzen, um die Auswirkungen von Änderungen zu prüfen

Rückverfolgbarkeit hilft Teams bei der Beantwortung einer praktischen Frage: Was wird durch diese Änderung sonst noch beeinflusst? Wenn Anforderungen mit Designentscheidungen, Randbedingungen, Verifizierungsprüfungen und Nachweisen verknüpft bleiben, können Teams erkennen, was sich geändert hat, was weiterhin abgedeckt ist und was überprüft werden muss, bevor Nacharbeit kostspielig wird.

Wie ein vernetzter Requirements-Workflow hilft

Hardware-Teams brauchen mehr als nur einen Ort, an dem Anforderungstexte gespeichert werden. Dokumente und Tabellen können Anforderungen erfassen, werden jedoch schwieriger zu verwalten, je komplexer ein Projekt wird und je stärker jede Anforderung über die gesamte Engineering-Kette hinweg verknüpft bleiben muss.

Altium Requirements Portal wurde entwickelt, um diesen Workflow zu unterstützen, indem Anforderungen, Rückverfolgbarkeit, Verantwortlichkeiten und Verifizierung in einer gemeinsamen Umgebung verwaltet werden. Anstatt Anforderungen als isolierten Text zu behandeln, können Teams sehen, was sich geändert hat, was davon betroffen ist, wem der nächste Schritt gehört und wie die Anforderung geprüft wird.

Was ist das „U-Boot“ in Ihrem Projekt?

Jedes Hardware-Entwicklungsprojekt hat Randbedingungen, die leicht übersehen werden können, wenn sich das Design schnell bewegt. Sie können mechanischer, elektrischer, regulatorischer, betrieblicher oder prozessbezogener Natur sein. Das Risiko besteht nicht darin, dass Teams über zu wenig Wissen verfügen, sondern darin, dass wichtiges Wissen bei Designänderungen nicht immer erfasst, verknüpft und überprüft wird.

Genau das macht den Fall S-80 über seinen Maßstab hinaus nützlich. Dasselbe Muster kann auch in der alltäglichen Produktentwicklung auftreten, wenn Engineering-Absicht, Designentscheidungen und Nachweise im Laufe der Zeit nicht miteinander verknüpft bleiben.

Erleichtern Sie die Rückverfolgung von Änderungsauswirkungen mit einem Requirements-Management-Tool, auf das Ihr gesamtes Team zugreifen kann.

Starten Sie mit Requirements Portal →

Häufige Fragen

Was verursacht Probleme beim Requirements Management in Hardware-Projekten?

Probleme beim Requirements Management treten häufig dann auf, wenn Anforderungen nicht mit der Designarbeit, den Randbedingungen und den Verifizierungsprüfungen verknüpft sind, die sie beeinflussen. Eine Anforderung mag existieren, aber wenn das Team nicht erkennen kann, womit sie verbunden ist, können wichtige Auswirkungen bei Designänderungen übersehen werden.

Warum werden Tabellenkalkulationen für Requirements Management schwierig?

Tabellenkalkulationen können Anforderungstexte erfassen, werden jedoch schwieriger zu verwalten, je komplexer ein Projekt wird. Teams benötigen eine Möglichkeit, Anforderungen über die gesamte Engineering-Kette hinweg mit Designarbeit, Änderungshistorie, Verifizierungsstatus und Nachweisen verknüpft zu halten.

Wie hilft Rückverfolgbarkeit dabei, Nacharbeit in späten Phasen zu reduzieren?

Rückverfolgbarkeit hilft Teams bei der Beantwortung einer praktischen Frage: Was wird durch diese Änderung sonst noch beeinflusst? Durch die Verknüpfung von Anforderungen mit Designentscheidungen, Randbedingungen, Verifizierungsprüfungen und Nachweisen können Teams erkennen, was überprüft werden muss, bevor Nacharbeit kostspielig wird.