怎么做需求分析?

1、需求分析的痛点

2、需求了解要做什么?

3、评审时要关注哪些方面？

在测试过程中，理解需求是第一步，也是最重要的一步。只有正确理解了需求，后面的工作才能顺利进行。

但在了解需求的过程中，经常会遇到各种各样的问题，比如说：

• 产品人员没有提供需求文档，或者提供的文档不清晰、不规范（有时候甚至用几句话描述一个复杂需求）

• 测试同学小明对某个需求不清楚，在公司里问了一圈都没有一个能准确解答他疑问的人（在一些互联网公司比较常见，产品人员流动性大，公司不重视文档记录）

• 产品组织需求评审，询问与会人员有什么问题时，测试同学小明一个问题都问不出来

• 产品给出需求文档后，测试经理安排给某测试同学小明了解需求。一段时间后小明反馈“文档已经看完了”，但测试经理询问“这次改了什么，为什么这么改，有哪些影响范围，什么时候上线”，小明都说不上来

• 需求开发完了，测试同学小明按照跟研发沟通的结果进行验证，测试通过后，产品人员（或客户）验收时却反馈这不是他们想要的，最后系统返工重做，浪费了人力物力，最后还失去了客户。后来公司内部追责时，小明被严厉批评

如果公司中出现了上面提到的场景，往往是因为多方面原因导致的。本文不对此展开细述，有兴趣的同学可以加我微信私聊。接下来讲讲需求评审时我们要要做什么?

• 需求文档是否规范、全面（写的是否清晰、详尽）。便于节省沟通成本，使项目质量和风险可控。
• 完整阅读需求，标记疑问（三种不同颜色，灰色代表没有疑问，红色表示有错误，黄色代表有疑问）。即使测试任务紧张，也要抽出时间来了解需求，不提前看需求，就会出现在需求评审时提不出问题来的尴尬局面。另外我习惯用excel表格把疑问整理下来，这样有助于知识传递。
• 书读百遍其义自见，多读几遍需求可能会自行解决一些疑问，多结合度娘解决一些术语性质的疑问
• 是否有原型图，新人加入团队时重点关注，多问问。
• 整个系统的流程图，发现逻辑缺失（整理资源竞争map、相关性map）
• 口头沟通的，邮件确认。
• 易用性。所谓移动性，就是“易学习、易理解、易操作”。举几个例子如下。
• 功能是否有冗余，操作路径是否过深
  • 需要进行说明的地方是否有说明？说明是否清晰易懂？
  • 文字、图片、按钮排版是否合理
  • 色调是否符合系统特色？效果是否统一
  • 误操作提示
  • 容错处理
• 在需求了解时，多看看竞争产品是如何设计的，或者类似产品（功能）是怎么设计的，这有助于从设计角度去看待产品，也是一条有助于迅速积累易用性经验的建议。

最后来说说评审时要关注哪些方面？个人认为最重要的就是多问问几个为什么。

• 需求背景，为什么要做这个需求，要解决什么问题？为什么要这么解决?是否有更好的解决方式，竞争对手怎么处理的这个问题？他们为什么要那么做？——这些问题都是直接或间接的为了明确我们的测试范围。
• 需求什么时候给出明确的、书面性的资料，什么时候开发完，什么时候上线？以此初步评估测试周期。