需求管理经验教训：单位换算失误
At a Glance
三个单位换算的故事表明：一个数字若只有数值而缺少更多信息，就无法真正指导工程工作。
在硬件产品开发中，工程师每天都会传递各种数字。一个数值可能从工程师进入图纸，从规格进入器件，或从你的团队传给供应商。大多数时候这都不会出问题，因为每个人都知道这个数字代表什么，以及它使用的单位。
风险出现在这个数值跨越交接环节时，而交接双方对它的理解并不一致。一方可能使用磅，而另一方预期的是千克。一份文档可能沿用较早的英制设计，而新项目已经转为公制。这个数字在双方看来都可能是正确的，但它已经不再指向同一个工程决策。
下面三个工程案例展示了这种情况是如何轻易发生的：
三个案例，同一种模式
这三起跨越三个年代的工程事故，以不同形式展现了同一种交接问题。在每个案例中，一个数字从工作流程的一部分传递到了另一部分。对使用者来说，这个数字看起来没问题，但实际上同时存在两种计量体系。问题在于交接时没有明确这个数字使用的是哪一种单位。
加拿大航空 143 航班：Gimli Glider
第一个例子是 1983 年的 Gimli Glider 事件。它展示了加拿大航空在从英制单位切换到公制单位时发生了什么。143 航班是一架从蒙特利尔飞往埃德蒙顿的波音 767，也是该航空公司第一架采用公制的飞机。
当天，燃油量指示系统（FQIS）无法工作，因此机组人员只能手动测量燃油。他们使用了加油人员提供的 1.77 这一密度数值，它表示每升多少磅，这是该机队其余飞机所采用的标准。但这架公制 767 需要的却是以千克/升表示的数值，正确值大约应为 0.8。
飞机起飞时实际携带的燃油只有机组预期的一半，导致飞行中两台发动机都停止工作。幸运的是，飞行员最终成功安全着陆。
火星气候轨道器
16 年后， 火星气候轨道器 因一次导航错误而损失，根本原因是未能将英制单位换算为公制单位。洛克希德·马丁的软件发送的推进器数据单位是磅力秒，而 NASA 的导航软件预期的是牛顿秒，两者相差 4.45 倍。
该航天器原本应在火星上空 150 到 200 千米的轨道运行，结果却下降到大约 57 千米，并 在火星大气层中烧毁。
东京迪士尼乐园的 Space Mountain 过山车
2003 年， 东京迪士尼乐园的 Space Mountain 过山车 通过设计图纸暴露出类似问题。该游乐设施在 1995 年从英制重新绘制为公制设计时，将一根车轴的直径从 44.14 毫米改为 45 毫米。然而，旧版图纸并未停止使用，因此实际上存在两套设计图纸。
2002 年重新订购一批新车轴时，订单依据的是 1995 年之前的设计版本。因此，交付的零件尺寸偏小。这 0.86 毫米的差异使轴承间隙远大于设计预期。经过数月使用后，车轴发生断裂。
在这三个案例中，数字本身看起来都不可疑。问题出在这个数字成为下一个工程步骤的依据时，其单位或来源没有被说明得足够清楚。
这个示意提醒我们：一个数值对所有人来说都可能“看起来没问题”，但依然可能是错的——你的交接双方是否对单位达成了一致？
硬件团队可以从这些案例中学到什么
大多数硬件团队不会驾驶飞机，也不会发射航天器。但类似的交接每天都在发生。一个数值会从需求进入图纸，从规格进入器件，或从你的团队传给供应商。在每一次交接中，单位都必须始终跟随这个数字。以下三种做法会有所帮助：
为每一个需求数值明确标注单位
单独一个数字是不够的。“45” 无法告诉下一个人应该制造什么或测试什么。“45 mm” 才赋予这个数字明确含义。每一次都要把单位紧跟在数值旁边。这不是格式细节，而是需求本身的一部分。
在工程交接点明确责任归属
单位混淆往往发生在信息从一个团队流向另一个团队的时候。一方可能依据某个参考来源工作，而另一方预期的却是另一个来源。这样的交接需要明确的负责人。在数值被下游使用之前，应由某个人检查单位体系、数据格式和源文档。
保持需求与证据可追溯
当一个数值发生变化时，团队需要找到哪些内容依赖于它。这意味着需求、图纸、器件、测试和证据不应彼此割裂地存在。 可追溯性 能帮助团队了解一个数值来自哪里、被哪些对象使用，以及它变化时哪些内容需要审查。
互联的需求工作流如何提供帮助
更好的需求工作流会将数字、单位、负责人以及源文档紧密关联在一起。它不会把这个数值仅仅当作电子表格、图纸或规格书中的一个孤立数字来处理。
这一点在交接环节尤为重要。当一个数值从需求传递到设计工作或验证环节时，下一位人员能够看到该数值的含义、所用单位以及它的来源。如果该数值发生变化，团队也能找出哪些内容需要审查。
Altium Requirements Portal 通过在一个共享环境中集中管理需求、责任归属、可追溯性和验证工作，支持这种工作流。它不会替代工程判断，而是在数值被下游使用之前，帮助团队保持单位、负责人以及相关工程上下文的可见性。
关键要点
- 单位混淆通常始于交接环节：当一个数值被传递到另一个团队、文档或系统，而其单位没有被明确说明时，问题就出现了。
- 在一个数字指导下一个工程步骤之前，团队应当知道它来自哪里，以及由谁负责。
- 可追溯性帮助团队在数值发生变化或流向下游之前，看清有哪些内容依赖于它。
你项目中的每一个数字都完整吗？
上述每一起事故本来都可以避免。并不需要更高明的工程技术，而是在交接时提出清晰的问题：
- 你的需求中的每一个数值都带有单位吗？
- 每一个团队之间的接口都有明确的责任人吗？
- 当前生效的是哪一版规格说明，这一点是否清楚？
- 如果明天某些内容发生变化，你的流程能否显示哪些内容需要审查？
现在，也请你用同样的问题审视自己的项目。如果其中任何一个问题的答案是“可能吧”，那么你已经知道该从哪里开始了。
借助整个团队都能使用的需求管理工具，在每一次交接中让关键工程信息保持清晰且易于核查。
常见问题
为什么工程项目中会发生单位换算错误？
这类混淆很少是因为算术错误。它们通常发生在交接时，也就是一个数值在团队、工具或文档之间传递的时候。一方可能默认该数值采用某一种单位，而另一方则按另一种单位去理解。这个数值本身仍可能是正确的，但它是基于错误假设下的“正确”。
一个完整的需求数值应包含哪些内容？
一个完整的需求数值应包括数字本身、单位，以及正确使用它所需的上下文。例如，“45” 不够明确，而 “45 毫米” 才可以。团队还可能需要知道该数值适用的条件、源文档，以及由谁负责这项需求。
可追溯性如何帮助减少交接错误？
可追溯性会将一个数值与所有依赖它的内容关联起来：从顶层需求一直到相关器件、测试以及对应负责人。当数值发生变化时，这些关联能让团队更容易找出还有哪些内容可能需要审查。这可以降低旧规格、不明确单位或过时测试被误用的风险。
关于作者
Related Technical Documentation
相关资源
目录
Better Requirements
Less Busywork
Build better hardware with AI agents that live and act in your requirements tool.
Learn More
Thank you, you are now subscribed to updates.
沪公网安备 31010502006411号