4. 用例驱动需求捕获与系统边界定义

在SysML需求工程中，用例图承担着“从利益相关者视角划定系统职责”的关键作用。它不描述系统内部如何实现，而是回答三个问题：谁在使用系统、系统为谁提供哪些可观测的服务、系统与外部环境的边界在哪里。对于后续的需求追踪而言，用例是连接“利益相关者需要”与“功能需求条目”的中间枢纽——每个用例都应能向下分解为一组可验证的功能需求，向上追溯到具体的利益相关者诉求。

参与者、用例与系统边界的三元关系

SysML用例图由三个核心元素构成。参与者（Actor）代表与系统交互的外部实体，可以是人、外部系统、计时器或环境条件；用例（Use Case）代表系统向参与者提供的一段完整、有价值的行为；系统边界（Subject）用矩形框表示，框内是用例，框外是参与者，边界线本身就是“系统负责什么、不负责什么”的契约声明。

识别参与者时，应沿着“谁发起交互、谁接收结果、谁提供输入、谁受系统影响”四条线索展开。以无人机巡检系统为例，参与者包括：飞手（发起任务、接管控制）、地面站软件（下发航线和接收遥测）、电池管理系统（提供电量状态）、空域监管接口（接收飞行计划报备）。注意，参与者始终位于系统边界之外，即使它是另一个软件系统。

用例的命名应使用“动词+名词”的动宾结构，体现可观测的价值交付，例如“执行自动巡检航线”“上报实时遥测数据”“触发低电量返航”。避免使用“处理数据”“管理信息”这类无法验证的模糊命名。每个用例至少与一个参与者关联，关联线表示交互关系，不带箭头表示双向通信，带箭头表示主动发起方向。

用例之间的关系：包含、扩展与泛化

当多个用例共享一段公共行为时，使用«include»关系抽取公共用例。例如“执行自动巡检航线”和“执行手动巡检航线”都需要“上报实时遥测数据”，则后者被前者包含。包含关系是强制性的，基用例执行时必然执行被包含用例。

«extend»关系表示可选或条件触发的行为扩展。例如“触发低电量返航”扩展了“执行自动巡检航线”，但仅在电量低于阈值（如20%）时才插入执行。扩展用例可以独立定义触发条件，基用例不感知扩展的存在。泛化关系则用于参与者或用例的继承，例如“飞手”可以泛化为“高级飞手”和“实习飞手”，后者继承前者的所有交互能力并增加特定用例。

从用例到功能需求的映射

用例本身是需求捕获的起点，但不可直接作为验证对象。必须将每个用例展开为用例描述（Use Case Description），再从中提取可验证的功能需求条目。用例描述的标准字段包括：用例名称与编号、参与者、前置条件、主成功场景（基本流）、扩展场景（备选流）、后置条件。主成功场景按步骤编号，每一步描述“谁做什么、系统如何响应”。

以“触发低电量返航”为例，其主成功场景可写为：

1. 电池管理系统周期性上报电量百分比至飞控。
2. 飞控判断电量低于20%且飞行器处于自动巡检模式。
3. 飞控计算当前位置到返航点的最短安全路径。
4. 飞控切换飞行模式为“自动返航”，并停止当前巡检航线。
5. 飞控向地面站发送返航状态与预计到达时间。
6. 飞行器沿安全路径返回，到达返航点后自动降落并锁定电机。

从上述步骤中可提取功能需求条目，例如：“当电量低于20%且处于自动巡检模式时，飞控应在2秒内切换至自动返航模式”（对应步骤2-4）；“返航过程中，飞控应以不低于1Hz的频率向地面站发送返航状态”（对应步骤5）。每条功能需求都应分配唯一标识（如FR-UC03-01），并建立到用例的追踪链接。

实战：无人机巡检系统用例模型

以下给出一个可填写的用例描述模板，以“执行自动巡检航线”为例，展示从用例到功能需求的完整映射过程。

完成所有用例描述后，应建立追踪矩阵，检查覆盖完整性。例如，若“空域监管接口”参与者关联了“报备飞行计划”用例，但该用例未派生任何功能需求，则说明需求捕获存在遗漏。反之，若某条功能需求无法追溯到任何用例，则需确认它是否属于系统边界内的职责，或应归入外部系统需求。

最终交付的用例模型应包含：一张完整的用例图（参与者、用例、边界、关系）、每个用例的详细描述表、以及用例到功能需求的追踪矩阵。这三者共同构成从利益相关者诉求到可验证需求的完整链路，为后续的需求验证与确认提供结构化基础。