前言

需求的语法结构，在业内相关的标准或指南中有不同的名称，例如：template, pattern, syntax, schema, structure

遵循需求语法结构，需求能更好满足需求特征（即：提高需求的质量），例如：

提高确定性（unambiguous）

提高完整性（complete）

确保原子性（Singular）

确保可验证和可确认性（verifiability and validatability）

提高符合性（conforming）

......

如果想了解需求特征的更多内容，可参考如下文章：

浅谈需求及需求特征

ASPICE V4.0 - 需求特征 – 01

ASPICE V4.0 - 需求特征 – 02

ASPICE V4.0 - 需求特征 – 03

好的需求的展现方式，一定是 <文字描述 + 图表（如：活动图，状态迁移图，信号流图，时序图，用例图，决策表等）>，本文介绍的需求语法结构，只是关于<需求的文字描述>

一、ISO/IEC/IEEE 29148 Systems and software engineering — Life cycle processes — Requirements engineering

ASPICE V4.0需求过程（SYS.2, SWE.1, HWE.1, MLE.1），在提到需求特征时引用了ISO/IEC/IEEE 29148

ISO/IEC/IEEE 29148中的需求语法结构示例：

[Condition][Subject][Action][Object] [Constraint of Action]

EXAMPLE:

When signal x is received [Condition], the system [Subject] shall set [Action] the signal x received bit [Object] within 2 seconds [Constraint of Action].

At sea state 1 [Condition], the Radar System [Subject] shall detect [Action] targets [Object] at ranges out to 100 nautical miles [Constraint of Action]

[Subject][Action] [Constraint of Action]

EXAMPLE:

The Invoice System [Subject] shall display pending customer invoices [Action] in ascending order of invoice due date [Constraint of Action]

一些OEM对供应商的要求中，也有类似的需求语法结构要求，例如KGAS的早期版本中，有如下条款：

[A: KGAS_3267] Each specification of system and software requirements as well as system and software elements and components must follow a defined schema (e.g. [condition] [the system or software or component] [shall or must do] [action or procedure or interface requirement]).

二、INCOSE Guide to Writing Requirements

ASPICE V4.0需求过程（SYS.2, SWE.1, HWE.1, MLE.1），在提到需求特征时引用了INCOSE Guide to Writing Requirements

INCOSE中的需求语法结构示例：

1、强制性需求（Shall 模式）

语法：[系统/组件] shall [行为] [条件]

规则：shall 仅用于描述系统必须实现的能力；行为必须可观测、可测试

示例：BMS系统 Shall 在100ms内切断主正接触器，当通过CAN收到安全气囊的碰撞信号时。（验证方法：HIL 测试注入碰撞信号，监测接触器状态）

2、禁止性需求（Shall Not 模式）

语法：[系统/组件] shall not [行为]

应用场景：Safety场景

示例：BMS系统 shall not 允许单体电压超过 4.25V，持续超过 500ms。

3、条件性需求（When/If 模式）

语法：

When [触发条件], [系统] shall [响应行为]

If [异常条件], [系统] shall [处理行为]

示例：

When 车辆进入赛道模式，电机控制器 shall 解除扭矩限制。

If 检测到 CAN 总线通信丢失，网关控制器 shall 切换至冗余通道。

4、非功能性量化需求（Measurable 模式）

语法：[系统] shall [指标] [数值] [单位] under [条件]

指标类型：性能、可靠性、安全性

示例：域控制器 shall 在 -40°C 至 85°C 环境下，启动时间 ≤ 2s。

INCOSE中相关的一些规则

1、主语明确化

错误示例：应实现快速响应

修正后：ESP 控制器 shall 在 100ms 内响应制动请求

2、行为动词标准化

禁用模糊词汇：如support, process, handle, track, manage等

使用确定性动词：如receive, store, calculate, report, display等

3、条件边界量化

错误示例：在低温下正常工作

修正后：在 -40°C 至 125°C 环境温度下满足功能需求

4、可验证性绑定

每个需求需标注验证方法（Test / Inspection / Analysis / Demonstration）

三、EARS (Easy Approach to Requirements Syntax)

EARS (Easy Approach to Requirements Syntax) 是一种轻量级的需求描述框架，专为降低歧义、提升可测试性而设计

EARS核心动机与目标：

降低歧义： 通过定义简单的语法模板，强制要求需求以结构化方式表述，减少自然语言的模糊性

提高一致性： 为所有需求提供统一的表述风格

