项目中，你们如何进行需求评审？

开发甲：这个需求咱们能在技术上实现吗？需要的成本、资源是否可支持

开发乙：需求实现方案是否可验证，有没有轻便的实现方案？需求粒度怎么样，对进度、风险评估影响大吗？

测试甲：需求实现的客户群体、用户习惯怎样？测试有哪些风险？

测试乙：需求的测试范围是啥？非功能有什么要求？

包括需求自己、产品经理、项目经理，都会为整个项目推动的源头客户需求进行不停的发出疑问，做出相应的调整，否则产品对需求含糊，开发、测试对需求不理解，项目推进困难，走不少弯路，不仅浪费了时间，还无法保证项目的方向是对的，因为可能你连实现的需求都是错误的，怎么可能保证产品有效、交付质量高？

所以可见需求理解的重要性，那么怎么保证项目组的成员都对需求了解清楚，这就是需求评审发挥作用的时候了，咱们评审的目的就是为了保证开发、测试等项目组成员之间消除歧义、完善需求细节、达成共识，以保证开发的内容是有效的，测试的内容是符合需求的。

01 那么如何开始需求评审呢？

首先，咱们得组织起来召开会议，最有效的方式就是面对面沟通，并且是需求这种又重要内容又多的东西。那么参会人员有哪些？

咱们先来看看项目成员与需求的关系。一个项目成员的构成一般包括：

项目：即项目预研、立项、组建项目团队、设计开发软件、测试、交付验收，软件运营等各项具体的工作

项目经理：项目总负责人、对人员、资源、进度、风险、质量、安全等进行管理，负责项目整体推进与交付运营

用户：即提出需求、验收需求的人

产品(经理)即需求人员：调研需求，编制软件需求规格说明书

开发人员：研发技术人员，即实现软件需求的人

测试人员：负责软件测试，保证软件符合需求

等等，还包括未列举的QA、运维、其它各类文档等都是项目成员

看出来了吗，项目成员里与需求紧密关联的其实就是用户、需求人员、开发、测试人员，所以评审的关键人员就是这些了。

评审形式就看企业内部流程了，比如常见的流程：

       会议前：需求提前邮件发起评审通知到开发、测试，并表明评审会议时间、地点、参会人员及需求文档（原型），开发测试提前熟悉需求，标记不清楚、疑问、建议的地方，待参会时一并提出，提高参会效率。

        会议中：产品人员讲解需求，讲解后，项目组人员提出疑问或看法建议等，待产品人员进行解释，按需采纳建议，保证大家的理解一致性。当然，会议中提出的问题肯定是要做记录的，以免遗漏，这个就叫评审纪要，记录会议中的问题争议点、建议、修改方案等。

        会议后：发送评审纪要，若评审通过或有条件通过，产品则按评审意见（评审纪要）进行修改，最后形成统一的、标准的需求文档发出来确认即可，不需要进行二次评审，若评审不通过，那么可能就要修改后进行二次评审，保证需求的完整性、准确性、理解一致性。

       当然，要保证会议的高效进行，咱们的注意控制会议时间、讨论重点等，以免进度拖沓，重点问题得不到有效解决。

        最后，需求明确后，应落实到各个环节，制定时间节点，排期研发等

02 再来看看需求评审的具体方法或是通用的评审点

参照质量模型（GB25000-51部分）来进行评价：

正确性	对照用户的原始需求，检查产品人员制定的需求文档是否偏离了用户的原始需求。通用检查点： 文笔-错别字，特别是界面上的文案。例如，登陆->登录 逻辑-流程的出入口：是否明确，是否过多（连用户都会昏头转向） 逻辑-条件与规则说明：是否有矛盾，是否仍有不确定的情况，是否疏漏了其它条件以及多个条件组合的情况
明确性	检查需求文档中每一个需求项是否存在一些含糊其辞的词汇，用语是否清晰，是否有歧义。通用检查点： 文笔-歧义-要求无歧义性 文笔-表达不清，模糊-需求规格说明书中的每个需求都描述表达清楚，保证项目干系人都能看懂，且理解一致 逻辑-需求的目标都没想清楚，为了有新版本而做需求
完整性	对照用户的原始需求，检查需求文档是否覆盖了用户所提出的所有需求项，每个需求项有没有遗漏用户提出的必要、重要信息。通用检查点： 逻辑-缺少异常状态的考虑 逻辑-缺少说明数据的来源、类型、精度、取值范围、默认值、显示格式、计算处理方式 用户的体验与交互、文字描述是否有问题、业务流程是否畅通、是否有考虑到异常场景、兼容性、安全性
限制性	每个需求项里是否清晰地描述了输入输出限制，前提条件限制等。通用检查点： 逻辑-没考虑其它功能或需求的关联影响 逻辑-用户体验 实现-在平台限制、人员能力等条件下无法实现 实现-难度较大，耗时
优先级	需求文档中是否做了优先级标识和编号，标记出重要功能、次要功能等
一致性	检查需求文档里的内容前后是否达到一致，确保前后不冲突不矛盾 通用检查点： 文笔-没有统一术语，多处地方用不同词语来表示同一概念 文笔-是否杂乱无章，不便于阅读和查找信息

03 写在最后

以上只是一个简单的顺畅的评审流程，但在实际工作中，可能会出现各种各样的状况，像需求文档根本没有一定的规范，写的不清不楚，或是项目本身迭代快，需要紧急上线等，这些都会影响整个流程的推动，所以在具体项目中，咱们一定要根据实际情况不停思考总结，以求达到最合理的协作状态，发挥团队最大的效用。