記事A「業務の困り事を、実装と確認ができる要件へ変える」で使う。 記入例は requirements_example.md。項目の意味は記事Aの本文を参照。

1. 聞取りメモの整理表

番号聞いた言葉（そのまま）誰が言ったか（役割）現象か原因か希望か確認したいこと
M-1
M-2
M-3

2. 確認事項と「勝手に決めてはいけないこと」

番号確認する内容誰に確認するか確認前に仮置きしてよいか（可/不可）回答・決定
Q-1
Q-2

3. 利用者と役割

役割誰か（部署・人数の目安）できることできないこと

4. 対象データと状態

データ主な項目状態の種類状態が変わるきっかけ

5. 業務要件一覧

要件ID誰がどの条件で何をできる／できない対象外・備考
REQ-001
REQ-002
REQ-003
REQ-004
REQ-005

6. 受入条件一覧

受入条件（Acceptance Criteria）＝機能が要求を満たしたと判断するための、入力・操作・期待結果まで決めた条件。

受入条件ID対応要件ID前提（利用者・データ・状態）操作期待結果種類（正常／権限なし／入力不足／状態外／重複／途中失敗）
AC-001
AC-002
AC-003

7. 今回は作らないこと（対象外）

項目対象外にした理由将来検討するか

8. 次工程へ渡すもの