EARS 需求语法详解与示例

EARS 从哪里来

当时在 Rolls-Royce PLC 的 Alistair Mavin、Philip Wilkinson、Adrian Harwood 和 Mark Novak，于 2009 年在 17th IEEE International Requirements Engineering Conference 发表 “Easy Approach to Requirements Syntax (EARS)”。文献标识是 10.1109/RE.2009.9。他们在从适航规章 Certification Specification for Engines（CS-E）第 CS-E 50 节抽取发动机控制需求时建立这些规则。原文把需求、设计指导和注释混在一起。

论文点出不受约束的自然语言的八个问题：歧义、含糊、复杂、遗漏、重复、冗长、不恰当的实现、无法测试。一小套规则要让每一条这样的需求使用五种模板之一。作者说这种记法适合高层干系人需求，并不声称它覆盖系统分解的每一层。

Mavin 自己的指南把 EARS 描述为温和约束文本需求的方法。子句保持一个顺序，他称之为时序逻辑：先是任何前置条件，然后是触发，然后是系统名称和响应。规则是零个或多个前置条件、零个或一个触发、一个系统名称、一个或多个响应。2009 年的论文把这个形状分成五种模板。同一份指南也命名了组合这些关键词的复杂需求。

在论文的案例里，原始摘录有 36 条需求，改写后的集合有 47 条。平均长度从 36.9 个词降到 25.6 个词。作者报告，在那项研究里，复杂、遗漏、重复、不恰当的实现和无法测试在改写后的集合中不存在，歧义、含糊和冗长减少了但没有消除。他们也列出限度：样本小、只有高层安全需求、含糊的分类含有判断。这些数字是那篇论文对那一份文件的数字。

EARS 句式

关键词来自 2009 年的论文和 Mavin 的指南。论文也允许在表示状态时用 During 代替 While，意思相同，只为读起来更顺。示例句子说明模板，不是论文引文。Kiro 用全大写写事件驱动句式；原始记法在句首用大写。示例保持英语，因为 EARS 语法是英语。

常见错误

Kiro 如何使用 EARS

Kiro 的功能规格页面标明更新于 2026年8月4日，本文于 2026年11月2日阅读。该页说 requirements.md 使用 EARS。印出的句式是 WHEN [condition/event]，接着 THE SYSTEM SHALL [expected behavior]。页面示例是：WHEN a user submits a form with invalid data, THE SYSTEM SHALL display validation errors next to the relevant fields。

需求优先页面说，生成的 requirements.md 包含带验收准则的用户故事，以及同一 WHEN … THE SYSTEM SHALL … 形式的系统行为。注册示例是三句：有效注册数据创建账户，已存在的邮箱显示 “Email already registered”，无效邮箱格式显示校验错误。

进入设计之前，Analyze Requirements 查找逻辑不一致、歧义、相互冲突的约束和缺口。功能规格页面说，需求生成之后，从聊天选项或编辑器里的 Continue 菜单选择它。design.md 和 tasks.md 放在需求旁边。Quick Spec 连续跑需求、设计和任务，中间没有批准停顿。

这项分析是 Kiro 内部的一步。功能规格页面没有把它写成你可以加进自己 CI 的格式检查器。其他工具如何检查规范，见工具指南。两个产品的比较是 SpecScore vs Kiro。

同一条需求写成 SpecScore

SpecScore 不检查一句话是否符合 EARS 模板。来自 specscore-cli 仓库的 specscore spec lint 检查结构。它的帮助文字点名 README 文件、Open Questions 节、标题层级、功能引用、内部链接和索引条目。一句 EARS 可以是 REQ 标题下的散文。检查器不给英语打分。

需求规范把每条需求放在 ## Behavior 里某个主题标题之下，低一层，通常是 #### REQ: slug。slug 使用小写字母、数字和连字符。标识是 {feature-path}#req:{slug}。规范说需求应当使用 RFC 2119（Request for Comments 2119）关键词：MUST、MUST NOT、SHOULD、SHOULD NOT 和 MAY。下面的对应里，EARS 的 shall 写成 MUST。

