---
name: define-requirements
description: 変更要望をインタビュー形式で明確化し要求仕様を作成する。コード変更はしない。
---

# 要件定義

変更要望を受け取り、インタビュー形式で明確化して要求仕様を作成する。
コード変更は行わない。

## 処理フロー

1. 要望把握: 与えられた変更要望や、Issue / PR などの周辺情報を読み、実現したいことを整理する
2. コードベース調査: 関連する既存コード、ドキュメント、テストを調査し、質問せずに分かる事実を自分で埋める
3. 曖昧さの分類: 不明点を「仕様を変える重大な曖昧さ」と「推奨デフォルトで進められる軽微な曖昧さ」に分ける
4. 質問: 重大な曖昧さについてのみ質問する。各質問になぜ聞くのか、選択肢、推奨を付ける
5. 回答の反映: 回答を受けて要件を更新する。新たな重大曖昧さがあれば3に戻る。なければ6に進む
6. 要求仕様の出力: 重大な曖昧さが全て解消されたら出力する

## 質問の原則

- repo を見れば分かる質問はしない。先に調べる
- 可逆で低リスクな曖昧さは推奨デフォルトを採用し、仮定として明記する。質問しない
- 仕様を変える、重要な前提を確定する、意味のあるトレードオフを選ぶ、のいずれかに該当する場合のみ質問する
- 各質問に選択肢、選択肢記号、推奨を付け、答えやすくする
- 回答後に新たな重大曖昧さが出なければ即座に仕様出力に移る。質問を発散させない

## 確認すべき観点

以下の観点で不明点がないか確認する。全て質問する必要はなく、重大な曖昧さがある観点のみ質問する。

- 背景と目的
- 利用者
- 成功条件
- 対象範囲と対象外
- 制約
- 既存との互換性
- 異常系と境界条件
- 優先順位とトレードオフ

## 要求仕様の原則

- read-only。コードベースの調査のみ行い変更しない
- 受入基準は観測可能な振る舞いで書く。「仕様通り動く」のような主観的表現を使わない
- 要件文は曖昧語を避け、検証可能に書く
- 軽微な曖昧さに対して採用したデフォルトは仮定として明記する
- 判断できない事項は黙って埋めず未確定事項として残す

## 出力形式

以下の構成で報告する。

### 背景と目的

要望の背景と実現したいことを記述する。

### 利用者

この変更の利用者を記述する。

### スコープ

対象範囲と、対象外を明記する。

### 機能要件

要件を箇条書きで記載する。

### 受入基準

観測可能な振る舞いとして箇条書きで記載する。

### 制約

技術的・運用的な制約を記載する。

### 仮定

軽微な曖昧さに対して採用した推奨デフォルトを記載する。該当なしなら「なし」と書く。

### 未確定事項

判断を保留した事項と判断材料を記載する。該当なしなら「なし」と書く。