Lessons Learned im Requirements Management: Fehler bei der Einheitenumrechnung

Bei der Entwicklung von Hardwareprodukten teilen Ingenieure jeden Tag Zahlen miteinander. Ein Wert wandert von einem Ingenieur in eine Zeichnung, von einer Spezifikation zu einem Bauteil oder von Ihrem Team zu einem Lieferanten. Meistens funktioniert das, weil alle wissen, was die Zahl bedeutet und welche Einheit verwendet wird.

Das Risiko entsteht, wenn dieser Wert eine Übergabe durchläuft und beide Seiten ihn nicht auf dieselbe Weise lesen. Die eine Seite arbeitet vielleicht in Pfund, während die andere Kilogramm erwartet. Ein Dokument verwendet möglicherweise noch ein älteres imperiales Design, während das neue Projekt metrisch ist. Die Zahl kann auf beiden Seiten korrekt aussehen, aber sie steuert nicht mehr dieselbe Entscheidung.

Die drei folgenden Technikgeschichten zeigen, wie leicht das passieren kann:

Drei Fälle, ein Muster

Drei technische Fehlschläge aus drei Jahrzehnten zeigen dasselbe Übergabeproblem in unterschiedlicher Form. In jedem Fall wurde eine Zahl von einem Teil des Workflows in einen anderen weitergegeben. Die Zahl schien für die Anwender richtig zu sein, aber es waren zwei verschiedene Maßsysteme im Spiel. Bei der Übergabe wurde nicht klargestellt, welche Einheit die Zahl verwendete.

Air Canada Flug 143: Gimli Glider

Das erste Beispiel ist der Gimli Glider von 1983. Er zeigt, was geschah, als die Fluggesellschaft Air Canada von imperialen auf metrische Einheiten umstellte. Flug 143, eine Boeing 767 von Montreal nach Edmonton, war ihr erstes metrisches Flugzeug.

An diesem Tag funktionierte das Kraftstoffmengen-Anzeigesystem (FQIS) nicht, daher maß die Besatzung den Kraftstoff von Hand. Sie verwendeten den Dichtewert des Tankwarts von 1,77, angegeben in Pfund pro Liter, dem Standard für den Rest der Flotte. Die metrische 767 benötigte diesen Wert jedoch in Kilogramm pro Liter, wobei der richtige Wert ungefähr 0,8 betrug.

Das Flugzeug startete mit nur etwa der Hälfte des Kraftstoffs, den die Besatzung erwartete, wodurch während des Flugs beide Triebwerke ausfielen. Glücklicherweise gelang es den Piloten, sicher zu landen.

Mars Climate Orbiter

Sechzehn Jahre später ging der Mars Climate Orbiter durch einen Navigationsfehler verloren, der durch die fehlgeschlagene Umrechnung von englischen in metrische Einheiten verursacht wurde. Die Software von Lockheed Martin übermittelte Triebwerksdaten in Pound-Force-Sekunden. NASAs Navigationssoftware erwartete Newtonsekunden, die sich von Pound-Force-Sekunden um den Faktor 4,45 unterscheiden.

Das Raumfahrzeug sollte in 150 bis 200 Kilometern Höhe über dem Mars in eine Umlaufbahn eintreten. Stattdessen sank es auf etwa 57 Kilometer ab und verglühte in der Marsatmosphäre.

Tokyo Disneyland’s Space Mountain Achterbahn

Im Jahr 2003 zeigte die Space Mountain Achterbahn im Tokyo Disneyland ein ähnliches Problem in Konstruktionszeichnungen. Die Attraktion wurde 1995 von imperialen auf metrische Maße umgezeichnet, wobei sich der Durchmesser einer Achse von 44,14 auf 45 Millimeter änderte. Die älteren Zeichnungen wurden jedoch nicht außer Gebrauch genommen, sodass zwei Sätze von Konstruktionszeichnungen im Umlauf waren.

Als 2002 ein neuer Satz Achsen nachbestellt wurde, basierte die Bestellung auf der Konstruktionsversion von vor 1995. Dadurch wurden die Teile zu klein geliefert. Dieser Unterschied von 0,86 Millimetern machte das Lagerspiel deutlich größer als vorgesehen. Nach monatelangem Einsatz brach die Achse.

In allen drei Fällen sah die Zahl selbst nicht verdächtig aus. Das Problem begann, als diese Zahl zur Grundlage des nächsten technischen Schritts wurde und ihre Einheit oder Herkunft nicht eindeutig genug war.

Die Abbildung erinnert daran, dass ein Wert für alle richtig aussehen und dennoch falsch sein kann: Sind sich beide Seiten Ihrer Übergabe über die Einheit einig?

Was Hardware-Teams aus diesen Geschichten lernen können

Die meisten Hardware-Teams fliegen keine Flugzeuge und starten keine Raumfahrzeuge. Aber ähnliche Übergaben passieren jeden Tag. Ein Wert wandert von einer Anforderung in eine Zeichnung, von einer Spezifikation zu einem Bauteil oder von Ihrem Team zu einem Lieferanten. Bei jeder Übergabe muss die Einheit beim Wert bleiben. Drei Praktiken können helfen:

Einheiten bei jedem Anforderungswert angeben

Eine Zahl allein reicht nicht aus. „45“ sagt der nächsten Person nicht, was gebaut oder getestet werden soll. „45 mm“ gibt der Zahl Bedeutung. Halten Sie die Einheit jedes Mal direkt neben dem Wert. Sie ist kein Formatierungsdetail, sondern Teil der Anforderung.

