需求管理经验教训：Ariane 5 501次飞行
At a Glance
了解 Ariane 5 灾难如何说明：在硬件产品开发项目中，复用的工程成果、既有假设以及验证检查都必须重新审查。
Ariane 5 Flight 501 灾难说明了，为什么我们在直接复用以往项目中的需求、工程设计和测试之前，必须三思而后行。
在硬件产品开发中，复用早期项目中的需求、软件例程、测试用例或设计决策非常常见。这确实可以节省时间，但前提是当初使这些选择成立的条件在当前项目中仍然适用。
Ariane 5 Flight 501是欧洲 Ariane 5 火箭于 1996 年 6 月 4 日的首飞。这枚火箭复用了 Ariane 4 的部分惯性参考软件；Ariane 4 是欧洲更早的一型火箭，该软件曾在其中成功运行。但 Ariane 5 采用了不同的飞行轨迹，其中一个数值超出了软件预期范围，结果火箭在发射后不到一分钟便被摧毁。
这个教训很简单，却很容易被忽视： 在复用过去项目的成果之前，先确认在新项目中，相同的假设和运行条件是否依然成立。
关键要点
- 复用经过验证的需求、软件、测试或设计决策能够节省时间，但必须重新审视其原有背景。
- 在将复用的测试用例用于证明另一款产品中的相同需求之前，应先进行评审。
- 通过将需求、测试流程、证据和状态保持关联，可以降低风险。
Ariane 5 发射中发生了什么
1996 年 6 月 4 日，Ariane 5 在法属圭亚那库鲁完成首次发射，为欧洲航天局搭载了四颗 Cluster 科研卫星。但此次任务持续时间不到一分钟。飞行大约 37 秒后，火箭偏离了预定轨道，随后被摧毁。
问题出在惯性参考系统上，该系统负责向火箭的机载计算机发送姿态和速度数据。Ariane 5 复用了 Ariane 4 的软件，包括一个在发射后仍会持续运行约 40 秒的校准例程。这个例程在 Ariane 4 中运行正常，但 Ariane 5 的飞行剖面并不相同。
由于这种飞行剖面的差异，接连发生了以下情况：
- 一个水平速度值变得比软件预期的更大。
- 软件尝试将该数值从 64 位浮点数转换为 16 位有符号整数，但该值已经无法容纳。
- 转换发生溢出，惯性参考系统将其视为错误并关闭。
- 备用系统运行的是同样的软件，因此也因相同原因关闭。
- 在缺少有效飞行数据的情况下，机载计算机转而使用诊断数据，发出了错误的飞行指令，最终导致火箭被摧毁。
这正是该案例对需求管理具有借鉴意义的原因。被复用的软件此前确实运行成功，但它继承了早期火箭中的一个假设：这个数值会始终保持在安全范围内。Ariane 5 改变了这一假设所处的背景，因此在新系统中，这个假设本应被明确呈现并重新验证。
这个案例提醒我们，即使是复用的工程成果，也仍然需要一个简单检查：其背后的假设在新系统中是否依然成立？
硬件团队能从 Ariane 5 案例中学到什么
大多数硬件团队并不制造火箭，但他们一直都在复用经过验证的成果。一个来自旧产品的 PCB 模块可能会被复制到新设计中。某个固件例程可能会迁移到新的硬件版本中。一项测试流程也可能在电源架构发生变化后仍被继续沿用。
这都是正常的工程实践。复用能帮助团队更快推进工作。关键在于确保需求、假设和验证检查仍然与新系统相匹配。
审查复用的需求
在一个产品中有效的需求，不应在下一个产品中被自动视为仍然有效。文字表述看起来可能完全没变，但其周围的运行条件可能已经改变。例如，某个电流限制、热范围或接口约束，在一个设计中可能是安全的，但在另一个设计中则需要重新评估。在复用需求之前，团队应确认新产品是否仍然运行在相同的假设条件之内。
将假设追溯到验证流程
一些最重要的工程假设，从未被写成正式需求。它们可能存在于设计说明、旧测试计划，或某个人的记忆里。当成果被复用时，这会带来风险。如果某个假设影响了设计决策，团队就需要一种方式来 将其与验证检查关联起来。否则，人们很容易在复用该决策时，看不到当初使其成立和安全的原因。
需求变化时重新审查测试
一个在上个项目中通过的测试用例，并不总能在下个项目中证明同样的内容。如果需求发生变化，或者需求所处的系统环境发生变化，相关测试流程也可能需要同步修改。对于复用测试用例、验收标准或合规性证据的团队来说，这一点尤其重要。
为什么互联的需求工作流会有帮助
更完善的需求工作流，不会把需求当作一条孤立的文本来看待。它会让需求与其背后的原因、受其影响的设计工作，以及用于证明其是否仍然有效的验证工作保持关联。
当发生变化时，这一点尤为关键。一个被复用的需求表面上可能仍然正确，但其背后的假设可能已不再适用于新产品。一个测试可能依然存在，但它可能已经无法再检查正确的条件。
在互联的工作流中，团队可以将关键要素紧密关联：需求、其背后的背景、验证方法、流程、结果、证据以及当前状态。这样，工程师无需在旧文档或测试报告中四处查找，就能看到哪些内容彼此相关，以及哪些部分可能需要再次审查。
Altium Requirements Portal通过在同一共享环境中保留需求、可追溯性、责任归属和验证工作，支持这种工作流。这有助于团队更有信心地复用经过验证的成果，因为需求及其周边检查始终保持关联。
你项目中的旧假设现在仍然成立吗？
每个硬件团队都会复用经过验证的成果。这并不是应当避免的捷径，而是一种能够更快构建产品并延续优秀工程决策的务实方式。
真正有价值的问题是：这些复用成果周围到底发生了什么变化？
- 运行范围是否变了？
- 测试是否需要修订？
- 最初决策背后的那些假设是否仍然适用？
当团队能够回答这些问题时，复用就更值得信赖。需求并不是孤立存在的。其背后的原因、验证检查和相关证据会始终保持足够接近，以便团队在产品背景发生变化时进行审查。
这也是 Ariane 5 至今仍带给硬件团队的启示：只有当复用背后的背景保持关联时，复用才能发挥最佳效果。
借助一款整个团队都可访问的需求管理工具，让复用决策更容易检查，也更值得信赖。
常见问题
复用工程成果会带来风险吗？
当产品背景发生变化，而原有假设、运行限制或验证检查没有被重新审查时，复用工程成果就可能带来风险。这些成果表面上可能仍然正确，但使其在先前项目中成立的条件，可能已经不再适用。
在复用需求、测试或设计决策之前，工程师应检查什么？
团队应检查新产品是否与原项目具有相同的运行条件、接口、限制和验收标准。同时还应确认，相关验证方法在新系统中是否仍然能够证明正确的内容。
当需求被复用时，可追溯性如何提供帮助？
可追溯性能够帮助团队看清需求如何与设计决策、假设、测试流程、证据和状态相连接。当复用成果被带入新项目时，这些关联能让团队更容易判断哪些内容仍然有效，哪些可能需要重新审查。
关于作者
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号