第04章 软件需求和获取
一、需求的重要性
二、需求的定义及分类
1、需求的定义
1）用户解决问题或达到目标所需条件或权能。
2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
3）一种反映上面1）或2）所属条件或权能的文档说明。
4）它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，如性能、质量标准或设计限制。
2、需求的分类
1）用户需求（user requirement）文档描述了用户使用产品必须要完成的任务，这在使用实例（use case）文档或方案脚本（scenario）说明中予以说明。
2）业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。
3）功能需求（functional requirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务需求。
3、需求分析
三、需求对测试的重要性
1、测试的根本出发点
1）基于什么环境：地铁/办公室/走路/夜晚/户外……
2）基于什么用户：具备什么特征，如身份、收入、区域……
3）基于什么行为：行为或操作流程，如购物流程、操作习惯、行为认知……
2、8020原则
1）Bug分布：需求和设计方面的缺陷占据79%；
3、缺陷的修复成本
四、需求跟踪矩阵
1、需求分析
1）软件需求主要包括两方面：需求开发和需求管理
2）需求开发分为4个阶段：
（1）需求获取阶段
（2）需求分析阶段
（3）编写需求规格阶段
（4）需求验证阶段
2、需求规格说明书
1）完整性
（1）不能遗漏任何必要的需求信息。注重用户的任务而不是系统的功能将有助于避免不完整性。如果知道缺少某项信息，用TBD（“待确定”）作为标识来标明这项缺漏。
2）一致性
（1）一致性是指与其他软件需求或高层（系统、业务）需求不相矛盾。
3）可修改性
（1）要求每项需求要独立标出，并与别的需求区别开来，从而无二义性。每项需求只应在SRS（Software requirement specification）中出现一次。这样更改时易于保持一致性。
4）可跟踪性
（1）应该在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接，这种可跟踪性要求每项需求以一种结构化的方式编写并单独标明，而不是大段大段叙述。
3、需求管理
1）定义需求
2）确认需求
3）建立需求状态
4）需求评审
5）需求跟踪
6）需求变更控制
7）不适当的需求过程可能引发风险
（1）用户不多导致产品无法被接受；
（2）用户需求的增加带来过度的耗费和降低产品的质量；
（3）模棱两可的需求说明可能导致时间的浪费和返工；
（4）用户增加一些不必要的特性和开发人员画蛇添足（gold-plating）；
（5）过分简略的需求说明以致遗漏某些关键需求；
（6）忽略某类用户的需求将导致众多客户的不满；
（7）不完善的需求说明使得项目计划和跟踪无法准确进行。
8）安装Axure软件；
4、测试需求跟踪矩阵
1）根据软件开发需求说明书逐条列出软件开发需求，并判断其可测性；
2）形成可测试的描述并界定出测试范围；
3）根据质量标准，逐条制定质量需求，即测试通过标准；
4）分析测试执行时需要实施的测试类型；
5）建立测试需求跟踪矩阵，对测试需求实施严格有效的管理。
6）见excel文件：第04章需求跟踪矩阵模板.xlsx
（1）需求编号：Req_项目名称_模块名称_功能名称_0001
（2）功能点名称：功能名称
（3）需求描述：跟测试点相关的元素的规则规范
（4）需求拆分：从需求里面可以分析出多少个小的不同的测试要点
（5）测试类别：正向/反向
（6）测试要点：对软件做什么样的测试
（7）测试负责人：交给谁测试
（8）优先级：High、Middle、Low
7）编写测试需求跟踪矩阵的步骤
（1）阅读理解各类需求；
（2）结合界面原型图理解软件各部分功能；
（3）从叶级别的功能点开始编写矩阵；
（4）保证每个功能点都有正反测试思路覆盖，正反测试配比达到1：4（部分功能点没有反向测试）；
（5）只写清测试思路和预期结果，不用具体展开；
（6）写好的测试需求跟踪矩阵必须通过评审才算最终完成。