4. 系统需求分析与规格化

利益相关者需求（Stakeholder Requirements）回答的是“谁希望系统为他做什么”，而系统需求（System Requirements）回答的是“系统本身必须做什么、做到什么程度”。两者之间不是简单的文字改写，而是一次责任转移与工程化翻译：把用户视角的期望，转换为可分配给系统架构、可验证、可追踪的工程陈述。本节聚焦这一转换过程，并给出需求规格化的落地方法。

一、从利益相关者需求到系统需求的转换逻辑

转换的核心动作有三个：识别系统边界、区分功能与非功能、补齐约束与接口。以“电动汽车充电桩”为例，利益相关者需求可能是“车主希望在30分钟内补充200公里续航”。这条需求本身无法直接验证，因为它混合了用户意图、时间指标和能量指标。系统级转换后应拆为：

• 功能需求：系统应能识别车辆电池管理系统的充电请求，并按请求功率输出直流电。
• 非功能需求：在环境温度25℃、电池SOC 20%～80%区间内，系统应支持不低于120kW的持续输出功率。
• 接口需求：系统应通过GB/T 27930协议与车辆BMS完成握手与参数协商。
• 约束需求：系统应满足GB/T 18487.1对充电安全与绝缘检测的要求。

可以看到，原始期望被分解为“做什么”“做到什么程度”“和谁交互”“受什么限制”四类陈述。这正是系统需求规格化的基本骨架。

二、功能需求与非功能需求的划分

功能需求描述系统必须执行的行为或提供的服务，通常可用“系统应能……”“当……时，系统应……”的句式表达。非功能需求描述系统执行功能时所处的质量水平或约束条件，包括性能、可靠性、安全性、可用性、可维护性、环境适应性等。二者并非绝对割裂：一条性能指标往往依附于某个功能行为，因此在规格化时建议采用“功能+质量”配对写法，避免出现悬空的指标。

三、可验证需求陈述的写法

一条可验证的系统需求应满足：单一、明确、可测量、无歧义、可追踪。推荐使用如下结构：

[条件/触发] + [系统/主体] + [应/必须] + [可观测行为] + [量化指标] + [验证方式]

例如，将“充电桩应快速充电”改写为：

当车辆BMS请求充电且握手成功后，充电桩应在10s内建立直流输出，
输出功率不低于120kW，稳态电压偏差不超过±1%，
验证方式：台架测试+功率分析仪记录。

改写后的需求包含了触发条件、主体、行为、量化指标和验证方式，测试人员可以直接据此设计用例，而无需再向需求作者追问“快速”到底是多少。

四、需求属性与规格化

规格化不仅是文字工作，更是属性管理。每条系统需求至少应携带以下属性：

其中 Rationale 常被忽视，但它是需求变更时最重要的判断依据。当有人提出“这条需求能不能删”时，Rationale 能直接说明它支撑的是哪条利益相关者期望或哪条法规，避免因信息丢失而误删关键需求。

五、需求分解与追踪关系

系统需求不是孤立列表，而是从利益相关者需求向下分解、向架构与验证延伸的网络。下图展示了从利益相关者需求到系统功能/非功能需求，再到验证活动的追踪链路，并标注了每条需求应携带的关键属性。

图中左侧是利益相关者需求，中间是系统级功能与非功能需求，右侧是规格化属性，下方是验证活动与架构分配。整条链路说明：需求不是写完就结束，而是要在“来源—需求—架构—验证”之间保持双向可追踪。当利益相关者需求发生变化时，可以沿链路快速定位受影响的系统需求、架构元素和验证用例。

六、规格化检查要点

在需求评审前，建议逐条检查以下问题：

1. 是否只描述了一个需求，而不是把多个需求塞进一句话？
2. 是否包含可测量的指标或明确的通过/失败判据？
3. 是否写明了触发条件或适用场景？
4. 是否避免了“快速”“友好”“尽量”等不可验证的形容词？
5. 是否填写了ID、优先级、来源、Rationale和验证方法？
6. 是否能向上追溯到至少一条利益相关者需求或法规？

以充电桩为例，若某条需求写成“系统应具有良好的充电体验”，它既无法验证，也无法分配。改写为“当充电枪插入并锁止后，系统应在3s内点亮充电指示灯，并在HMI上显示当前SOC与预计剩余时间”，就变成了可测试、可追踪的系统需求。

系统需求分析与规格化的最终产出，是一份可验证、可追踪、带属性、有 rationale 的系统需求规格说明。它向上承接利益相关者期望与法规约束，向下驱动架构设计与验证活动，是MBSE需求闭环中承上启下的关键环节。