需求追踪简述
需求追踪需求追踪是指追踪一个需求运用期限的全过程，需求追踪包含编制每个需求同系统元素之间的联系文档，这些元素包含其余类型的需求，体系结构，其余设计部件，源代码模块，试探，帮助文件等。需求追踪为我们给予了由需求到产品达到整个过程规模的清晰查阅的能力。需求追踪的目的是建立与维护“需求－设计－编程－试探”之间的统一性，保证所有的工作成果符合用户需求。
需求追踪的方式
需求追踪有两种方式：
（1）正向追踪。检查《产品需求规格表明书》中的每个需求能否都能在后继工作成果中寻到对应点。
（2）逆向追踪。检查设计文档、代码、试探用例等工作成果能否都能在《产品需求规格表明书》中寻到出处。
正向追踪和逆向追踪合称为“双向追踪”。不论采取何种追踪方式，都要建立与维护需求追踪矩阵（即表格）。需求追踪矩阵保存了需求与后继工作成果的对应关系。
需求追踪的内容
追踪能力（联系）链（traceability link）使你能追踪一个需求运用期限的全过程，即从需求源到达到的前后生存期。追踪能力是优秀需求规格表明书的一个特质。为了达到可追踪能力，务必统一地标识出每一个需求，以便能清晰地执行查阅。
图1：四类需求可追踪能力
图1表明了四类需求追踪能力链。客户需求可向前追溯到需求，如此就能区分出开发过程中或开发终结后受于需求变更承受影响的需求。这也保证了需求规格表明书包含所有客户需求。同样，可以从需求回溯相应的客户需求，确 认每个软件需求的源头。假使用运用实例的形式 来描述客户需求，图的上半部分就是运用实 例和功能性需求之间的追踪情形。图的下半 部分表示：受于开发过程中系统需求转变为软件 需求、设计、编撰等，所以通过定义单个需求和 特定的产品元素之间的（联系）链可从需求向前 追溯。该种联系链使你知道每个需求对应的产品 部件，进而保证产品部件满足每个需求。第四类 联系链是从产品部件回溯到需求，使你知道每个 部件存在的原因。绝大部分项目不包含与用户需 求直接有关的代码，但对于开发者却要知道为什 么写这一行代码。假使不能把设计元素、代码段 或试探回溯到一个需求，你或许有一个“画蛇添 足的程序”。但是，若这些孤立的元素显示了一 个正值的功能，则表明需求规格表明书漏掉了一项需求。
追踪能力联系链记录了单个需求之间的父层、互连、依靠的关系。当某个需求变更（被删除或修改）后，该种信息能够保证正确的变更传播，并将相应的任务做出正确的调整。下图2表明了很多能在项目中定义的直接追踪能力联系链。一个项目不必拥有所有种类的追踪能力联系链，要依据具体的情形调整。
需求追踪目的
在某种程度上，需求追踪给予了一个显示与合同或表明统一的方法。更更深一步，需求追踪可以改观产品质量，减弱维护成本，而且很容易达到重用。
图2：一部分或许的需求追踪能力联系链
需求追踪是个要求手工操作且劳动力度很大的任务，要求组织供应支持。伴随系统开发的执行和维护的实施，要维持关联链信息与事实统一。追踪能力信息一旦过时，或许再也不会重建它了。受于这些原因，应当正确运用需求追踪能力。
下面是在项目中运用需求追踪能力的一部分好处： 审核（certification） 追踪能力信息可以帮助审核保证所有需求被应用。 变更影响分析追踪能力信息在增、删、改需求时可以保证不忽视每个承受影响的系统元素。 维护牢靠的追踪能力信息致使维护时能正确、完整地实行变更，进而提升生产率。若是一下子不能为整个系统建立追踪能力信息，一次可以只建立一部分，再渐渐增长。从系统的一部分着手建立，先列表需求，然后记录追踪能力链，再渐渐拓展。 项目追踪在开发中，认真记录追踪能力报告，就可以得到计划功能目前达到状态的记录。仍未显现的联系链代表着没有相应的产品部件。 再设计（从新建造） 你可以列出传统系统中将要替换的功能，记录它们在新系统的需求和软件组件中的位置。通过定义追踪能力信息链供应一种方法收集从一个现成系统的反向工程中所学到的方法。 重复利用追踪信息可以帮助你在新系统中对相同的功能利用旧系统有关资源。比如：功能设计、有关需求、代码、试探等。 减小风险使部件互连关系文档化可降低受于一位核心成员离开项目导致的风险。 试探试探模块、需求、代码段之间的联系链可以在试探出错时表示最或许有困难的代码段。
以上所述很多是长期利益，降低了整个产品生存期费用，但同期要注意到受于积攒和管理追踪能力信息增长了开发成本。这个困难应当如此来说，把增长的费用当作一项投资，这笔投资可以使你公布让人满意同期更容易维护的产品。即使很难计算，但这笔投资在每一次修改、扩展或代替产品时全将有所体现。假使在开发工程中收集信息，定义追踪能力联系链一点也不难，但要在整个系统完成后再实行代价的确很大。
CMMI要求具备需求追踪能力。软件产品工程活动的核心过程域相关于它的陈述，“在软件工作产品之间，维护统一性。工作产品包含软件计划，过程描述，分配需求，软件需求，软件设计，代码，试探计划，以及试探过程。”需求追踪过程中还定义了一部分有关一个组织如何处理需求追踪能力的期望。
需求追踪能力矩阵
表明需求和别的系统元素之间的联系链的最广泛方式是运用需求追踪能力矩阵。下表展示了该种矩阵，这是一个“化学制品追踪系统”实例的追踪能力矩阵的一部分。这个表表明了每个功能性需求向后连接一个特定的运用实例，向前连接一个或多个设计、代码和试探元素。设计元素可以是模型中的对象，比如报告流图、关系报告模型中的表单、或对象类。代码参考可以是类中的方法，源代码文件名、过程或函数。加之许多的列项就可以拓展到与其它工作产品的关联，比如在线帮助文档。包含越多的细节就越花时间，但同期很容易得到有关联的软件元素，在做变更影响分析和维护时就可以节省时间。
追踪能力联系链可以定义各种系统元素类型间的一对一，一对多，多对多关系。表1中允许在一个表单元中填入几个元素来达到这些特质。这里是一部分或许的分类：
一对一一个代码模块应用一个设计元素。 一对多多个试探实例验证一个功能需求。 多对多每个运用实例致使多个功能性需求，而一部分功能性需求常拥有几个运用实例。
手工创建需求追踪能力矩阵是一个应当养成的习惯，即便对小项目也很有效。一旦确立运用实例基准，就准备在矩阵中添加每个运用实例演化成的功能性需求。伴随软件设计、构造、试探开发的进度持续更新矩阵。比如，在达到某一功能需求后，你可以更新它在矩阵中的设计和代码单元，将需求状态设置为“已完成”。表明追踪能力信息的其他方法是通过矩阵的集合，矩阵定义了系统元素对间的联系链。比如：
一类需求与另一类需求之间。 同类中不同的需求之间。 一类需求与试探实例之间。
可以运用这些矩阵定义需求间或许的不同联系，比如：指定/被指定、依靠于、衍生为以及制约/被制约。
下表2中称明了两维的追踪能力矩阵。矩阵中绝大部分的单元是空的。每个单元指示相对应行与列之间的联系，可以运用不同的符号清晰表明“追溯到”和“从.. 回溯”或其余联系。表2中运用一个箭头表明一个功能性需求是从一个运用实例追溯来的。这些矩阵相对于表16-6中的单追踪能力表更容易被机器自动支持。
追踪能力联系链无论谁有合适的信息都可以定义。下表3定义了一部分典型的知识源，即有关不同种类源和目标对象间的联系链。定义了可以为工程项目供应每种追踪能力信息的角色和个人。
需求追踪能力工具
受于联系链因为开发构成员的头脑中，所以需求追踪能力不能完全自动化。但是，一旦已确定联系链，特定工具就能帮你管理重大的追踪能力信息。可以运用电子报告表来维护几百个需求的矩阵，但更大的系统需要更“鲁棒”的处理办法。
具有强大需求追踪能力的商业需求管理工具均运用如表16 -7的追踪能力矩阵。可以在工具的报告库中存储需求和其余信息，定义不同对象间的联系链，甚至包含同类需求的对等联系链。有一部分工具需要区分“追溯到（追踪进）”与“从..回溯（追踪出）”关系，自动定义相对的联系链。这就是说，假使你表示需求R追溯到试探实例T，工具会自动定义相对的联系“ T从R回溯”。仍有一部分工具可以在联系链某端变更后将另一端标为“可疑”。可以让你检查保证知道变更的后续效果。
这些工具允许定义“跨项目”或“跨子系统”的联系链。一个有20个子系统的大项目，某些高层产品需求建立在多个子系统之上。有些情形下，分配给一个子系统的需求，事实上是由其他子系统供应的服务完成的。如此的项目采取商业需求管理工具可以成功地追踪这些复杂的追踪能力关系。
需求追踪能力过程
当你应用需求追踪能力来管理工程时，可以考虑下列步骤：
决定定义哪几种联系链，可以参见图2来执行。 选择运用的追踪能力矩阵的种类，是表1依旧表2。 确定对产品哪部分维护追踪能力信息。由核心的核心功能、高风险部分恐会来维护量大的部分开始做起。 通过修订过程和核对表来警示开发者在需求完成或变更时更新联系链。 策划标记性的规范，用以统一标识所有的系统元素，高达可以相互联系的目的。若必要，作文字记录，如此就可以分析系统文件，便于重建或更新追踪能力矩阵。 确定供应每类联系链信息的个人。 培训项目构成员，使其接受需求追踪能力的概念和了解重要性、这次活动的目的、追踪能力报告存储位置、定义联系链的技术—比如，运用需求管理工具的特点。保证与会人士明白担负的责任。 一旦有人完成某项任务就要即将更新追踪能力报告，即要立刻通知有关人士更新需求链上的联系链。 在开发过程中周期性地更新报告，以使追踪信息与事实吻合。若是发现追踪能力报告没完成或不正确那就表明没有高达效果。需求追踪能力的可行性
对有很多子系统的重大产品执行追踪能力管理是一项重大的工程，但这很必要。并没有是所有的公司全将由于软件困难而产生严重的结果，但是应当严肃地对待需求追踪，尤其对涉及你业务核心的信息系统。考虑了应用技术的成本和不运用的风险后，才可决定能否运用任何改进的需求工程实践。伴随软件的成长，要把时间投向回报丰厚的地方。
