需求改了，谁会受影响？这才是 Polarion 需求追溯的价值

项目会上，这个问题常常会换来一句话：“先找相关同事确认一下。”

于是，需求负责人翻文档，开发检查实现，测试查找用例。大家各自掌握一部分信息，却很难立即拼出完整答案。

上一篇，我们介绍了如何把一条需求作为工作项管理。这一篇继续往下看：当需求与上下游工作建立关系之后，团队能获得什么？

我们仍用“超温报警”这个案例展开。

以下为演示案例，编号、场景与测试数据用于说明管理过程。

设备监控系统中，有这样一条需求：

为了实现它，团队进一步定义了“超温事件接收与处理”“报警界面刷新”等软件需求，并编写“报警显示时限验证”测试用例。

这些内容可能分布在不同的 LiveDocs 文档中，分别由不同人员维护。

在 Polarion 中，可以通过工作项关系，把它们连接起来：

Polarion 支持通过可配置的链接角色表达这些关系，包括实现、细化、验证等语义。

PART 02

改一个数字，找到一串检查对象

项目进行到一半，客户提出：

改文字很容易。但实现这项变更，可能涉及多个环节：事件处理是否存在排队？界面刷新间隔是否过长？测试用例的判定条件是否还是 2 秒？

如果这些信息没有关联，团队就要逐份寻找，还要担心漏掉某个环节。

有了追溯关系，工程师可以从 BBB-214 出发，沿着链接检查下级需求和测试用例，逐项判断是否需要调整。关联能力为变更影响分析提供依据。

链接代表“需要检查”，不代表关联对象一定要修改。最终影响仍需工程人员评估。

逐条查看关系适合分析具体问题。但面对几十条、几百条需求，项目还需要一个整体视角。

这时，可以用追溯矩阵检查需求与测试用例之间的关系。

假设报警模块还有一条独立需求：

团队编写了“报警信息完整性验证”用例，却忘了建立对应关联。在矩阵中，就可能出现这样的情况：

这个空缺会促使团队进一步检查：是测试用例还没写，还是已经写了但漏建关联？是否有其他适用的验证方式？

Polarion 提供矩阵及覆盖分析相关能力，帮助团队检查预期的追溯关系。

矩阵中的关联表示存在验证关系，不等于测试已经执行通过。空缺也要结合筛选范围、链接方向和项目规则判断。

追溯还可以从结果往回查。

假设按“1 秒内显示”的要求执行测试，实际测得 1.6 秒，结果失败。

测试人员记录问题，并关联缺陷。开发人员可以从失败记录进入测试用例，再找到 BBB-214，确认：这项测试验证什么要求？当前判定条件是什么？对应哪一版需求？

项目经理也能进一步了解：这次失败影响的是哪项需求，是否关系到当前交付范围？

对比两种描述：

与：

后者更容易让各角色围绕同一个问题开展工作。

PART 05

交付前，沿着关系检查证据

到了交付阶段，团队需要回答：“这项需求凭什么说已经满足？”

此时，可以从需求出发，检查对应测试用例、执行记录、缺陷处理情况，以及修复后的验证结果。

这条记录链帮助团队区分：哪些是历史结论，哪些能够支持当前交付。

检查时仍需确认需求版本、测试依据和软件构建相互对应。一条链接本身，不能替代这些判断。

回头看这个案例，需求追溯帮助团队完成了几件具体的事：

这些能力建立在日常维护的关联关系之上。关系类型要明确，链接要准确，变更之后也要重新检查。