还剩1页未读,继续阅读
文本内容:
需求跟踪矩阵1需求跟踪矩阵RTM有什么作用?1在需求变更、设计变更、代码变更、测试用例变更时,需求跟踪矩阵是目前经过实践检验的进行变更波及范围影响分析的最有效的工具,如果不借助RTM,则发生上述变更时,往往会遗漏某些连锁变化2RTM也是验证需求是否得到了实现的有效工具,借助RTM,可以跟踪每个需求的状态:是否设计了,是否实现了,是否测试了2需求跟踪矩阵分为哪几类?1纵向跟踪矩阵,包括如下的3种需求之间的派生关系,客户需求到产品需求实现与验证关系需求到设计,需求到测试用例等需求的责任分配关系;需求由谁来实现横向跟踪矩阵2需求之间的接口关系3在实践中,如何把握该建立哪些RTM1在SEI的调查中达成的基本共识是:纵向跟踪是必须的,如果没有,则REQM SP
1.4无法通过横向跟踪如果不作,则是大部分实施2对于纵向跟踪矩阵必需的客户需求与产品需求的跟踪产品需求与测试用例的跟踪100%的接口需求需要建立客户需求-产品需求-设计-编码-测试用例的跟踪矩阵全局性需求要建立跟踪矩阵,包括:客户需求-产品需求-设计-编码-测试用例的跟踪矩阵核心需求要建立跟踪矩阵并非必需的性能需求可以不建立跟踪矩阵不影响系统架构的功能需求4需求跟踪矩阵由谁来建立?有多个角色参与建立RTM需求开发人员负责客户需求到产品需求的RTM建立,测试O用例的编写人员负责需求到测试用例的RTM建立,设计人员负责需求到设计的RTM的建立等等PPQA负责检查是否建立了RTM,是否所有的需求都被覆盖了5RTM是否纳入基线管理?RTM要纳入基线管理纳入基线后,每次变更都要申请,RTM的变更一般是和其他配置项的变更一起申请,很少单独申请变更RTM,除非RTM有错误6如何简化RTM的工作?由于在RTM中,需求可能有很多项,设计、测试用例、代码等都有多项,所以建立和维护RTM的工作量还是比较大、比较烦琐对于变化频繁的项目,更是如此在实践中,为了简化该RTM的建立与维护工作,有的企业仅仅通过需求与设计、代码、测试用例的编号来实现跟踪,如需求为:rl,r2,…等编号,而设计的编号为:rl-dl,rl-d2,….,测试用例的编号为:rl-t2等等需要注意的是需求与它们之间是多对多的关系,仅通过编号是无法实现这种关系的如果不借助DOORS之类的需求管理工具,一般只能通过EXCEL来维护RTM,工作量就是比较大要简化,就要平衡管理的投入与产出,平衡时,可以借鉴上面的问题3当然也可以考虑增大需求、设计、代码、测试用例的颗粒度大小,但是那样RTM的作用就打了折扣,还是一个平衡问题在CMM三级中要求软件团体必须具备需求跟踪的能力:〃在软件工作产品之间,维护一致性工作产品包括软件计划,过程描述,分配需求,软件需求,软件设计,代码,测试计划,以及测试过程〃需求跟踪矩阵并没有规定的实现办法,每个团体注重的方面不同,所创建的需求跟踪矩阵也不同,只要能够保证需求链的一致性和状态的跟踪就达到目的了。