2. 需求建模核心语法

需求图是 SysML 中专门用于表达“系统应当满足什么”的图型。它不描述系统内部如何实现，而是把需求本身当作可建模的元素，让需求拥有标识、文本、属性，并能与其它模型元素建立可追溯的关系。理解需求图的关键，是把它看成一张“需求及其追溯网络”，而不是一张功能结构图。

需求元素：标识、文本与属性

在需求图中，一个需求用矩形框表示，框内通常包含三部分信息：需求标识（id）、需求文本（text）以及需求属性（properties）。需求标识是需求的唯一名字，例如 REQ-001；需求文本是自然语言描述，例如“当车速超过 30 km/h 时，系统应在 200 ms 内发出碰撞预警”；需求属性则用于补充管理或验证信息，常见的有 Id、Text、Source、Risk、VerifyMethod、Status 等。

需求文本应遵循“单一、可验证、无歧义”的原则。例如“系统应快速响应”无法验证，而“系统应在收到制动信号后 100 ms 内输出制动指令”则具备可测性。需求属性中的 VerifyMethod 可取值 Test、Analysis、Inspection、Demonstration，它决定了后续验证活动的方式。

四类核心关系：包含、派生、满足、验证

需求图的价值在于关系。SysML 需求图定义了多种关系，其中最核心的是包含（containment）、派生（derive）、满足（satisfy）和验证（verify）。

• 包含关系：用带十字圆圈的虚线表示，表示一个复合需求由若干子需求组成。例如“整车安全需求”可包含“前向碰撞预警需求”和“自动紧急制动需求”。
• 派生关系：用带 «deriveReqt» 的虚线箭头表示，表示子需求由父需求推导而来。派生强调逻辑来源，例如从“系统应避免碰撞”派生出“系统应检测前方障碍物距离”。
• 满足关系：用带 «satisfy» 的虚线箭头表示，由设计元素指向需求，表示某个模块、组件或行为满足了该需求。例如“雷达感知模块”满足“检测前方障碍物距离”需求。
• 验证关系：用带 «verify» 的虚线箭头表示，由测试用例或验证活动指向需求，表示该活动验证了该需求。例如“AEB 实车测试用例”验证“自动紧急制动需求”。

这四类关系构成了需求追溯的主干：包含与派生建立需求之间的层级和推导，满足把需求连接到设计，验证把需求连接到测试。缺少任何一环，需求都难以闭环。

需求属性与需求表格

当需求数量增多时，逐个查看图形框会变得低效。SysML 允许把需求属性以表格形式呈现，即需求表格（Requirement Table）。表格的列通常包括 Id、Text、Source、VerifyMethod、Status、SatisfiedBy、VerifiedBy 等。表格与图形是同一模型数据的两种视图：在表格中修改属性，图形中的需求框会同步更新；在图形中建立关系，表格中的追溯列也会自动填充。

下面给出一个可直接参考的需求表格示例，字段和取值均属于教学示例，实际项目应按组织规范调整。

建模时的常见判断

建立需求图时，有几个容易混淆的判断点。第一，包含与派生的区别：包含强调“整体—部分”的分解，派生强调“逻辑推导”。如果子需求是父需求的一部分，用包含；如果子需求是从父需求推导出的新约束，用派生。第二，满足与验证的区别：满足连接的是设计元素，回答“谁实现了它”；验证连接的是测试活动，回答“谁证明了它”。第三，需求文本不要写成设计说明。需求应说明“需要什么”，而不是“怎么做”；一旦写入具体实现方案，就会限制设计空间，也会让满足关系变得难以判断。

掌握需求图的构造、标识与文本、四类关系以及属性表格之后，就可以把分散在文档中的需求转化为可追溯、可验证、可管理的模型元素。这是后续把需求连接到系统架构与验证活动的基础。