3. 功能需求捕获与功能清单构建

利益相关者需求（Stakeholder Requirements）描述的是“谁希望系统为他做什么、达到什么效果”，而系统功能需求（System Function Requirements）描述的是“系统自身必须执行什么行为来满足这些期望”。两者之间不是简单的文字改写，而是一次视角转换：从外部使用视角切换到系统内部行为视角。本节围绕这一转换，讲清捕获方法、粒度控制、完整性检查，并以某机电系统为例生成一份可用的功能清单。

一、转化的本质：把“期望”翻译成“行为”

利益相关者需求通常带有主观性和结果导向，例如“操作员希望设备启动后 3 秒内进入工作状态”。这句话里，系统需要承担的行为是“接收启动指令—完成自检—驱动执行机构—反馈就绪状态”。转化的核心动作是：识别需求中的动作主体、触发条件、期望结果，再把这些结果拆解为系统必须完成的功能序列。

常用的转化路径是“需求→场景→功能”。先为每条利益相关者需求构造一个使用场景（谁、在什么条件下、做什么、期望什么），再从场景中提取系统必须提供的功能。场景是桥梁，它把抽象需求落到具体交互上，功能才不容易漏、也不容易凭空多出来。

二、功能捕获的四种手段

功能不会自动出现，需要主动捕获。工程上常用四类手段配合使用：

• 场景走查：按正常、备用、异常三类场景逐步推演，问“此时系统必须做什么”。
• 接口反推：从外部接口（供电、通信、机械连接、人机交互）反推系统必须提供的功能，如“接收 24V 供电”对应“电源管理功能”。
• 状态驱动：先定义系统状态（停机、自检、运行、故障），再问“进入/退出每个状态需要什么功能”。
• 失效反推：从可能的失效模式反推应具备的保护、监测、降级功能。

四种手段交叉使用，能显著降低遗漏率。场景走查保证主流程完整，接口反推补齐边界功能，状态驱动保证状态迁移不缺失，失效反推补齐安全相关功能。

三、粒度控制：功能清单不能太粗也不能太碎

粒度是功能清单最容易失控的地方。太粗，一条“控制电机”无法分配、无法验证；太碎，把“读取寄存器”也列为功能，清单会膨胀到无法管理。判断粒度是否合适，可用三条准则：

1. 可分配：该功能能明确分配给一个架构单元（组件、子系统或人）。
2. 可验证：该功能有明确的输入、输出和成功判据，能设计测试用例。
3. 单一职责：一个功能只完成一件可命名的事，不把“采集+判断+执行”混在一条里。

推荐把功能分为两级：一级功能（系统级能力，如“运动控制”“安全保护”）和二级功能（可分配、可验证的具体行为，如“采集位置传感器信号”“超限时切断驱动输出”）。一级功能用于架构分层，二级功能用于详细设计与验证。粒度控制在二级即可，不再继续下钻到软件函数级。

四、完整性检查：四个维度查漏

功能清单初步形成后，必须做完整性检查，否则遗漏会在后期以返工形式暴露。建议从四个维度检查：

检查时用“双向追溯矩阵”最有效：行是需求，列是功能，交叉打勾。出现空行说明需求未覆盖，出现空列说明功能无来源（可能是多余功能，也可能是漏掉的需求）。

五、实战：某机电系统功能清单生成

以一台“伺服驱动直线运动单元”为例，其利益相关者需求为：SR1 上电后 3 秒内进入就绪；SR2 运行中位置精度 ±0.5mm；SR3 超程或过载时自动停机；SR4 状态与故障码可被上位机读取；SR5 维护模式下可手动点动。

按“需求→场景→功能”转化，得到二级功能清单如下（含输入、输出与验证要点）：

用双向追溯矩阵检查：SR1→F1、F2；SR2→F3；SR3→F4、F5；SR4→F5；SR5→F6。五条需求全部覆盖，六个功能均有需求来源，无空行空列。再按场景检查：正常启动、连续运行、超程保护、上位机监控、维护点动均有功能支撑；按状态检查：停机、自检、就绪、运行、故障五种状态的进入与退出均有对应功能。检查通过，清单可作为后续功能架构设计的输入。

完成功能清单后，建议为每条功能补充“来源需求编号”和“验证方法”两个字段，形成可追溯、可验证的功能基线。这份基线将直接支撑下一阶段的功能分解与逻辑架构设计。