要件と完了条件：望む動作を合意する

なぜ必要なのか

「買い物かごを作って」という依頼は、同じ本を二度追加した瞬間に曖昧になります。二行を期待する人も、数量二を期待する人も、重複禁止を期待する人もいます。どれも実装できますが、利用者が望んだ結果とは限りません。内部のデータ構造を選ぶ前に、見える動作の合意が必要です。

どう解決するのか

1. 一つの成果から始めます。例えば、読者が選んだ本を失わず注文を準備できることです。誰がどこから始め、初回公開では何をしないかも決めます。推薦や割引が今回の目的に不要なら後回しにします。機能名の一覧より、利用者が終えたい作業を範囲の基準にします。
2. 実際の値でたどります。空のかごに本Aを入れ、もう一度入れたら一行で数量二と合意します。一冊減らせば数量一か、在庫不足なら元のかごを保つかも決めます。これは製品の動作です。配列やマップの選択は、合意した動作に合わせてAIが決められます。
3. 不都合な経路も確認します。保存中、通信失敗後、連続した押下で何を表示するでしょうか。意図した二冊目の追加と、同じ要求が二度届くことは別です。未決定なら内部用語を質問するより、期待する結果を聞きます。失敗を成功として扱わないようにします。
4. 判断を確認可能な文に変えます。初期状態と在庫を与え、操作した後の行、数量、通知を比べます。「速い」も対象条件と測定可能な基準に直します。どの製品にも通用する数値を勝手に設定せず、必要な水準を合意します。検証で何を見るかが分かる形にします。
5. AIがシナリオ、未解決の質問、確定事項を記録します。要件に識別子を付けると実装作業や確認結果を結び付けられます。範囲が変われば影響する条件と理由も更新します。古いテストが、いつの間にか現在の製品方針を決める状態を避けます。

これらの例だけを使って、協力者と結果を予測してみます。成功、失敗、繰り返しで同じ答えになれば具体的な実装計画へ進めます。長い文書があっても重要な動作の答えが違うなら合意は不足しています。不明点は不明とし、判断する人と必要な情報を残す方が役に立ちます。

確認するときは操作前の状態もそろえます。条件の違う画面同士を比べても、同じ要求を満たしたか判断できません。

どんな考え方なのか

観察できる動作と制約を記述し、受け入れ条件で確認するのが要件定義です。SRSは合意を整理する形式の一つで、ストーリーやシナリオは補助手段です。利用者が文書形式から選ぶ必要はありません。NASAのチェックリストは明確で検証可能な要件を支えます。AIは重要な判断の背景と結果を記録し、製品の決定権は利用者に残します。