全国咨询热线：136-9172-9932
为什么需要有一个需求跟踪矩阵呢？其实需求跟踪矩阵是在 CMM3 中提出 来的方法，之所以需要对需求进行跟踪，是因为测试是一个验证客户需求是否被正确实现的一个过 程，开发是实现需求的过程，那么如何确定开发的内容是否满足用户需求呢？这就必须对需求的每 个实现的阶段进行验证，只有每个阶段验证后没有问题，才能保证每个阶段的工作是对的，这样才能确保最后的系统是满足客户需求的。我们不可能脱离过程直接来衡量结果，这样结果将无法控制， 但我们以前的工作中并没有一个对需求进行跟踪的一个全景图，所以需求一个记录需求使用期限全 过程的表格来跟踪需求，这就是需求跟踪矩阵被提出的原因。
需求跟踪是指跟踪一个需求使用期限的全过程，需求跟踪包括编制每个需求同系统元素之间的 联系文档，这些元素包括其他类型的需求、体系结构、其他设计部件、源代码模块、测试、帮助文 件等。需求跟踪为我们提供了由需求到产品实现整个过程范围的明确查阅的能力。
需求跟踪矩阵的目的是： （1）建立与维护需求、设计、编程、测试之间的一致性，确保所有的工作成果符合用户需求。 （2）作为各个环节的负责人沟通的桥梁。 （3）作为一根线条将需求与最终的实现串联在一起。 （4）作为一种检验的手段，确认需求是否被实现，确认需求是否被覆盖。 （5）在某种程度上，需求跟踪提供了一个表明与合同或说明一致的方法。 需求跟踪的方式通常有以下两种： （1）正向跟踪：检查《产品需求规格说明书》中的每个需求是否都能在后续工作成果中找到 对应点。（2）逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明 书》中找到出处。 跟踪能力（联系）链（Traceability Link）使你能跟踪一个需求使用期限的全过程，即从需求源 到实现的前后生存期。跟踪能力是优秀需求规格说明书的一个特征。为了实现可跟踪能力，必须统 一地标识出每一个需求，以便能明确地进行查阅。
需求分为客户需求和需求两类，客户需求是指客户的原始需求，而这里的需求是我们通常所说 的开发的原始需求。需求是通过客户需求追溯过来的，这样的好处是可以区分出开发过程中或开发 结束后由于客户需求变更带来的对需求的影响，同时也可以确定客户的需求都被实现了，即我们通 常说的需求都被满足了。从需求回溯到客户需求可以确认每个软件需求都有一个来源的源头，不致 于是无中生有的，如果用使用实例的形式来描述客户需求，图的上半部分就是使用实例和功能性需 求之间的跟踪情况。图的下半部分指出，由于开发过程中系统需求转变为软件需求、设计、编写等， 所以通过定义单个需求和特定的产品元素之间的（联系）链，可从需求向前追溯。这种联系链让我 们知道每个需求对应的产品部件，从而确保产品部件满足每个需求。第四类联系链是从产品部件回 溯到需求，使你知道每个部件存在的原因。 绝大多数项目不包括与用户需求直接相关的代码，但对于开发者却要知道为什么写这一行代 码。如果不能把设计元素、代码段或测试回溯到一个需求，则可能有一个画蛇添足的程序。然而， 若这些孤立的元素表明了一个正当的功能，则说明需求规格说明书漏掉了一项需求。 需求跟踪能力图记录了单个需求之间的父层、互连、依赖的关系，在这个过程中， 如果某个需求发生了变更，那么这个变更的信息将会延续下去，这样后面的研发工作就必须做出正 确的调整。
需求跟踪是个要求手工操作且工作量很大的任务，需要组织提供支持，随着系统开发的进行和 维护的执行，要保持关联链信息一致，跟踪能力信息一旦过时，可能再也不会重建它，所以平时需 求正确地使用需求跟踪能力。 在工作中，需求可能会出现变更，甚至有的公司需求变更得很频繁，每次变更都会影响整个跟 踪链的信息，这些信息可能出现增、删、改。维护可靠的跟踪能力信息，使得维护时能正确、完整 地实施变更，从而提高生产率。 在开发中，认真记录跟踪能力数据，就可以获得计划功能当前实现状态的记录。还未出现的联 系链意味着没有相应的产品部件。再设计（重新建造）时，可以列出传统系统中将要替换的功能， 记录它们在新系统的需求和软件组件中的位置。通过定义跟踪能力信息链提供一种方法收集从一个 现成系统的反向工程中所学到的方法。重复利用跟踪信息可以帮助我们在新系统中对相同的功能利 用旧系统相关资源，如功能设计、相关需求、代码、测试等。减小风险使部件互连关系文档化，可 减少由于一名关键成员离开而给项目带来的风险。测试测试模块、需求、代码段之间的联系链，可 以在测试出错时指出最可能有问题的代码段。 CMMI要求具备需求跟踪能力。软件产品工程活动的关键过程域关于它的陈述，“在软件工作 产品之间，维护一致性。工作产品包括软件计划、过程描述、分配需求、软件需求、软件设计、代 码、测试计划、以及测试过程。”
上表说明了每个功能性需求向后连接一个特定的使用实例，向前连接一个或多个设计和测试元 素。通过需求跟踪矩阵可以清楚地看到每个需求被验证的情况，因为测试是验证需求是否被正确实 现的，所以我们这里并没有列举同需求被实现的情况，我们是站在测试的角度，并没有对需求实现 的过程进行跟踪。这个表记录了测试过程中我们对每个需求进行验证的情况，这样可以确定测试的 完整性，当然如果需求发生变更，我们对相应的测试项也需要进行修改。
