📚 课程目录第4章多学科模型协同的需求工程

4. 多学科模型协同的需求工程

在多学科协同开发中，需求不是一份静态文档，而是贯穿机械、电气、控制、软件、热流等各学科模型的“共同契约”。需求工程要解决的核心问题是：把利益相关方的期望转化为可验证的需求条目，并让每一条需求都能找到对应的设计模型、仿真模型或测试用例，同时在需求变更时快速判断影响范围。本节围绕需求建模、需求追溯、需求与多学科模型的关联，以及需求变更对协同模型的影响分析展开。

需求建模：从自然语言到可追溯条目

需求建模的第一步是结构化。以某电动助力转向系统（EPS）为例，原始需求可能是“车辆低速时转向应轻便，高速时转向应沉稳”。这句话无法直接验证，需要拆解为带参数的需求条目。常用做法是采用需求模板：主体 + 动作 + 对象 + 约束条件 + 指标。例如：

REQ-EPS-001：在车速 0～30 km/h 区间，方向盘力矩应小于 3.5 N·m（示例目标值）。
REQ-EPS-002：在车速 80～120 km/h 区间，方向盘力矩应大于 6.0 N·m（示例目标值）。
REQ-EPS-003：助力电机响应延迟应小于 20 ms（示例目标值）。

每条需求应具备唯一标识、版本、状态（草稿/评审/基线/变更）、来源、验证方法和优先级。需求建模工具（如 DOORS、Polarion、Jama 或开源方案）通常以属性字段承载这些信息。需求之间还存在分解、派生、依赖、冲突等关系，例如 REQ-EPS-001 可分解为“传感器采集需求”“控制算法需求”“电机执行需求”，形成需求层级树。

需求追溯：建立双向链路

需求追溯的本质是建立“上游—需求—下游”的双向可追踪关系。上游是利益相关方需求或法规标准，下游是设计模型、仿真模型、测试用例和验证结果。追溯矩阵是常见载体，但更重要的是追溯链路要能回答两个问题：这条需求被哪些模型实现？这个模型为什么存在？

在协同工程中，追溯关系通常跨越工具边界。例如机械团队在 CATIA 中建立转向柱三维模型，控制团队在 Simulink 中建立助力控制模型，软件团队在 Git 中管理 ECU 应用层代码。需求管理工具通过链接字段或 OSLC（Open Services for Lifecycle Collaboration）接口与这些工具建立关联。追溯粒度建议至少到“需求—模型元素”级别，而不是只到“需求—文件”级别，否则变更影响分析会过于粗糙。

需求与多学科模型的关联

需求与模型的关联方式决定了协同效率。常见关联类型包括：

实现关联：需求由某个模型元素实现，如 REQ-EPS-003 由 Simulink 中的“电机电流环”模块实现。
验证关联：需求由某个测试用例或仿真场景验证，如 REQ-EPS-001 由“低速转向台架试验 TC-012”验证。
参数关联：需求指标直接绑定模型参数，如力矩阈值绑定到控制模型中的查表参数。
约束关联：需求作为设计约束输入到多学科优化模型，如质量、功耗、成本约束。

关联建立后，需求管理工具中的需求条目与各学科模型元素形成一张有向图。这张图是后续变更影响分析的基础。实际项目中，建议为每条需求维护“关联覆盖率”指标，即已建立实现和验证关联的需求比例，作为需求工程成熟度的检查项。

需求变更对协同模型的影响分析

需求变更不可避免。假设 REQ-EPS-003 的响应延迟指标从 20 ms 收紧到 10 ms，影响分析应按以下路径展开：

沿追溯链路找到所有实现该需求的模型元素：控制模型中的电流环、电机选型参数、传感器采样周期。
判断各学科模型是否受影响：控制模型需重新整定 PID 参数；电机模型需检查峰值扭矩响应；软件模型需检查任务调度周期。
评估跨学科接口：若采样周期从 5 ms 改为 2 ms，CAN 通信负载和 ECU 计算负载是否超限。
识别验证用例：TC-012 的通过判据需同步更新，并补充高速工况回归测试。
输出变更影响清单，标注受影响的需求、模型、接口、测试和负责人。

为提升分析效率，可在需求管理工具中配置影响分析视图，按“需求—模型—接口—测试”四层展开。变更评审时，重点检查是否存在“需求已改、模型未改”或“模型已改、测试未改”的断链。建议将变更影响分析结果纳入基线，确保各学科团队基于同一版本协同。

实践提示：需求追溯链路应在项目早期建立，而不是等到变更发生后再补。追溯覆盖率低于 80% 时，变更影响分析往往只能依赖人工经验，容易遗漏跨学科接口。

上图展示了从利益相关方需求到多学科模型的追溯链路，以及变更请求 CR-017 沿追溯关系传播的影响路径。红色虚线表示变更影响传播方向，底部清单汇总了受影响的需求、模型、测试和接口。实际项目中，这张图可由需求管理工具自动生成，但前提是追溯关系已经建立并保持更新。

落地建议

要让需求工程真正支撑多学科协同，建议在项目启动阶段就明确三件事：需求条目的属性模板和唯一标识规则；追溯关系的类型和粒度标准；变更影响分析的触发条件和评审流程。工具层面，优先选择支持 OSLC 或开放 API 的需求管理平台，便于与 CATIA、Simulink、Git 等学科工具建立链接。流程层面，每次需求基线发布时同步检查追溯覆盖率，把“需求—模型—测试”断链作为评审阻塞项。这样，当需求变更发生时，团队才能快速定位影响范围，避免各学科模型各自为战。