如何创建和使用需求追溯矩阵

你可能已经理解需求追溯对于产品团队在整个开发生命周期中维护一条数字化流程的重要性。但你应该从何处开始呢？如果一个流程并未像预期那样为你的团队提供服务，你又该如何改进它呢？

需求追溯矩阵（RTM）通常是首选。它的入门门槛较低，易于上手，几乎无需预付成本。我们甚至已经创建了一个免费的RTM模板，所以你今天就可以开始使用。

像PingCode、Jama Connect这样的需求管理软件工具也是一个选择。本文将解释：

• 需求追溯矩阵（RTM）是什么？
• 有哪些不同类型的RTM？
• 如何创建需求追溯矩阵？
• 什么情况下，一个公司从使用需求管理软件中获益，而不是在Excel中使用需求追溯矩阵？

一、什么是需求可追溯性矩阵?

需求追溯矩阵（RTM）是一个文档，在其中，产品团队会追踪记录产品开发过程中需求、验证、风险以及其他各类元素之间的关联。RTM的内容可能会包括商业需求、系统和子系统的需求、设计元素、测试用例、缺陷，以及这些项目相关的信息，比如状态，这主要取决于所采用的RTM的类型。其主要目的是通过展示从单独的需求到其实施和验证的直接追踪，来证明需求已经得到了满足。

为了确保你能具体了解在你的组织中实施需求追溯的最有效方式，本文还将对比手动管理的RTM和专业的生命周期管理（ALM）工具管理的RTM。这些需求管理工具会自动创建从高级需求到低级需求以及测试的数字化追踪关系。

二、使用需求可追溯性矩阵的目的

产品团队需要确保他们正在开发正确的产品。为此，他们必须追踪所有需求的数据，包括用于验证所有需求是否得到满足的测试。在一些行业中，这种验证是出于功能安全或法规合规所必需的。

需求追踪使参与产品定义、设计、风险评估和验证的跨学科团队能够将他们各自活动中的工作项目关联起来，并分析在复杂且高度互联的系统中各个部分之间的联系和影响。此外，利益相关者和监管机构可以看到，从业务或规定和标准中产生的产品需求是否得到了满足。

三、不同类型的需求追溯矩阵（RTM）以及示例

在宏观层面上，需求追溯矩阵有三种类型：前向追溯、后向追溯和双向追溯。

每一种追溯矩阵都是为了确保高级需求已经分解到适当的抽象层次，低级需求与更高级别的需求相联系，以及验证测试用例已经就位并有其结果。区别在于用户能够查看哪个方向的事件——向前看、向后看，或者两者。这种类型的差异是显著的，这取决于用户需要从矩阵中获取的信息：例如，我的所有子系统需求是否追溯到系统需求？我所有的需求的验证是否已通过？如果我们改变这个高级需求，下游的影响会是什么？

前向追溯矩阵从客户或高级需求追溯到系统和子系统需求，以及所有相应的下游设计元素和测试用例。遵循前向追溯使得团队能在整个开发过程中随时了解变化及其可能的影响。此外，它确保每个需求不仅得到满足，而且得到验证和确认。

举例：在开发过程中，一家电脑公司降低了其新笔记本电脑的重量要求。团队可以使用前向追溯来调查项目上改变的影响。任何相关的需求或生成的工件都可以相应地调整，并且测试用例可以调整以确保全面的测试覆盖。

四、在Excel中创建需求追溯矩阵的步骤

步骤1：决定你需要哪种类型的追溯矩阵

当创建需求追溯矩阵时，你要从最终目标出发。你对这个矩阵的目标是什么？你需要哪种类型的追溯矩阵来达到这个目标？可以再看一遍刚刚讨论的不同类型的RTM以获得灵感。

在创建需求可追溯性矩阵的过程中，首先要明确所需要的矩阵类型。我们需要从结果出发思考：想要通过这个矩阵实现什么目标？需要哪种类型的追溯性矩阵来达到这个目标？可对比上文讨论过的RTM不同类型。

步骤2：确定包含哪些组件和工作项

确定了你的需求追溯矩阵（RTM）的目标之后，你就需要决定应该包含哪些内容或工作项。例如，你可能希望包括以下三类典型的项目：需求、测试和缺陷。在你的需求追溯矩阵中，你可能希望包括以下信息：

• 高级需求：包括客户需求、商业需求，以及每个需求的唯一标识符（ID）。
• 系统和下级需求：包括系统需求（追溯到高级需求）、硬件和软件需求（追溯到系统需求），以及每个需求的唯一标识符。
• 验证：包括测试用例（追溯到需求）、测试用例ID，以及验证结果（如通过/未通过）。
• 缺陷：包括缺陷描述（追溯到验证）和缺陷ID。

