2. 基于用例的系统功能范围界定
从需求文本到用例模型：识别参与者与核心用例
用例图的核心价值在于把“系统要做什么”从需求文本中提炼为可追溯的功能单元。本案例以一个“智能温室环境控制系统”为建模对象，从顶层需求出发，识别参与者、核心用例，并建立用例与需求之间的追溯关系。
第一步：从需求中提取参与者
参与者是系统边界之外、与系统发生交互的角色。对智能温室系统，顶层需求描述如下：
- R1：系统应能根据温室内温度自动调节通风与加热设备。
- R2：系统应能根据土壤湿度自动控制灌溉阀门。
- R3：种植管理员应能远程查看温室环境数据并手动覆盖自动控制。
- R4：维护技术员应能对传感器和执行器进行校准与故障诊断。
- R5：系统应能向外部气象服务请求未来天气数据以优化控制策略。
从上述需求中可识别出四类参与者：种植管理员（人）、维护技术员（人）、气象服务（外部系统）、环境传感器与执行器（外部设备）。注意：传感器和执行器虽然物理上可能属于系统部署的一部分，但在SysML用例建模中，若它们作为独立外部实体与控制器交互，则应作为参与者处理。
第二步：定义核心用例
每个参与者与系统之间的交互目标对应一个用例。核心用例清单如下：
| 用例编号 | 用例名称 | 主参与者 | 关联需求 |
|---|---|---|---|
| UC-01 | 自动调节温度 | 环境传感器与执行器 | R1 |
| UC-02 | 自动控制灌溉 | 环境传感器与执行器 | R2 |
| UC-03 | 远程监控与手动覆盖 | 种植管理员 | R3 |
| UC-04 | 设备校准与故障诊断 | 维护技术员 | R4 |
| UC-05 | 获取天气预报数据 | 气象服务 | R5 |
第三步：用例与需求的追溯关系
追溯关系确保每个需求至少被一个用例覆盖，同时每个用例都能追溯到具体需求，避免功能冗余。上表已建立UC与R的映射。检查覆盖情况：R1→UC-01，R2→UC-02，R3→UC-03，R4→UC-04，R5→UC-05，五条需求全部覆盖，无遗漏。反向检查：每个用例都有明确需求来源，无冗余用例。
若某条需求无法映射到任何用例，说明功能范围存在遗漏；若某个用例无法追溯到需求，说明可能存在范围蔓延，需要与利益相关者确认。
第四步：范围完整性检查
完成用例图后，执行以下检查：
- 需求覆盖检查：逐条遍历顶层需求，确认每条需求至少关联一个用例。本例中R1~R5全部覆盖。
- 用例冗余检查：逐条遍历用例，确认每个用例都有明确的需求来源。本例中UC-01~UC-05均可追溯。
- 参与者完整性检查：确认所有与系统交互的外部实体都已识别。本例中四类参与者覆盖了人、外部系统、外部设备三种类型。
- 边界一致性检查：确认用例图中系统边界与例1中内部块图定义的边界一致，参与者与外部接口对象对应。
追溯矩阵是范围界定的核心工具。当需求或用例发生变更时，通过追溯矩阵可以快速评估变更影响范围：修改R1会影响UC-01，进而可能影响环境传感器与执行器参与者的接口定义。
常见问题与处理
- 参与者识别过多：若把系统内部的传感器模块也列为参与者，会导致边界模糊。判断标准：该实体是否在系统边界之外、是否与系统有交互。
- 用例粒度过细：如“读取温度值”不应作为独立用例，它属于UC-01的内部步骤。用例应代表对参与者有价值的完整目标。
- 追溯关系缺失：若某用例无法追溯到需求，需确认是需求遗漏还是用例冗余，并与利益相关者沟通确认。