2. 需求获取与SysML需求图建模
需求工程中最常见的失败并不是“写不出需求”，而是把不同层次、不同来源、不同抽象程度的需求混在一起，导致后续无法追踪、无法验证。本节的核心任务，是建立一条从利益相关者需求到系统需求的转化路径，并用SysML需求图把每条需求变成可标识、可追溯、可验证的模型元素。
一、从利益相关者需求到系统需求
利益相关者需求（Stakeholder Requirement）描述的是“谁希望系统带来什么价值”，通常以自然语言、场景、业务目标或约束条件的形式出现，例如“运维人员希望无人机在电池低于20%时自动返航”。系统需求（System Requirement）则是工程团队能够设计、实现和验证的正式陈述，它必须明确系统边界、输入输出、性能指标和验收条件。
转化过程不是简单改写句子，而是完成三次“收敛”：
- 角色收敛：识别提出需求的主体，如用户、运维、监管、制造、维护等，并记录其关注点。
- 行为收敛：把模糊期望转化为系统可执行的功能或性能约束，明确触发条件、系统响应和边界条件。
- 验证收敛：为每条系统需求指定验证方法，如检查、分析、演示或测试，并给出可判定的通过准则。
以无人机巡检项目为例，利益相关者需求“操作员希望单次任务覆盖不少于5公里管线”可以转化为系统需求“在标准巡检载荷下，无人机单次任务航程应不小于5 km，且返航电量余量不低于20%”。这条系统需求已经包含对象、条件、指标和约束，具备进入模型的条件。
二、SysML需求图的核心元素
SysML需求图（Requirement Diagram）用图形方式表达需求条目及其关系。一个需求在图中通常表现为一个带«requirement»构造型的矩形，内部可包含标识、文本、优先级、来源、状态和验证方法等属性。需求之间、需求与其他模型元素之间通过关系线连接，常见关系包括：
- 包含（containment）：父需求分解为若干子需求，形成需求层级。
- 派生（derive）：系统需求由利益相关者需求派生而来，保留来源依据。
- 满足（satisfy）：设计元素或系统模块满足某条需求。
- 验证（verify）：测试用例、分析模型或检查活动验证某条需求。
- 精化（refine）：用更详细的需求或模型元素进一步说明某条需求。
需求图的价值不在于“画得漂亮”，而在于让每条需求都有唯一标识、明确来源、可追踪去向和可判定的验证方式。下面这张图展示了一个无人机巡检项目的需求结构片段：左侧是利益相关者需求，中间是派生出的系统需求，右侧是满足与验证关系。
三、需求条目的属性定义
在SysML需求图中，每条需求都应具备一组稳定的属性字段。字段不是越多越好，而是要覆盖“来源—内容—优先级—状态—验证”这条主线。以下字段可直接用于实战项目：
| 字段 | 含义 | 示例 |
|---|---|---|
| id | 需求唯一标识，便于追踪与引用 | SY-101 |
| text | 需求正文，包含条件、对象、指标 | 标准载荷下航程≥5 km |
| source | 需求来源，指向利益相关者或上层需求 | SR-001 |
| priority | 优先级，用于冲突取舍与迭代排序 | 高 |
| status | 生命周期状态 | 已确认 / 已评审 / 已实现 / 已验证 |
| verifyMethod | 验证方法 | 检查 / 分析 / 演示 / 测试 |
| acceptance | 通过准则，用于判定验证结果 | 实测航程≥5 km且余量≥20% |
其中，status字段建议采用有限状态集合，避免出现“差不多完成”“基本通过”这类不可判定的描述。一个可用的状态序列是：草稿 → 已确认 → 已评审 → 已实现 → 已验证。每次状态变更都应记录变更依据，例如评审记录编号或测试报告编号。
四、实战：完成需求条目化建模
下面以无人机巡检项目为例，给出一个可直接参考的需求条目化建模过程。假设已收集到三条利益相关者需求：
- 运营方要求单次任务覆盖不少于5公里管线。
- 运维方要求电池低于20%时自动返航。
- 监管方要求飞行日志保存不少于90天。
第一步，为每条利益相关者需求分配标识并记录来源、优先级和状态。第二步，逐条派生系统需求，把“希望”转化为“指标+条件+验收准则”。第三步，在需求图中建立«derive»关系，并补充«satisfy»与«verify»关系。第四步，检查每条系统需求是否具备可判定的验证方法。
以第二条为例，派生出的系统需求可写为：
id: SY-102
text: 当电池剩余电量低于20%时，飞行控制模块应在5秒内触发返航，
返航过程中保持与地面站通信，并在电量低于10%前完成着陆。
source: SR-002
priority: 高
status: 已评审
verifyMethod: 测试
acceptance: 模拟电量下降至20%，记录返航触发时间≤5秒；
电量降至10%时无人机已处于着陆状态。
这条需求已经具备触发条件（电量低于20%）、系统响应（5秒内触发返航）、过程约束（保持通信）和验收判据（触发时间与着陆电量）。在需求图中，它通过«derive»连接到SR-002，通过«satisfy»连接到飞行控制模块，通过«verify»连接到TC-202返航测试用例。
五、常见问题与检查要点
需求条目化建模中，最容易出现的问题有三类。第一类是来源缺失：系统需求没有指向任何利益相关者需求，导致后续无法判断该需求是否真的必要。第二类是验证方法缺失：需求写得完整，但没有说明用检查、分析、演示还是测试来验证，导致验证阶段无法排期。第三类是状态失真：需求尚未评审就标记为“已确认”，或测试未执行就标记为“已验证”。
完成一轮建模后，可以用以下检查表快速复查：
- 每条系统需求是否都有唯一id，且id在项目内不重复？
- 每条系统需求是否都能追溯到至少一条利益相关者需求？
- 每条系统需求是否都有明确的verifyMethod和acceptance？
- status是否只使用约定状态集合中的值？
- 需求图中的«derive»、«satisfy»、«verify»关系是否与追踪矩阵一致？
当这些检查项都能通过时，需求图就不再是一张“示意图”，而是可以支撑后续设计、测试和变更影响分析的工作模型。下一阶段的工作，将围绕这些需求条目建立追踪矩阵，并在设计推进过程中持续更新状态与验证结果。