Requirements Management Lessons Learned: Unit Conversion Failures

In hardware product development, engineers share numbers every day. A value moves from an engineer into a drawing, from a specification to a part, or from your team to a supplier. Most of the time, that works because everyone knows what the number means and which unit it uses.

The risk appears when that value crosses a handoff, and the two sides do not read it the same way. One side may work in pounds while the other expects kilograms. One document may use an older imperial design, while the new project is metric. The number can look correct on both sides, but it is no longer guiding the same decision.

The three engineering stories below show how easily that can happen:

Three Cases, One Pattern

Three engineering failures, across three decades, show the same handoff problem in different forms. In each case, a number moved from one part of the workflow to another. The number seemed right to the users, but two measurement systems were at play. The handoff didn't clarify which unit the number used.

Air Canada Flight 143: Gimli Glider

The first example is the Gimli Glider from 1983. It shows what happened when an airline, Air Canada, switched from imperial to metric units. Flight 143, a Boeing 767 flying from Montreal to Edmonton, was its first metric aircraft.

On that day, the fuel quantity indication system (FQIS) was not working, so the crew measured the fuel by hand. They used the refueler's density figure of 1.77, which was pounds per liter, the standard for the rest of the fleet. But the metric 767 needed that figure in kilograms per liter, where the right number was about 0.8.

The aircraft took off with only half the fuel the crew expected, which caused both engines to stop during the flight. Luckily, the pilots managed to land it safely.

Mars Climate Orbiter

Sixteen years later, the Mars Climate Orbiter was lost due to a navigation error caused by a failure to translate English units to metric. Lockheed Martin's software sent thruster data in pound-force seconds. NASA's navigation software expected newton-seconds, which differ from pound-force seconds by a factor of 4.45.

The spacecraft was meant to orbit at 150 to 200 kilometers above Mars. Instead, it dropped to about 57 kilometers and burned up in Mars' atmosphere.

Tokyo Disneyland’s Space Mountain Roller Coaster

In 2003, Space Mountain roller coaster at Tokyo Disneyland showed a similar issue through design drawings. The ride was redrawn from imperial to metric in 1995, changing an axle diameter from 44.14 to 45 millimeters. However, the older drawings were not taken out of use and, as a result, there were two sets of design drawings.

In 2002, when a new set of axles was reordered, the order was based on the pre-1995 design version. As a result, the parts came in undersized. That 0.86 millimeter difference made the bearing clearance much wider than intended. After months of use, the axle broke.

Across all three cases, the number itself did not look suspicious. The problem started when that number became the basis for the next engineering step, and its unit or source was not clear enough.

The illustration is a reminder that a value can look right to everyone and still be wrong: do both sides of your handoff agree on the unit?

What Hardware Teams Can Learn From These Stories

Most hardware teams are not flying aircraft or launching spacecraft. But similar handoffs happen every day. A value moves from a requirement to a drawing, from a spec to a part, or from your team to a supplier. At each handoff, the unit has to stay with the number. Three practices can help:

Specify Units on Every Requirement Value

A number on its own is not enough. “45” does not tell the next person what to build or test. “45 mm” gives the number meaning. Keep the unit next to the value every time. It is not a formatting detail; it is part of the requirement.

Assign Ownership at Engineering Handoffs

Unit mix-ups often happen when information moves from one team to another. One side may be working from one reference, while the other expects another. That handoff needs a clear owner. Someone should check the unit system, data format, and source document before the value is used downstream.

Keep Requirements and Evidence Traceable

When a value changes, the team needs to find what depends on it. That means the requirement, drawing, part, test, and evidence should not live as disconnected pieces. Traceability helps the team see where a value came from, what uses it, and what needs review when it changes.

How a Connected Requirements Workflow Helps

A better requirements workflow keeps the number, its unit, its owner, and the source document close together. It does not treat the value as just a loose number in a spreadsheet, drawing, or specification.

That matters most at handoffs. When a value moves from a requirement to design work or verification, the next person can see what the value means, which unit it uses, and where it came from. If the value changes, the team can also find what needs reviewing.

Altium Requirements Portal supports this kind of workflow by keeping requirements, ownership, traceability, and verification work in one shared environment. It does not replace engineering judgment. It helps keep the unit, owner, and related engineering context visible before a value is used downstream.

Key Takeaways

• Unit mix-ups often start at handoffs, when a value moves to another team, document, or system and its unit is not made clear.
• Before a number guides the next engineering step, the team should know where it came from and who owns it.
• Traceability helps teams see what depends on a value before it changes or moves downstream.

Is Every Number in Your Project Complete?

Every one of these incidents was preventable. Not with better engineering, but with clear questions asked at the handoff:

• Does every value in your requirements carry a unit?
• Does every interface between teams have someone accountable for it?
• Is it clear which version of a specification is the current one?
• If something changed tomorrow, would your process show what needs to be reviewed?

Now ask yourself the same questions about your project. If the answer to any of these is "probably", you already know where to start.

Keep important engineering information clear and easy to check at every handoff with a requirements management tool your whole team can use.

Get Started with Requirements Portal →

Frequently Asked Questions

Why do Unit Conversion Errors Happen in Engineering Projects?

These mixups rarely come from bad math. They happen at handoffs, when a value moves between teams, tools, or documents. One side may assume the value is in one unit, while the other side reads it in another. The value can still be correct, but it is correct for the wrong assumption.

What Should a Complete Requirement Value Include?

A complete requirement value should include the number, the unit, and the context needed to use it correctly. For example, “45” is not enough; “45 millimeters" is. The team may also need to know the condition where the value applies, the source document, and who owns that requirement.

How Does Traceability Help Reduce Handoff Mistakes?

Traceability links a value to everything that depends on it: from the top-level requirement down to the part, test, and owner behind it. When a value changes, those links make it easier to find what else may need review. This reduces the chance that an old spec, an unclear unit, or an outdated test remains in use by mistake.