如何跟踪需求

需求管理简介

需求管理的目的是管理项目的产品和产品组件的需求，并识别这些需求与项目计划和工作产品之间的不一致。

需求管理从获得利益相关者对基线需求的认同开始，包括所有涉及到的活动：

• 控制基线需求
• 使需求与计划和其他工作产品保持一致
• 随着项目在软件开发过程中的进展，跟踪需求的状态，以确保需求在后续的工作产品中得到实际的构建和验证。
• 请求对基础需求进行修改，对所要求的修改进行影响分析，批准或不批准这些修改，并实施所批准的修改。
• 必要时根据已批准的变更的影响协商新的承诺。

需求管理活动与需求开发活动密切相关，都是需求工程的一部分。如果需求的变化被批准，需求开发过程必须重复进行，以获得关于这些变化的信息，分析新的/改变的需求，指定新的/改变的需求，并验证这些变化和这些需求以及任何其他可能被变化影响的需求。然后，一个新的需求基线被创建。

各种组织和外部因素影响着这些活动。软件需求工程所处的环境会影响其实践和活动。因此，软件工程中使用的工具和技术应该根据参与者、项目和组织的需要而定制。

需求变更管理

需求变更管理评估需求变更对所有类型的生命周期模型的软件开发过程的影响。

在传统的软件开发方法中，良好的需求变更管理实践将需求规范确定为配置项。这些配置项被置于正式的变更控制之下，当它们被基线化时。需求变更管理过程必须包括以下机制。

• 要求并记录对基线需求的改变
• 对每个要求的需求变更进行影响分析。
• 告知受影响的利益相关者每个要求的需求变化，并征求他们对影响分析的意见。
• 让适当的机构，通常被为配置控制委员会（CCBconfiguration control board），就接受、推迟或拒绝每个要求的变化做出决定。
• 告知受影响的利益相关者关于接受、推迟或拒绝需求变更的决定，如果变更被接受，则获得他们对变更的承诺。
• 从提交到最终处理（拒绝或完成变更），跟踪需求变更。
• 如果需求变更被接受，所有受影响的工作产品和项目计划都应相应地更新（并酌情重新确定基线），以便它们与更新的需求保持一致。
• 在所有受影响的软件工作产品中验证已批准的需求变更的实施。

版本控制实践跟踪需求文件基线的变化历史。衡量标准也应该被用来跟踪需求的稳定性，也被称为波动性或流失率。

敏捷项目中的需求变更管理比较简单。因为每个迭代最多只持续几周，一般不会需求变更来打断迭代。因此，需求变更是通过在需求池中发布新的故事来处理的，或者通过改变尚未实施的故事，并酌情更改优先级。然而如果需求变很关键，则需要中断当前的迭代。处理需求变更的方式和前面类似，但终止当前的迭代，并将所有未完成的工作返回到需求池中。开始新的迭代，关键的变化被排在首位。

如果使用迭代、增量或进化的生命周期，每一套新的需求（新的需求基线）都构成对现有软件需求的改变。应该对每个基线中的新的/更新的需求进行需求变更管理过程，包括影响分析，以确保新的需求不与现有软件中已经建立的功能和质量/产品属性相冲突。

可追溯性

使用各种工具和技术来确保从需求发起和分析到设计和测试的双向可追溯性。开发过程中两个或多个产品之间可以建立关系的程度，特别是先后或主-从关系的产品"。

可追溯性被用来跟踪产品级需求和它的来源之间的关系。例如，产品需求可以通过利益相关者的功能需求，追溯到业务层面的需求，利益相关者的要求，业务规则，外部接口规范，行业标准，法律或法规，或其他一些来源。可追溯性也被用来跟踪需求和该需求被分配到的工作产品之间的关系。例如单一的产品需求可以追踪到架构元素，详细的设计元素，对象/类，源代码模块，单元/集成/系统/alpha/beta/验收测试，用户或操作文档主题，培训材料，等等，这些都是实现该需求的。

良好的可追溯性实践允许双向的可追溯性，这意味着可追溯性链可以在前向和后向进行追踪。

向前追踪每个独特的产品级需求到架构、设计、源代码模块、测试、文档、流程、培训材料和其他实现该需求的工作产品。目的是确保每个需求在软件产品中被实现，每个需求被彻底测试。

前向追踪验证了不断发展的产品的正确方向（项目正在建立正确的产品），并表明后续实施的完整性。例如，如果一个业务规则不能被向前追踪到一个或多个产品级需求，那么产品需求规范是不完整的，所产生的产品可能不符合业务的需要。如果一个产品需求不能向前追溯到其相关的架构设计元素，那么架构设计是不完整的，以此类推。

