- 底层代码可能是为了满足合法的隐含（派生）要求而实现的，然后可以将其添加到需求规范中。
或者，它可能只是不再属于当前产品的孤立代码。 - 可追溯性链接在这种情况下可以提高清晰度，阐明系统的各个部分如何组合在一起。
- 简化项目估算
- 增强流程可见性
- 提高开发效率
- 改进变更影响分析
- 演示验证和确认
- 增强产品质量
- 证明合规性或功能安全性
派生需求可追溯性是一种需求管理形式，侧重于追踪那些在更高级别需求中未明确定义但对于满足更高级别需求以及使整个系统按预期运行必不可少的需求。在派生需求可追溯性中，团队将记录这些较低级别需求与其他系统元素之间的依赖关系和逻辑链接。
派生需求解释
为了充分实现派生需求可追溯性，每个需求都必须具有唯一且持久的标签，以便在整个项目中进行明确的跟踪。为此，集中式现代需求管理解决方案比众多分散的需求文档更可取。
这样的管理工具不仅提供了一个方便的地方来收集反馈并实时协作审查和批准，而且还支持上游和下游关系的实时可追溯性，可以清楚地看到变更对所有级别的需求以及测试覆盖率的影响。因此，项目团队可以为其派生需求设置四种不同类型的可追溯性链接。
图 1. 四种类型的需求可追溯性
四种衍生需求可追溯性
1. 向前追溯到需求
当客户需求发生变化时，可能需要调整需求。通过进行这些调整，项目团队可以跟上客户优先级的变化、新业务规则的引入、现有规则的修改等事件。
2. 从需求向后追溯
从需求向后追溯可以明确每个衍生需求的来源。例如，需求管理工具可以显示衍生需求、其来源需求和正在处理的客户用例之间的联系。
3. 从需求向前追溯
一旦衍生需求在产品开发过程中开始流入下游可交付成果，就可以绘制需求与其对应元素之间的跟踪关系。这种类型的链接可以确保每个需求都由特定组件满足。
4. 向后追溯到需求
最后，这种类型的链接可以了解创建某些功能的原因。考虑一下大多数应用程序包含的代码行与利益相关者需求没有直接关系。即便如此，了解软件工程师最初编写该代码的原因也很重要。
虽然对这四种类型的全面说明超出了本文的范围，但让我们看一下第四种类型的更深入的示例。假设测试人员发现了没有相应要求的意外功能。这可能表明两种不同的可能性：
相反，从单个需求派生并追溯到单个需求的测试用例提供了一种检测未实现需求的机制，因为测试人员找不到预期的功能。
一个项目内可能存在多种类型的可追溯性关系，但并非所有项目都需要这些关系。但是，通过具有灵活性的最佳解决方案来实现派生需求可追溯性是有充分理由的，可以根据特定项目的需要进行利用。
图 2. 一些可能的需求可追溯性链接
派生需求可追溯性的主要动机
从高层次来看，可追溯性有助于提高产品生命周期的效率和卓越的项目管理。实施可追溯性的更具体原因包括：
认证 Certification
可追溯性数据可以证明所有需求都已得到实施，从而支持安全关键产品的认证。
影响分析 Impact analysis
通过追踪派生需求，在确定需求变更的影响时，不太可能忽略某些内容。
维护 Maintenance
清晰的可追溯性简化了维护，因为可以更有信心地执行变更（例如，响应政府法规或公司政策的更新）。现代需求管理工具可以更轻松地显示需求中每个适用规则的解决位置。
项目跟踪 Project tracking
可追溯性信息提供了计划功能的实施状态的准确记录，缺少的链接表示尚未创建工作产品。
再造 Reengineering
列出旧系统中需要替换的功能，并使用可追溯性数据记录新系统需求和软件组件中解决这些功能的位置。
重用 Reuse
有了派生需求可追溯性，通过识别相关需求、设计、代码和测试包，重用产品组件就更加实用了。
降低风险 Risk reduction
记录组件互连可以降低风险，以防掌握系统基本知识的关键团队成员离开项目。
测试 Testing
当测试产生意外结果时，需求、测试和代码之间的联系有助于指示错误可能出现的位置。此外，了解哪些测试验证了哪些需求将节省时间，因为可以消除冗余测试。
本系列的第二篇文章讨论了需求可追溯性矩阵，最后一部分提出了一种使需求可追溯性在您的项目中发挥作用的程序。
需求可追溯性的目的和重要性
可追溯性使产品团队能够将特定需求与所有相关项目工件以及其他需求（包括前向和后向）相关联，以便任何人都可以在开发过程中的任何时间点看到活动与需求之间的关系（反之亦然）。此功能也称为实时可追溯性，可促进团队协作并能够尽早发现可能的生产风险。
这样想：在定义、质量和时间方面正确开发产品有多重要？任务至关重要，对吧？这就是端到端可追溯性如此重要的原因。
让我们来看看在整个产品开发生命周期中可追溯性的一些好处。例如，实时可追溯性：
对需求或数字线程的单一视线对于应用程序生命周期管理 (ALM) 和产品生命周期管理 (PLM) 至关重要。两者都承受着紧迫的时间线和越来越多的需求——包括法规中的需求，其中合规性是不可协商的。
了解需求、风险、测试等之间的关系是按时开发合规产品与陷入返工、延迟发布和处理不满意的利益相关者之间的区别。有了需求可追溯性，您不必在速度或质量上妥协。
最重要的是，端到端可追溯性确认您正在构建正确的东西，并帮助您证明合规性或功能安全性。没有需求可追溯性，您的开发效率和产品质量就会受到威胁。
前向和后向可追溯性：创建数字线程的机制
要连接产品开发生命周期的所有阶段（从客户需求到支持），必须使用四种不同的链接将流程端到端串联起来。这包括高级需求以及派生需求（这些需求未明确定义，但对于满足已定义的需求或使系统按预期运行必不可少）。派生需求也必须得到充分跟踪，才能充分利用实时可追溯性。
什么是前向可追溯性？
前向可追溯性有两种：前向到需求和前向从需求。它们都从上游组件跟踪到下游工件。区别在于它们的起点。
前向到需求跟踪从客户需求到需求。这很重要，因为客户需求会随着时间的推移而发展。如果客户需求发生变化，则需求可能需要随之改变。遵循这种前向可追溯性，团队可以在整个开发过程中随时了解优先级的变化。
前向从需求跟踪需求与相应的下游工件（包括测试用例）之间的关系。这种跟踪类型可确保每个需求不仅得到满足，而且得到验证和确认。
什么是后向可追溯性？
与前向可追溯性一样，后向可追溯性也有两种。这对可追溯性从端点或下游工作产品追溯到上游元素。两种后向可追溯性的起点不同。
从需求向后追溯通过将需求与其所涉及的客户用例联系起来，可以深入了解需求的产生过程。这使团队能够通过了解需求的来源来改进决策。
从已执行的工作开始追溯到其需求。它使人们能够了解创建特定项目的原因以及系统的不同部分如何组合在一起。以这种方式跟踪还允许测试人员找到差距或缺失的需求。
什么是双向可追溯性？
双向需求可追溯性是指执行前向和后向可追溯性的能力。双向可追溯性是最佳的可追溯性类型，因为它使团队能够从需求规范到构建、测试、变更、缺陷再到后向完全可见。这种级别的可追溯性只能通过自动化需求管理工具（例如 Jama Connect®）实现。
需求可追溯性的常见挑战
如果这一切听起来都像可追溯性太难了，请不要害怕。虽然需求可追溯性存在一些挑战，但您也可以使用许多模板和工具来简化流程（下文将详细介绍）。现在，让我们来解决一些挑战，以便您了解如何克服它们。
不同的组织观点。
并非每个人都对为什么以及如何执行可追溯性有相同的理解。赞助商或管理职位的利益相关者可能仅从标准或监管角度看待需求可追溯性。他们认为这是“必须具备的”，但可能不像项目或系统工程师那样理解需求可追溯性的额外好处（如上所述）。
解决这一障碍的一种方法是教育利益相关者如果实现端到端可追溯性可以实现什么。与参与开发过程的每个人分享这篇文章，以便他们能够基本了解为什么需求可追溯性是需求管理的重要组成部分，而不仅仅是知道他们需要它来覆盖他们的基础。
整个组织范围内的采用。
公司采用可追溯性的速度可能很慢，原因有很多。培训就是一个例子。考虑到利益相关者，并非所有从事项目的团队或个人都知道可追溯性为何如此重要，或者他们可能根本不知道如何正确执行适当的可追溯性。此外，有些人可能担心来自决策点的可追溯性数据可能会反过来伤害他们。
如果这对您的组织来说是一个挑战，那么教育也是必不可少的。但除此之外，您还需要创建一种文化，在这种文化中，可追溯性被视为开发过程的固有部分。首先制定明确的政策，说明组织如何管理可追溯性。然后为所有新员工和现有员工制定积极的培训计划。如果您选择需求管理工具，请确保它具有良好的记录，是直观且易于使用的软件，可以适应您的流程 – 而不是相反。
实施成本。
让整个开发组织在需求可追溯性方面达成共识，然后确保正确执行，可能是一项昂贵的工作。制定政策、开展培训以及创建/维护可追溯性数据所花费的时间加起来甚至会让人们感觉效率低下。此外，您可以选择采用可追溯性工具来简化流程，这意味着前期成本将高于以前的项目。
克服这一障碍需要改变思维方式。我们敦促您考虑无所作为的代价。低效的工作时间、漫长的上市时间、返工和缺陷都是需求可追溯性不足的极其昂贵的症状。这些都带有高昂的代价。要了解这些复杂情况可能给您的组织带来多少成本，请查看我们的《买家指南》第 9-11 页的计算器。虽然实施需求可追溯性和管理工具需要付出成本，但在整个开发过程中节省的金额远远超过短期投资。
管理变更。
在构建复杂产品时，变更是不可避免的。团队成员必须了解变更并确定其在整个产品开发生命周期中的影响范围。这意味着要仔细查看任何相关的系统要求、下游要求和可能受影响的验证测试。
使用手动需求可追溯性工具执行此活动可能很麻烦且耗时。 相关风险类似于什么都不做，因为在处理静态文档和人为错误时，您无法确定是否已考虑到所有问题。
如果您的组织遇到过这种挫折，那么可能是时候探索自动化需求管理工具了，这些工具可以实现实时需求的可追溯性。
管理工具不当。
一些开发团队仍在使用 Word 或 Excel 文档跟踪需求关系并通过电子邮件进行协作。需求可追溯性矩阵是一种文档示例，它通过电子表格手动跟踪需求管理的元素，包括业务需求、目标、设计元素和测试用例。团队输入需求列表并填写相关数据。电子表格是静态的，但在整个开发生命周期中由团队手动更新。
如果您正在开发的产品没有太多需求，使用需求可追溯性矩阵可能会有优势。这比完全不跟踪要好。您甚至可以使用模板来创建需求可追溯性矩阵。但是，如果您的产品很复杂，有很多需求，您可能会遇到上面讨论的许多挑战。
对于复杂的产品，需求可追溯性矩阵不具备您需要的功能，无法跟上变化的步伐并在利益相关者要求的时间内创建高质量的产品。灵活的需求管理工具（如 Jama Connect）甚至可以捕获跨团队和工具集的跟踪关系，从而进一步增强可追溯性的优势。
合规框架不足。
受监管行业需要需求管理来证明符合行业标准。审核人员和监管机构必须以特定方式接收监管提交。要通过审计，您必须提供全面可追溯性的证明。
如果在整个开发过程中没有执行全面的可追溯性，则事后将花费大量时间来收集必要的信息。即使在 Word 或 Excel 中精心维护了可追溯性，仍需要花费时间将其编译为可接受的监管提交格式。与此同时，将可追溯性作为其流程固有的竞争对手将率先进入市场。
听起来很熟悉？幸运的是，有些工具可以执行端到端可追溯性，并附带符合行业标准的框架。需求管理工具（如 Jama Connect）通过导出模板简化了审计流程，从而加快了合规性呈现流程。
模板和工具可简化需求可追溯性流程
有许多工具可用于协助可追溯性流程。评估您的需求以了解最适合您的工具非常重要。
您是否正在创建一种没有功能安全或监管要求的简单产品？如果是这样，RTM 可能就足够了。下载此需求可追溯性矩阵模板，立即开始使用。
您是否正在创建具有软件和硬件组件的多面产品？您是否需要证明功能安全或法规合规性？在这些情况下，您需要一个具有双向可追溯性和合规性模板的需求管理工具，您可以轻松导出这些模板。
