1、需求评审概述：需求评审的定义、目的与价值

说实话，做了这么多年软件质量，我见过太多项目栽在需求阶段。有的团队代码写了一半才发现需求理解错了，有的上线后用户说「这不是我要的」。你想想看，这些问题如果在早期就能发现，得省多少事？

需求评审，就是干这个的。

1.1 需求评审的定义

需求评审，说白了就是一群人坐在一起，拿着需求文档逐条过一遍。看看有没有歧义、有没有遗漏、有没有逻辑矛盾。它不是走形式，而是实打实的质量把关。

我个人习惯把需求评审分成两种：

• 正式评审：有主持人、记录员、评审专家，走完整流程，出评审报告
• 非正式评审：三五个人拉个会，对着文档聊一聊，发现问题就改

我在项目中遇到过一种情况：团队觉得非正式评审效率高，结果漏掉了一个关键的业务规则。上线后用户数据全乱了。嗯，从那以后我建议，核心需求必须走正式评审。

1.2 需求评审的目的

为什么要做需求评审？我总结了三个核心目的：

1. 发现缺陷：需求文档里的错误、遗漏、矛盾，越早发现修复成本越低
2. 达成共识：产品、开发、测试、业务方，大家对需求的理解必须一致
3. 评估可行性：有些需求技术上根本做不了，或者成本太高，评审时就能发现

我曾经参与过一个电商项目，需求文档里写「支持所有支付方式」。评审时开发一问，才知道业务方想要的是微信、支付宝、银行卡、货到付款、分期付款……一共十几种。开发当场就炸了：「这得做到明年去！」最后砍到三种核心支付方式，项目才按期上线。

1.3 需求评审的价值

需求评审的价值，用一句话概括就是：用最小的成本，解决最大的问题。

我给大家算笔账：

缺陷发现阶段	修复成本	相对比例
需求评审阶段	改几行文字	1x
设计阶段	改设计文档	3-6x
编码阶段	改代码+重新测试	10x
测试阶段	定位+修复+回归	15-40x
上线后	紧急修复+用户赔偿	60-100x

你看，需求阶段发现一个缺陷，可能就改几个字。等到上线才发现，那代价就大了去了。我见过一个金融项目，因为需求里一个金额精度没写清楚，上线后对账差了十几万。最后光排查就花了一周，还赔了用户不少钱。

1.4 评审在软件生命周期中的位置

需求评审在软件生命周期里，处于非常靠前的位置。我画个简单的流程你就明白了：

需求收集 → 需求分析 → 需求文档编写 → 【需求评审】 → 设计 → 编码 → 测试 → 上线

为什么它这么重要？因为它是质量保障的第一道防线。你想想看，如果需求阶段就埋下了雷，后面所有的工作都是在雷区里跳舞。

我个人习惯把软件生命周期中的评审点分成三个层次：

• 需求评审：验证「做不做」和「做什么」
• 设计评审：验证「怎么做」
• 代码评审：验证「做得对不对」

这三个评审缺一不可。但说实话，很多团队只做代码评审，跳过了需求和设计评审。结果呢？代码写得再漂亮，方向错了也是白搭。

好了，这一章我们聊了需求评审的定义、目的、价值和它在生命周期中的位置。下一章我会详细讲讲需求评审的具体流程和角色分工。到时候我会分享一些我在实际项目中踩过的坑，保证对你有用。