1.1 需求跟踪动机

一个尴尬的开发经历，就是忽略了一个需求，所以在自认为完成编程后，不得不返工编写额外的代码。就是因为忘了，后来不得不返工。如果忽略某几个需求造成用户不满意或发布一个不符合要求的产品，那就不仅仅是尴尬了。在某种程度上，需求跟踪提供了一个表明与合同或说明一致的方法。更进一步，需求跟踪可以改善产品质量，降低维护成本，而且很容易实现重用。

需求跟踪是个要求手工操作且劳动强度很大的任务，要求组织提供支持。随着系统开发的进行和维护的执行，要保持关联链信息与实际一致。跟踪能力信息一旦过时，可能再也不会重建它了。由于这些原因，应该正确使用需求跟踪能力。下面是在项目中使需求链中的联系链有效的一些好处：

• 审核：跟踪能力信息可以帮助审核确保所有需求被应用。
• 变更影响分析：跟踪能力信息在增、删、改需求时可以确保不忽略每个受到影响的系统元素。
• 维护：可靠的跟踪能力信息使得维护时能正确、完整地实施变更，从而提高生产率。要是一下子不能为整个系统建立跟踪能力信息，可以一次只建立一部分，再逐渐增加。
• 项目跟踪：在开发中，认真记录跟踪能力数据，就可以获得计划功能当前实现状态的记录。还未出现的联系链意味着没有相应的产品部件。
• 再设计(重新建造)：你可以列出传统系统中将要替换的功能，记录它们在新系统的需求和软件组件中的位置。通过定义跟踪能力信息链提供一种方法收集从一个现成系统的反向工程中所学到的方法。
• 重复利用：跟踪信息可以帮助你在新系统中对相同的功能利用旧系统相关资源。例如:功能设计、相关需求、代码、测试等。
• 减小风险：使部件互连关系文档化可减少由于一名关键成员离开项目带来的风险。
• 测试：测试模块、需求、代码段之间的联系链可以在测试出错时指出最可能有问题的代码段。

以上所述许多是长期利益，减少了整个产品生存期费用，但同时要注意到由于积累和管理跟踪能力信息增加了开发成本。这个问题应该这样来看，把增加的费用当作一项投资，这笔投资可以使你发布令人满意同时更容易维护的产品。尽管很难计算，但这笔投资在每一次修改、扩展或代替产品时都会有所体现。如果在开发工程中收集信息，定义跟踪能力联系链一点也不困难，但要在整个系统完成后再实施代价确实很大。

CMM（能力成熟度模型）的第三层次要求具备需求跟踪能力。

软件产品工程活动的十个关键处理领域中有关于它的陈述：“在软件工作产品之间，维护一致性。工作产品包括软件计划、过程描述、分配需求、软件需求、软件设计、代码、测试计划以及测试过程。”需求跟踪过程中还定义了一些关于一个组织如何处理需求跟踪能力的期望。

1.2 需求跟踪能力矩阵

表示需求和别的系统元素之间的联系链的最普遍方式是使用需求跟踪能力矩阵。这个表说明了每个功能性需求向后连接一个特定的使用实例,向前连接一个或多个设计、代码和测试元素。设计元素可以是模型中的对象,例如数据流 ¹图、关系数据模型中的表单、或对象类。代码参考可以是类中的方法,源代码文件名、过程或函数。加上更多的列项就可以拓展到与其它工作产品的关联,例如在线帮助文档。包括越多的细节就越花时间,但同时很容易得到相关联的软件元素,在做变更影响分析和维护时就可以节省时间。

跟踪能力联系链可以定义各种系统元素类型间的一对一,一对多,多对多关系。允许在一个表单元中填入几个元素来实现这些特征。这里是一些可能的分类: - 一对一：一个代码模块应用一个设计元素。 - 一对多：多个测试实例验证一个功能需求。 - 多对多：每个使用实例导致多个功能性需求,而一些功能性需求常拥有几个使用实例。

手工创建需求跟踪能力矩阵是一个应该养成的习惯,即使对小项目也很有效。一旦确立使用实例基准,就准备在矩阵中添加每个使用实例演化成的功能性需求。随着软件设计、构造、测试开发的进展不断更新矩阵。例如,在实现某一功能需求后,你可以更新它在矩阵中的设计和代码单元,将需求状态设置为“已完成”。