此外，你可能还希望在你的RTM中包含其他工作项，如系统架构、子系统设计元素、风险分析、功能安全目标和用户需求。

同时，除了每个工作项的唯一ID之外，你可能还希望在RTM中包含每个工作项的其他相关信息，比如它们的状态或简短描述。

步骤3：在Excel中建立追溯矩阵

现在你知道了你将使用哪种类型的RTM来实现你的目标，现在是时候开始使用你选择的元素来构建你的电子表格了。这些应作为列标题输入。

需求追溯矩阵电子表格可以像我们创建的可下载的RTM模板那样模板化，让你快速开始。你可以调整列，以确保你捕获你需要的信息并实现你定义的目标。

步骤4：收集并输入数据

为了在你的追溯矩阵中获取正确的信息，你需要从多种来源收集数据 —— 商业需求文档(BRD)、功能或技术需求文档，以及测试用例文档。

一旦你收集到了你需要的信息，就可以开始添加每一个高级需求（例如，客户需求）及其相关的系统和低级需求。然后为每个需求分配一个唯一的需求ID。从那里开始，你可以根据你选择使用的列添加尽可能多的详细信息。

步骤5：开始工作

只要你把所有必要的数据都输入到你的需求追溯矩阵中，你就可以开始你的工作。这个工作涉及到对需求追溯矩阵的持续性维护。

随着产品开发活动的不断进行，你会发现需求、测试、缺陷等都会被添加、淘汰或修改。尽管必须更新包含这些信息的文件（例如，系统需求文件或验证协议）以反映这些变化，但同样重要的是要对需求追溯矩阵进行评估，并相应地进行更新。这可能涉及到添加新项和/或更新项目之间的关系。如果不持续对需求追溯矩阵进行维护，你将无法实现需求追溯的任何好处。

例如，你可能会失去你希望得到的增强的可视化效果，并且几乎没有可能提高效率或改进变更影响的分析。在分析覆盖范围或确定变更影响时，使用过时的需求追溯矩阵是特别有风险的。需求追溯矩阵对于产品的质量和安全至关重要，如果忽视了对它的维护，那么依赖这个被忽视的需求追溯矩阵来进行决策和分析可能会导致产品质量下降和进度受影响。

在复杂产品使用电子表格实现需求可追溯性的风险

在受监管的行业中开发复杂产品时，使用电子表格来建立需求可追溯性可能会带来一系列问题。尤其是需要遵守法规或功能安全规定的行业，如医疗设备、汽车或航空航天开发。

以下是使用电子表格实现需求可追溯性时可能遇到的风险：

效率低下

手动输入数据会减慢团队的工作速度，使团队成员无法专注于他们的主要工作职责。而且，由于正在开发的产品复杂性高，可能需要大量的列以及成百上千行的数据。在保持版本控制、给合适的利益相关者访问权限的同时，要想及时更新所有信息并获取有关关系的洞察，几乎是不可能的。

错误出现概率高

需求追溯矩阵易于出现用户错误，因为在整个开发生命周期中，团队需要手动更新它。往往，信息来自多种来源，如电子邮件或其他电子表格，这些来源可能含有过时或错误的信息。

使用成本高

RTM的维护通常被视为繁琐的工作。这意味着数据输入可能会被推迟到其他工作完成之后。这就否定了需求追溯在产品制作过程中的价值。此外，如果你无法追踪到所有分散的电子邮件和文件中的记录，你可能会遗漏重要的合规性信息。

像PingCode这样的需求管理工具可以简化需求追溯矩阵，因为它在工作进行的过程中为你记录双向追溯。它也简化了验证和验证的过程。

使用需求管理软件进行追溯的优势

大多数需求管理工具都能够支持追溯性。然而，PingCode通过创建我们所称的“实时追溯”——一种动态的追溯关系视图，来取代静态的追溯矩阵。PingCode的实时追溯视图能够显示需求之间的数字化联系，并提供实时的分析和编辑体验。

使用PingCode，团队可以自动地享受到所有需求追溯性的好处。这些好处包括提高过程的可见性，改善对变更影响的分析，确保验证和确认过程的准确性，以及证明合规性或功能安全性。

同样地，使用电子表格带来的风险——例如用户错误和疲劳——都能够被消除，这样团队就能够更加专注于他们的核心工作，从而提高工作效率。实时追溯还能提升团队的协作，使得生产风险的早期发现变得可能。