需求管理-上课笔记-3.02

需求管理（整个软件生成的源头，整个测试工作的源头）

 

依据软件的需求，进行测试工作。

软件的生命周期：整个软件从无到有的过程

 

市场调研阶段→需求阶段（需求人员开始介入，将调查到的市场需求归类整理成一个文档，让后续开发人员进行开发→  设计（设计人员借用计算机技术做具体设计）→开发人员编写具体的代码，实现前面这些系统要求具备的需求→测试阶段（测试团队测试）→上线发布→运行维护

 

配置管理人员：编译代码，环境部署。

角色划分，每个人有不同的职责：市场，需求，开发，测试，配置，运维

测试人员的测试对象(软件）：与软件有关的说明性的文档（操作文档，安装文档…)+具体程序代码，数据。

 

课程目标：

了解软件需求工程过程

      1>可行性分析

  2> 需求导出分析过程  

 3>需求检查

      1.有效性检查：根据不同用户需要确定不同的功能，要在不同用户中协商系统功能，保证功能有效性

      2.一致性检查：文档不应有冲突，同个功能在同一系统中不能有不同描述或相互矛盾的约束

      3.完备性检查：需求文档应包含所有用户需要的功能和约束

      4.现实性检查：对已有技术的了解，检查需求以保证能利用现有技术实现

      5.可检验性检查：为避免减少客户、开发商的争议，开发的系统应可以设计一些检验交付的系统是否满足需求

   4>需求管理

1.获得对需求的理解，在初步整理需求的基础上，项目小组和用户代表通过初步分析讨论，对当前项目的需求达成共识，并在需求列表在做相应记录

      2.获取需求承诺，书面承诺，建立各方、各项工作的基准

      3.管理需求变更，维护变更历史，为调整与控制提供数据

      4.需求变更后维护对需求的双向可追溯性，从软件可维护的角度提出管理要求

      5.标识项目工作（计划和产品）与需求的不一致性，若不一致，随即启动纠正措施

   5>需求评审

人员不是固定的，途中是一些通常项目的人员

    召开前→会议中→会议后

 

  掌握软件需求评审的过程和内容

  掌握测试需求分析

                            GE/T(不带T属于国家强制性，带T不强制）/16260-2006、ISO 9126:2001

         质量模型：一组特性及特性之间的关系，它提供规定质量需求和评价质量的基础

了解软件质量特性，测试工程师需进行测试需求分析，定义测试范围，明确测试项及测试子项，便于后续设计测试用例

原始测试需求分析：

      测试需求来源：SRS(Software Requirements Specification)、开发需求，协议/标准/规范，用户需求，继承性需求，测试经验库，同行竞争分析等

      原始需求：口述，记录

            “用户需要一杯水”

      需求规格：原始需求细化

             “用户需要一杯50ml，60℃左右的纯净水”

      开发需求：希求规格细化，一般有明确的实现方式

               用户需要一杯用双层玻璃杯盛着的50ml，60℃左右的纯净水，并且使用木质托盘送上”

 

 

 

掌握如何获取测试项、测试子项

了解需求跟踪矩阵的内容、目的

需求跟踪矩阵（Requirements Traceability Matrix）RTM

是一种主要管理需求变更和验证需求是否得到了实现的有效工具，可以跟踪每个需求的状态

 

RTM作用：1>在需求变更，设计变更，代码变更，测试用例变更时，需求跟踪矩阵是目前经过实践检验的进行变更搏波及范围影响分析的最有效工具，如不借助RTM，则发生上述变更时，往往会遗漏某些连锁变化。

               ：2>RTM也是验证需求是否得到了实现的有效工具，借助RTM，可以跟踪每个需求的状态：

ssr：需求分析报告中的需求状态（已描述，未描述）

 

软件需求说明书

SRS(Software Requirements Specification), 软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解， 使之成为整个开发工作的基础。包含硬件、功能、性能、输入输出、接口需求、警示信息、保密安全、数据与数据库、文档和法规的要求等等。