表示跟踪能力信息的另一个方法是通过矩阵的集合,矩阵定义了系统元素对间的联系链。

例如: - 一类需求与另一类需求之间。 - 同类中不同的需求之间。 - 一类需求与测试实例之间。可以使用这些矩阵定义需求间可能的不同联系,例如:指定/被指定、依赖于、衍生为以及限制/被限制。

矩阵中绝大多数的单元是空的。每个单元指示相对应行与列之间的联系,可以使用不同的符号明确表示“追溯到”和“从……回溯”或其他联系。

跟踪能力联系链无论谁有合适的信息都可以定义。下表定义了一些典型的知识源,即关于不同种类源和目标对象间的联系链。定义了可以为工程项目提供每种跟踪能力信息的角色 ²和个人。

跟踪能力联系链可能的信息源

1.3 需求跟踪能力工具

由于联系链源于开发组成员的头脑中,所以需求跟踪能力不能完全自动化。然而,一旦已确定联系链,特定工具就能帮你管理巨大的跟踪能力信息。可以使用电子数据表来维护几百个需求的矩阵,但更大的系统需要更“鲁棒”的解决办法。

可以在工具的数据库中存储需求和其他信息,定义不同对象间的联系链,甚至包括同类需求的对等联系链。有一些工具需要区分“追溯到(跟踪进)”与“从……回溯(跟踪出)”关系,自动定义相对的联系链。这就是说,如果你指出需求 R 追溯到测试实例 T,工具会自动定义相对的联系“T 从 R 回溯”。还有一些工具可以在联系链某端变更后将另一端标为“可疑”。可以让你检查确保知道变更的后续效果。

这些工具允许定义“跨项目”或“跨子系统”的联系链。一个有 20 个子系统的大项目,某些高层产品需求建立在多个子系统之上。有些情况下,分配给一个子系统的需求,实际上是由另一个子系统提供的服务完成的。这样的项目采用商业需求管理工具可以成功地跟踪这些复杂的跟踪能力关系。

1.4 需求跟踪能力过程

应用需求跟踪能力管理项目时，可以考虑以下步骤：

1. 明确需要定义的联系链类型。
2. 选择适合的跟踪能力矩阵类型。
3. 确定需要维护跟踪能力信息的产品部分，优先关注关键核心功能、高风险部分或维护量大的部分。
4. 通过修订过程和核对表，提醒开发者在需求完成或变更时更新联系链。
5. 制定标记规范，统一标识所有系统元素，便于相互联系。如有必要，进行文字记录，以便分析系统文件，更新或重建跟踪能力矩阵。
6. 确定提供每类联系链信息的责任人。
7. 培训项目组成员，使其理解需求跟踪能力的概念、重要性、活动目的、跟踪能力数据存储位置以及定义联系链的技术（如使用需求管理工具的特性）。确保与会人员明白自身责任。
8. 有人完成任务后，立即更新跟踪能力数据，并通知相关人员更新需求链上的联系链。
9. 在开发过程中周期性地更新数据，确保跟踪信息与实际情况相符。如发现跟踪能力数据不完整或不正确，说明项目效果不佳，需要及时改进。

1.5 需求跟踪能力可行吗,必要吗?

你可能会认为构建需求跟踪能力矩阵十分繁琐，而且收益有限，或者虽然简单却不实用。举个例子，一位在飞机制造厂工作的参会者告诉我，他们公司最新型喷气客机的用户需求说明书有一人高，而且还有完整的需求跟踪能力矩阵。听到开发人员如此严格地管理软件需求，我感到非常高兴。对于有很多子系统的大型产品而言，进行跟踪能力管理是一项艰巨的任务，但他们知道这很有必要。

并不是所有的公司都会因为软件问题而遭受严重后果，然而，需求跟踪仍然值得认真对待，尤其是对于涉及企业核心业务的信息系统。有一次，我在一个专题会议上介绍完跟踪能力后，在场的一位大公司的 CEO 问道：“为什么不对战略 ³商业系统做一个跟踪能力矩阵？”这是一个很好的问题。只有在考虑了应用新技术的成本和不使用的风险后，才能决定是否采用任何改进的需求工程实践。随着软件的发展，我们应该把时间投入到回报丰厚的领域。

