架空企業「みらい業務サービス」の社内依頼・承認管理アプリの例。実在する会社・案件・人物は含まない。 記事「受入条件が要件をもれなく確認できているかを点検する」（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-011REQ-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. 完了条件の確認

5. 次工程へ渡すもの