另一方面，如果业务环境有变化（例如，业务规则的变化或标准的变化），并且如果保持了良好的向前追溯性，该变化可以向前追溯到相关的利益相关者和/或项目级需求以及受该变化影响的所有工作产品。这大大减少了在发生变化时进行彻底影响分析所需的工作量。它也减少了任何受影响的工作产品被遗忘的风险，从而导致变化的不完整实施。

向后追踪，也叫反向追踪，着眼于追踪每个独特的工作产品（例如，设计元素，对象/类，源代码模块，测试，文件，培训材料，等等）回到它的相关需求。向后追踪有助于验证需求与后续工作产品保持一致，因为它们是基于这些需求建立的。

追溯每个需求的来源--例如，商业/利益相关者的需求，法规，法律，标准，等等。向后追踪有助于确保不断发展的软件产品在原始和/或不断发展的需求方面保持在正确的轨道上（该项目正在建立正确的产品）。其目的是确保产品的范围不会因为增加需求中没有规定的特性或功能而扩大（"镀金 "或 "爬行的优雅"）。如果在实施过程中需要改变，或者如果开发人员想出了一个创造性的、新的技术解决方案，那么这个改变或解决方案应该追溯到需求和/或业务需求，以确保它是在所需产品的范围之内。如果有一个工作产品元素没有追溯到需求，那么有两种情况是真的。

• 第一种可能性是，因为工作产品元素确实需要，所以需求被遗漏。在这种情况下，可追溯性有助于识别缺失的需求，也可以用来评估在项目计划和其他工作产品中增加该需求的影响（再次向前追溯）。

• 第二种可能性是，有镀金的情况发生--一些不应该是产品的一部分的东西被添加进来。镀金是一种高风险的活动，因为项目计划没有为这项工作分配时间或资源，而且产品的这一部分的存在可能没有很好地传达给其他项目人员（例如，测试人员没有测试它和/或它没有包括在用户文档中）。

向后追踪的另一个好处是，当工作产品被发现有缺陷时。例如，如果源代码模块有缺陷，那么追溯性可以用来帮助确定该缺陷的根本原因。它只是代码缺陷，还是可以追溯到设计或需求中的缺陷？如果是设计或需求方面的缺陷，那么向前追溯就可以用来确定该缺陷可能会影响到哪些其他工作产品？

许多现代需求管理工具和一些敏捷工具包括可追溯性机制，允许直接从工具中生成一个可追溯性矩阵。这些工具支持需求和它们的源和后续工作产品之间的联系。

典型的手工方式是通过构建一个可追溯矩阵来执行可追溯性。需求矩阵的优势在于，它是一个记录所有工作产品的前向和后向追溯的单一资源库。虽然维护一个手动的可追溯性矩阵是一个劳动密集型的活动，但来自更高的可见性、减少影响分析工作和减少风险的好处可以使它成为一个增值的活动。

另一个实施可追踪性的机制是追踪标签。同样，每个需求，每个需求源，和每个工作产品元素必须有一个唯一的标识符。然而，在跟踪标记中，这些标识符被用作后续工作产品的标记，以识别对前代文件的反向追踪。例如，软件设计规范（SDS）包括标识由每个唯一标识的设计元素实现的需求的标签，而单元测试规范（UTS）包括追溯到每个测试用例验证的设计元素的跟踪标签。这种标记通过工作产品集传播，包括追溯到设计元素的源代码模块，追溯到架构元素的集成测试案例，以及追溯到需求的系统测试案例，这取决于软件使用的工作产品的层次结构。追踪标签的优势在于它是工作产品的一部分，因此不需要维护一个单独的矩阵。然而，虽然使用跟踪标签很容易进行后向跟踪，但使用这种机制进行前向跟踪却非常困难。

所有的可追溯性实施技术都需要一个跨职能的参与者团队的承诺，以创建和维护需求、需求来源和分配给后续工作产品之间的联系。需求分析员必须启动需求追踪，并记录产品需求到其来源的原始追踪。当系统和软件架构师创建架构设计时，这些从业人员将他们的信息添加到可追溯性文件中。从事组件设计、代码和单元测试的开发人员必须为他们创建的元素添加额外的可追溯性信息，集成、系统和α、β和验收测试人员也是如此。对于小项目来说，其中一些角色可能不存在，或者由一个从业人员完成，这就限制了从事可追溯性信息的不同人员的数量。对于较大的项目，可追溯性信息来自于许多不同的从业人员，可能需要有人来协调、记录，并对所有不同来源的可追溯性信息进行定期审计，以验证所有可追溯元素的完整性和一致性。