4. 需求建模与追溯
在MBSE中，需求不是一份静态文档，而是模型中可以建立关系、可以被追溯、可以被验证的结构化元素。SysML通过需求图（Requirement Diagram）把需求从文本条目变成模型节点，使“谁满足谁、谁派生谁、谁验证谁”成为可查询、可分析、可维护的模型关系。本章围绕需求捕获、需求图建模、需求分解与派生、四类核心需求关系、需求追溯矩阵以及需求变更影响分析展开。
4.1 需求捕获：从利益相关者到可建模需求
需求捕获的目标不是把用户原话直接抄进模型，而是把模糊期望转化为可验证、可追溯、可分配的需求条目。典型来源包括利益相关者访谈、运行场景、法规标准、接口协议、历史故障报告和现有系统文档。捕获时建议同步记录需求属性：唯一标识（如REQ-001）、需求文本、来源、类型（功能/性能/接口/安全）、优先级、验证方法、状态。
以无人机巡检系统为例，用户说“希望飞得久一点”，不能直接作为需求。应转化为：“在标准巡检载荷下，无人机续航时间应不小于45分钟，验证方法为飞行试验。”这条需求具备可测量参数、明确条件和验证手段，才能进入模型。
4.2 需求图建模：把需求放进模型
SysML需求图的核心元素是«requirement»，每个需求可包含id和text属性。需求图不是流程图，而是关系图：它展示需求之间、需求与设计元素之间、需求与验证用例之间的连接。建模时通常先建立需求包（Package），再按层级组织需求，最后用关系线连接。
需求图的价值在于：当设计模型发生变化时，可以沿关系链反向查询受影响的需求；当需求变更时，可以正向查询受影响的设计、测试和接口。
4.3 需求分解与派生
需求分解是把高层需求拆成若干子需求，使每个子需求可独立分配、独立验证。SysML中用«contain»表示包含关系，父需求包含子需求。例如REQ-001“完成自主巡检任务”可包含REQ-002“续航≥45min”和REQ-003“图像分辨率≤2cm/px”。
需求派生（«derive»）则不同：派生需求不是父需求的组成部分，而是由父需求推导出的新需求。例如从REQ-002“续航≥45min”可派生出REQ-004“电池容量≥12000mAh”。派生关系具有方向性：REQ-002是源，REQ-004是目标。当REQ-002的45分钟改为60分钟时，REQ-004的容量阈值必须重新计算，这就是派生链的追溯价值。
4.4 四类核心需求关系
SysML需求建模中，最常用的四类关系是：
- 包含（contain）：父需求到子需求的分解，表示“由……组成”。
- 派生（derive）：从一条需求推导出另一条需求，表示“由……推出”。
- 满足（satisfy）：设计元素（如Block、部件、软件模块）满足某条需求，表示“由……实现”。
- 验证（verify）：测试用例、分析模型或检查方法验证某条需求，表示“由……确认”。
四类关系的方向必须统一：包含和派生从需求指向需求；满足从设计元素指向需求；验证从验证元素指向需求。方向混乱会导致追溯查询失效。
4.5 需求追溯矩阵
需求追溯矩阵（Requirements Traceability Matrix, RTM）是把需求与设计、测试、接口等元素建立二维对应关系的表格。它不替代需求图，而是提供批量查询和覆盖率统计。典型字段包括：需求ID、需求文本、来源、派生自、满足元素、验证用例、验证状态、覆盖率。
| 需求ID | 需求摘要 | 派生自 | 满足元素 | 验证用例 | 状态 |
|---|---|---|---|---|---|
| REQ-001 | 自主巡检任务 | — | 任务管理模块 | TC-001 | 已验证 |
| REQ-002 | 续航≥45min | REQ-001 | 电池模块 | TC-002 | 待验证 |
| REQ-003 | 分辨率≤2cm/px | REQ-001 | 相机模块 | TC-003 | 已验证 |
| REQ-004 | 电池容量≥12000mAh | REQ-002 | 电池模块 | TC-004 | 待验证 |
覆盖率统计是RTM的核心用途：若某条需求没有满足元素，说明设计遗漏；若没有验证用例，说明验证遗漏；若某设计元素没有对应需求，可能是过度设计。示例中REQ-002和REQ-004状态为“待验证”，说明验证活动尚未闭环。
4.6 需求变更影响分析
需求变更影响分析的目标是：当一条需求发生变化时，快速找出所有受影响的需求、设计元素、测试用例和接口。操作上分三步：
- 定位变更源：确定变更需求ID，例如REQ-002续航从45min改为60min。
- 沿关系链正向追踪：从REQ-002出发，沿«derive»找到REQ-004，沿«satisfy»找到电池模块，沿«verify»找到TC-002。
- 评估影响并更新：REQ-004容量阈值需从12000mAh重新计算；电池模块参数需重新校核；TC-002试验时长和判定条件需同步修改。
4.7 实操建议与常见问题
在实际项目中，需求建模最容易出现三类问题：一是需求文本不可验证，如“系统应友好易用”；二是关系方向写反，如把«satisfy»画成需求指向设计元素；三是派生链断裂，即派生需求没有记录来源，导致变更时无法追溯。
建议在建模工具中为每条需求强制填写id、text、验证方法三个属性，并定期运行追溯覆盖率检查。对于安全关键需求，还应增加“验证状态”和“变更历史”字段。需求图、RTM和变更影响分析三者配合，才能形成从捕获到验证的完整闭环。