了解什么是简易需求语法方法(EARS)，学习怎么更好的给 AI 提需求

作者: MakerNeo
最后更新: 2026-04-05 15:51:48
标签:

Index

了解什么是简易需求语法方法(EARS)，学习怎么更好的给 AI 提需求

在软件开发和系统工程中，需求的质量直接影响项目的成功与否。模糊或不清晰的需求可能导致开发过程中的错误、成本增加和项目延误。EARS（Easy Approach to Requirements Syntax，需求语法简易方法）是一种轻量级、结构化的方法，旨在通过规范化的自然语言表达来改进需求编写。它由 Alistair Mavin 和 Rolls-Royce PLC 团队于 2009 年开发，最初用于分析航空发动机控制系统的适航性法规，并在 IEEE RE09 会议上首次亮相。此后，EARS 被广泛采用，特别是在大型组织和学术机构中。

EARS 的定义与核心理念

EARS 的核心理念是利用自然语言的熟悉性，同时通过特定的句式和关键词（如“当”、“如果”、“则”）来约束需求表达，从而减少歧义和不一致性。它不要求专门的工具，培训成本低，通常半天或更短时间即可掌握，适合初学者和经验丰富的工程师。这使得 EARS 成为需求工程领域的一种实用工具，尤其在处理复杂系统需求时表现突出。研究表明，EARS 能有效减少自然语言需求中的错误，如模糊性、冗长性和逻辑不完整。它通过提供标准化的结构，确保不同作者编写的需求保持一致性，同时易于利益相关者理解和审查。

开发背景

EARS 的开发源于 Rolls-Royce PLC 在分析航空发动机控制系统适航性法规时的实际需求。Alistair Mavin 和他的团队发现，这些法规中的需求往往遵循相似的模式，存在潜在的歧义和复杂性。通过提取和简化这些需求，他们开发了 EARS 的框架，并于 2009 年在 IEEE RE09 国际需求工程会议上发表。此后，EARS 被全球多个组织采用，包括 Bosch、Daimler、Dyson、Honeywell、Intel、NASA、Rolls-Royce 和 Siemens。此外，许多大学（如中国、法国、德国、瑞典、英国和美国的机构）也将 EARS 纳入教学内容，表明其在学术和工业界的广泛接受度。

EARS 的优势

EARS 提供了以下 10 个关键优势，基于实践验证，特别是在大型组织中的应用：

  1. 减少或消除自然语言需求中的错误。
  2. 使需求更简单、一致、易于理解，无风格偏见。
  3. 培训时间短（半天或更少），与测试用例对齐，易于审查。
  4. 帮助新手和专家编写更好的初稿，减少迭代次数。
  5. 补充活动图和状态图等模型，增强需求的可视化。
  6. 提高个人和团队沟通，减少项目风险，增强团队流动性。
  7. 适合经验丰富的工程师，提供清晰的框架。
  8. 系统处理复杂需求，使其更清晰、可实施。
  9. 学习曲线低，新用户快速改进。
  10. 得到大组织（如 Bosch、Daimler、Dyson、Honeywell、Intel、NASA、Rolls-Royce、Siemens）的验证。

与传统的无约束自然语言需求相比，EARS 显著降低了开发过程中的波动性和风险，减少了因需求不明确导致的返工和成本增加。例如，无约束的自然语言需求可能导致错误解释和实施偏差，而 EARS 通过结构化的句式（如“当...时，系统应...”）确保需求的可测试性和清晰度。

EARS 的语法与模式

EARS 提供了一套通用的语法结构，具体如下：

  • 通用结构：“在 <可选的前提条件> 的情况下，当 <可选的触发条件> 时，<系统名称> 必须 <系统响应>。”
  • 规则：
    • 0 或多个前提条件
    • 0 或 1 个触发条件
    • 1 个系统名称
    • 1 或多个系统响应

基于此，EARS 定义了六种主要模式，具体如下表所示：

