3. 需求分析与评审：需求可测试性分析、需求评审流程、需求跟踪矩阵(RTM)建立、需求变更管理

说实话，做了十几年嵌入式项目，我踩过最大的坑，往往不是代码写错了，而是需求本身就有问题。你想想看，一个连测试都没法验证的需求，开发再努力也是白搭。这一章，我就把需求分析与评审这块硬骨头，掰开了揉碎了讲给你听。

3.1 需求可测试性分析

什么叫需求可测试性？说白了，就是拿到一条需求，你能不能用明确的测试手段去验证它「通过」还是「不通过」。我见过太多需求写成「系统响应要快」、「界面要友好」——这种话，你让测试工程师怎么测？没法测。

我个人习惯，拿到需求第一件事，就是拿「可测试性检查清单」过一遍：

• 明确性：需求有没有歧义？「大约」、「左右」、「可能」这类词，必须干掉。
• 可量化：性能指标有没有具体数值？比如「响应时间小于100ms」就比「响应快」强一百倍。
• 可观测：测试结果能不能被仪器或日志捕获？比如串口输出、GPIO电平变化。
• 可重复：同样的测试条件，能不能复现同样的结果？

这里我分享一个实用技巧。遇到模糊需求，直接反问需求方三个问题：

1. 「你说的这个功能，我拿什么仪器测？」
2. 「测出来的数据，多少算合格？」
3. 「测10次，允许失败几次？」

这三个问题一问，80%的需求漏洞就暴露出来了。

3.2 需求评审流程

需求评审不是走过场。我见过很多团队，评审就是读一遍文档，然后问「大家有没有意见？」——没人吭声，就过了。结果开发到一半，才发现需求根本不合理。

我建议的评审流程是这样的：

阶段	参与角色	关键动作
预审	需求分析师、测试经理	检查需求完整性、可测试性
正式评审	产品、开发、测试、硬件	逐条过需求，记录争议点
复审	核心干系人	确认争议点解决方案
签字确认	项目经理	需求基线化，进入开发

嗯，这里要注意。正式评审的时候，我习惯让测试工程师先发言。为什么？因为测试最清楚哪些需求是「坑」。开发往往觉得「这个功能简单」，但测试一眼就能看出「这个场景根本测不了」。

3.3 需求跟踪矩阵(RTM)建立

RTM这东西，很多人觉得是形式主义。但我在项目中吃过亏——有一次客户问「那个温度报警功能到底测试了没有？」我翻遍了测试报告，愣是找不到对应关系。从那以后，RTM就成了我的命根子。

RTM说白了就是一张表，把需求、设计、测试用例、测试结果串起来。我常用的模板是这样的：

需求ID	需求描述	设计文档	测试用例ID	测试结果	状态
REQ-001	系统上电后3秒内完成自检	DSGN-001	TC-001 ~ TC-005	通过	✅
REQ-002	按键响应时间≤50ms	DSGN-002	TC-006 ~ TC-008	2项未通过	❌
REQ-003	支持OTA升级	DSGN-003	TC-009 ~ TC-015	待测试	⏳

你想想看，有了这张表，项目进度一目了然。哪个需求没测、哪个测试没通过、哪个设计还没做，全都在上面。我每周的项目例会上，就盯着这张表看。

3.4 需求变更管理

嵌入式项目，需求不变更是不可能的。客户今天说要加个蓝牙，明天说要改个协议，后天又说原来的方案更好——这都是常态。关键不是杜绝变更，而是管好变更。

我总结了一套「变更四步法」：

1. 提变更：必须书面提出，口头说的不算。我要求所有变更走邮件或工单系统。
2. 评估影响：变更对进度、成本、质量的影响。这里我特别关注「回归测试范围」——改了A，B会不会挂？
3. 决策：项目经理拍板，接受还是拒绝。不接受就关闭，接受就进入下一步。
4. 执行与验证：更新需求文档、RTM、测试用例，然后执行测试。

这里有个坑，我必须要说。很多团队只关注「变更本身」，忽略了「变更的连锁反应」。举个例子，你改了一个通信协议的数据包格式，看起来只是改个结构体。但你可能需要同步修改：

• Bootloader的解析代码
• 上位机的显示界面
• 测试用的模拟器
• 产线的测试工装

这些地方漏掉一个，就是线上事故。

最后说一句，需求变更不可怕，可怕的是变更不受控。只要流程规范、记录完整、影响评估到位，变更反而是项目优化的机会。