A.  需求分类

是对需求按照可以管理的方式分组。可分为以下：

(一) 原始需求(客户需求)：原始需求可视为客户的需求，而客户是不了解软件开发技术的，提出的需求是没有办法直接用于开发的，输出文档：市场需求文档(Market Requirement Document，MRD)

(二) 产品需求：产品设计人员或者需求分析人员根据原始需求、结合软件可以实现的功能形成的需求，我个人理解应该就是所说的业务需求，这点待讨论.输出文档：产品需求文档(Product Requirement Document，PRD)

(三) 软件需求：软件开发人员根据软件实现原理进一步将产品需求详细化，输出文档：软件需求规格说明书（Software  Requirements  Specification），简称SRS

(四) 测试需求：开发人员不了解如何对软件进行测试，无法将需求详细到可直接用于测试，所以测试人员还需要将软件需求转化为测试需求

客户需求->产品需求(业务需求)->软件需求->测试需求，可看成需求由简单到详细的过程，对于每个需求类型都要界定需求实现的优先级、工作量和风险

一个经典的例子：

小明说，他要吃猪骨头火锅(客户需求)，80块吧，但没想到又碰到了授客。

授客：“真的想吃？”

小明：“想吃！”

授客：“为什么？”

小明：“我饿了……”（找到了本质）

授客：“哦，这里是两个馒头（产品需求），请你吃，才1块钱”

……

 

小知识：客户和用户的区别

客户是为产品或服务买单的人。

用户是使用产品或服务的人，和产品或服务产生直接的交互过程。

 

客户是对产品或服务形成服务请求和达成买卖关系的人或实体。也可以说是对产品或服务购买有决策权的相关人，这里包含技术决策者和业务决策者等系列人。

客户一般关注的是价格和效果，效果包括了产品使用后的工作效率提升，也隐含了领导的业绩提升。有的时候客户既不关心价格也不关心效果，他关心自己的个人利益。所以找到客户的真实意图是拿单的关键所在。

 

用户对产品的关注点是好用，简单，提高效率，带来便利。产品最终是为用户服务的，即使产品被客户买单，但最终用户用不起来，那么这也是个失败的产品。

所以，产品被用户认可，使用后能提升工作效率，同时给客户带来利益，这才是双赢的局面。

 

B.  测试需求

什么是测试需求，见名知意，要测啥？简单说也就是设计测试用例中的验证点，测试依据，这里包括功能性测试需求，也包括非功能性能测试需求。做测试的要学会从需求规格说明书中挖掘需要测试的验证点，进行用例设计。

例子：从软件需求规格说明书中获取测试需求

（举例目的在于让新手了解写用例并不是直接复制需求说明书中的内容，而是要挖掘测试点）

假设需求规格说明书中有如下一功能需求

功能描述：

功能名称	快速搜索
功能描述	可以根据人名或文章、标题的内容进行搜索
用户及角色	注册用户
补充说明	无

输入项：略

处理流程：略

输出项：略

 

即便仅有功能描述的情况下，我们也可对其进行挖掘测试需求：

1.输入是否支持中文？数字？英文？空格？

2.是否可以输入较长的搜索字符？

3.输入是否支持模糊搜索？

……

确定以上问题为测试需求后即可把它们作为用例设计的验证点，进行用例设计

 

C.  需求评审

1．需求阶段评审的角色和职责

一句话，根据具体情况选择相关人员，充当相关角色，履行相关职责，大家也别吐槽我，现实就是这样，别去记忆这些死规则了

 

2．好的需求应具备的特点

完整性：每一项需求都必须将所有要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。

正确性：每一项需求都必须准确的陈述其要开发的功能。

一致性：指与其它软件需求或高层需求不相矛盾

可行性：每一项需求都必须是已系统和环境的权能和限制范围可以实施的。

无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求简明的用户性的语言表达出来。

健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。

必要性：可理解为每项需求都是用来授权你编写文档的“根源”，要使每项需求都能回溯至某项客户的输入。

可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。

可修改性：每项需求只应在SRS中出现一次。这样更改时容易保持一致性。另外，使用目录列表、索引和相互参照列表方法使软件需求规格说明书更容易修改。

可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好(f i n e - g r a i n e d )的方式编写并单独标明，而不是大段大段的叙述。

分配优先级：应当对所有的需求分配优先级。如果把所有的需求都看作同样的重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度

以上特点也是需求评审的要点，评审前可以根据实际情况指定需求评审检查表来帮助评审。

可以根据以上特点对需求进行评审

 

3．软件需求评审输出

还是一句话，根据具体情况适当的做好评审记录，形式不限，输出文档名称也不限，随便你取，^^内容才是重点

 

4．组织需求评审原则

还是一句话，组织自己定吧，适合就好，效率优先 ^^，别吐槽，没骗你的，不信你百度去，可以百度出不同答案

 

5.需求评审形式

总 体来说可以分为正式评审与非正式评审。正式评审是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职 责，对需求进行正规的会议评审。而非正式的评审并没有这种严格的组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件、文件汇签甚至是网络聊天 等多种形式对需求进行评审。2种形式各有利弊，在评审时，灵活地利用这2种方式。

仔细来说，可以分为如下：

(1)相互评审、交叉评审( Pear-to-pear Review )，甲和乙在一个项目组，处在一个领域，但工作内容不同，甲的工作成果交给乙审查，乙的工作成果交给甲审查，相互评审是最不正式的一种评审形式，但应用方便、有效，被普遍使用

(2)轮查( Pass-round )，又称分配审查方法，是一种异步评审方式。作者将需要评审的内容发送给各位评审员，并收集他们的反馈意见。是一种一种非正式的同行评审。

(3)走查(Walkthrough )，产品的作者将产品在现场向一组同事介绍，描述产品要有怎样的功能、结构，从头到尾走一遍，以收集大家的意见。希望参与评审的其他同事可以发现产品中的错误，并能进行现场讨论这种形式介于正式和非正式之间，其应用普遍。是一种一种非正式的同行评审

(4)小组评审(Group Review)，通过正式的小组会议完成评审工作，是有计划的和结构化的评审形式。评审定义了评审会议中的各种角色和相应的责任，所有参与者在评审会议的前几天就拿到了评审材料，并对该材料进行了独立研究。

(5)审查(Inspection )。审查和小组评审很相似，但更为严格，是最系统化、最严密的评审形式，包含了制定计划、准备和组织会议、跟踪和分析审查结果等。

 

6.需求评审的策略

(1)分层次评审

一般，可以分成如下的层次：

*目标性需求指整个系统需要达到的业务目标，是最高层次的、基本的需求，是企业的高层管理人员所关注的。如果让具体的操作人员去评审目标性需求，容易导致“捡了芝麻，丢了西瓜”的现象。

*功能性需求指整个系统需要实现的功能和任务，是目标之下的第二层需求，是企业的中层管理人员所关注的。

*操作性需求指完成每个任务具体的人机交互〔UI)需求，是企业的具体操作人员所关注的。

 

(2)分阶段评审

应该在需求形成的过程中进行分阶段的多次评审，而不是在需求最终形成后才进行仅有的一次评审分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，这样就降低了需求分析返工的风险，提高了评审的质量。

这点对于敏捷开发模式特别有效。需求按版本为单位划分，根据版本进行需求评审（确定做啥，是不是那样做），通过后开发针对该版本需求进行开发，测试根据需求进行用例编写和维护，然后按这种模式进行迭代。

 

7.注意事项

精心挑选评审人员->定制规范化评审流程->准备好评审材料->做好结果跟踪工作等