今天开会中听到这个词,一直对这种正规的软件公司的流程,规范,管理都不是很了解,转篇文章方便以后查阅.
1()有什么作用?
(1) 在需求变更、设计变更、代码变更、
(2) RTM也是验证需求是否得到了实现的有效工具,借助RTM,可以跟踪每个需求的状态:是否设计了,是否实现了,是否测试了。
2 需求跟踪矩阵分为哪几类?
(1) 纵向跟踪矩阵,包括如下的3种:
需求之间的派生关系,客户需求到产品需求
实现与验证关系:需求到设计,需求到测试用例等
需求的责任分配关系;需求由谁来实现
(2) 横向跟踪矩阵:
需求之间的接口关系
3 在实践中,如何把握该建立哪些RTM?
(1) 在SEI的调查中达成的基本共识是:纵向跟踪是必须的,如果没有,则 REQM SP1.4无法通过。横向跟踪如果不作,则是大部分实施。
(2) 对于纵向跟踪矩阵:
必需的:
客户需求与产品需求的跟踪
产品需求与测试用例的跟踪
100%的接口需求需要建立客户需求-产品需求-设计-编码-测试用例的跟踪矩阵
全局性需求要建立跟踪矩阵,包括:客户需求-产品需求-设计-编码-测试用例的跟踪矩阵
核心需求要建立跟踪矩阵
并非必需的:
性能需求可以不建立跟踪矩阵
不影响系统架构的功能需求
4 需求跟踪矩阵由谁来建立?
有多个角色参与建立RTM。需求开发人员负责客户需求到产品需求的RTM建立,测试用例的编写人员负责需求到测试用例的RTM建立,设计人员负责需求到设计的RTM的建立等等。PPQA负责检查是否建立了RTM,是否所有的需求都被覆盖了。
5 RTM是否纳入基线管理?
RTM要纳入基线管理。纳入基线后,每次变更都要申请,RTM的变更一般是和
6 如何简化RTM的
由于在RTM中,需求可能有很多项,设计、测试用例、代码等都有多项,所以建立和维护RTM的工作量还是比较大、比较烦琐。对于变化频繁的项目,更是如此。在实践中,为了简化该RTM的建立与维护工作,有的企业仅仅通过需求与设计、代码、测试用例的编号来实现跟踪,如需求为:r1,r2,……等编号,而设计的编号为:r1-d1,r1-d2,…….,测试用例的编号为:r1-t1,r1-t2等等。需要注意的是需求与它们之间是多对多的关系,仅通过编号是无法实现这种关系的。如果不借助DOORS之类的
当然也可以考虑增大需求、设计、代码、测试用例的颗粒度大小,但是那样RTM的作用就打了折扣,还是一个平衡问题。