2. 需求建模语言与工具基础
在 MBSE 中，需求不是一段孤立的文字，而是模型中的一个可被引用、可被追踪、可被验证的元素。要做到这一点，必须依赖建模语言提供的“需求表达载体”和工具提供的“需求管理机制”。本节聚焦 SysML 中与需求表达最直接相关的三类图——需求图、用例图、块定义图，并对比 Rhapsody、MagicDraw、Capella 三款主流工具在需求管理上的能力差异。
一、三类图在需求表达中的分工
SysML 需求图（Requirement Diagram）是唯一以「需求」为一等公民的图。它用 «requirement» 构造型表示一条需求，需求可以带 id、text 两个核心属性，并通过 «containment» 形成需求层级（父需求—子需求），通过 «deriveReqt» 表示派生关系，通过 «satisfy» 表示设计元素满足需求，通过 «verify» 表示测试用例验证需求。需求图的价值在于：它把“需求—设计—验证”三类元素放进同一张可追踪的网里，而不是散落在文档和表格中。
用例图（Use Case Diagram）回答的是“系统为谁提供什么价值”。它用参与者（Actor）、用例（Use Case）、系统边界（Subject）描述外部视角的功能需求。用例图本身不写详细需求文本，但它为需求提供了上下文：一个用例往往对应一组功能需求，用例的 «include»、«extend» 关系还能帮助识别需求的层次与可选分支。
块定义图（Block Definition Diagram，BDD）回答的是“系统由哪些结构组成”。它用块（Block）、组合（Composition）、泛化（Generalization）、关联（Association）描述系统的静态结构。BDD 与需求的关系体现在：块是 «satisfy» 关系最常指向的目标——一条“最大起飞重量不超过 25 kg”的需求，最终要由某个具体的块来满足。因此 BDD 是需求落地到设计的“承接面”。
三者的协作关系可以概括为：用例图界定范围，需求图组织需求并建立追踪，块定义图提供被追踪的设计对象。缺少任何一环，需求追踪都会断裂。
二、需求图的关键关系与建模约定
在需求图中，最容易被误用的是 «deriveReqt» 与 «containment»。containment 表示“这条需求是那条需求的组成部分”，例如“续航 ≥ 4h”下面挂“电池容量 ≥ 800Wh”和“整机功耗 ≤ 200W”，二者是并列的子需求，缺一不可。deriveReqt 则表示“子需求是从父需求推导出来的”，推导过程往往伴随设计决策，例如从“续航 ≥ 4h”和“整机功耗 ≤ 200W”推导出“电池容量 ≥ 800Wh”，这里包含了能量守恒的计算：800Wh ÷ 200W = 4h。建模时应把推导依据写进需求的 text 或注释中，否则追踪链只有形式没有内容。
«satisfy» 由设计元素指向需求，方向不能反。«verify» 由验证用例指向需求，表示“这个测试用来验证这条需求”。一个常见错误是把 verify 画成需求指向测试，导致追踪方向混乱。建议在项目建模规范中明确：所有追踪关系一律“从具体指向抽象”，即从设计/验证指向需求。
三、主流工具的需求管理能力对比
三款工具都能表达 SysML 需求图，但需求管理的重心不同。下表从需求条目管理、追踪矩阵、变更影响分析、与仿真/验证的衔接四个维度进行对比，供选型参考。
| 能力维度 | IBM Rhapsody | MagicDraw / Cameo | Capella (Arcadia) |
|---|---|---|---|
| 需求条目管理 | 支持 «requirement»，可与外部需求库同步 | 原生需求模型完善，支持需求表、需求树 | 需求作为 Arcadia 模型的一部分，强调与架构对齐 |
| 追踪矩阵 | 支持，需配置；矩阵视图较基础 | 内置 Dependency Matrix，可自定义行列元素类型 | 通过 Arcadia 层级自动建立追踪，矩阵以“层间对齐”呈现 |
| 变更影响分析 | 可结合状态机与仿真分析行为影响 | 影响分析视图成熟，可跨模型查询 | 强调架构层间影响，适合系统级变更 |
| 与验证衔接 | 与测试用例、仿真执行结合紧密 | 可对接测试管理工具，支持验证用例建模 | 通过 Arcadia 验证活动与功能链关联 |
选型建议：若项目以嵌入式实时系统为主、需要早期行为仿真验证需求，Rhapsody 的状态机与仿真能力更贴合；若项目需求条目多、追踪矩阵和影响分析是日常高频操作，MagicDraw 的矩阵与查询能力更高效；若项目强调从需求到架构再到验证的完整方法流程，Capella 的 Arcadia 方法能提供更强的流程约束，但需要团队接受其方法论。
四、从建模到追踪的最小实践
以一个无人机续航需求为例，最小实践路径如下：在用例图中建立“执行任务”用例，识别出“续航”这一质量属性；在需求图中建立 REQ-001“续航 ≥ 4h”，并派生 REQ-002“电池容量 ≥ 800Wh”；在块定义图中建立“动力电池组”块，用 satisfy 关系指向 REQ-002；最后建立验证用例“续航测试”，用 verify 关系指向 REQ-001。此时在工具的追踪矩阵中，应能看到 REQ-001 同时被“续航测试”验证、被“执行任务”用例上下文覆盖，REQ-002 被“动力电池组”满足。若矩阵中出现空白行或空白列，即说明存在未追踪需求或未承接需求的设计元素，需要回到模型中补齐。