この記事は、構成と文章の整理にAIを使っています。
あくまで読みやすくするための補助で、内容そのものをAIにすべて任せて書いているわけではありませんが、ところどころ相談しながら整えています。

要件定義書を書くときの「型」としてEARS(Easy Approach to Requirements Syntax)というのを知ったので調べてみた。

何者か

2009年、Rolls-Royce PLCのAlistair Mavinらのチームが提唱したもの。RE’09(Requirements Engineering カンファレンス)で発表された。ジェットエンジンの制御システムの耐空性規制を分析している過程で、要件の記述パターンが自然と似た構造に収束していったのがきっかけらしい。

読み方はそのまま英単語の “ears”(耳)と同じ。2010年に出た続編の論文タイトルが “Big Ears” だったので、耳のダジャレは狙って付けたものだと思う。

Airbus、Bosch、Dyson、Honeywell、Intel、NASA、Siemensなどが採用してるほか、2025年以降はAmazonのKiro IDEのようなAI仕様駆動開発ツールにも組み込まれ始めている。

5つのパターン

パターン	構文
Ubiquitous(普遍的要件)	The <system> shall <response>.
Event-driven(イベント駆動)	When <trigger>, the <system> shall <response>.
State-driven(状態駆動)	While <state>, the <system> shall <response>.
Optional feature(オプション機能)	Where <feature>, the <system> shall <response>.
Unwanted behavior(異常系)	If <trigger>, then the <system> shall <response>.

複合も可能で、実務だと When ○○ while ○○, the system shall ○○ みたいに組み合わせて使うことも多いらしい。

日本語で書くときの注意

<> の中身だけ日本語にして、キーワード部分(shall/When/While など)は英語のまま残す、みたいな書き方をしそうになるけど、それは違う。EARSは言語非依存の構文パターンなので、キーワードごと日本語文法に翻訳するのが正しい使い方。

対応はこんな感じ:

• shall → 〜しなければならない
• When → 〜したとき、
• While → 〜している間、
• Where → 〜が存在する場合、
• If〜then → 〜した場合、

例えば Unwanted behavior のパターンなら:

決済ゲートウェイがタイムアウトした場合、システムはトランザクションを最大3回再試行しなければならない。

英単語だけ残して The システム shall 〜 みたいに書くと普通に気持ち悪い文になるので注意。

使う場面

要件が「常に成り立つ制約なのか」「イベントに反応するものなのか」「異常系なのか」を型で分類できるので、レビューする側も読み分けがしやすくなる。逆に前提条件が3つ以上絡むような要件は1文が長くなりすぎるので、決定表や状態遷移図の方が向いてるらしい(実機未確認、文献ベース)。