Verantwortlichkeiten bei technischen Übergaben festlegen

Verwechslungen bei Einheiten entstehen oft dann, wenn Informationen von einem Team zum anderen wandern. Eine Seite arbeitet möglicherweise mit einer bestimmten Referenz, während die andere eine andere erwartet. Für diese Übergabe braucht es eine klare verantwortliche Person. Jemand sollte das Einheitensystem, das Datenformat und das Quelldokument prüfen, bevor der Wert nachgelagert verwendet wird.

Anforderungen und Nachweise rückverfolgbar halten

Wenn sich ein Wert ändert, muss das Team herausfinden können, wovon er abhängt. Das bedeutet, dass Anforderung, Zeichnung, Bauteil, Test und Nachweis nicht als voneinander getrennte Elemente existieren sollten. Rückverfolgbarkeit hilft dem Team zu sehen, woher ein Wert stammt, was ihn verwendet und was überprüft werden muss, wenn er sich ändert.

Wie ein vernetzter Requirements-Workflow hilft

Ein besserer Requirements-Workflow hält die Zahl, ihre Einheit, ihren Verantwortlichen und das Quelldokument eng beieinander. Er behandelt den Wert nicht einfach als lose Zahl in einer Tabelle, Zeichnung oder Spezifikation.

Das ist besonders bei Übergaben wichtig. Wenn ein Wert von einer Anforderung in die Konstruktion oder Verifikation übergeht, kann die nächste Person sehen, was der Wert bedeutet, welche Einheit er verwendet und woher er stammt. Wenn sich der Wert ändert, kann das Team außerdem erkennen, was überprüft werden muss.

Altium Requirements Portal unterstützt diese Art von Workflow, indem Anforderungen, Verantwortlichkeiten, Rückverfolgbarkeit und Verifikationsarbeit in einer gemeinsamen Umgebung zusammengeführt werden. Es ersetzt nicht das technische Urteilsvermögen. Es hilft dabei, Einheit, Verantwortlichkeit und den zugehörigen technischen Kontext sichtbar zu halten, bevor ein Wert nachgelagert verwendet wird.

Wichtige Erkenntnisse

• Verwechslungen bei Einheiten beginnen oft bei Übergaben, wenn ein Wert an ein anderes Team, Dokument oder System weitergegeben wird und seine Einheit nicht eindeutig gemacht wird.
• Bevor eine Zahl den nächsten technischen Schritt bestimmt, sollte das Team wissen, woher sie stammt und wer dafür verantwortlich ist.
• Rückverfolgbarkeit hilft Teams zu erkennen, was von einem Wert abhängt, bevor er geändert oder weitergegeben wird.

Ist jede Zahl in Ihrem Projekt vollständig?

Jeder dieser Vorfälle wäre vermeidbar gewesen. Nicht durch bessere Ingenieurskunst, sondern durch klare Fragen bei der Übergabe:

• Trägt jeder Wert in Ihren Anforderungen eine Einheit?
• Gibt es für jede Schnittstelle zwischen Teams eine verantwortliche Person?
• Ist klar, welche Version einer Spezifikation die aktuelle ist?
• Würde Ihr Prozess zeigen, was überprüft werden muss, wenn sich morgen etwas ändert?

Stellen Sie sich jetzt dieselben Fragen zu Ihrem Projekt. Wenn die Antwort auf eine davon „wahrscheinlich“ lautet, wissen Sie bereits, wo Sie anfangen müssen.

Halten Sie wichtige technische Informationen bei jeder Übergabe klar und leicht prüfbar – mit einem Requirements-Management-Tool, das Ihr gesamtes Team nutzen kann.

Erste Schritte mit Requirements Portal →

Häufig gestellte Fragen

Warum passieren Fehler bei der Einheitenumrechnung in Technikprojekten?

Diese Verwechslungen entstehen selten durch schlechte Mathematik. Sie passieren bei Übergaben, wenn ein Wert zwischen Teams, Tools oder Dokumenten wechselt. Die eine Seite nimmt vielleicht an, dass der Wert in einer bestimmten Einheit vorliegt, während die andere ihn in einer anderen liest. Der Wert kann also korrekt sein, aber für die falsche Annahme.

Was sollte ein vollständiger Anforderungswert enthalten?

Ein vollständiger Anforderungswert sollte die Zahl, die Einheit und den Kontext enthalten, der für die richtige Verwendung nötig ist. Zum Beispiel reicht „45“ nicht aus; „45 Millimeter“ schon. Das Team muss möglicherweise auch die Bedingung kennen, unter der der Wert gilt, das Quelldokument und wer für diese Anforderung verantwortlich ist.

Wie hilft Rückverfolgbarkeit dabei, Übergabefehler zu reduzieren?

Rückverfolgbarkeit verknüpft einen Wert mit allem, was von ihm abhängt: von der übergeordneten Anforderung bis hin zum Bauteil, Test und Verantwortlichen dahinter. Wenn sich ein Wert ändert, machen diese Verknüpfungen es leichter zu erkennen, was sonst noch überprüft werden muss. Dadurch sinkt die Wahrscheinlichkeit, dass eine alte Spezifikation, eine unklare Einheit oder ein veralteter Test versehentlich weiterverwendet wird.