码迷,mamicode.com
首页 > 其他好文 > 详细

软件--需求管理

时间:2018-03-11 14:31:44      阅读:218      评论:0      收藏:0      [点我收藏+]

标签:图片   范围   相互   状态   避免   测试   分析   生产   测试方法   

一个好的软件件一定离不开严格的需求管理过程!

今天给大家介绍的就是需求管理!

众所周知,软件并不是凭空产生的,有了需求,才会催生出相应的软件产品!所有生产软件的项目组才会如此的重视软件的需求管理过程,这一个过程叫做需求工程。

一、了解软件需求工程的过程

需求工程流程图

技术分享图片

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

 

可行性分析过程

技术分享图片

需求导出和分析过程

技术分享图片

这之中的需求检查过程尤为重要,需求检查的内容如下

1. 有效性检查
根据不同的用户需要确定不同的功能,所以要在不同用户中协商系统功能,保证功能的有效性。
2. 一致性 检查
在文档中不应该有冲突,即同一个功能在同一系统中不能有不同描述或相互
矛盾的约束。
3. 完备性 检查
需求文档中应该包含所有用户所需要的功能和约束。
4. 现实性检查 :
对已有技术的了解,检查需求以保证能利用现有技术实现。
5. 可检验性检查:
为了避免减少客户和开发商的争议,开发的系统应该可以设计一些可以检验交付的系统是否满足需求。

 

需求管理

技术分享图片

①获得对需求的理解。在初步整理需求的基础上,项目小组和用户代表通过初步的分析讨论,对当前
项目的需求达成共识,并在需求列表中作相应记录。
②获取需求承诺。通过项目参与者的书面承诺,建立各方或各项工作的基准。
③管理需求变更。维护变更历史,为调整与控制提供数据。
④在需求变更后维护对需求的双向可追溯性。从软件可维护性的角度提出管理要求。
⑤标识项目工作(包括计划和产品)与需求的不一致性。若发现不一致性,即启动纠正措施。

 

二、需求评审会议

开需求评审的目的是为了更快捷高效的讨论并解决软件需求的相关问题,便于后期的软件开发工作。

参与会议的人员如下图

技术分享图片

参与人员并不是固定的,根据公司具体要求配置(通常都包含需求、开发、测试人员)

 需求评审会议的流程

 技术分享图片

技术分享图片

技术分享图片

 

三、测试需求分析---测试人员的工作

了解测试软件产品的质量标准:GB/T(推荐性国家标准);ISO(国际标准)

 

软件产品的质量模型:一组特性及特性之间的关系,它提供规定质量需求和评价软件产品质量的基础。

技术分享图片

 

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

技术分享图片

测试需求分析的过程:
1.根据需求规格提取独立的功能点,确定测试范围;
2.对独立功能进行分析,确定各独立功能的测试点;
3.对业务场景即功能组合进行分析,提供业务场景的测试点;
4.对非功能特性进行分析,了解需要测试的非功能特性;
5.针对系统级接口进行分析,了解被测试对象、测试规格。
分析可测性,确定测试方法、工具。

 

测试需求分析的方法:

三步法:调用原始测试需求分析-->编写测试项---->编写测试子项

 

测试项、测试子项的概念:

测试项:作为测试对象的工作版本。

测试子项:是对测试项的细分。

举例

技术分享图片

 

 

四、需求跟踪矩阵(RTM)

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

作用:

(1) 在需求变更、设计变更、代码变更、测试用例变更时,需求跟踪矩阵是目前经过实践检验的进行变更波及范围影响分析的最有效的工具,如果不借助RTM,则发生上述变更时,往往会遗漏某些连锁变化。
(2) RTM也是验证需求是否得到了实现的有效工具,借助RTM,可以跟踪每个需求的状态:是否设计了,是否实现了,是否测试了。

技术分享图片

 

软件--需求管理

标签:图片   范围   相互   状态   避免   测试   分析   生产   测试方法   

原文地址:https://www.cnblogs.com/Ceslie-zhang/p/8543675.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!