3. 产品化需求工程

在数据中心芯片项目中，客户SOW（Statement of Work）通常是一份几十页到上百页的商务与技术混合文档，它描述的是“客户想要什么业务结果”，而不是“芯片应该怎么设计”。产品化需求工程的核心任务，就是把SOW中的业务语言、场景约束和验收条件，逐层翻译成可设计、可实现、可验证、可追溯的芯片规格书（Chip Specification）。这个过程不是一次性的文档转换，而是一条带有反馈回路的需求链：捕获→分析→排序→基线化→变更控制。

一、需求捕获：从SOW中提取可工程化的需求条目

捕获阶段最容易犯的错误，是直接把SOW段落复制进需求库。正确的做法是按“业务目标—使用场景—功能行为—接口/性能约束—验收条件”五层拆解。以一份典型的AI训练加速卡SOW为例，客户写的是“支持大规模分布式训练，单卡有效带宽不低于800GB/s，端到端时延抖动小于5%”。这句话至少可以拆出四条独立需求：

• REQ-BW-001：HBM有效带宽≥800GB/s（在70%典型访问命中率下测得）；
• REQ-LAT-002：在持续负载下，P99时延抖动≤5%；
• REQ-SCALE-003：支持≥8卡全互联，集合通信效率≥85%；
• REQ-VER-004：验收测试需在客户指定模型上完成，吞吐量基线由双方共同确认。

每条需求必须带唯一ID、来源（SOW章节号）、类型（功能/性能/接口/可靠性/合规）、优先级、验证方法和责任人。捕获阶段不追求“写全”，而追求“每条都可判定”。如果一条需求无法回答“怎么测、测到什么值算通过”，它就不应该进入需求库，而应退回客户澄清。

二、可行性分析：在架构冻结前识别硬约束

可行性分析不是简单的“能不能做”，而是要在工艺节点、IP复用、封装能力、功耗预算、软件生态五个维度上做交叉判断。以800GB/s HBM带宽为例，若目标工艺为5nm，HBM3e单栈理论带宽约1.2TB/s，看似余量充足；但实际可用带宽受限于NoC仲裁效率、缓存一致性开销和DFI接口利用率。工程上通常按“理论带宽×0.65~0.75”估算可持续带宽。若客户要求800GB/s可持续，则至少需要两栈HBM3e并保证NoC在目标流量模式下不成为瓶颈。

可行性分析的输出不是“可行/不可行”二值结论，而是一张“需求—约束—风险—缓解措施”对照表。对于不可行或高成本的需求，应提出替代方案，例如用Chiplet拆分、用近存计算降低带宽压力，或与客户协商放宽验收条件。

三、优先级排序：用MoSCoW与成本/风险矩阵双维度排序

需求优先级不能只按客户口头强调排序。工程上常用MoSCoW（Must/Should/Could/Won't）结合“实现成本×不实现风险”矩阵。Must级需求通常是合规、基础接口、启动与安全功能；Should级是性能目标；Could级是差异化特性；Won't级是本代明确不做、但需记录以备下代评估的需求。

排序时还要考虑需求之间的依赖关系。例如“支持PCIe 5.0”是“支持CXL 2.0”的前置条件；“支持多租户隔离”依赖“SR-IOV”和“内存加密”两项需求。若前置需求被降级，后置需求必须同步调整，否则会在规格书中留下无法闭合的逻辑缺口。

四、需求追溯矩阵：让每条需求都有“来路”和“去路”

需求追溯矩阵（RTM）是需求工程的骨架。它至少应包含：需求ID、来源SOW条款、需求描述、优先级、验证方法、验证用例ID、设计模块、规格书章节、变更记录。RTM的价值在于双向追溯：正向可从SOW查到验证用例，反向可从任一测试失败定位到原始需求和设计模块。

在芯片项目中，RTM通常与需求管理工具（如Jama、DOORS或内部平台）绑定，但工具不是关键，关键是每条需求在规格书、RTL、验证计划、测试报告中都有唯一锚点。若某条需求在RTM中找不到验证用例，说明它不可验证；若某条RTL模块找不到对应需求，说明可能存在范围蔓延。

五、变更控制：需求基线后的受控修改

当规格书完成评审并基线化后，任何需求变更都必须走变更控制流程（CCB）。变更请求应包含：变更原因、影响范围（设计/验证/软件/封装/功耗）、成本与进度影响、替代方案、审批结论。变更控制的难点不在流程，而在于影响分析是否充分。例如客户要求把PCIe 5.0升级为PCIe 6.0，表面只改PHY，实际会波及SerDes、控制器、PCB材料、散热和验证平台，必须逐项评估。

六、从需求到规格书的落地要点

规格书不是需求库的简单导出，而是经过工程化裁剪后的设计契约。它应明确“做什么、做到什么程度、在什么条件下测、由谁验证”。对于性能类需求，必须写清测试场景、流量模型、温度与电压条件；对于接口类需求，必须写清协议版本、速率、通道数、兼容性要求；对于可靠性需求，必须写清FIT率、温度循环次数、ESD等级。

最后，需求工程的成功标准不是文档厚度，而是三条闭环：每条需求都能追溯到SOW来源，每条需求都有对应验证用例，每次变更都能同步刷新规格书、RTM和验证计划。做到这三条，芯片规格书才真正成为设计、验证、软件和客户验收之间的共同语言。