类型 模板 示例
通用模式 (Ubiquitous) xxx 应该 xxx 手机的质量应该小于 XX 克
状态驱动模式 在 xxx 情况下 xxx 应 xxx 当飞机处于飞行状态且发动机在运行的情况下，控制系统应保持发动机燃油流量高于 xx 磅/秒
事件驱动模式 当 xxx 时，xxx 应 xxx 当飞行器发出连续点火指令时，控制系统应启动连续点火
可选功能模式 在 xxx 条件下，xxx 应该 xxx 在控制系统具有超速保护功能的条件下，在飞机起飞前，控制系统应测试超速保护功能的有效性
不想要的行为模式 如果 xxx，那么 xxx，“应该 xxx” 如果计算空速不可用，那么控制系统应使用模型空速
复杂模式 （期望行为）在…情况下…，当…时..., 当…时…应
（异常行为）在…情况下, 当…时..., 如果…应..		 当飞机位于地面的情况下，当收到反推力指令时，控制系统应启动反推力装置

这些模式覆盖了需求工程中的各种场景，从简单的功能描述到复杂的条件逻辑，均能通过 EARS 有效表达。例如，“当飞行器发出连续点火指令时，控制系统应启动连续点火”是一个典型的事件驱动需求，而“在控制系统具有超速保护功能的条件下，在飞机起飞前，控制系统应测试超速保护功能的有效性”则展示了可选功能模式的实用性。

实际应用与案例

EARS 的实际应用广泛，特别是在航空、汽车和软件开发领域。例如，Rolls-Royce 使用 EARS 来分析航空发动机控制系统的需求，确保适航性法规的清晰性和可实施性。Bosch 和 Siemens 等组织也采用 EARS 来改进需求工程流程，减少项目风险。

一个具体的例子是需求澄清：模糊的需求如“系统应断开网络连接”可以通过 EARS 改进为“当按下断开按钮时，软件应断开网络连接”，从而明确触发条件和系统响应。这种改进不仅提高了需求的测试性，还减少了开发过程中的误解。

此外，EARS 还与测试用例紧密相关。例如，“当飞行器发出连续点火指令时，控制系统应启动连续点火”可以直接转化为测试场景，确保系统在特定条件下正确响应。

示例1：用户登录功能

  • 传统描述：

    “系统应该让用户登录方便一点，出错时要有提示。”

  • EARS改进：

    当 用户输入用户名和密码并点击“登录”按钮时，系统应 验证凭据是否与数据库匹配。若 验证失败，系统应 显示“用户名或密码错误”提示。

EARS类型：事件驱动型（触发动作） + 条件型（错误处理）。

示例2：数据保存功能

  • 传统描述：

    “用户编辑内容后，系统最好能自动保存。”

  • EARS改进：

    当 用户在编辑框中停止输入超过5秒时，系统应 自动保存当前内容至草稿箱。

EARS类型：事件驱动型（时间触发）。

示例3：权限管理

  • 传统描述：

    “管理员可以删除用户帖子，但普通用户不行。”

  • EARS改进：

    当 用户尝试删除帖子时，系统应 检查其角色是否为“管理员”。若 角色非管理员，系统应 显示“权限不足”提示并阻止删除操作。

EARS类型：条件型（权限校验） + 事件驱动型（用户动作）。

示例4：系统性能约束

  • 传统描述：

    “页面加载不能太慢。”

  • EARS改进：

    系统应 在用户发起请求后2秒内返回页面内容（网络延迟除外）。

EARS类型：约束型（明确量化指标）。

EARS的核心改进点总结

  1. 消除模糊词：
    • 传统：“最好能”“方便一点” → EARS：“应”“必须”。
  2. 明确触发条件：
    • 传统：省略触发时机 → EARS：“当…时”“若…”。
  3. 拆分复合需求：
    • 传统：一句话混多个要求 → EARS：分多条描述（验证+提示）。
  4. 量化非功能需求：
    • 传统：“不能太慢” → EARS：“2秒内”。

是不是清晰了很多。 现在 AI 时代我们大量和 AI 沟通需求的时候最好采用 EARS 。这样AI 能很清晰的了解我们的需求。再同样先进的模型面前我们能领先其他人很多。

其他需求描述方法

除了 EARS（Easy Approach to Requirements Syntax），还有其他几种常用的 结构化需求编写方法，它们的目标都是提高需求的清晰度、可测试性和可追溯性。以下是几种类似的方法及其特点：

