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の案内にあるものです。論文は、状態について While の代わりに同じ意味の During を、その方が読みやすいときに使ってよいとしています。例文は型の説明であり、論文からの引用ではありません。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 はこの木に対し、2026年10月30日に公開された最新版 specscore 0.55.1 と、dogfood.yml に固定された specscore 0.39.1 の両方で、違反0件を報告しました。形式のリポジトリがそのワークフローの場所です。

---
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 は、ACの中の別の段落ではなく、spec/features/checkout/_tests/ のシナリオファイルです。

質問

出典

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