验收准则是可选的。使用时，它是 ## Acceptance Criteria 里的 ### AC: slug，下一行是带这些标识的 **Requirements:**。验收准则规范说，AC 陈述抽象条件，不得包含 Given/When/Then 步骤、具体输入或实现细节。具体流程是功能 _tests/ 目录里的场景。功能规范还要求状态、摘要、问题、行为、验收准则、未决问题和遵循页脚。

下面的文件是一个结账功能。show-field-error 是事件驱动示例。reject-invalid-email 是不希望行为的示例。2026年11月2日，specscore spec lint 对这棵树报告 0 项违规：一次用 2026年10月30日发布的最新版本 specscore 0.55.1，一次用 dogfood.yml 里固定的 specscore 0.39.1。格式仓库是该工作流所在之处。

---
format: https://specscore.md/feature-specification
status: Draft
---

# Feature: Checkout validation

> [SpecScore.**Studio**](https://specscore.studio): | [Explore](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=explore) | [Edit](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=edit) | [Ask question](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=ask) | [Request change](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=request-change) |

**Status:** Draft
**Source Ideas:** —

## Summary

The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address.

## Problem

A vague sentence such as "the form should handle bad input" does not say which event causes which response. Checkout needs those obligations written so a reviewer and a linter can point at them.

## Behavior

### Field validation

The checkout system checks the form when the shopper submits it.

#### REQ: show-field-error

When a shopper submits the checkout form with invalid data, the checkout system MUST show a validation error next to the invalid field.

#### REQ: reject-invalid-email

If the submitted email is not a valid address, then the checkout system MUST reject the form.

## Acceptance Criteria

### AC: invalid-submission

**Requirements:** checkout#req:show-field-error, checkout#req:reject-invalid-email

Submitting the checkout form with invalid data shows a validation error next to the invalid field, and an email that is not a valid address is rejected.

## Open Questions

None at this time.

---
*This document follows the https://specscore.md/feature-specification*

---
format: https://specscore.md/features-index-specification
---

# Features

| Feature | Status | Description |
|---|---|---|
| [Checkout validation](checkout/README.md) | Draft | The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address. |

## Open Questions

None at this time.

---
*This document follows the https://specscore.md/features-index-specification*

# Checkout specification

## Open Questions

None at this time.

# SpecScore Repo Config Schema: https://specscore.md/repo-config

project:
  title: Checkout sample
  host: github.com
  org: example
  repo: checkout

把这个示例做成能通过时，还出现过两个错误，都已在上面的文件里改正。没有 **Source Ideas:** 的功能会因 feature-source-ideas-required 失败；空值是 —。功能索引还需要前言字段 format: https://specscore.md/features-index-specification。

检查器通过，表示文件符合这些结构规则。它不表示这些句子是好的 EARS，也不表示结账产品存在。这个行为的 Given/When/Then 应是 spec/features/checkout/_tests/ 下的场景文件，而不是 AC 里的另一段。

问题

来源

阅读日期为 2026年11月2日；页面自己印有更新日期的，以该日期为准。Kiro 功能规格页面写明更新于 2026年8月4日。

• Mavin、Wilkinson、Harwood 与 Novak — Easy Approach to Requirements Syntax (EARS)，17th IEEE International Requirements Engineering Conference，2009，DOI 10.1109/RE.2009.9
• Alistair Mavin — EARS 指南
• Kiro 文档 — 功能规格与 EARS（页面更新于 2026年8月4日）
• Kiro 文档 — 需求优先流程
• specscore/specscore — 需求规范
• specscore/specscore — 验收准则规范
• specscore/specscore — 场景规范
• specscore/specscore — 功能规范
• specscore/specscore — dogfood CI 工作流
• specscore/specscore-cli
• specscore/specscore

相关

• 面向 AI 编程的 Markdown PRD 模板
• 在 CI 中用规格检查器检查规格
• 怎样写出 AI 代理能够验证的验收标准
• SpecScore vs Kiro
• 规范驱动开发工具
• 规范驱动开发
• 需求规范
• 验收准则规范
• 功能规范
• 校验器与 CI