需求跟踪矩阵(需求跟踪矩阵实例)

什么是需求跟踪矩阵RTM

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

需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵， 可以把每个需求与业务目标或项目目标联系起来， 有助于确保每个需求都具有商业价值。

需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。最后， 需求跟踪矩阵还为管理产品范围变更提供了框架。

扩展资料

需求跟踪矩阵的作用主要包括：

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

2、需求跟踪矩阵也是验证需求是否得到实现的有效工具。可以跟踪每个需求的状态，是否设计了，是否实现了，是否测试了；

3、如果建立了需求跟踪矩阵，我们对照需求跟踪矩阵进行测试用例的评审，则会更加方便。同时，作者本人很容易在评审之前就发现未被测试用例覆盖的需求。

参考资料来源：百度百科-需求跟踪矩阵

需求跟踪矩阵更新的时机

需求跟踪矩阵更新的时机：在相关阶段评审结束后更新。

使用需求跟踪矩阵跟踪需求需要遵循的检查和步骤：

1、浏览矩阵中的需求数目和需求文档中的需求，确保矩阵中列出了所有的需求，没有遗漏。

2、为确保在矩阵中列出的所有程序在最终的软件中都是必要的，并且没有冗余的代码，必须在矩阵中指出每个程序、类和其他单元。

3、通过确保功能需求没有空白列来检查需求的实现。

4、对每个性能需求，都应该设计一些测试用例。

5、集成和系统测试用例可以和矩阵一起进行交叉检查，以此来保证需求的所有条件都包含在系统测试用例中。

需求跟踪矩阵模板：

需求跟踪矩阵的分类

（1） 纵向跟踪矩阵，包括如下的3种：
需求之间的派生关系，客户需求到产品需求
实现与验证关系：需求到设计，需求到测试用例等
需求的责任分配关系；需求由谁来实现
（2） 横向跟踪矩阵：
需求之间的接口关系
在实践中，如何把握该建立哪些RTM
（1） 在SEI的调查中达成的基本共识是：纵向跟踪是必须的，如果没有，则 REQM SP1.4无法通过。横向跟踪如果不作，则是大部分实施。
（2） 对于纵向跟踪矩阵：
必需的：
客户需求与产品需求的跟踪
产品需求与测试用例的跟踪 100%的接口需求需要建立客户需求-产品需求-设计-编码-测试用例的跟踪矩阵
全局性需求要建立跟踪矩阵,包括：客户需求-产品需求-设计-编码-测试用例的跟踪矩阵
核心需求要建立跟踪矩阵
并非必需的：
性能需求可以不建立跟踪矩阵
不影响系统架构的功能需求

需求跟踪矩阵的如何简化

由于在需求跟踪矩阵中，需求可能有很多项，设计、测试用例、代码等都有多项，所以建立和维护RTM的工作量还是比较大、比较烦琐。对于变化频繁的项目，更是如此。 在实践中，为了简化该RTM的建立与维护工作，有的企业仅仅通过需求与设计、代码、测试用例的编号来实现跟踪，如需求为：r1,r2,……等编号，而设计 的编号为：r1-d1,r1-d2,…….,测试用例的编号为：r1-t1,r1-t2等等。需要注意的是需求与它们之间是多对多的关系，仅通过编号是无 法实现这种关系的。 如果不借助DOORS之类的需求管理工具，一般只能通过EXCEL来维护RTM，工作量就是比较大。要简化，就要平衡管理的投入与产出，平衡时，可以借鉴 上面的问题3。
当然也可以考虑增大需求、设计、代码、测试用例的颗粒度大小，但是那样RTM的作用就打了折扣，还是一个平衡问题。
在CMM三级中要求软件团体必须具备需求跟踪的能力：“在软件工作产品之间，维护一致性。工作产品包括软件计划，过程描述，分配需求，软件需求，软件设计，代码，测试计划，以及测试过程。”
需求跟踪矩阵并没有规定的实现办法，每个团体注重的方面不同，所创建的需求跟踪矩阵也不同，只要能够保证需求链的一致性和状态的跟踪就达到目的了。

如何制定一份有效需求跟踪矩阵表

以下是我目前准备重新制定需求跟踪矩阵设计的时候分析:
说明：需求阶段，我们的输出产物为：业务需求说明书、用户需求说明书、功能设计说明书
1、相关涉众：项目经理、需求分析师、设计师、软件工程师、测试工程师、客户
2、用例统计：需求总数、模块总数、变更总数、用例总数
3、需求变更类型：新增、遗漏、修改
4、需求跟踪矩阵表中的设计元素：（以对应角色关注点列出，有部分共同关注点没有单独列出）
项目经理：返工量评估、评估变更风险、质量影响、纠正措施、跟踪结果、跟踪人
需求分析师：需求用例ID、用户需求说明书、需求稳定性、需求优先级、变更相关涉众（一般指客户）、关联模块、需求维护人（具体需求分析师，针对变更）、需求 变更类型、验收标准
设计师：功能设计ID、功能设计说明书、技术难度（评估）、设计维护人
开发工程师：工作量反馈、修改人、单元测试用例ID（链接）
测试工程师：测试用例ID（链接）、测试用例说明书、用例维护人
以上字段是我打算设计使用的字段，请大家帮忙指点，看是否有遗漏或不妥之处。
此次交流期望：想得到一份比较简单但执行效率高的需求跟踪矩阵。