S-80 潜艇项目向我们表明,在硬件产品开发项目中,需求、约束、设计变更和验证检查必须保持关联。
在硬件产品开发中,一项设计变更可能解决当前的直接问题,却在系统的其他地方引发新的疑问。因此,需求管理不仅仅是记录产品应该做什么,还要在设计不断演进的过程中,让相关约束、设计决策和验证检查始终清晰可见。
西班牙的 S-80 潜艇项目就非常清楚地体现了这种模式。在开发过程中,该项目遇到了重大的重量和浮力问题。重新设计有助于解决这一问题,但更新后的舰艇尺寸又带来了一个新的实际问题:潜艇现在过长,无法适配原本计划使用的港口。
这为所有开发硬件产品的团队带来了一个可迁移的经验——无论你们是在建造潜艇还是电子设备:当需求、约束、设计变更和验证检查彼此脱节时,团队就很难看清某项变更还会影响什么。
西班牙启动 S-80 项目,旨在开发一种新级别的潜艇。在开发过程中,该项目遇到了严重的重量和浮力问题。舰艇比原计划更重,这引发了对其在下潜后是否仍有足够浮力裕度、能够可靠上浮的担忧。
为了解决这一问题,设计进行了修订。其中一项关键变更是加长艇体,这有助于恢复所需的浮力裕度。但这次修订也改变了舰艇的物理尺寸。随后,更新后的潜艇必须根据其运行所依赖的基础设施进行复核,而这一复核发现了一个实际问题:它将不再适配该港口。
这一基础设施问题给原本就已经需要重大重新设计的项目又增加了一层工作。最终,该项目变得比最初预期更加复杂、耗时更长、成本更高。
这个案例提醒我们,每一次重新设计之后都还要再回答一个问题:现在还有什么需要检查?
大多数硬件团队的规模都小于潜艇项目,但同样的模式也会出现在日常产品开发中:某项设计变更可能会影响尺寸、合规要求或接口约束,而这些影响超出了团队当前正试图解决的问题本身。
仅仅知道这些约束还不够。这正是 需求管理重要的地方:它帮助团队在设计演进过程中,让这些约束保持可见、可关联、可审查。对硬件团队而言,这归结为三个实用习惯:
关键约束不应只存在于会议记录、电子表格或某个人的记忆中。它们应被清晰记录下来,并在可能的情况下用可衡量的术语表述,这样团队就能随着设计变更对其进行检查。
当一项需求与其影响的系统区域、模块、设计对象或工程活动建立关联时,这项需求会更有价值。这种关联能帮助工程师理解某个设计决策为何重要、它支持哪些需求,以及当设计发生变化时还可能影响哪些内容。
可追溯性帮助团队回答一个实际问题:这项变更还会影响什么?当需求始终与设计决策、约束、验证检查和证据保持关联时,团队就能看清发生了哪些变化、哪些内容仍被覆盖,以及在返工成本变高之前还有哪些需要审查。
硬件团队需要的不只是一个存放需求文本的地方。文档和电子表格可以记录需求,但随着项目复杂度提升,并且每项需求都需要在整个工程链中保持关联,它们会变得越来越难以管理。
Altium Requirements Portal正是为支持这种工作流程而设计,它在一个共享环境中管理需求、可追溯性、责任归属和验证。团队不再把需求视为孤立的文本,而是能够看清发生了哪些变化、这些变化会影响什么、下一步由谁负责,以及该如何检查这项需求。
每个硬件开发项目中都有一些在设计快速推进时很容易被忽略的约束。它们可能与机械、电气、法规、运行或流程相关。风险并不在于团队缺乏知识,而在于当设计发生变化时,这些重要知识并不总是被记录、关联和审查。
这正是 S-80 案例超越其规模本身的价值所在。当工程意图、设计决策和证据没有随着时间推移保持关联时,同样的模式也会出现在日常产品开发中。
使用整个团队都能访问的需求管理工具,让变更影响更容易追溯。
当需求没有与其所影响的设计工作、约束和验证检查建立关联时,需求管理问题就常常会出现。某项需求也许确实存在,但如果团队看不清它关联到什么,那么在设计发生变化时,就可能遗漏重要影响。
电子表格可以记录需求文本,但随着项目复杂度增加,它们会变得越来越难以管理。团队需要一种方式,让需求在整个工程链中与设计工作、变更历史、验证状态和证据保持关联。
可追溯性帮助团队回答一个实际问题:这项变更还会影响什么?通过将需求与设计决策、约束、验证检查和证据关联起来,团队可以在返工成本变高之前看清哪些内容需要审查。