1. 用户故事（User Stories）

适用场景：敏捷开发、产品需求描述
格式：

As a [角色]，I want [功能]，so that [价值/目的]。

示例：

传统描述： “用户应该能重置密码。”
用户故事改进：
“As a 忘记密码的用户, I want to reset my password via email, so that I can regain access to my account.”

优点：

  • 强调用户视角和价值，避免技术细节堆砌。
  • 适合敏捷开发中的需求拆分和优先级排序。

缺点：

  • 缺乏严格的语法约束，可能仍然模糊。
  • 通常需要补充 验收标准（Acceptance Criteria） 来明确细节。

2. 用例（Use Cases）

适用场景：系统交互流程描述
格式：

  • 参与者（Actor）：谁执行操作？
  • 主要流程（Main Flow）：正常情况下的步骤。
  • 备选流程（Alternative Flow）：异常或分支情况。

示例：

传统描述： “用户登录系统。”
用例改进：
用例名称：用户登录
参与者：注册用户
主要流程：

  1. 用户输入用户名和密码。
  2. 系统验证凭据。
  3. 系统显示主页。
    备选流程：
    • A1: 验证失败 → 系统提示“用户名或密码错误”。

优点：

  • 适合描述复杂的交互流程。
  • 结构化强，便于开发人员理解业务逻辑。

缺点：

  • 编写耗时，不适合简单需求。
  • 可能过于详细，导致需求文档臃肿。

3. Gherkin 语法（BDD 行为驱动开发）

适用场景：自动化测试、验收测试驱动开发（ATDD）
格式：

Given [初始条件]，
When [触发事件]，
Then [预期结果]。

示例：

传统描述： “购物车应该能计算总价。”
Gherkin 改进： 

Scenario: 计算购物车总价  
  Given 用户添加了3件商品到购物车  
  When 用户点击“结算”按钮  
  Then 系统应显示正确的总价（含税）

优点：

  • 直接映射到自动化测试代码（如Cucumber）。
  • 业务人员和技术人员可共同编写，减少沟通误差。

缺点：

  • 仅适用于可测试的需求，不适合描述约束或架构需求。

4. 需求模式（Requirement Patterns）

适用场景：复杂系统需求（如安全、性能需求）
格式：基于行业最佳实践的标准模板。

示例（安全需求模式）：

传统描述： “系统应该防止未授权访问。”
模式改进：
“系统应对所有敏感API端点实施基于JWT的身份验证，未提供有效Token的请求应返回HTTP 403。”

优点：

  • 提供行业标准化的表述方式，减少歧义。
  • 适合合规性需求（如GDPR、ISO 27001）。

缺点：

  • 需要团队熟悉相关模式，学习成本较高。

5. 决策表（Decision Tables）

适用场景：复杂业务规则（如定价、风控逻辑）
格式：用表格描述不同条件下的系统行为。

示例（电商折扣规则）： 用户类型 订单金额 促销活动 折扣率
新用户 ≥100元 无 5%
老用户 ≥200元 双11 15%

优点：

  • 直观展示多条件组合逻辑。
  • 便于测试用例设计。

缺点：

  • 仅适用于规则明确、条件有限的情况。

如何选择合适的方法？

方法 适用场景 核心优势
EARS 功能性需求（软件/硬件） 语法简单，可测试性强
用户故事 敏捷开发、产品需求 强调用户价值
用例 复杂交互流程（如银行系统） 结构化清晰
Gherkin 自动化测试需求 可直接生成测试代码
需求模式 合规性、安全需求 标准化，减少歧义
决策表 多条件业务规则 直观展示逻辑组合

如果你的需求是 “系统在X条件下应该做Y”，EARS 是最佳选择；如果是 “用户想要什么”，用户故事更合适；如果是 “如何测试这个功能”，Gherkin 更适用。

推荐组合使用：

  • 用 用户故事 描述宏观需求，再用 EARS 或 Gherkin 细化规则。
  • 用 决策表 处理复杂业务逻辑，再用 用例 描述交互流程。

希望这些方法能帮助你更高效地编写清晰、可执行的需求！ 🚀