QA新人求助！求解Requirement trace matrix（RTM)，一点都不懂需求跟踪矩阵啊
QA实习生求助！！！ 老大让我根据Requirement trace matrix概念（RTM)，制作一个模板.此方法用于Feature Complete前的测试进度跟踪管理。并制作个PPT给大家讲解一下
Requirement trace matrix 即需求跟踪矩阵，
自己看了部分资料大致只是初识皮毛资料太少了，
求助大家帮我想想方案喝着给我提供点文档什么的
在此谢谢了！！！！！ 来人啊真是找不到相关资料啊 在CMMI3级中提出了需求跟踪矩阵的使用。以前在一些项目中也用过，但似乎总是觉得不是那么有效，并且似乎难以填写。现在我们的做法是直接根据功能规格书来检查详细设计书的完整性，遗漏的情况也不是很多，因此对需求跟踪矩阵的必要性产生了怀疑。
在上一周（2005/12/01~2005/12/03）参加了CMMI引论培训，讲师是中国的CMMI第一人周伯生老师，他的项目经验和CMMI经验都毋庸置疑。在讨论中验证了我以前的一个看法，虽然有些事后诸葛亮，但是为了能够记住，现记录在下面。
矩阵应该是多个，而不该是一个。现在公司的需求跟踪矩阵从需求收集到测试统统都是一个矩阵，似乎想一个矩阵解决需求跟踪的所有问题。这样导致了使用的复杂性，矩阵看起来也乱糟糟的，总之，难用！想起当时做SimulatorEL的项目时，也是这个原因让江尧将这个矩阵变成了多个，确实是被逼的。但是因为据说这是当时的咨询师提出的，有一定权威性，所以我一直都在迷惑，需求跟踪矩阵是一个合理还是多个合理。
另外一个是用需求跟踪矩阵的问题是，需求点的粒度难以掌握。如果粒度太粗，则会遗漏一些具体的功能要求；如果太细，则会变成功能规格书的一个拷贝。所以到现在为止，项目组的做法都是直接根据功能规格书来评审详细设计书是否遗漏。
但是今天，在和日本客户的交流中，又碰到了需求跟踪遗漏的问题，当然使我们的软件中出现了BUG。和他来来回回的交流中，又让我感觉到了需求跟踪矩阵的重要性。因为这个遗漏就是在从功能规格书到详细设计书的遗漏。本来我觉得只要加强评审即可，但是日本客户追根究底，要求说明如何加强评审（日本人的这种追根究底的精神确实值得中国人学习，中国人也许就是缺乏这种精神，领先了五千多年后被西方赶上，并被狠狠地甩在了后面。这种追根究底的精神是研究现代科学所必需的！）。这让我想到了需求跟踪矩阵。我们还是有不算少的跟踪遗漏，并且已经找不到办法再次提高了，也许我们又到了再次试一试需求跟踪矩阵的时候了。
也许解决方案应该是，在详细设计之前，根据功能规格书，做成功能点的需求跟踪矩阵，然后测试组开发组同时对需求跟踪矩阵（主要是完整性）进行评审。然后，根据需求跟踪矩阵做成详细设计书。最后，使用需求跟踪矩阵检查详细设计的完整性。我想这样也许会使我们的需求跟踪遗漏减少，值得一试。
那么，需求跟踪矩阵的粒度如何掌握呢？我想，掌握需求跟踪矩阵的粒度的原则应该是，在不遗漏任何粗的和细的功能点的情况下，尽可能简单。
我想我们到了可以试一试需求跟踪矩阵的时候了。这应该值得高兴，因为这也许就是成长 在CMMI3级中提出了需求跟踪矩阵的使用。以前在一些项目中也用过，但似乎总是觉得不是那么有效，并且似乎难以填写。现在我们的做法是直接根据功能规格书来检查详细设计书的完整性，遗漏的情况也不是很多，因此对需求跟踪矩阵的必要性产生了怀疑。
在上一周（2005/12/01~2005/12/03）参加了CMMI引论培训，讲师是中国的CMMI第一人周伯生老师，他的项目经验和CMMI经验都毋庸置疑。在讨论中验证了我以前的一个看法，虽然有些事后诸葛亮，但是为了能够记住，现记录在下面。
矩阵应该是多个，而不该是一个。现在公司的需求跟踪矩阵从需求收集到测试统统都是一个矩阵，似乎想一个矩阵解决需求跟踪的所有问题。这样导致了使用的复杂性，矩阵看起来也乱糟糟的，总之，难用！想起当时做SimulatorEL的项目时，也是这个原因让江尧将这个矩阵变成了多个，确实是被逼的。但是因为据说这是当时的咨询师提出的，有一定权威性，所以我一直都在迷惑，需求跟踪矩阵是一个合理还是多个合理。
另外一个是用需求跟踪矩阵的问题是，需求点的粒度难以掌握。如果粒度太粗，则会遗漏一些具体的功能要求；如果太细，则会变成功能规格书的一个拷贝。所以到现在为止，项目组的做法都是直接根据功能规格书来评审详细设计书是否遗漏。
但是今天，在和日本客户的交流中，又碰到了需求跟踪遗漏的问题，当然使我们的软件中出现了BUG。和他来来回回的交流中，又让我感觉到了需求跟踪矩阵的重要性。因为这个遗漏就是在从功能规格书到详细设计书的遗漏。本来我觉得只要加强评审即可，但是日本客户追根究底，要求说明如何加强评审（日本人的这种追根究底的精神确实值得中国人学习，中国人也许就是缺乏这种精神，领先了五千多年后被西方赶上，并被狠狠地甩在了后面。这种追根究底的精神是研究现代科学所必需的！）。这让我想到了需求跟踪矩阵。我们还是有不算少的跟踪遗漏，并且已经找不到办法再次提高了，也许我们又到了再次试一试需求跟踪矩阵的时候了。
也许解决方案应该是，在详细设计之前，根据功能规格书，做成功能点的需求跟踪矩阵，然后测试组开发组同时对需求跟踪矩阵（主要是完整性）进行评审。然后，根据需求跟踪矩阵做成详细设计书。最后，使用需求跟踪矩阵检查详细设计的完整性。我想这样也许会使我们的需求跟踪遗漏减少，值得一试。
那么，需求跟踪矩阵的粒度如何掌握呢？我想，掌握需求跟踪矩阵的粒度的原则应该是，在不遗漏任何粗的和细的功能点的情况下，尽可能简单。
我想我们到了可以试一试需求跟踪矩阵的时候了。这应该值得高兴，因为这也许就是成长 也许解决方案应该是，在详细设计之前，根据功能规格书，做成功能点的需求跟踪矩阵，然后测试组开发组同时对需求跟踪矩阵（主要是完整性）进行评审。然后，根据需求跟踪矩阵做成详细设计书。最后，使用需求跟踪矩阵检查详细设计的完整性。我想这样也许会使我们的需求跟踪遗漏减少，值得一试。 需求跟踪矩阵是一个过程，起点在需求阶段，结束在测试阶段。
它起初是需求分析的工作产品之一，然后在概设、详设、编码、测试的每个阶段都要去跟踪，看是否全面覆盖、如果有变更要更新本矩阵。概设、详设、编码由编码人员进行，测试阶段由测试人员进行，qa检查过程中的每个阶段执行情况。 需求跟踪矩阵是一个过程，起点在需求阶段，结束在测试阶段。
它起初是需求分析的工作产品之一，然后在概设、详设、编码、测试的每个阶段都要去跟踪，看是否全面覆盖、如果有变更要更新本矩阵。概设、详设、编码由编码人员进行，测试阶段由测试人员进行，qa检查过程中的每个阶段执行情况。 1 需求跟踪矩阵（RTM）有什么作用？
（1） 在需求变更、设计变更、代码变更、测试用例变更时，需求跟踪矩阵是目前经过实践检验的进行变更波及范围影响分析的最有效的工具，如果不借助RTM，则发生上述变更时，往往会遗漏某些连锁变化。
（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的变更一般是和其他配置项的变更一起申请，很少单独申请变更RTM，除非RTM有错误。
6 如何简化RTM的工作？
由于在RTM中，需求可能有很多项，设计、测试用例、代码等都有多项，所以建立和维护RTM的工作量还是比较大、比较烦琐。对于变化频繁的项目，更是如此。在实践中，为了简化该RTM的建立与维护工作，有的企业仅仅通过需求与设计、代码、测试用例的编号来实现跟踪，如需求为：r1,r2,……等编号，而设计的编号为：r1-d1,r1-d2,…….,测试用例的编号为：r1-t1,r1-t2等等。需要注意的是需求与它们之间是多对多的关系，仅通过编号是无法实现这种关系的。 如果不借助DOORS之类的需求管理工具，一般只能通过EXCEL来维护RTM，工作量就是比较大。要简化，就要平衡管理的投入与产出，平衡时，可以借鉴上面的问题3。
当然也可以考虑增大需求、设计、代码、测试用例的颗粒度大小，但是那样RTM的作用就打了折扣，还是一个平衡问题。
另需求跟踪矩阵与需求双向跟踪就不在发了 希望对相关需要的人有帮助求楼主加分啊 坑爹啊找了好几天 1 需求跟踪矩阵（RTM）有什么作用？
（1） 在需求变更、设计变更、代码变更、测试用例变更时，需求跟踪矩阵是目前经过实践检验的进行变更波及范围影响分析的最有效的工具，如果不借助RTM，则发生上述变更时，往往会遗漏某些连锁变化。
（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的变更一般是和其他配置项的变更一起申请，很少单独申请变更RTM，除非RTM有错误。
6 如何简化RTM的工作？
由于在RTM中，需求可能有很多项，设计、测试用例、代码等都有多项，所以建立和维护RTM的工作量还是比较大、比较烦琐。对于变化频繁的项目，更是如此。在实践中，为了简化该RTM的建立与维护工作，有的企业仅仅通过需求与设计、代码、测试用例的编号来实现跟踪，如需求为：r1,r2,……等编号，而设计的编号为：r1-d1,r1-d2,…….,测试用例的编号为：r1-t1,r1-t2等等。需要注意的是需求与它们之间是多对多的关系，仅通过编号是无法实现这种关系的。 如果不借助DOORS之类的需求管理工具，一般只能通过EXCEL来维护RTM，工作量就是比较大。要简化，就要平衡管理的投入与产出，平衡时，可以借鉴上面的问题3。
当然也可以考虑增大需求、设计、代码、测试用例的颗粒度大小，但是那样RTM的作用就打了折扣，还是一个平衡问题。
另需求跟踪矩阵与需求双向跟踪就不在发了 希望对相关需要的人有帮助求楼主加分啊 坑爹啊找了好几天 楼主你在自问自答么？？我汗。。。 新人，学习！ study 有没有个具体的例子啊:) :handshake :dizzy: 从AR跟踪到SRS到HLD、LLD到CODE 到SDVC的跟踪。
可以正向跟踪和反向跟踪
另外在CR中要注意及时更新RTM
页:
[1]
