5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Kiro のドキュメントで見かけた EARS (Easy Approach to Requirements Syntax) って?

Last updated at Posted at 2025-07-29

Kiro のご紹介 – プロトタイプからプロダクションまで、あなたと共に働く新しい Agentic IDE | Amazon Web Services ブログ
https://aws.amazon.com/jp/blogs/news/introducing-kiro/


Kiroのドキュメントを眺めていたら EARS (Easy Approach to Requirements Syntax) という用語が。
知らない。ちょっと調べてみてもあまり情報が無い。その筋では知られているのかな。

この先のスタンダードになるかもしれないのでちょっとお勉強しておこう。

Concepts - Docs - Kiro
https://kiro.dev/docs/specs/concepts/#requirements

The requirements.md file is written in the form of user stories with acceptance criteria in EARS notation. The way you wish your PM would give you requirements!

EARS (Easy Approach to Requirements Syntax) notation provides a structured format for writing clear, testable requirements. In a spec's requirements.md file, each requirement follows this pattern:

requirements.mdファイルは、EARS記法で書かれた受け入れ基準を含むユーザーストーリー形式で記述されます。まさに、プロジェクトマネージャーが要件定義をしてくれるような書き方です!

EARS(Easy Approach to Requirements Syntax)記法は、明確でテスト可能な要件を記述するための構造化されたフォーマットを提供します。仕様書のrequirements.mdファイルでは、各要件は以下のパターンに従います。

image.png

EARS (Easy Approach to Requirements Syntax)

曖昧さ、不明確さ、主観性、およびテスト不能性といった一般的な問題を低減するために開発された簡易構文テンプレートです。この手法は、ロールス・ロイスPLCのアリスター・メイビン氏と彼の同僚によって開発され、2009年に初めて公開されて以来、世界中の多くの組織で採用されています。

EARSが要求の質を向上させる方法

EARSは、その構造化されたアプローチにより、要求の質を多角的に向上させます。

  • 曖昧さの軽減と明確性・簡潔性の向上
    • 自然言語の要求に内在する曖昧さ、不明確さ、主観性、非テスト可能性といった問題に対処します
    • EARSは、曖昧な言葉を排除し、誤解の可能性を減らすことで、すべての関係者が追加の説明を必要とせずに要求を理解するのに役立ちます
      • 初期の研究では、EARSが曖昧さと文の長さを減らすことが示されています
      • ロールス・ロイスでのケーススタディでは、EARSによる要求の書き換えが、曖昧さ、重複、冗長性、不明確さ、複雑さ、省略、不適切な実装、非テスト可能性という8つの主要な問題タイプの全てを大幅に削減したと報告されています
  • 標準化と一貫性の確保
    • EARSは、要求を記述するための一貫したフレームワークと統一された構文を提供します
      • これにより、レビューと監査が簡素化され、プロジェクトガバナンスの向上につながります
      • 少数の定義済みパターンを使用することで、すべての要求が統一されたスタイルに従うことが保証されます
  • テスト可能性(検証可能性)の向上
    • EARSは、自然言語要求の一般的な問題点の一つである 「テスト不能性」を減らす ことを目的としています
      • 明確に定義された要求は、システムが指定された要求を満たしていることを証明する手段を提供するため、検証が容易になります
  • 品質ガイドラインへの適合
    • 一般的に、EARSを含むテンプレートは、フリーテキストと比較して要求の質を向上させることが示されています
    • ISO/IEC/IEEE 29148などの標準でリストされている「曖昧でないこと(Unambiguous)」、「完全性(Complete)」、「単一性(Singular)」、「検証可能性(Verifiable)」、「適合性(Conforming)」といった主要な品質属性に肯定的な影響を与えます

EARSが開発プロセスに影響を与える方法

EARSは、要求の質を向上させることで、結果的に開発プロセス全体に良い影響を与えます。

  • 開発リスクとコストの削減
    • 要求の問題は開発の下流工程に伝播し、不必要な不安定性やリスクを生み出し、プログラムのスケジュールとコストに影響を与えます
    • EARSはこれらの問題の発生を低減または排除することで、開発プロセスにおけるリスクを軽減し、コストのかかるプロジェクトの遅延や失敗を防ぐのに役立ちます
  • ステークホルダー間のコミュニケーションの促進
    • EARSのシンプルさと読みやすさは、技術系および非技術系の利害関係者間のコミュニケーションギャップを埋めるのに役立ちます
    • 構造化された形式は明確な議論を可能にし、誰もが要求プロセスに効果的に参加できるようになります
    • 開発者と検証チームは、要求の明確さを提供し、曖昧さを取り除く点でEARSを高く評価しています
  • トレーサビリティの強化
    • EARSは要求の文書化における一貫性を促進し、プロジェクトライフサイクル全体の追跡可能性にとって重要です
    • これにより、要求を設計要素、テストケース、検証プロセスにマッピングすることが容易になります
  • ツールとプロセスの統合
    • EARSは軽量であり、特別なツールを必要とせず、トレーニングの負担が少ないため、実務家の間で人気があります
    • EARSをサポートする要求管理ツール(例:Visure Requirements ALM Platform)を活用することで、組織化と追跡可能性を向上させ、要求の変換と検証プロセスを効率化できます
    • Intelでは2010年にEARSが導入され、既存の要求エンジニアリングトレーニング資料に統合されました
  • アジャイル環境での活用
    • アジャイルプラクティスが柔軟性と反復的な配信を重視する動的なプロジェクト設定において、EARSは明確さを維持するための理想的なツールとなります
    • EARS表記法をアジャイルスプリントのユーザー ストーリーと受け入れ基準の定義に採用できます

