4. 从需求到设计的形式化转换

在数字线程中，需求模型与设计模型之间如果只靠文档和人工传递，就会出现“需求改了设计不知道、设计改了需求对不上”的断裂。基于模型的系统工程（MBSE）要解决的核心问题，就是让需求模型中的每一条需求、每一个参数、每一个接口约束，都能以形式化方式自动映射到设计模型与接口定义中，使这条转换链可追溯、可校验、可重复执行。

一、形式化转换的本质：从自然语言到可计算约束

需求通常以自然语言描述，例如“制动控制器在收到制动请求后 50ms 内输出制动指令”。这句话对人可读，但机器无法直接判断设计是否满足。形式化转换的第一步，是把需求拆解为可计算的约束三元组：对象、属性、约束关系。上例可形式化为：对象=制动控制器，属性=响应时间，约束=≤50ms，触发条件=收到制动请求。

在 SysML 中，这类约束通常用参数图（Parametric Diagram）表达，配合约束块（Constraint Block）定义数学关系。需求模型中的每个约束参数，都对应设计模型中的一个值属性（Value Property）。当设计模型中的实际参数被赋值后，约束引擎即可自动判定满足与否。

二、映射规则的设计：三类典型转换

需求到设计的自动映射并非一条万能规则，而是按需求类型分派不同转换策略。实践中通常分为三类：

• 结构映射：功能需求映射为设计模型中的模块、组件或活动。例如“系统应具备制动控制功能”映射为 BrakeController 模块及其 BrakeControl 活动。
• 参数映射：性能需求映射为值属性与约束。例如“响应时间≤50ms”映射为 BrakeController.responseTime 值属性，并绑定约束块 ResponseTimeConstraint。
• 接口映射：接口需求映射为端口、流属性与接口块。例如“制动请求通过 CAN 总线传输”映射为 CanPort 端口及 BrakeRequestSignal 流属性。

这三类映射在模型工具中通过映射规则表或转换脚本实现。规则表定义“需求类型→设计元素类型→属性绑定方式”，转换脚本则遍历需求模型，按规则生成或更新设计模型元素。

三、接口定义的自动生成

接口是需求到设计转换中最容易出错的部分，因为接口涉及方向、数据类型、单位、时序等多重约束。形式化转换要求接口需求必须包含足够的信息量。以“制动请求信号从整车控制器发送至制动控制器，周期 10ms，数据长度 8 字节”为例，可提取出：

当这些信息在需求模型中结构化存储后，转换脚本可自动生成接口块（Interface Block）及端口连接，并检查源与目标的数据类型、方向是否匹配。若需求中缺少周期或数据长度，转换应报错并标记该需求为“信息不完整”，而不是静默生成一个不完整的接口。

四、转换链的可追溯性与校验闭环

自动映射完成后，必须建立双向追溯：从需求可查到对应的设计元素，从设计元素也可反查其来源需求。在模型工具中，这通过满足关系（Satisfy）和追溯关系（Trace）实现。每次需求变更后，转换脚本重新执行，更新设计模型并标记受影响的设计元素。

校验闭环包含三个检查点：

1. 覆盖性检查：是否存在未被任何设计元素满足的需求？
2. 一致性检查：设计模型中的参数值是否满足需求约束？
3. 接口完整性检查：接口的源、目标、数据类型、周期是否全部定义且匹配？

以下 SVG 展示了从需求模型到设计模型与接口定义的完整转换链，包括三类映射路径、转换引擎以及校验闭环。

五、实践中的关键参数与判断依据

在真实项目中，转换脚本需要处理需求条目的状态。每条需求通常带有 status 字段，取值包括 draft、approved、implemented、verified。只有 approved 状态的需求才参与自动映射，draft 状态的需求仅生成占位设计元素并标记为待确认。

转换脚本执行后，应输出一份转换报告，包含：成功映射的需求数量、失败或信息不完整的需求列表、新生成的设计元素、被更新的设计元素、以及校验未通过的约束项。以下是一个转换报告示例结构：

转换报告
─────────────────────────────
需求总数: 48
成功映射: 42
信息不完整: 4  (缺少周期/数据类型)
未映射: 2      (无对应设计元素)
─────────────────────────────
新增设计元素: 12
更新设计元素: 8
校验通过: 40
校验失败: 2    (responseTime=62ms > 50ms)
─────────────────────────────
建议: 补充 REQ-017 的周期字段；
      检查 BrakeController.responseTime 赋值。

判断转换是否成功的依据不是“脚本跑完了”，而是三个条件同时成立：所有 approved 需求都有对应的设计元素；所有参数约束校验通过；所有接口的源、目标、数据类型、周期完整且匹配。任一条件不满足，转换链就存在断裂，必须回到需求模型或设计模型修正后重新执行。

从需求到设计的形式化转换，本质上是把“人读的需求”翻译成“机器可校验的约束”，再通过映射规则和转换引擎自动生成设计元素与接口定义。这条链路的每个环节都必须保留追溯关系，并在每次变更后重新执行校验闭环，才能真正支撑数字线程中需求、设计、测试之间的无缝衔接。