📚 课程目录第3章需求工程与数字线程起点

3. 需求工程与数字线程起点

数字线程的起点不是模型，也不是仿真，而是需求。如果需求本身以自然语言散落在文档、邮件和会议纪要里，后续的设计参数、测试用例和验证结果就无法与需求建立稳定的数字关联，数字线程会在源头断裂。本节要解决的核心问题是：如何把模糊的期望捕获为可标识的需求项，用结构化方式表达，并通过需求追溯矩阵（RTM）把需求与设计、仿真、测试环节连接起来。

需求捕获：从期望到可标识的需求项

需求捕获的目标不是“写文档”，而是把利益相关方的期望转化为一条条可编号、可追溯、可验证的需求项。实际工作中，捕获来源通常包括客户规格书、访谈记录、法规条款、既有系统缺陷报告和运行场景描述。捕获时最容易犯的错误是把多个需求混在一句话里，例如“系统应在-20℃~55℃下连续工作8小时且功耗低于15W”，这实际上包含环境适应性、续航和功耗三个可独立验证的需求。

一个可操作的做法是采用“需求条目化”原则：每条需求只表达一个可验证的意图，并赋予唯一标识。例如：

REQ-ENV-001：系统应在 -20℃ ~ 55℃ 环境温度范围内正常启动并连续工作。
REQ-PWR-001：系统在常温满载工况下整机功耗应 ≤ 15W。
REQ-PWR-002：系统在 25℃、50% 负载工况下连续工作时间应 ≥ 8h。
REQ-IF-001：系统应通过 CAN 2.0B 接口以 500kbps 波特率上报状态帧，周期 100ms。

标识规则建议包含“类别-序号”，如 ENV 表示环境类、PWR 表示功耗类、IF 表示接口类。这样在后续追溯时，可以按类别快速筛选，也便于发现某类需求是否缺失。

结构化表达：让需求可计算、可检查

自然语言需求难以自动检查一致性，因此需要结构化表达。常用的结构是“主体 + 条件 + 动作 + 对象 + 约束 + 验证方式”。以 REQ-PWR-002 为例：主体是系统，条件是 25℃、50% 负载，动作是连续工作，对象是整机，约束是 ≥8h，验证方式是台架放电测试。把这条需求写成结构化字段后，后续可以自动生成测试用例的初始框架。

在工程实践中，结构化表达通常落到需求管理工具的属性字段中，例如：需求 ID、需求描述、需求类型（功能/性能/接口/安全）、优先级、来源、验证方法（测试/分析/检查/演示）、状态（草稿/评审中/已批准/已实现/已验证）。这些字段不是管理装饰，而是数字线程中传递语义的载体。例如“验证方法=测试”的需求，在后续环节必须关联至少一个测试用例；“验证方法=分析”的需求，则关联仿真模型或计算报告。

结构化表达的关键判断：如果一条需求无法回答“用什么方法验证”，说明它还没有被真正结构化，应退回补充验证方式后再进入追溯矩阵。

需求追溯矩阵：把需求与后续环节连起来

需求追溯矩阵（RTM）是数字线程在需求层的核心载体。它的行是需求项，列是后续环节的工件，交叉点表示关联关系。一个最小可用的 RTM 至少应覆盖四类关联：需求→设计参数、需求→仿真模型/工况、需求→测试用例、需求→验证结果。这样当某个设计参数变更时，可以沿矩阵反向找到受影响的需求；当某条需求变更时，可以正向找到需要重跑的仿真和测试。

下面给出一个示例 RTM 片段，需求与设计参数、仿真工况、测试用例建立关联：

需求 ID	需求摘要	设计参数	仿真工况	测试用例	验证方法
REQ-ENV-001	-20℃~55℃ 正常工作	散热面积、加热功率	SIM-THERM-01/02	TC-ENV-001	测试
REQ-PWR-001	满载功耗 ≤15W	主频、电源效率	SIM-PWR-01	TC-PWR-001	测试
REQ-PWR-002	50% 负载续航 ≥8h	电池容量、负载曲线	SIM-PWR-02	TC-PWR-002	测试
REQ-IF-001	CAN 500kbps/100ms 上报	CAN 控制器配置	SIM-BUS-01	TC-IF-001	测试

RTM 的价值在于“可查询”和“可影响分析”。例如当电池容量从 10Ah 调整为 8Ah 时，沿 REQ-PWR-002 行可以立即定位到 SIM-PWR-02 和 TC-PWR-002，判断是否需要重跑仿真和测试。如果某条需求在 RTM 中没有关联任何测试用例，说明它尚未被验证覆盖，属于追溯缺口。

建立需求与后续环节的数字关联

数字关联不是手工在表格里填几个编号，而是让需求 ID 成为贯穿全链路的“主键”。在需求管理工具中，每条需求有唯一 URI 或 GUID；在设计工具中，设计参数通过链接指向需求 ID；在仿真平台中，仿真工况记录其覆盖的需求 ID；在测试管理系统中，测试用例和测试结果同样携带需求 ID。这样，需求变更时可以通过工具链的链接关系自动生成影响清单。

实际操作中，建议先建立“需求-设计-仿真-测试”四层关联的最小闭环，再逐步扩展到变更管理和覆盖率统计。判断关联是否建立成功的标准很简单：任选一条需求，能否在 3 分钟内找到它对应的设计参数、仿真工况、测试用例和最近一次验证结果；任选一个测试用例，能否反向找到它覆盖的需求。如果两个方向都能走通，需求层的数字线程起点就算真正建立起来了。

上图展示了 RTM 的四层结构：需求层、设计层、仿真层、测试层。正向箭头表示需求被设计参数、仿真工况和测试用例覆盖；底部红色虚线表示反向影响分析路径。当电池容量从 10Ah 调整为 8Ah 时，沿 REQ-PWR-002 可以定位到 SIM-PWR-02 和 TC-PWR-002，从而判断是否需要重跑仿真和测试。如果某条需求在测试层没有对应节点，就形成追溯缺口，需要在评审中标记并补齐。

常见误区：把 RTM 做成“一次性表格”，评审后不再维护。数字线程要求关联关系随需求变更同步更新，否则追溯矩阵会迅速失效，后续仿真和测试将基于过期需求执行。

总结来说，需求工程作为数字线程起点，需要完成三件事：第一，用条目化和唯一 ID 把期望捕获为可验证需求；第二，用结构化字段表达条件、约束和验证方法；第三，用 RTM 建立需求到设计、仿真、测试的双向关联。做到这三点，后续环节才能沿需求 ID 形成可追溯、可影响分析的数字链路。