需求跟踪概述
需求跟踪需求跟踪是指跟踪一个需求使用期限的全过程，需求跟踪包括编制每个需求同系统元素之间的联系文档，这些元素包括其他类型的需求，体系结构，其他设计部件，源代码模块，测试，帮助文件等。需求跟踪为我们提供了由需求到产品实现整个过程范围的明确查阅的能力。需求跟踪的目的是建立与维护“需求－设计－编程－测试”之间的一致性，确保所有的工作成果符合用户需求。
需求跟踪的方式
需求跟踪有两种方式：
（1）正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。
（2）逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。
正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后继工作成果的对应关系。
需求跟踪的内容
跟踪能力（联系）链（traceability link）使你能跟踪一个需求使用期限的全过程，即从需求源到实现的前后生存期。跟踪能力是优秀需求规格说明书的一个特征。为了实现可跟踪能力，必须统一地标识出每一个需求，以便能明确地进行查阅。
图 图1：四类需求可跟踪能力
图1说明了四类需求跟踪能力链。客户需求可向前追溯到需求，这样就能区分出开发过程中或开发结束后由于需求变更受到影响的需求。这也确保了需求规格说明书包括所有客户需求。同样，可以从需求回溯相应的客户需求，确 认每个软件需求的源头。如果用使用实例的形式 来描述客户需求，图的上半部分就是使用实 例和功能性需求之间的跟踪情况。图的下半 部分指出：由于开发过程中系统需求转变为软件 需求、设计、编写等，所以通过定义单个需求和 特定的产品元素之间的（联系）链可从需求向前 追溯。这种联系链使你知道每个需求对应的产品 部件，从而确保产品部件满足每个需求。第四类 联系链是从产品部件回溯到需求，使你知道每个 部件存在的原因。绝大多数项目不包括与用户需 求直接相关的代码，但对于开发者却要知道为什 么写这一行代码。如果不能把设计元素、代码段 或测试回溯到一个需求，你可能有一个“画蛇添 足的程序”。然而，若这些孤立的元素表明了一 个正当的功能，则说明需求规格说明书漏掉了一项需求。
跟踪能力联系链记录了单个需求之间的父层、互连、依赖的关系。当某个需求变更（被删除或修改）后，这种信息能够确保正确的变更传播，并将相应的任务作出正确的调整。下图2说明了许多能在项目中定义的直接跟踪能力联系链。一个项目不必拥有所有种类的跟踪能力联系链，要根据具体的情况调整。
需求跟踪能力工具
由于联系链源于开发组成员的头脑中，所以需求跟踪能力不能完全自动化。然而，一旦已确定联系链，特定工具就能帮你管理巨大的跟踪能力信息。可以使用电子数据表来维护几百个需求的矩阵，但更大的系统需要更“鲁棒”的解决办法。
具有强大需求跟踪能力的商业需求管理工具均使用如表16 -7的跟踪能力矩阵。可以在工具的数据库中存储需求和其他信息，定义不同对象间的联系链，甚至包括同类需求的对等联系链。有一些工具需要区分“追溯到（跟踪进）”与“从..回溯（跟踪出）”关系，自动定义相对的联系链。这就是说，如果你指出需求R追溯到测试实例T，工具会自动定义相对的联系“ T从R回溯”。还有一些工具可以在联系链某端变更后将另一端标为“可疑”。可以让你检查确保知道变更的后续效果。
这些工具允许定义“跨项目”或“跨子系统”的联系链。一个有20个子系统的大项目，某些高层产品需求建立在多个子系统之上。有些情况下，分配给一个子系统的需求，实际上是由另一个子系统提供的服务完成的。这样的项目采用商业需求管理工具可以成功地跟踪这些复杂的跟踪能力关系。
需求跟踪能力过程
当你应用需求跟踪能力来管理工程时，可以考虑下列步骤：
决定定义哪几种联系链，可以参见图2来进行。
选择使用的跟踪能力矩阵的种类，是表1还是表2。
确定对产品哪部分维护跟踪能力信息。由关键的核心功能、高风险部分或将来维护量大的部分开始做起。
通过修订过程和核对表来提醒开发者在需求完成或变更时更新联系链。
制定标记性的规范，用以统一标识所有的系统元素，达到可以相互联系的目的。若必要，作文字记录，这样就可以分析系统文件，便于重建或更新跟踪能力矩阵。
确定提供每类联系链信息的个人。
培训项目组成员，使其接受需求跟踪能力的概念和了解重要性、这次活动的目的、跟踪能力数据存储位置、定义联系链的技术—例如，使用需求管理工具的特点。确保与会人员明白担负的责任。
一旦有人完成某项任务就要马上更新跟踪能力数据，即要立刻通知相关人员更新需求链上的联系链。
在开发过程中周期性地更新数据，以使跟踪信息与实际相符。要是发现跟踪能力数据没完成或不正确那就说明没有达到效果。
需求跟踪能力的可行性
对有很多子系统的巨大产品进行跟踪能力管理是一项巨大的工程，但这很必要。并不是所有的公司都会因为软件问题而造成严重的结果，然而应该严肃地对待需求跟踪，尤其对涉及你业务核心的信息系统。考虑了应用技术的成本和不使用的风险后，才能决定是否使用任何改进的需求工程实践。随着软件的发展，要把时间投向回报丰厚的地方。