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