2. 需求阶段风险识别：需求模糊与变更风险、需求文档评审方法、需求基线化管理
说实话，我见过太多嵌入式项目在后期翻车，根源都出在需求阶段。
硬件改一版，周期至少四周起步，打样费几千上万。软件改架构，牵一发动全身。你想想看，如果需求没理清楚就开干，后面调试时你会发现——这根本不是客户要的东西。
这一节，我们就聊聊需求阶段怎么管风险。
2.1 需求模糊：嵌入式项目的头号杀手
什么叫需求模糊？我举个例子。
客户说：“这个设备要能快速响应。” 什么叫“快速”？是 10ms 还是 100ms？是中断响应还是轮询响应？没有量化，就是模糊。
- 使用“大概”、“尽量”、“可能”等不确定词汇
- 缺少具体的性能指标（响应时间、功耗、精度）
- 没有明确异常处理逻辑（断网怎么办？掉电怎么办？）
- 接口协议只写“兼容XX协议”，但不写版本号
我在项目中遇到过最典型的一次：客户说“数据要实时上传”。我们按 1 秒间隔做了，结果验收时客户说“实时”是指 100ms。没办法，改硬件选型，换更高主频的 MCU，成本直接涨了 30%。
2.2 需求变更：不是洪水猛兽，但要有流程
需求变更是常态，不变才不正常。但嵌入式项目最怕的是——变更没有流程。
硬件工程师按 V1.0 画板子，软件按 V1.1 写代码，测试按 V1.2 做用例。最后对不上，互相甩锅。
需求变更必须走正式流程。我建议至少包含这几步：
- 变更申请——谁提的？改什么？为什么改？
- 影响评估——改硬件？改软件？改测试？改文档？
- 成本与周期评估——多花多少钱？多花多少时间？
- 变更评审——项目经理、硬件、软件、测试一起签字。
- 变更实施与通知——更新基线，通知所有人。
| 变更类型 | 影响范围 | 审批层级 | 典型周期 |
|---|---|---|---|
| 功能新增 | 软件 + 测试 | 项目经理 | 1-3 天 |
| 接口修改 | 硬件 + 软件 + 测试 | 技术负责人 | 3-7 天 |
| 性能指标变更 | 硬件选型 + 软件架构 | 项目总监 | 1-2 周 |
| 核心方案变更 | 全项目组 + 供应链 | 高层决策 | 2 周以上 |
2.3 需求文档评审：别走过场
很多团队做需求评审，就是拉个会，读一遍文档，问“有没有问题？” 没人说话，就过了。这跟没评审一样。
我自己的评审方法，分三轮：
- 第一轮：自审——写文档的人自己检查。有没有歧义？有没有遗漏？有没有前后矛盾？
- 第二轮：互审——硬件审软件需求，软件审硬件需求。为什么？因为对方能发现你没想到的依赖关系。
- 第三轮：专家评审——找有经验的人，专门挑刺。重点关注：边界条件、异常处理、资源约束。
- 所有输入输出是否定义了电气特性（电压、电流、时序）？
- 通信协议是否明确了帧格式、校验方式、超时处理？
- 是否有明确的启动、运行、休眠、故障状态定义？
- 是否有明确的错误码或故障码定义？
- 是否有明确的测试验收标准？
说白了，评审不是找茬，是省钱。需求阶段发现一个问题，改一行字就行。等到调试阶段发现，改代码、改硬件、改测试，成本翻几十倍。
2.4 需求基线化管理：锁住版本
基线是什么？就是某个时间点，大家达成一致的需求版本。之后所有变更，都要基于这个基线来谈。
没有基线，就是各说各话。硬件说“我按 V2 做的”，软件说“我按 V3 做的”，测试说“我按 V1 测的”。乱成一锅粥。
- 每个里程碑（需求冻结、设计冻结、测试冻结）建立基线
- 基线文档必须带版本号、日期、审批人签名
- 基线变更必须走变更流程，更新版本号
- 所有项目成员只能基于最新基线工作
嗯，这里要注意：基线不是锁死需求不让改，而是让变更可控。每次变更都留下记录，将来出了问题，能追溯到是谁、在什么时候、为什么改的。
2.5 知识结构图：需求阶段风险管控全景
下面这张图，是我自己总结的需求阶段风险管控框架。你可以把它贴在工位上。
2.6 避坑指南：我踩过的那些坑
最后，分享几个我亲身经历的教训：
- 客户说“跟XX产品一样就行”，我没让他写下来。结果验收时他说“这里不一样，那里也不一样”。—— 从那以后，任何“参考XX”都必须附上具体差异清单。
- 需求文档里写了“支持OTA升级”，但没写升级失败怎么办。结果现场升级到一半断电，设备变砖。—— 从那以后，所有功能需求必须包含异常处理。
- 项目经理口头答应客户加功能，没走变更流程。硬件已经投板了，软件已经写完了。最后硬塞进去，稳定性一塌糊涂。—— 从那以后，口头变更一律不认，必须邮件+签字。
嗯，这些坑，你大概率也会遇到。提前做好需求阶段的风险管控，后面调试会轻松很多。