name: define-requirements description: 変更要望をインタビュー形式で明確化し要求仕様を作成する。コード変更はしない。
要件定義
変更要望を受け取り、インタビュー形式で明確化して要求仕様を作成する。 コード変更は行わない。
処理フロー
- 要望把握: 与えられた変更要望や、Issue / PR などの周辺情報を読み、実現したいことを整理する
- コードベース調査: 関連する既存コード、ドキュメント、テストを調査し、質問せずに分かる事実を自分で埋める
- 曖昧さの分類: 不明点を「仕様を変える重大な曖昧さ」と「推奨デフォルトで進められる軽微な曖昧さ」に分ける
- 質問: 重大な曖昧さについてのみ質問する。各質問になぜ聞くのか、選択肢、推奨を付ける
- 回答の反映: 回答を受けて要件を更新する。新たな重大曖昧さがあれば3に戻る。なければ6に進む
- 要求仕様の出力: 重大な曖昧さが全て解消されたら出力する
質問の原則
- repo を見れば分かる質問はしない。先に調べる
- 可逆で低リスクな曖昧さは推奨デフォルトを採用し、仮定として明記する。質問しない
- 仕様を変える、重要な前提を確定する、意味のあるトレードオフを選ぶ、のいずれかに該当する場合のみ質問する
- 各質問に選択肢、選択肢記号、推奨を付け、答えやすくする
- 回答後に新たな重大曖昧さが出なければ即座に仕様出力に移る。質問を発散させない
確認すべき観点
以下の観点で不明点がないか確認する。全て質問する必要はなく、重大な曖昧さがある観点のみ質問する。
- 背景と目的
- 利用者
- 成功条件
- 対象範囲と対象外
- 制約
- 既存との互換性
- 異常系と境界条件
- 優先順位とトレードオフ
要求仕様の原則
- read-only。コードベースの調査のみ行い変更しない
- 受入基準は観測可能な振る舞いで書く。「仕様通り動く」のような主観的表現を使わない
- 要件文は曖昧語を避け、検証可能に書く
- 軽微な曖昧さに対して採用したデフォルトは仮定として明記する
- 判断できない事項は黙って埋めず未確定事項として残す
出力形式
以下の構成で報告する。
背景と目的
要望の背景と実現したいことを記述する。
利用者
この変更の利用者を記述する。
スコープ
対象範囲と、対象外を明記する。
機能要件
要件を箇条書きで記載する。
受入基準
観測可能な振る舞いとして箇条書きで記載する。
制約
技術的・運用的な制約を記載する。
仮定
軽微な曖昧さに対して採用した推奨デフォルトを記載する。該当なしなら「なし」と書く。
未確定事項
判断を保留した事項と判断材料を記載する。該当なしなら「なし」と書く。