2.1 影响分析过程

项目变更控制委员会通常会请资深开发人员对提出的需求变更申请进行影响分析。为了帮助影响分析员理解接受一个建议变更的影响，可以设计一系列问题核对表，如下所示：

建议的变更涉及的问题核对表：

1. 基准（线）中是否已有需求与建议的变更相冲突？
2. 是否有待解决的需求变更与已建议的变更相冲突？
3. 不采纳变更会有什么业务或技术上的后果？
4. 进行建议的变更会有什么样的负面效应或风险？
5. 建议的变更是否会不利于需求实现或其它质量属性 ⁵？
6. 从技术条件和员工技能的角度看该变更是否可行？
7. 若执行变更是否会在开发、测试和许多其它环境方面提出不合理要求？
8. 实现或测试变更是否有额外的工具要求？
9. 在项目计划中，建议的变更如何影响任务的执行顺序、依赖性、工作量或进度？
10. 评审 ⁶变更是否要求原型法或别的用户提供意见？
11. 采纳变更要求后，浪费了多少以前曾做的工作？
12. 建议的变更是否导致产品单元成本增加？例如增加了第三方产品使用许可证的费用。
13. 变更是否影响任何市场营销、制造、培训或用户支持计划？

或如下表所示,用来帮助确定涉及的软件元素。

变更影响的软件元素核对表：

1. 确认任何用户接口要求的变更、添加或删除。
2. 确认报告、数据库或文件中任何要求的变更、添加或删除。
3. 确认必须创建、修改或删除的设计部件。
4. 确认源代码文件中任何要求的变更。
5. 确认文件或过程中任何要求的变更。
6. 确认必须修改或删除的已有的单元、集成或系统测试用例。
7. 评估要求的新单元、综合和系统测试实例个数。
8. 确认任何必须创建或修改的帮助文件、培训素材或用户文档。
9. 确认变更影响的应用、库或硬件部件。
10. 确认须购买的第三方软件。
11. 确认在软件项目管理计划、质量保证计划和配置管理计划等中变更将产生的影响。
12. 确认在修改后必须再次检查的工作产品。

熟练以后,可以按照具体情况修改。

下面是一个评估需求变更影响的简单例子。许多评估问题的出现是因为评估者没有完全按此行事。所以，这个影响分析方法强调广泛的任务确认。对于重大的变更，小组—不只是一个开发者—应该做影响分析和工作量估算 ⁷来确保不忽略重要的任务。

1. 按照建议的变更涉及的问题核对表进行一遍。
2. 按照变更影响的软件元素核对表进行一遍，要使用有效的跟踪能力信息。有一些需求管理工具包含影响分析报告并且能发现受变更影响的系统元素。
3. 使用一个检查清单来评估预期任务要求的工作量，绝大多数的变更仅要求工单所列任务的一部分。
4. 计算评估工作值的总和。
5. 确认任务执行的顺序，这些任务如何同当前的计划任务配合？
6. 决定变更是否处于项目的关键路径。如果一个处于关键路径的任务延期，项目的完成之日将遥遥无期。每个变更都会消耗资源，如果能避免变更影响关键任务，则变更不会造成整个项目延期。
7. 估计变更如何影响进度和费用。
8. 通过与其它任意需求的收益、代价、成本和技术风险的比较来评估变更的优先级 ⁸。
9. 向变更控制委员会报告影响分析结果，他们可以在采纳或拒绝变更的决策过程中使用这些评估信息。

在绝大多数实例中，完成这些过程不会超过一到二小时。对于一个繁忙的开发人员来说似乎浪费了很多时间，其实为了确保开发人员对有限的资源的精打细算，这只是一笔很小的投资。如果不用系统的评估技能从容地评估出变更影响，就去做吧；但要小心别让自己进入“流沙区”。

检查清单例子：

2.2 影响分析报告模板

使用模板可以帮助变更控制委员会找到有用的信息来作出正式的决策。实现此项变更的开发人员可能需要详细的分析情况和工作量计划工单，但变更控制委员会仅需要影响分析的总结。可以视情况调整模板。