增强可读性和可理解性： 使需求对工程师、测试人员、管理人员等各类角色都更易读

支持自动化： 结构化的需求更容易被工具解析，用于需求管理、追踪和测试用例生成

轻量级和易用性： EARS 学习曲线平缓，易于集成到现有工作流程中

EARS的语法模式

1、普适需求 (Ubiquitous Requirement)

模式：The [控制器] shall [行为]

应用场景：描述系统始终遵守的规则，无触发条件

示例：

电池管理系统（BMS） shall 在每次上电时执行自检，并记录诊断码（DTC）。（验证方法：监测上电序列日志（CANoe捕捉0x7E0报文））

2、事件驱动需求 (Event-Driven Requirement)

模式：When [触发事件], the [控制器] shall [响应行为]

应用场景：特定触发条件下的响应

示例：

电池管理系统（BMS） Shall 在100ms内切断主正接触器，当通过CAN收到安全气囊的碰撞信号时。（验证方法：HIL 测试注入碰撞信号，监测接触器状态）

3、异常处理需求 (Unwanted Behavior Requirement)

模式：If [故障条件], the [控制器] shall [处理行为]

应用场景：防御性设计（错误/边界条件）

示例：

If 前视摄像头通信丢失持续 > 500ms，the 感知融合模块 shall 切换至纯毫米波雷达模式，并在仪表盘点亮黄色警告图标（ID：0x2A1）。

4、状态驱动需求 (State-Driven Requirement)

模式：While [状态条件], the [系统/组件] shall [行为]

场景：系统在特定状态下需维持的行为

示例：

While 电池温度 > 45°C，the 热泵控制器 shall 维持冷却液流量 ≥ 5 L/min，且压缩机转速 ≥ 3000 RPM。

5、可选需求 (Optional Requirement)

模式：The [系统/组件] may [行为]

场景：非强制性的能力扩展

示例（智能座舱控制器）：

The 语音识别模块 may 支持方言识别（粤语/四川话），当系统存储空间 ≥ 128MB 时启用。

EARS可以与工具链进行集成，如：

使用IBM DOORs/Jama编写需求时，可以预置EARS模板字段

使用Simulink Requirements模型验证时，可以将EARS语句链接至Stateflow状态机

EARS的核心优势是简洁、易执行，但存在对复杂逻辑的支持有限，非功能性需求量化不足等局限性

四、Planguage

Planguage 是系统工程专家 Tom Gilb 提出的量化需求工程方法，核心思想是通过精确的测量指标替代模糊表述，驱动精准验证，适用于功能安全（ISO 26262）、性能及可靠性需求，缺点是：学习成本高、灵活性不足（难适应创意性需求（如UI交互设计））

术语

标尺（Scale）：定义测量维度，例如：响应时间（ms）、SOC估算误差（%）

计量器（Meter）：指定测量工具/方法，例如：CANoe信号分析、HIL台架测试

目标值（Target）：设计的理想值，例如：80ms（典型工况）

约束值（Constraint）： 安全/法规底线，例如：≤120ms（极端温度）

失效条件（Fail）：定义系统不可接受状态，例如：单体电压 > 4.25V持续 > 500ms

BMS系统过压保护需求示例：

需求ID：SFTY-BMS-01

标签 (Tag)：单体电压保护

相关方（Stakeholder）：功能安全工程师

描述 (Description)：防止电芯过压导致热失控。

标尺 (Scale)：单体最高电压 (V)

计量器 (Meter)：BMS诊断日志 (采样率10kHz)

目标值 (Target)：4.20V (标称充电截止)

约束值 (Constraint)：≤4.25V (ASIL-D要求)

失效条件 (Fail)：>4.25V持续 > 500ms → 触发继电器断开

五、Boeing Core Requirement Patterns

波音定义了 四种基础需求模式（Boeing Core Requirement Patterns），适用于复杂安全关键系统（如航空电子、航天器）

1、功能需求（Functional Requirements）

定义：系统对特定输入的 响应行为

语法模板：

当 [触发条件]，[控制器] 应 [执行动作] 生成 [输出结果]

关键规则：

明确触发信号（传感器输入/指令）

动作必须可观测（如“计算”“传输”“激活”）

2、性能需求（Performance Requirements）

定义：规定功能执行的 量化指标边界。

语法模板：

在 [环境条件] 下，[控制器] 的 [指标] 应 ≤/≥ [值] [单位]

关键规则：

覆盖温度/电压/EMC等车规工况

定义统计边界（如99%分位值）

3、约束需求（Constraint Requirements）

