4、需求追溯（REQ）：从客户需求到系统需求的追溯方法与实践

4.1 为什么需求追溯这么重要？

说实话，我刚入行那会儿，觉得需求追溯就是个形式主义。客户说要个自动泊车功能，我直接开干不就完了？结果呢？项目做到一半，客户说「我要的是能识别地锁的泊车」，而我们做的是「识别划线车位的泊车」。嗯，这就是典型的追溯断裂。

需求追溯，说白了就是建立一条「客户说了什么」到「我们做了什么」的完整链路。你想想看，没有这条链，你怎么证明你的系统需求确实覆盖了客户的所有期望？ASPICE 的 REQ 过程域，核心就是干这件事。

4.2 追溯矩阵长什么样？

我习惯用表格来管理追溯关系。别小看这个表格，它可是整个项目的「交通地图」。下面是我常用的模板：

客户需求ID	客户需求描述	系统需求ID	系统需求描述	追溯类型	验证状态
CR-001	车辆在倒车时，系统应自动检测后方障碍物	SR-001	倒车雷达系统应在R档激活后200ms内启动	直接覆盖	已评审
CR-001	车辆在倒车时，系统应自动检测后方障碍物	SR-002	倒车雷达检测距离应覆盖0.3m至2.5m范围	分解细化	已评审
CR-002	障碍物报警声音应随距离变化	SR-003	报警蜂鸣器频率应在0.5Hz至4Hz之间线性变化	直接覆盖	待验证

你看，一个客户需求可能对应多个系统需求。CR-001 被拆成了 SR-001 和 SR-002，一个管启动时间，一个管检测范围。这就是「分解细化」的典型场景。

4.3 追溯的三种常见模式

我在项目里总结出三种追溯模式，分享给你：

• 直接覆盖：客户需求可以直接翻译成系统需求。比如客户说「报警声音要响」，系统需求就是「蜂鸣器声压级≥85dB」。这种最简单，但别大意，我见过有人把「响」理解成「持续响」，结果客户要的是「间歇响」。
• 分解细化：一个客户需求需要拆成多个技术需求。比如「自动泊车要安全」，你得拆成「车速≤5km/h」「障碍物距离≥0.2m」「转向角度误差≤3°」等等。这种最容易漏项，我建议你每拆一个，就反问自己一句：「这个子需求不满足，客户的需求还能实现吗？」
• 派生需求：客户没明说，但系统必须有的需求。比如客户说「要能远程启动」，你自然要推导出「车辆必须处于P档」「发动机盖必须关闭」「钥匙必须在有效范围内」。这些派生需求也要追溯，但追溯类型要标注清楚。

4.4 实操：如何建立追溯？

别一上来就填表格。我建议按这个步骤来：

1. 第一步：梳理客户需求清单。把客户给的每一条需求都编号。别管它写得多模糊，先编号再说。我曾经遇到客户写「操作要方便」，这种需求也得编号，后面再细化。
2. 第二步：逐条分析客户需求。问自己三个问题：这条需求对应什么功能？有什么性能指标？有什么约束条件？把答案记下来，这就是系统需求的雏形。
3. 第三步：建立系统需求。用标准格式写系统需求。我习惯用「主语+条件+动作+指标」的句式。比如「当车辆处于R档时，倒车雷达系统应在200ms内完成自检并输出障碍物信息」。
4. 第四步：填写追溯矩阵。把客户需求ID和系统需求ID对应起来。注意，一个系统需求可能对应多个客户需求，这种情况也要写清楚。
5. 第五步：评审和确认。拉上客户、系统工程师、测试工程师一起过一遍。我吃过一次亏：自己觉得追溯得很完美，结果测试工程师说「你这个系统需求没法测」，只好返工。

4.5 避坑指南

4.6 工具和自动化

说实话，用 Excel 管理追溯矩阵，项目小还行，项目大了就是灾难。我建议至少用需求管理工具，比如 DOORS、Polarion 或者 Jama。这些工具能自动生成追溯图，还能做影响分析——就是当你改了一个客户需求，系统会自动告诉你哪些系统需求、哪些测试用例会受影响。

如果你团队预算有限，也可以用开源工具，比如 ReqView 或者用 Git 配合 Markdown 文件管理。但不管用什么工具，核心还是那四个字：双向追溯。