产品人员会产出一个需求文档，然后组织一个需求的宣讲。测试人员的任务就是在需求宣讲当中，分析需求有没有存在一些问题，然后在需求宣讲结束之后通过分析需求文档，分析里面的测试点并预估一个排期。
一、需求文档是什么样的？
1.查看需求文档
产品需求文档范例：https://docs.qq.com/doc/DV2ZMWUxFWE9XaEVk
2.模拟需求宣讲
一般产品经理在做完用户调查之后，就会根据用户的需求来输入这种需求文档（详细描述用户所需要的功能和功能实现后的效果）。
文档输出之后，产品经理就会和开发人员、测试人员开一个需求宣讲会，他会讲解需求中的内容，并且会对需求中存在的一些问题去进行讨论（讲完需求后，问问大家还有没有什么问题）。
二、需求评审可以从哪几个角度去进行？（评审需求文档）
用户故事：
用户故事指站在用户角度考虑，在真实使用这个产品的过程中，会遇到哪些场景情况（看这些场景情况在需求中是否都找到对应的描述，是否覆盖全了，看看用户故事是否完整）
业务流程图：
根据想出来的用户故事能否构建出完整的业务流程图（各种路径间的约束关系是否说的很明白，执行条件是不是很明确，在需求文档里是不是都写清楚了）
功能点角度：
从功能角度去考虑，数据约束是否全面合理；如果存在分支的逻辑、描述是否覆盖所有路径；如果存在多状态，状态流转是否合理完整；权限描述是否明确。
三、需求分析都需要分析什么东西？（分析需求文档）
1.需求分析定义
把不太直观的需求文档转换成比较直观的测试点
2.需求分析需要分析出来的内容
明确测试范围：需不需要把关联的老功能模块去进行测试
明确功能点：要把需求文档中的功能点都列出来
明确业务流程：根据需求文档中的业务流程图，去把业务流程去梳理清楚
明确输出结果：让每一项都有明确的结果，没有歧义性
分析异常流程：提高系统的容错性，如果用户做了一些不符合要求的操作，要保证系统还是稳定的，可以提供一个正确的服务，而不是直接就崩溃了
预估测试需要的时间和资源：为测试计划的编写做准备
四、怎么去提高需求分析的能力
1.熟悉我们的业务，了解我们的系统：
越熟悉业务，越容易发现问题
2.站在用户的角度，更客观的去考虑问题：
作为用户，产品是不是用起来方便，对于客户的价值是不是大
3.善于总结：
把平常见到的一些用例、需求当中可能存在的一些问题进行一些总结。以后再遇到类似的一些问题时，就可以很快的给出一些自己的建议，也就是不断提高自己的一些业务能力
