📚 课程目录第3章需求图实战

3. 需求图实战

需求图（Requirement Diagram）是 SysML 中专门用于表达“需求本身”以及“需求与其它模型元素之间关系”的图型。它不描述系统如何工作，而是回答三个问题：系统必须满足什么、这些要求从哪里来、以及我们凭什么说它被满足了。在机电系统项目中，需求往往散落在客户规格书、行业标准、内部设计约束和测试大纲里，需求图的价值就是把这些文字条目变成可追溯、可验证、可分解的模型元素。

一、需求图的三类核心关系

SysML 需求图定义了三种标准关系，理解它们是建模的前提：

包含（containment）：用带十字圆圈的虚线箭头表示，从父需求指向子需求，表达“父需求由这些子需求共同满足”。这是需求层次分解的骨架。
派生（derive）：用带 «deriveReqt» 的虚线箭头表示，从派生需求指向源需求，说明“这条需求是从上游需求推导出来的”。它强调来源，而非分解。
满足（satisfy）：用带 «satisfy» 的虚线箭头表示，从设计元素（如模块、部件、接口）指向需求，说明“该设计元素实现了这条需求”。

此外还有 验证（verify） 关系，用带 «verify» 的虚线箭头从测试用例指向需求，说明“该测试用例验证了这条需求”。在工程实践中，满足关系回答“谁实现”，验证关系回答“谁证明”，两者缺一不可。

二、从规格书到需求层次分解

假设我们正在建模一台“电动升降平台”，客户规格书中有一条顶层需求：“平台应在 30 秒内将 200 kg 负载从地面提升至 1.5 m 高度，并保持位置误差不超过 ±5 mm。”

这条需求不能直接分配给某个零件，必须先分解。合理的分解路径是：

顶层需求 REQ-001：整机提升性能要求（30 s、200 kg、1.5 m、±5 mm）。
派生需求 REQ-010：驱动系统需提供不小于 3 kN 的额定推力（由 200 kg 负载与安全系数 1.5 估算）。
派生需求 REQ-011：传动机构需具备自锁能力，防止断电下滑。
派生需求 REQ-012：控制系统需实现位置闭环，采样周期不大于 10 ms。
派生需求 REQ-013：结构件在 1.5 m 行程末端需承受 1.2 倍额定负载的冲击。

这里要注意：REQ-010 到 REQ-013 与 REQ-001 之间是 派生关系，而不是包含关系。包含关系用于“父需求拆成若干子需求后，子需求合起来等价于父需求”的场景，例如把 REQ-001 拆成“提升时间需求”“负载能力需求”“定位精度需求”三条并列子需求。派生关系则用于“由上层需求推导出新的、更具体的约束”。实际建模中，两种关系经常混合使用，关键是语义要清晰。

三、需求追溯：向上与向下

需求追溯分为两个方向。向上追溯回答“这条需求为什么存在”，通常指向客户规格、法规标准或上层派生源；向下追溯回答“这条需求由什么实现、由什么验证”，指向设计元素和测试用例。

在需求图中，向上追溯用 «deriveReqt» 表达，向下追溯用 «satisfy» 和 «verify» 表达。一个健康的机电系统需求模型，应当满足：每条底层需求至少有一条向上派生路径，每条顶层需求至少有一条向下满足路径和一条向下验证路径。如果某条需求既没有来源也没有实现，它很可能是“孤儿需求”；如果某条需求没有验证关系，它就无法在验收阶段被证明。

四、需求验证关系的建模

验证关系把测试用例与需求绑定。以 REQ-012（位置闭环，采样周期 ≤ 10 ms）为例，可以建立测试用例 TC-012：

测试用例 TC-012：位置闭环采样周期验证
前置条件：控制器上电，闭环使能，负载 200 kg
操作步骤：
  1. 在控制器中注入阶跃位置指令 0 → 1.5 m
  2. 用示波器抓取控制周期信号与编码器采样信号
  3. 记录连续 100 个采样周期的实际间隔
判定依据：
  最大采样间隔 ≤ 10 ms，且位置稳态误差 ≤ ±5 mm
结果记录：最大间隔 8.7 ms，稳态误差 +2.1 mm → 通过

在需求图中，TC-012 通过 «verify» 箭头指向 REQ-012。如果同一测试用例同时验证多条需求，可以画多条验证箭头；如果一条需求需要多个测试用例覆盖，也应全部画出。验证关系不是“测试计划”，而是模型层面的可追溯链接，它让需求覆盖率可以被自动统计。

建议在需求属性中补充 id、text、risk、verificationMethod 四个字段。verificationMethod 可取值：inspection（检查）、analysis（分析）、demonstration（演示）、test（测试）。这四类方法直接决定验证关系的类型和测试用例的设计方式。

五、需求图与其它图的协同

需求图本身不描述结构或行为，它通过 «satisfy» 与块定义图（BDD）中的模块相连，通过 «verify» 与用例图或测试模型相连。因此，需求图通常作为“追溯中枢”存在：左侧是需求层次，右侧是设计元素和测试用例，中间用关系箭头打通。在电动升降平台案例中，REQ-010 由「驱动模块」满足，REQ-011 由「丝杠传动模块」满足，REQ-012 由「控制器模块」满足，REQ-013 由「结构框架模块」满足。这样，当某个模块设计变更时，可以沿满足关系反向查出受影响的需求，评估变更影响范围。

六、建模检查要点

完成需求图后，建议按以下要点自查：

每条需求是否有唯一的 id 和明确的 text，避免“性能良好”这类不可验证的表述。
顶层需求是否至少有一条包含或派生路径向下展开，避免需求悬空。
每条底层需求是否至少有一条 «satisfy» 指向具体设计元素，避免“无人实现”。
每条需求是否至少有一条 «verify» 指向测试用例，且验证方法（检查/分析/演示/测试）已明确。
派生关系是否指向正确的源需求，避免循环派生或来源缺失。

需求图不是一次性画完的文档，而是随设计迭代持续维护的追溯网络。当驱动模块推力从 3 kN 调整为 3.5 kN 时，应沿 «satisfy» 反向检查 REQ-010 是否仍然成立，并确认 REQ-001 的 30 s 提升时间是否受影响。这种“变更—追溯—再验证”的闭环，才是需求图在机电系统建模中真正的工程价值。