近期进入一个新的项目，由于需求问题，导致在项目进行中需要不断地沟通细节，甚至出现基本工作实现完毕后，需求推倒重做的问题，从测试或开发人员角度反思一下，发现前期的需求评审工作我们并没有引起重视，出现了后续的一系列问题。为了避免后续问题，需要加强对需求评审，所以如何进行需求评审，评审是需要关注的什么内容进行了相关总结，希望对大家有帮助。

（当然，要解决新项目的问题不能只通过需求评审就可以解决的，在这里就不体现其他的问题和解决方案了）

1.通读一边需求文档，将不理解的内容打上标记，后续一一处理。

（不理解的有可能存在需求不通顺的问题！）

2.了解需求产生的背景，了解产品人员想要达到的效果以及要解决的核心问题是什么？文档定义交互，文字等信息是否达到了需求目的?当然也不能为了产品目的牺牲用户的核心体验?

例1：卸载挽留功能，目的是在用户卸载时能够起到挽留的效果，当时功能里添加一些萌图，软文，测试发现将常规的按钮位置，用户很容易将客户端卸载，如果调换将按钮位置调换，则挽留的效果就达到了。

（嘿嘿，这里可能会有吐槽吧，就是你们这些人，卸载的时候还得操作两次~~）

例 2：线上版本有一个用了很久的功能：按下某一个固定按键A，进入到特定的功能；在当前版本，提出将固定按键A修改成B,目的是更正用户固有的操作习惯，觉 得B才是合理的入口快捷键，产品目的我们很清楚，但是将一个用户已经使用习惯的快捷键更换还是会对用户的使用造成一定影响的，该问题测试人员公示测试的建 议，但仍然没有阻止产品修改这个策略，结果上线后针对这个操作抱怨一片，产品迫于压力，立即调整回原有的操作，重新上线，像类似的问题，测试一定要严格把 关不能纵容，否则就会出现影响口碑，反复上线，功能白做的情况出现。

3.一个新功能添加的必要性需要评估。(产品预期状态是否能够达到，投入产出比是否合适)

例： 文件管理的在线预览功能，原有支持word，excel，现产品提出支持思维导图mmap文件的预览功能，开发提交功能后，测试验证时发现只能支持文字方 面的预览，图片、结构格式都不显示，如果想要支持主要的结构图，需要花费很多的时间进行调研，测试推进找到产品确认该需求的用户量，如果不添加该功能会有 什么影响，结果是对用户的影响不是很大，只有个位数的人需要这样的功能，投入和产出完全不成正比，所以将该功能删除掉了。

（ps：如果新需求属于实验状态则不能按照常规的评估进行，需要密切关注实验的结果进行评估，同时产品需要不断调优修改，这个是需要测试开发做好心理准备的）

4.模块需求按照画流程图的方式，整理一遍，你会发现逻辑缺失的问题！

5.功能模块是否与其他模块需求冲突，冲突时是否有相关处理方式？

例1：启动app时，会弹出业务相关的推送窗口或提示窗口，这时这些窗口显示顺序尤为重要。

例2：如果有些内容或开关是云控的，更需要避免出现冲突的问题了。

6.体验产品原型图的交互状态是否齐全？测试平台要求的基本交互状态是否齐全？交互行为组合后的效果是否有所体现？

以手机为例：按下抬起、滑动-上下左右、返回、跳转、提示方式、数据显示加载过程、数据加载完毕，操作行为后的页面或对象状态、颜色、玻璃效果等，虚拟键或实体键的交互行为。

7.交互操作是否冗余（例如：操作路径深，操作步骤多，操作复杂）

这个问题一般在测试的过程中都能发现，但在需求评审阶段不太容易，提醒注意。

8.文字、按钮、logo是否能够说明功能，明确表达的意思，让用户能够理解~

9.文字、图片静态元素的颜色，大小，类型，显示位置，长度，显示的形式是否有说明？效果是否统一？

以字体为例：文字为宋体，粉色，居中显示，字体大小为16像素大小，超过5个汉字后，后面内容自动截断。

ps：图片的显示方式—取等比例效果、截取部分内容、直接按照定义的规格压缩图片。

10.动画效果的展示是有助于用户的使用，有助于用户直观体验的，是否耗时？

例：一个动画在刚开始看到的使用很新颖，但是时间长了以后新鲜感一过，动画的展示时间和必要的需求效果就很重要，如果每次启动使用过程中用户每次都要看到这个动画，时间还很长，那就会产生厌恶感。

11.是否有避免误操作的提示？

例：对用户操作行为时，无意中的取消，无意中的删除，给出一个提示，防止用户误操作后的损失。

12.容错处理、异常处理的相关流程或提示是否清楚全面，是否可以有优化的空间（数据或图片无法加载，网络情况，程序崩溃）

例1：在注册页面上填写某一项用户信息错误时，给出的提示是“信息错误”也不给具体是哪一项错误，什么原因错误；

例2：当程序崩溃的时候，给出一个提示框告诉程序崩溃了好，还是在崩溃的时候程序闪退后自动启动程序好呢，连崩溃都可以进行优化还有什么不可以优化的需求呢，嘿嘿，小编大言不惭的发言~~

再补充一下，由于需求评审时无法看到产品的demo，需要人员凭靠经验来进行评审，这时如有同类产品，多体验一些同类产品的交互，在需求评审的时候帮助会很大；如没有同类产品，建议流程图以及原型图结合在使用的平台上走走，比空想脑补会好一些。

希望对大家有所帮助，同时欢迎大家补充你们的需求评审方法~~