接前一篇文章：软考 系统分析师系列知识点之需求管理（2）
所属章节：
第11章. 软件需求工程
第8节. 需求管理
11.8.4 需求跟踪
根据IEEE的定义，可跟踪性包含两个层面的含义：一个是开发过程的两个或多个产品之间能够建立关系的程度，尤其是那些具有前后关系或主从关系的产品。例如，某个给定构件的需求和设计的匹配程度；另一个是软件开发产品中每个元素能够建立其存在理由的程度。例如，DFD中的每个元素定位它所满足需求的程度。
可跟踪性是软件需求的一个重要特征，需求跟踪是将单个需求和其它系统元素之间的依赖关系和逻辑联系建立跟踪。这些元素包括包括各种类型的需求、业务规则、系统架构和构件、源代码、测试用例以及帮助文件等。CMMI也要求具备需求跟踪能力，其对需求跟踪的定义是“在软件工作产品之间维护一致性”，其中工作产品包括软件计划、过程描述、分配需求、软件需求、软件设计、程序代码、测试计划和测试过程。CMMI中的“分配需求”是指项目启动前分配给该项目的需求，其实也就是用户的原始需求。
1. 需求跟踪的内容
根据国家标准GB/T8567-2006，SRS中的每个软件配置项的需求到其涉及的系统（或子系统）需求都要有双向可追踪性。所谓双向跟踪，包括正向跟踪和反向跟踪。正向跟踪是指检查SRS中的每个需求是否能在后续工作成果中找到对应点；反向跟踪也成为逆向跟踪，是指检查设计文档、代码、测试用例等工作成果是否都能在SRS中找到出处。需求跟踪涉及5种类型，如下图所示：
上图中的箭头表示需求跟踪能力联系链，它能跟踪需求使用的整个周期，即从需求建议到交付的全过程。
上图的左半部分表明，从用户原始需求可向前追溯到软件需求，这样就能区分出开发过程中或开发结束后由于变更而受到影响的需求，也确保了SRS中包括了所有用户需求；同样，可以从软件需求回溯到相应的用户原始需求，确认每个软件需求的出处。如果以用例的形式来描述用户需求，左半部分就是用例和功能性需求之间的跟踪情况。
上图的右半部分表明，由于在开发过程中，软件需求转变为设计和编码等实现元素，因此通过定义单个软件需求和特定的产品元素之间的联系链，可以从软件需求追溯到产品元素。这种联系链使开发人员知道每个需求对应的产品元素，从而确保产品元素满足每个需求。第四类联系链是从产品元素回溯到软件需求，使开发人员知道每个产品元素存在的原因。绝大多数项目不包括与用户需求直接相关的代码，但开发人员应该知道为什么要写这一行代码。如果不能把设计元素、代码段或测试用例回溯到一个软件需求，就可能出现画蛇添足的现象。当然，如果某个孤立的产品元素表明了一个正当的功能，则说明SRS漏掉了一项需求。
第五类联系链是软件需求之间的跟踪。这种跟踪便于更好地处理软件需求之间的逻辑相关性，检查需求分解中可能出现的错误或遗漏。
2. 需求跟踪的目的
需求跟踪是一项劳动强度很大的任务，在整个系统开发、运行和维护的过程中，要始终保持联系链信息与实际相符。在项目实践中，使用需求追踪能力，可以获得如下好处：
（1）审核。跟踪能力信息可以帮助开发人员审核和确保所有需求都被正确应用。
（2）变更影响分析。在增、删、改需求时，跟踪能力可以确保不忽略每个受到影响的系统元素。
（3）维护。可靠的跟踪能力信息使得维护能够正确而完整地实施变更，从而提高生产率。
（4）项目跟踪。认真记录跟踪能力数据，就可以获得计划功能当前实现状态的记录。
（5）再工程。可以列出遗留系统中将要替换的功能，记录它们在新系统中的需求和在软件构件中的位置。
（6）重复利用。跟踪能力信息可以帮助开发人员在新系统中对相同的功能利用现有系统的相关资源。
（7）减小风险。需求联系文档化可减少由于项目团队关键成员离职带来的风险。
（8）测试。测试模块、需求和代码段之间的联系链，可以在测试出错时指出最可能有问题的代码段。
3. 需求跟踪矩阵
表示需求和其它系统元素之间的联系链的最普遍方式是使用需求跟踪（能力）矩阵。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵。需求跟踪矩阵保存了需求与后继工作成果的对应关系。例如，从用户原始需求到软件需求之间的跟踪，可以采用如下表所示的矩阵：
| 用例 原始需求 | UC-1 | UC-2 | UC-3 | …… | UC-n |
|---|---|---|---|---|---|
| FR-1 | |||||
| FR-2 | |||||
| …… | |||||
| FR-m |
对于从软件需求到下游工作产品之间的跟踪，可以采用如下表所示的矩阵：
上表明确展示了每个用例是如何连接到一个或多个设计、编码和测试元素的。其中设计元素可以是模型中的对象，例如，DFD、E-R图或类图等；代码模块可以是类中的方法、源代码文件名、过程或函数。需求跟踪矩阵中可以定义各种系统元素类型间的一对一、一对多和多对多关系，也就是说，允许在上表的一个单元格中填入多个元素来实现这些特征。例如，一个代码模块对应一个设计元素，多个测试用例验证一个功能点，每个用例导致多个功能点等。
至此，“11.8 需求管理”的内容就全部讲解完了。
