# 要件定義ひな形（空欄版）

記事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. 次工程へ渡すもの

- [ ] 業務要件一覧（第5節）
- [ ] 受入条件一覧（第6節）
- [ ] 対象外の一覧（第7節）
- [ ] 未決の確認事項（第2節で回答が空のもの）
- [ ] 承認者（この要件で進めてよいと判断した人）：