定义：设计必须遵守的 物理/协议/安全限制

语法模板：

[控制器] 应 符合 [标准] [条款]

[控制器] 不得 [禁止行为]

关键规则：禁用模糊术语（如：足够、可靠）

4、可验证性需求（Verifiable Requirements）

定义：强制需求，可被客观检验的

语法模板：需求 [ID] 应 通过 [方法] 在 [阶段] 完成验证

关键规则：绑定验证活动，并确定使用的验证工具

热管理系统控制器（Thermal Management Unit）示例：

功能需求：

当 电池温度 >40°C，控制器 应 启动冷却泵，调节冷却液流量至 5-7 L/min。

性能需求：

在 海拔3000米 且 环境温度45°C 下，温度控制响应时间 应 ≤ 15s（从超温到降温启动）。

约束需求：

PID控制算法 应 符合 MISRA C 2023规则（禁用动态内存分配，规则22.5）。

可验证性需求：

需求 TMU-PER-202 应 通过：

a) MIL：Matlab/Simulink高温模型仿真

b) HIL：风洞模拟台架测试

在 DV（设计验证）阶段 完成

六、Use Case Template

Use Case Template（用例模板） 适用于描述 交互密集型需求，特别关注用户/外部系统与目标系统之间的动态行为。其价值在于将模糊的业务目标转化为可执行的场景化需求

标准Use Case模板结构：

用例名称：动词短语，清晰描述用户目标

例如：交流充电

用例ID：唯一标识符，用于追踪

参与者：触发用例的角色（人或外部系统）

例如：用户、充电桩、BMS、云平台

前置条件：执行用例前必须满足的状态

例如：

车辆处于P档且充电枪已物理连接 (CC信号=1)

电池SOC < 95% 且温度在0°C~45°C

用户通过App/车机启动充电请求

后置条件：用例执行完成后系统必须达到的稳定状态和数据状态

例如：

硬件状态（物理层安全），包括主接触器（K1/K2）断开，驱动信号电压 ≤ 1V

……

主成功场景：用户与系统交互的标准流程（理想路径）

例如：

步骤1：用户插入Type2充电枪 à 控制器检测CC/CP信号（CC电压>4V → 连接确认）

步骤2：用户点击“开始充电” à OBC发送鉴权请求至云平台（VIN码+充电桩ID加密传输）

步骤3：云平台返回授权成功 à OBC闭合接触器，发送充电参数至BMS

……

扩展路径：主流程的异常分支或可选流程（处理错误/变体）

例如：

3a. 步骤3鉴权失败

……

业务规则：约束行为的策略或逻辑

例如：

绝缘电阻<500kΩ立即停止充电

非功能性需求：性能、安全等要求（可选）

例如：

性能 - 从充电请求到电流输出延迟 ≤ 1.5s（验证方法：HIL测试(CANoe)）

特殊需求：技术依赖或特殊设计需求

七、User Story

用户故事（User Story） 是敏捷开发中的核心需求描述工具，通过用户视角的价值表达 取代传统技术规格说明

语法结构：

“作为一个 [角色]，我想要 [功能]，以便 [价值]”

(As a [role], I want [feature], so that [benefit])

用户故事需要遵循的INVEST原则

I - 独立 (Independent)：故事之间无依赖（可单独开发/测试）

N - 可协商 (Negotiable)：细节留待开发前讨论

V - 有价值 (Valuable)：用户/业务方能直接感知其收益

E - 可估算 (Estimable)： 开发团队能评估工作量

S - 足够小 (Small)：单个Sprint内可完成（通常2-5人天）

T - 可测试 (Testable)：有明确的验收标准（DoD）

通过用户故事，可聚焦用户可感知的价值流，尤其适用于智能座舱、自动驾驶等快速迭代领域

示例1：

作为：通勤车主

我想要：上车自动播放昨日未听完的播客

以便：无缝衔接通勤体验

验收标准：蓝牙连接后5s内续播，进度误差 ≤ 3秒

依赖：云端同步API + 座舱SOC算力

示例2

作为：长途货车司机

我想要：夜间自动识别故障车辆三角牌

以便：提前变道避免事故

验收标准：100m外识别三角牌（≥95%置信度），雨雾天气误触发率<0.1%

硬件依赖：4D毫米波雷达 + 红外摄像头

写在最后：

为提高需求质量，组织/项目可以为不同类型的需求，分别定义相对应的需求语法结构。即：每种类型的需求，至少有一个需求语法结构。