需求图入门：需求图元素与建模规则
需求图（Requirements Diagram，简称 ReqD）是 SysML 中专门用于捕获、组织和追踪需求的建模工具。在汽车电子系统开发中，需求往往来自多个利益相关方——整车性能目标、法规安全要求、客户功能期望、平台复用约束等，它们之间存在着复杂的派生、满足、验证和细化关系。需求图的核心价值在于：将散落在文档、表格和邮件中的需求文本，转化为结构化的模型元素，并通过显式的关系连线，建立起需求与需求、需求与设计、需求与测试之间的可追溯链条。本章将围绕需求图的五大核心元素（需求、派生关系、满足关系、验证关系、细化关系）展开，并结合汽车域控制器开发的实际场景，讲解建模规则与最佳实践。
上图展示了需求图中五类核心元素的关系语义。在汽车项目中，需求图通常以“需求”节点为中心，向外辐射出派生、细化、满足和验证四条关系链路。下面我们将逐一拆解这些元素的建模要点。
4.1 需求元素：从文本到模型的结构化转换
核心原理：需求元素是需求图的基本单元，它不仅仅是文本的容器，更是一个带有唯一标识（ID）、文本描述、优先级、来源、状态等属性的模型对象。在 SysML 中，需求使用 «requirement» 构造型表示，可以包含 id、text、priority、status 等标签值。汽车行业实践中，需求 ID 通常遵循组织定义的编码规则，例如 REQ-BMS-001 表示电池管理系统第 1 条需求。
判断方法：判断一个文本是否适合建模为需求元素，需要满足三个条件：① 可验证性——需求必须能够通过测试、检查或分析来确认是否被满足；② 原子性——需求不可再拆分，一条需求只表达一个意图；③ 可追踪性——需求能够关联到上游来源（如法规条款）和下游实现（如设计组件）。例如“系统应具有良好的安全性”是不可验证的，应改写为“当车辆发生正面碰撞时，安全气囊应在碰撞发生后 50ms 内完成展开”。
| 属性 | 说明 | 汽车示例 |
|---|---|---|
| ID | 全局唯一标识 | REQ-ADAS-012 |
| Text | 需求正文（可验证） | ACC 系统在车速 30-150 km/h 范围内应保持设定车距 |
| Priority | 优先级（高/中/低） | 高（涉及功能安全） |
| Status | 生命周期状态 | 已评审 / 已实现 / 已验证 |
| Source | 需求来源 | ISO 26262 / 客户规格书 / 内部平台需求 |
REQ-BMS-001 中的 BMS 表示电池管理系统。这样在大型模型中，仅通过 ID 就能快速定位需求所属的子系统，避免跨模块检索的困扰。4.2 派生关系：需求分解与分配
核心原理：派生关系（«deriveReqt»）表示一个需求从另一个需求推导而来，通常用于将高层级需求分解为更具体、更细粒度的子需求。在汽车 V 模型开发中，整车级需求（如“车辆应满足 Euro NCAP 五星碰撞标准”）会派生出系统级需求（如“车身结构应吸收 60% 的碰撞能量”），再进一步派生出组件级需求（如“B 柱采用 1500MPa 热成型钢”）。派生关系是单向的，从父需求指向子需求。
操作流程：建立派生关系时，建议遵循以下步骤：① 识别父需求中的关键性能指标或功能约束；② 将父需求拆解为多个可独立验证的子需求；③ 检查子需求是否覆盖父需求的所有语义；④ 在建模工具中创建派生连线，并附加“派生理由”注释。例如，父需求“车辆碰撞后应保证乘员生存空间”可派生出“车门在碰撞后应能正常开启”和“座椅在碰撞中不应发生位移”两条子需求。
4.3 满足关系：连接需求与设计
核心原理：满足关系（«satisfy»）将需求与设计元素（如模块、组件、用例、活动）关联起来，表示该设计元素实现了对应的需求。满足关系是需求追溯链中承上启下的关键环节——它回答了“这个需求由谁来实现”的问题。在汽车电子领域，一条需求可能由多个软硬件组件共同满足，例如“自动紧急制动功能”需要传感器、控制器、执行器协同工作。
判断方法：判断一个设计元素是否满足某条需求，需要检查设计元素的行为或结构是否完整覆盖了需求的全部内容。如果设计元素只覆盖了部分需求，应使用“部分满足”标注，或者将需求进一步细化后再建立满足关系。例如，需求“ACC 系统应支持跟停-起步功能”需要同时满足“跟停”和“起步”两个子场景，如果控制器软件只实现了跟停，则不能建立完整的满足关系。
4.4 验证关系：需求与测试的闭环
核心原理：验证关系（«verify»）将需求与测试用例或验证活动关联，表示该测试用于确认需求是否被正确实现。验证关系是需求闭环管理的重要环节，它确保每条需求都有对应的验证手段。在汽车功能安全（ISO 26262）实践中，验证关系是安全案例（Safety Case）的重要组成部分，评审员会检查每条安全需求是否都有对应的验证证据。
操作流程：建立验证关系时，应遵循以下步骤：① 为每条需求确定验证方法（测试、检查、分析、评审）；② 创建对应的测试用例或验证活动元素；③ 建立验证关系并标注验证级别（单元级、集成级、系统级）；④ 在测试执行后，将结果回填到验证关系的状态属性中。例如，需求“电池在 -20°C 环境下应能正常启动”对应验证活动“低温冷启动测试”，测试结果应记录在验证关系的 result 属性中。
| 验证方法 | 适用场景 | 汽车案例 |
|---|---|---|
| Test（测试） | 可执行的功能/性能验证 | ADAS 紧急制动测试 |
| Inspection（检查） | 物理属性或静态特征 | 线束端子压接质量检查 |
| Analysis（分析） | 仿真或理论计算 | 碰撞仿真分析（CAE） |
| Review（评审） | 文档或流程符合性 | 功能安全概念评审 |
4.5 细化关系：需求精化与约束补充
核心原理：细化关系（«refine»）表示一个需求对另一个需求进行更精确的描述或补充约束。与派生关系不同，细化关系不改变需求的层级归属，而是对同一需求进行精化。例如，需求“车辆应具备碰撞后解锁功能”可被细化为“碰撞后 200ms 内应自动解锁所有车门”和“碰撞后解锁功能应在电源中断情况下仍可工作”。细化关系常用于补充技术参数、环境条件或性能指标。
判断方法：当一条需求包含多个可独立验证的约束条件时，应考虑使用细化关系。判断标准是：细化后的需求是否比原需求更具体、更可执行，且不引入新的需求意图。例如，“系统应具有良好的电磁兼容性”可细化为“系统在 30MHz-1GHz 频段内的辐射发射应满足 CISPR 25 Class 5 限值要求”。
4.6 需求图建模规则与最佳实践
核心原理：需求图建模不是简单地画连线，而是需要遵循一定的规则来保证模型的可维护性和可追溯性。在汽车行业，需求图通常与 DOORS、Jama 等需求管理工具协同使用，SysML 模型负责展示需求之间的关系结构，而需求管理工具负责维护需求文本的版本和变更历史。
建模规则清单：
- 单一来源原则：每条需求在模型中只出现一次，避免复制粘贴导致的不一致。
- 关系完整性：每条需求至少应有一条派生关系（从父需求来）或满足关系（到设计去），孤立需求应标记为“待处理”。
- 命名规范：需求名称应简洁且具有业务含义，避免使用“需求1”“需求2”等无意义命名。
- 属性完整：关键属性（ID、Text、Priority、Status）必须填写，辅助属性（Source、Rationale）建议填写。
- 层次控制：需求图的层级建议控制在 3-5 层，过深会导致模型难以维护，过浅则无法表达分解细节。
总结复盘：需求图是 SysML 中最贴近系统工程实践的视图之一。在汽车项目中，需求图的价值不仅在于可视化需求结构，更在于建立从“用户期望”到“设计实现”再到“测试验证”的完整追溯链。建议团队在项目启动阶段就建立需求图建模规范，明确元素命名、关系类型、属性填写要求，并在项目里程碑节点进行需求追溯审计。通过本章的学习，读者应能够识别需求图中的五类核心元素，理解它们之间的语义差异，并能够在实际项目中应用建模规则创建高质量的需求图模型。