# 受入条件対応表ひな形（記入例）

架空企業「みらい業務サービス」の社内依頼・承認管理アプリの例。実在する会社・案件・人物は含まない。
記事「受入条件が要件をもれなく確認できているかを点検する」（02-04）の本文で使った内容をまとめたもの。空欄版は `02-04-acceptance-criteria_template.md`。

## 1. 要件と受入条件の対応表

| 要件ID | 対応する受入条件 | この記事での扱い |
|---|---|---|
| REQ-001（一意の識別） | AC-009 | 対応あり |
| REQ-002（役割に応じた範囲） | AC-007 | 対応あり |
| REQ-003（割当承認者のみ、自己承認禁止） | AC-001、AC-002、AC-003、AC-004、AC-008 | 対応あり |
| REQ-004（必須項目、差戻し理由） | AC-005、AC-006 | 対応あり。「再実行」の場面が抜けていたため補った |
| REQ-005（履歴を残す） | AC-001、AC-008に含まれる | 対応あり |
| REQ-006（重複操作で二重効果にならない） | AC-008 | 対応あり |
| REQ-007（片方だけの完了を正常扱いしない） | AC-010 | 対応あり |
| REQ-008（バックアップ・復元後の照合） | — | この題材の対象外。12-03（記事C）で扱う |

## 2. 新しく補った受入条件

| 受入条件ID | 対応要件ID | 前提（利用者・データ・状態） | 操作 | 期待結果 | 種類 |
|---|---|---|---|---|---|
| AC-011 | REQ-004、REQ-005 | 依頼者・佐藤。件名なしで拒否された依頼REQ-A02（差戻し中） | 佐藤が件名を書いて再提出する | 状態が提出済みに変わり、履歴に「再提出・佐藤・時刻」が1件追加される。前回の差戻しの履歴は残る | 再実行 |

## 3. 確認場面の振り分け

| 受入条件 | 確認場面（テスト／受入確認） | 理由 |
|---|---|---|
| AC-001、AC-002、AC-003、AC-004、AC-008、AC-010 | 機械的なテスト（記事B） | 承認処理のコードの動きとして記事Bで確認済み |
| AC-005、AC-006、AC-007、AC-009、AC-011 | 人が見る受入確認 | 提出・閲覧・再提出は画面操作を伴い、記事Bでは未検証 |

## 4. 完了条件の確認

- [x] 各要件IDに1件以上の受入条件が対応している、または対象外の理由がある
- [x] 正常・権限なし・状態不正・途中失敗・再実行の例がある
- [x] 期待結果が実装の出力ではなく要件から書かれている

## 5. 次工程へ渡すもの

- [x] 要件と受入条件の対応表（第1節）
- [x] 新しく補った受入条件（第2節）
- [x] 確認場面の振り分け（第3節）
- [ ] 承認者：総務課長（架空）— 記入例のため未承認の扱い