需求分析

一、什么是软件需求

业务需求：反应了组织机构或者客户对系统、产品高层次的要求，他们一般在项目视图与范围文档中予以说明。

用户需求：描述了用户使用产品必须要完成的任务，一般在使用的一些实例中或方案脚本说明中予以说明。

功能需求：定义了开发人员必须实现的软件功能，使得用户完成他们的任务，从而满足业务需求。

非功能性需求：

遵从某些标准，规范和合约。

性能要求。

质量属性。

二、需求澄清

需求阶段位置：

需求是软件项目研发的开始；
需求是组建研发团队后第一次集体参与讨论的事情；
需求是保障质量的重要一环。

需求会议：

1、怎么澄清？
2、谁澄清？
3、测试该怎么澄清？
4、不澄清会造成的后果有哪些？
深刻理解需求，需求澄清的时候就不要在会议上玩手机或做其他事情，因为如果需求理解不深刻，后面测试相关的工作就很难开展。如：不能正确编写测试用例，找不准测试点，业务相关知识串不起来。

测试需要做什么：

找到需求中设计不合理或者很难理解的地方，抛出情感，澄清；思考需求中的测试点，影响我们做测试的地方让产品经理给出说明，比如这种异常情况怎么处理？有多少种状态？状态之间如何转化，反正就是影响我们测试的地方都要让产品经理给出说明，这样给我们后面写测试设计和测试用例扫清障碍。

需求澄清参考：

需求人员将调研的成果，根据需求文档、需求规格说明书、原型图，来对需求测试的功能点进行梳理，而且通过需求文档能够更加了解项目的业务场景。

需求文档现状（3种）：

需求文档现状1
没有需求或者一句话需求：
如果你运气很不好遇到了，我们知道做测试很重要的一点是：我有一个预期，我要把软件运行的实际值跟我的预期值去对比，如果达到了预期，那么就没有问题，如果跟预期结果不一致那就是有问题，那么如果没有需求，我们该怎么办？比如：做一个餐饮系统。

需求文档现状2
有需求文档但是很粗糙：
一般有两种策略:
（1）如果开发团队很配合，可以要求开发或者需求分析人员完善需求文档。
（2）如果因为各种原因，比如时间紧张或者开发就是不愿意，那么就需要自己去沟通，对于文档中不明确的点问清楚，做出标记（红色）整理，切记不要含糊不清的测试，于人于己都没有好处。

需求文档现状3
有详细需求文档:
比较严谨负责的团队项目的实施是有详细的需求文档，我们就可以详阅需求文档来进行测试点的梳理工作，对于需求中你认为不明确的地方可以找项目领导人或者需求人员进行沟通，做到对需求整体把握和理解，利于测试更好的进行。

针对于需求文档的三种现状的答案借鉴：
1、第一种靠嘴去问，大家去协调，协商沟通，然后大家都回答没问题了，自己写一个概要的需求描述，然后扔到群里面去确认，或者直接发邮件确认（大的逻辑变更）。他说可以，那咱们就进行测试，有问题就不断的口头沟通。
2、直接喊需求人员、研发人员一起开会讨论，过一下需求点，整理出测试点，抛出来再确认，达到共识（高效、信息同步）。
3、基于用户使用的场景和行业的经验去做判断，判断它是否合理。

需求评审时测试应该关注什么：

需求评审的要点:要多问几个为什么，为什么要提这个需求（设计的背景是什么，以及设计的总体框架是什么，不要先讲细节）目前是遇到什么困难？现在是怎么做的？如果涉及到业务数量的，还可以问一下量大不大？帮助我们评估需求的合理性。
变更这个需求影响的点还有哪些？是否确认？

三、测试在需求阶段需要做哪些事情

1、首先要读完需求文档。
2、接下来是召开需求评审会议，我们一般在做需求评审的时候，有三方面需要去评审:
第一部分:需求文档里面流程不合理的点，尽量在评审的时候，把这些不合理的点评审出来；
第二部分:需求里面那些没有被量化的点，我们都要评审出来尽量可量化；
第三部分:我们要基于这些显性需求看能否挖掘出来一些隐性的需求。