4、需求评审方法论：同行评审、专家评审、走查与审查的区别、评审检查清单的制定

说到需求评审，很多硬件工程师第一反应就是「开会」。但说实话，我见过太多评审会开成了「批斗会」或者「故事会」。大家坐在一起，要么互相挑刺，要么各说各话，最后散会了需求文档还是那个样子。

为什么会这样？说白了，就是没搞清楚评审到底该怎么评。今天我就把这几种评审方法掰开揉碎了讲清楚。

4.1 四种评审方式，你分得清吗？

先问个问题：你平时说的「评审」，到底是哪一种？我敢打赌，很多人其实自己也说不清楚。嗯，我们先看个表格，一目了然。

评审方式	正式程度	参与人数	主要目的	典型场景
同行评审	中等	3-5人	发现缺陷、知识共享	模块设计文档、测试用例
专家评审	高	1-3位专家	技术把关、风险识别	关键接口定义、架构方案
走查	低	2-3人	理解内容、发现明显问题	需求初稿、变更说明
审查	最高	5-7人	正式验收、质量门禁	里程碑交付、需求基线

你看，这四种方式各有各的用处。我个人的习惯是：走查用来「过一遍」，同行评审用来「找漏洞」，专家评审用来「把方向」，审查用来「定生死」。

4.2 同行评审：最常用的「照妖镜」

同行评审，说白了就是让跟你水平差不多的同事来看你的文档。我在项目中遇到过很多次，自己写的东西怎么看怎么顺眼，但别人一看就能发现逻辑漏洞。

同行评审的核心要点：

• 角色对等：评审人应该是跟你做类似工作的工程师。让做FPGA的人去评审模拟电路的需求？那基本是浪费时间。
• 聚焦内容：不要评审人，要评审文档。我见过有人把评审会开成了对作者的人身攻击，这完全跑偏了。
• 时间控制：一次评审不要超过2小时。超过这个时间，人的注意力就开始下降了。

4.3 专家评审：关键时刻的「定海神针」

专家评审跟同行评审最大的区别在于：专家是来「拍板」的，不是来「找茬」的。

我记得有一次做高速SerDes接口的需求定义，团队内部争论了很久。后来请了一位有20年经验的老专家，他看了半小时就说：「你们这个时钟方案有问题，参考时钟的抖动预算没留够。」一句话就解决了我们争论两周的问题。

专家评审的注意事项：

• 提前把材料发给专家，别让人家现场看
• 明确告诉专家你需要他关注什么（比如：功耗、时序、成本？）
• 专家的意见要记录，但不要盲从。我见过有人把专家的随口一说当圣旨，结果后面发现专家自己也没想清楚。

4.4 走查 vs 审查：一个「轻」一个「重」

走查和审查，很多人容易搞混。我教你一个简单的区分方法：走查是「散步」，审查是「阅兵」。

走查（Walkthrough）：

• 作者带着1-2个人，把需求文档从头到尾过一遍
• 目的是让听众理解内容，顺便发现一些明显的问题
• 不需要正式记录，不需要签字
• 适合需求初稿、变更说明这种「还没定型」的内容

审查（Inspection）：

• 最正式的评审方式，有主持人、记录员、评审员
• 有明确的检查清单，逐条核对
• 需要形成正式的缺陷报告和评审结论
• 适合需求基线、里程碑交付这种「要存档」的内容

4.5 评审检查清单：你的「防漏网」

做评审最怕什么？最怕漏掉关键点。我刚开始带项目时，评审全凭经验，结果经常是「这次想到了这个，下次又忘了那个」。后来我养成了一个习惯：做检查清单。

下面是我个人常用的需求评审检查清单，你可以直接拿来用：

4.5.1 完整性检查

• □ 所有功能需求是否都有对应的输入/输出定义？
• □ 异常场景是否都覆盖了？（比如：上电时序异常、时钟丢失、温度超限）
• □ 接口定义是否完整？（电气特性、时序要求、协议格式）
• □ 性能指标是否量化？（不要写「尽可能快」，要写「≤ 10μs」）

4.5.2 一致性检查

• □ 需求文档内部是否有矛盾？（比如：前面说功耗≤5W，后面又说散热设计按10W做）
• □ 与上游系统需求是否一致？
• □ 术语使用是否统一？（同一个概念不要一会儿叫「模块A」，一会儿叫「单元A」）

4.5.3 可测试性检查

• □ 每个需求是否都可以通过测试来验证？
• □ 测试条件是否明确？（比如：测试温度范围、测试负载条件）
• □ 通过/失败的标准是否清晰？

4.5.4 可行性检查

• □ 当前技术方案是否可行？
• □ 成本和时间是否在可接受范围内？
• □ 是否有已知的技术风险？

4.6 总结一下

好了，四种评审方式讲完了。你想想看，是不是以前把评审想得太简单了？

最后送你一句话：评审不是为了证明谁对谁错，而是为了把问题在纸面上解决掉。等流片回来再发现问题，那代价可就大了去了。

下一章我会讲怎么把需求「翻译」成硬件设计规格，也就是从「要什么」到「做什么」的关键一步。到时候见。