附属書B(規定) EARS 記法(受入基準の書き方)
ピットイン方式の要件合意(G-2)は「受入基準が検証可能な形式で記述されている」ことを通過条件にしています。その「検証可能な形式」の標準が EARS 記法(Easy Approach to Requirements Syntax)です。このページは日本語での書き方のひな形集です。
本附属書は規定です(第1章 1.5)。第4章 G-2の基準1 が、本附属書の形式への準拠を求めます。
なぜ形式を決めるのか
Section titled “なぜ形式を決めるのか”- 「適切に」「柔軟に」「なるべく」で書かれた基準は、AI もテストに変換できず、人も合否を判定できない。曖昧語は要件合意の差し戻し理由の筆頭
- 形式を決めると、AI へ「この5パターンのどれかで書け」と指示でき、起案の品質が安定する
- 各基準がそのままテスト名になるため、「基準とテストの対応確認」(独立レビューのパス2)を機械的に行える
5つのパターン
Section titled “5つのパターン”すべての受入基準を、次の5パターンのどれか(または組み合わせ)で書きます。
| パターン | ひな形 | 使いどころ |
|---|---|---|
| 常時(Ubiquitous) | システムは、常に〈動作〉すること | 無条件で成り立つ性質(暗号化・ログ等) |
| イベント駆動(Event-driven) | 〈トリガー〉のとき、システムは〈動作〉すること | ユーザー操作・外部イベントへの応答 |
| 状態駆動(State-driven) | 〈状態〉の間、システムは〈動作〉すること | モード・状態が続く間の振る舞い |
| 望まない挙動(Unwanted) | もし〈異常条件〉なら、システムは〈防御動作〉すること | エラー・不正入力・障害時の振る舞い |
| 機能限定(Optional) | 〈機能・構成〉を備える場合、システムは〈動作〉すること | プラン差・フィーチャーフラグ・構成差 |
組み合わせも可能です(例: 「管理者モードの間、削除操作のとき、システムは確認ダイアログを表示すること」= 状態駆動+イベント駆動)。
良い例・悪い例
Section titled “良い例・悪い例”| 悪い例(曖昧) | 何が問題か | 良い例(EARS) |
|---|---|---|
| 検索は高速に応答すること | 「高速」の合否を判定できない | 検索クエリ送信のとき、システムは 95 パーセンタイルで 1 秒以内に結果を返すこと |
| 不正な入力を適切に処理すること | 「不正」「適切」が未定義 | もし数量欄に整数以外が入力されたら、システムは保存せずエラーメッセージ「数量は整数で入力してください」を表示すること |
| セッションは安全に管理すること | 検証手段がない | システムは、常にセッショントークンを HttpOnly かつ Secure 属性つき Cookie で発行すること |
| 大量アクセスにも柔軟に対応 | 条件も動作も未定義 | 同時 1,000 リクエストの間、システムはエラー率 1% 未満を維持すること |
書き方の手順(formalize-criteria タスクの実施手順)
Section titled “書き方の手順(formalize-criteria タスクの実施手順)”- AI が起案した受入基準を1件ずつ、5パターンのどれに当たるか分類する。どれにも当てはまらない基準は曖昧語が残っているので書き直す
- 各基準の〈動作〉に測定可能な値(時間・件数・率・表示文言)を入れる。値が決められない場合は、その場で価値責任者が決める(後回し禁止)
- 正常系1本につき、望まない挙動(Unwanted)パターンを最低1本書く(異常系のない基準セットは片面しか検証していない)
- 仕上げに AI へ「この基準をテストコードのテスト名に変換せよ」と指示する。変換できない基準が残っていたら 1 に戻る
草案を受け取ったときに確かめること
Section titled “草案を受け取ったときに確かめること”AI が起案した受入基準は、形式が整っていても、作りたかったものを表しているとは限りません。要件合意(G-2)が見るのは、企画書 観点3 に書いた価値と受入基準の対応の有無です。受入基準の内容そのものは、G-2 では判定しません(第4章 G-2)。基準の確定は価値判断であり、人が行います(第5章 5.5)。
草案を受け取った判定者は、基準をすべて満たしても、作りたかったものにならない場合がないかを確かめることを推奨します。そういう場合が見つかったら、基準を足すか、書き直します。
暗黙の前提とスコープ外の事項は、G-2 の基準3・基準4 によります。本節の確認は推奨事項です。判定基準を足しません。確かめたことの記録も求めません。
チェックリスト(G-2 提出前のセルフチェック)
Section titled “チェックリスト(G-2 提出前のセルフチェック)”- [ ] すべての受入基準が EARS の5パターンのどれかで書かれている- [ ] 曖昧語がゼロ(類と検出語は[第4章 G-2](/process-compass/phase4-process-design/gate-criteria/)「曖昧語(基準2)」による)- [ ] 各基準に測定可能な値(時間・件数・率・文言)が入っている- [ ] 正常系に対応する異常系(もし〜なら)の基準がある- [ ] 各基準がテスト名に変換できる(AI で試行済み)- Alistair Mavin ほか「Easy Approach to Requirements Syntax (EARS)」(RE 2009)。航空エンジン(Rolls-Royce)の要求仕様の曖昧さ削減のために考案された記法