“衍生需求可追溯性”是关于如何跟踪那些未明确列出，但从其他已明确列出的需求中衍生或推导出来的需求。在产品或项目开发过程中，通常会有一些需求是明确提出的（也被称为高层次需求），而有些需求虽然没有明确列出，但为了满足其他明确的需求或使整个系统正常运行，这些需求同样是必须要考虑的。
一、解释衍生需求
为了有效地追踪衍生的需求，每个需求都必须有一个独特且持久的标识，这样就能在项目的整个过程中明确地跟踪它。使用集中的、现代化的需求管理解决方案比使用多个独立的需求文档更为优秀。
这种管理工具（比如PingCode）不仅提供了一个方便的地方来收集反馈，进行实时的协作、审阅和批准，而且还支持对上游和下游关系的实时追踪，清楚地展示需求变化对所有层次的需求以及测试覆盖的影响。因此，项目团队可以为他们的衍生需求设立四种不同类型的可追溯性链接。
二、衍生需求可追溯性的四种类型
1.向需求前行
当客户需求发展时，可能需要调整需求。通过做出这些调整，项目团队可以跟上客户优先级的变化，引入新的商业规则，修改现有的规则，等等。
2.从需求回溯
从需求回溯可以清晰地了解每个衍生需求的起源。例如，需求管理工具可以展示衍生需求、它来自的需求，以及正在解决的客户用例之间的联系。
3.从需求向前
一旦衍生需求开始在产品开发过程中流向下游交付物，就可以在需求和其对应元素之间建立可追溯的关系。这种类型的链接提供了每个需求都由特定组件满足的保证。
4.回溯到需求
最后，这种类型的链接使人们能够看清为什么创建了某些功能。考虑到大多数应用程序包含的代码并不直接与利益相关者的需求有关，然而，了解软件工程师为何首先编写那段代码却很重要。
虽然对所有四种可追溯性链接类型的全面描述超出了这篇文章的范围，但是文章将深入探讨第四种类型的一个例子。假设在测试过程中，测试人员发现了一个没有对应需求的意外功能。这可能意味着两种情况：
- 一种可能是，这段底层代码可能是为了满足一个未明确提出但合理存在的（即衍生的）需求而编写的。如果是这种情况，可以将这个功能添加到需求规格中。
- 另一种可能是，这个功能只是一段孤立的代码，已经不再属于当前产品的需求范围内了。
可追溯性链接在此类情况下为系统的各部分如何结合在一起提供了清晰的视角。相对应地，从需求衍生并可以追溯到个别需求的测试用例提供了一种检测未实现需求的方式，因为如果某个功能未被实现，测试人员就无法在产品中找到预期的功能。
在一个项目中可能会有多种类型的可追溯性关系，并且并不是每个项目都需要全部类型的关系。然而，实施衍生需求可追溯性是有好处的，因为通过选择最佳的解决方案，它的灵活性可以根据特定项目的需求进行调整和利用。
三、衍生需求可追溯性的主要动机
在宏观层面上，可追溯性可以帮助提高产品生命周期的效率和提升项目管理的优秀性。实施它的更具体的原因包括：
- 认证：可追溯性数据可以支持对安全关键产品的认证，通过展示所有的需求都已经实施。
- 影响分析：通过追踪衍生需求，当确定需求变化的影响时，忽视某些因素的可能性就较小。
- 维护：清晰的可追溯性简化了维护，因为可以更有信心地进行变更（例如，响应政府法规或公司政策的更新）。现代化的需求管理工具更容易显示每一个适用规则在需求中的应用位置。
- 项目追踪：追踪性信息提供了对计划功能实施状态的准确记录，缺失的链接表示还未创建的工作产品。
- 重构：在准备替换的旧系统中列出功能，并使用追踪性数据记录新系统的需求和软件组件在哪里处理了它们。
- 复用：有了衍生需求的追踪性，通过识别相关的需求、设计、代码和测试的包，重用产品组件变得更为实用。
- 风险降低：记录组件之间的连接可以在关于系统的关键团队成员离开项目的情况下降低风险。
- 测试：需求、测试和代码之间的链接可以帮助指出当测试产生意外结果时，错误可能出现的地方。此外，知道哪些测试验证了哪些需求将节省时间，允许消除冗余的测试。
三、需求可追溯性的目的和重要性
可追溯性使得产品团队能够将特定的需求与所有相关的项目工件以及其他需求关联起来，无论是从需求派生出去的关联，还是反向跟踪到需求的关联，任何人都可以在开发过程的任何时刻看到这种活动与需求的关系——反之亦然。这种功能也被称为实时可追溯性，它可以促进团队协作，并且早期发现可能的生产风险。
换个角度看，关于产品的定义、质量和时机的正确开发有多重要？这是关键的任务，对吧？这就是为什么端到端的可追溯性如此关键。
让我们看看在整个产品开发生命周期中可追溯性的一些好处。例如，实时可追溯性：
- 简化项目估算
- 提高流程可见性
- 提高开发效率
- 改进变更的影响分析
- 展示验证和确认
- 加强产品质量
- 证明合规性或功能安全性
对于应用生命周期管理（Application Lifecycle Management, ALM）和产品生命周期管理（Product Lifecycle Management, PLM），能够一目了然地看到一个需求或数字线索是至关重要的。这两个领域都面临着紧张的时间表和不断增加的需求，其中包括来自法规的需求，这些需求对于合规性是不容妥协的。
了解需求、风险、测试之间的关系，是区分按时开发出符合规定的产品，还是陷入重做、推迟发布和处理不满的利益相关者之间的关键。有了需求可追溯性，你不必在速度或质量上妥协。
最重要的是，端到端的可追溯性能够确认你正在构建正确的事物，并帮助你证明其合规性或功能安全性。没有需求可追溯性，你的开发效率和产品质量就处于危险之中。
前向和后向可追溯性：创建数字线索的机制
为了连接产品开发生命周期的所有阶段，从客户需求到产品支持，必须使用四种不同的链接来端对端地串联整个过程。这包括高级需求以及衍生需求——那些没有明确定义，但对于满足已定义需求或使系统正常工作的需求。衍生需求也必须被充分追踪，才能充分利用实时可追溯性的好处。
什么是前向可追溯性？
前向可追溯性有两种：向需求前向和从需求前向。这两种形式都从上游的部分（如需求或设计）追踪到下游的工件（如实施或测试）。这两者的区别在于它们的出发点。
向需求前向的可追溯性是从客户需求开始，追踪到对应的产品需求。这一步很重要，因为客户的需求可能会随着时间的推移而发生变化。如果发生变化，产品需求可能需要相应地做出调整。通过遵循这种前向可追溯性，开发团队能够在开发过程中的任何阶段都了解优先事项的变化。
从需求前向的可追溯性则是追踪从产品需求到其对应的下游工件（例如测试用例）之间的关系。这种类型的追踪确保每个需求不仅被实现，而且也得到了验证和确认。
什么是后向可追溯性？
后向可追溯性，就像前向可追溯性一样，也有两种类型，它们都从下游工作产品（如实现或测试）追溯到上游元素（如需求或设计）。这两种类型的后向可追溯性的起点不同。
“从需求后向”是指通过将需求与其解决的客户用例关联起来，来理解一个需求的产生过程。这使得团队能够通过理解需求的起源来做出更好的决策。
“向需求后向”是指从已完成的工作（例如一个已实现的功能或已通过的测试）开始，追踪回其源头的需求。这种追踪方式使人们能够理解为什么特定的工作项被创建，以及系统的各个部分是如何协调在一起的。同时，这种方式的追踪也让测试人员有可能发现需求的遗漏或缺失。
什么是双向可追溯性？
双向需求可追溯性是指能够进行前向和后向追踪的能力。双向可追溯性被视为最优的可追溯性类型，因为它为团队提供了从需求规格到构建、测试、更改、缺陷管理，再追踪回需求规格的全过程视图。这种深度的追踪功能只能通过使用自动化的需求管理工具，如 PingCode来实现。
四、实施需求可追溯性的普遍挑战
如果所有这些听起来像是追踪性太难，不用担心。虽然对需求可追溯性有一些挑战，但也有很多模板和工具可以用来简化这个过程（下面会有更多介绍）。现在，让我们先来解决一些挑战，这样你就可以看到它们是如何被克服的。
不同的组织视角
每个人对于为什么以及如何执行追溯性的理解并不相同。那些担任发起人或管理职位的利益相关者可能只从规定或监管的角度看待需求追溯性。他们认为这是“必须的”，但可能不像项目或系统工程师那样理解需求追溯性的额外好处。
解决这个障碍的一种方法是让利益相关者明白，如果实现了端到端的追溯性，会带来哪些好处。与参与开发过程的每个人分享这篇文章，让他们理解需求追溯性不仅仅是需求管理的重要组成部分，而且不仅仅是覆盖他们的基础。
组织范围内的采用
有许多原因导致公司在采用追溯性方面进展缓慢。比如，培训就是其中一个因素。对利益相关者来说，参与项目的团队或个人可能并不都明白为什么追溯性如此重要，或者他们可能根本不知道如何正确执行适当的追溯性。此外，有些人可能担心决策点的追溯性数据可能会对他们产生影响。
如果你的组织面临这个挑战，那么教育是必不可少的。除此之外，你还需要创建一种文化，将追溯性视为开发过程的固有部分。首先，创建明确的关于组织如何管理追溯性的政策。然后，为所有新员工和现有员工制定积极的培训计划。如果你选择需求管理工具，确保它有良好的记录，使用直观且易于操作，并能适应你的流程，而不是相反。
实施成本
让整个开发组织在需求追溯性方面达成一致，并确保正确执行，可能会花费大量的成本。制定政策、进行培训以及创建和维护追溯性数据的时间累计起来，可能会让人们感觉生产力下降。此外，你可以选择采用追溯性工具来简化流程，但这意味着前期成本可能会比以前的项目高。
克服这个障碍需要改变思维方式。我们建议你考虑如果不采取行动的代价可能是什么。低效的工作时间、上市时间过长、返工和缺陷都是需求追溯性不足的极其昂贵的结果。每一项都带有高昂的价格标签。尽管实施需求追溯性和管理工具需要成本，但在整个开发过程中节省的金额远远超过了短期投资。
管理变革
在构建复杂产品的过程中，变革是不可避免的。团队成员必须理解变革，并确定其在整个产品开发生命周期中的影响范围。这意味着必须密切关注可能受影响的任何相关系统要求、下游要求和验证测试。
如果使用手动需求跟踪工具执行这个活动，可能会感到繁琐和耗时。相关的风险与什么都不做类似，因为你无法确定在处理静态文档和人为错误时是否考虑到了所有问题。
如果你的组织中曾经遇到过这种困扰，那么现在可能是时候探索自动化需求管理工具，以实现对实时需求的实时追踪了。
管理手段不当
一些开发团队仍在使用 Word 或 Excel 文档来跟踪需求关系并通过微信等工具进行协作。需求追溯性矩阵就是一个例子，它是一个通过电子表格手动跟踪需求管理元素（包括业务需求、目标、设计元素和测试用例）的文档。团队会在其中输入需求清单并填写相关数据。电子表格是静态的，但在整个开发生命周期中由团队手动更新。
如果你正在开发一个需求不多的产品，使用需求追溯性矩阵可能是有优势的。它比完全不追踪要好。你甚至可以使用模板来创建需求追溯性矩阵。但是，如果你的产品很复杂，有许多需求，你可能会遇到我们之前讨论过的许多挑战。
对于复杂的产品，需求追溯性矩阵无法跟上变化的脚步，也不能在利益相关者要求的时间范围内创建优质的产品。如 PingCode这样的灵活的需求管理工具甚至可以捕获跨团队和工具集的追踪关系，进一步增强追溯性的优势。
合规框架不足
受监管的行业需要需求管理来证明其符合行业标准。审查者和监管机构必须通过特定的方式接收监管提交的材料。为了通过审查，你必须提供全面的追溯性证明。
如果在整个开发过程中没有实施全面的追溯性，那么在事后将需要花费大量时间来收集必要的信息。即使在 Word 或 Excel 中精心维护追溯性，也需要花费时间将其编译成监管机构可以接受的格式。与此同时，那些将追溯性融入其流程的竞争对手将更快进入市场。
听起来很熟悉吗？幸运的是，有一些工具可以实施端到端的追溯性，并配备符合行业标准的框架。如 PingCode 这样的需求管理工具通过导出模板简化了审查流程，从而加速了合规性演示流程。
五、简化需求可追溯性的模版和工具
有许多工具可用来帮助进行需求追溯性的过程。对你的需求进行评估，以了解哪个工具最适合你是非常重要的。
你是否正在开发一种简单的产品，而且没有功能安全或监管要求？如果是这样，需求追溯性矩阵 (RTM) 可能就足够了。
你是否正在开发一个涵盖了软件和硬件组件的复杂产品？你是否需要证明功能的安全性或满足某些合规性要求？在这些情况下，你将需要一个需求管理工具，该工具具有双向追溯性和可以轻松导出的合规性模板。