EARSの主要パターン

EARSの基本構造は「While <オプションの事前条件>, when <オプションのトリガー>, the <システム名> shall <システム応答>」です。この構造に基づく主要なパターンは以下の通りです。

ユビキタス要件 (Ubiquitous Requirements)

The system shall <response>.

これは最も基本的な形式で、常に真であるか、システムが継続的に行うべきことを記述します。

イベント駆動要件 (Event-Driven Requirements)

When <condition>, the system shall <response>.

特定のイベントや条件が満たされたときに、システムが応答すべきことを記述します。

任意要件 (Optional Feature Requirements)

Where <feature is included>, the system shall <response>.

特定の機能が存在する場合にのみ適用される要件を記述します。

望ましくない状態要件 (Undesirable Feature Requirements)

When <condition> and <feature is excluded>, the system shall <response>.

特定の機能が存在しない場合に適用される要件を記述します。

状態駆動要件 (State-Driven Requirements)

While <state is active>, the system shall <response>.

特定のシステム状態がアクティブである間、システムが継続的に行うべきことを記述します。

状態とイベント駆動要件 (State-Driven Event-Driven Requirements)

While <state is active>, when <condition>, the system shall <response>.

特定のシステム状態がアクティブなときに、イベントが発生した場合にシステムが応答すべきことを記述します。

これらのテンプレートを使用することで、要件は「誰が(システムが)」「いつ(条件や状態に応じて)」「何をすべきか(応答)」が明確になります。

具体的なシステムを想定して、EARSを用いた要件記述の事例をいくつか挙げます。

システム例:スマートホームセキュリティシステム

ユビキタス要件 (Ubiquitous Requirements)

  • The system shall record all motion detection events.
    • (システムは、すべての動き検知イベントを記録すること。)
  • The system shall maintain the current security status (armed, disarmed, alert).
    • (システムは、現在のセキュリティ状態(警戒中、解除、警告)を維持すること。)

イベント駆動要件 (Event-Driven Requirements)

  • When a motion is detected while the system is armed, the system shall activate the alarm.
    • (システムが警戒中に動きが検知された場合、システムはアラームを起動すること。)
  • When a user inputs the correct disarm code, the system shall change its status to disarmed.
    • (ユーザーが正しい解除コードを入力した場合、システムはそのステータスを解除に変更すること。)

任意要件 (Optional Feature Requirements)

  • Where the outdoor camera feature is included, the system shall provide live video streaming to the user's mobile device.
    • (屋外カメラ機能が含まれている場合、システムはユーザーのモバイルデバイスにライブビデオストリーミングを提供すること。)

状態駆動要件 (State-Driven Requirements)

  • While the system is in alert status, the system shall continuously send alert notifications to the registered mobile numbers.
    • (システムが警告状態である間、システムは登録された携帯電話番号に継続的に警告通知を送信すること。)

状態とイベント駆動要件 (State-Driven Event-Driven Requirements)

  • While the system is armed, when the front door sensor is triggered, the system shall send an immediate alert notification to the user's mobile device.
    • (システムが警戒中である間、玄関ドアセンサーがトリガーされた場合、システムはユーザーのモバイルデバイスに即座に警告通知を送信すること。)

適用における留意点

すべての要求がEARS形式で記述されるべきではないとも指摘されています。

  • 複雑すぎる場合
    • 要求が複雑すぎる場合、例えば3つ以上の前提条件がある場合や、数学的な表現が最適な場合には、リストや決定表(ディシジョンテーブル)などの他の形式を使用することを検討すべきです
    • 要件の真の意味を正確に伝えることの方が、テンプレートに無理に当てはめることよりも価値があるとされています
  • 要求数の増加
    • フリーテキストの要求をEARSに書き換えることで、全体の要求数が増加する傾向があることも示されています
    • 例えば、あるデータセットでは要件の総数が8.8%増加しました
  • 内容の適切性
    • EARSの形式に従っているだけでは、必ずしも適切な仕様になるとは限りません
    • 要求の内容そのものが不適切だと、意図しない動作を引き起こす可能性があります。要求の意図を明確にし、条件を具体的に記述することが重要です

以上、 NotebookLM チャットにまとめてもらった内容です。

尚、GeminiのDeep Researchは200以上のサイトを参照中で数十分経過してもまだ頑張っています...

参考

Alistair Mavin EARS - Alistair Mavin
https://alistairmavin.com/ears/

見える化する要求仕様 〜 EARS(Easy Approach to Requirements Syntax)を活用したシステム要求の書き方 〜 - ビジネスガレージ株式会社
https://www.bgarage.co.jp/news/946/

要件仕様に EARS 表記法を採用 - Visure Solutions
https://visuresolutions.com/ja/%E3%82%A2%E3%83%AB%E3%83%A0%E3%82%AC%E3%82%A4%E3%83%89/%E8%80%B3%E8%A8%98%E6%B3%95%E3%82%92%E6%8E%A1%E7%94%A8%E3%81%99%E3%82%8B/

5
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?