requirement-analysis

要件分析（requirement-analysis）

「この要件では結局何をするのか」に答えます。テストを書くのではなく、システムを正しく理解します。

• 入力：PRD、設計ドキュメント、API ドキュメント、Bug、Issue、コードリポジトリ。並行シナリオでは exploratory-testing の探索メモ（システム理解＋リスク一覧）も利用します
• 出力（ファイルに保存）：{プロジェクト}/要件モデル.md——以下の Schema に沿って整理し、明確化の記録とユーザーの裁定を含めます
• 範囲外：テストケースは作成しません（→ test-case-writing）。明確化後も曖昧な項目は open_questions にそのまま記載し、推測で補いません

使用する場面

• PRD／設計ドキュメントを受け取り、テストに進む前に「この要件では結局何をするのか」を体系的に理解する必要がある
• 複数の入力元（ドキュメント＋コード＋Bug 報告）を相互確認し、矛盾や不足を明らかにする必要がある
• test-strategy／test-case-writing に向けて、構造化された要件モデルを用意する

使用しない場面

• 要件全体をエンドツーエンドでテストする → qa でオーケストレーション
• 要件モデルがすでにあり、テストケースを直接書く → test-case-writing（そのフェーズ 1 で簡易的な読み込みを行い、十分であれば事前にモデルを作成する必要はありません）
• 「この機能はどうテストすべきか」→ test-strategy
• ドキュメントがまったくなく、システムにも詳しくない → まず exploratory-testing で探索してから、要件モデルを作成します

要件モデル Schema（出力構造）

requirement_model:
  goal:                     # 需求目标（一句话 + 成功标准）
  scope:                    # 功能范围（含明确的非目标）
  roles: []                 # 角色 → 能做什么 / 不能做什么
  inputs: []                # 输入（来源、格式、约束）
  outputs: []               # 输出（去向、格式、消费方）
  states: []                # 状态与流转（状态A --事件--> 状态B，逐条）
  rules: []                 # 业务规则，每条带 evidence（文档章节或 文件:行）
  exceptions: []            # 异常情况（错误场景的预期行为）
  dependencies: []          # 依赖关系（上下游系统、共享数据、时序依赖）
  open_questions: []        # 不明确事项 → 澄清记录（含用户裁决）

証拠の注記（この段階で ../core/evidence.md を読み込みます）：rules／states／exceptions の各項目に evidence（レベル E0–E4＋source）を付記します。明確化の段階でユーザーが下した裁定は、open_questions の裁定フィールドに記録します。後続の skill はコードを根拠にこの裁定を覆してはなりません。

ワークフロー

1. 入力の収集と棚卸し

• 利用可能な入力元を確認します：PRD／設計ドキュメント／API ドキュメント／Bug 報告／FAQ／議事録／コードリポジトリ
• コードリポジトリがある場合は、積極的に情報を求めます（パス＋ブランチ＋変更範囲＋比較対象のベースライン base——フェーズ 7 で回帰範囲を定める基準になります）。静的な事実については、コードを最も信頼できる情報源とします。ブランチ名＋commit（または取得時刻）＋比較対象のベースラインを要件モデルファイルのヘッダーに記録します。パイプラインを再開するとき、または実行フェーズに進む前に、ブランチが変わっていないことを確認します。古いブランチを対象に作成したモデルの結論は再利用できません。ブランチが変わっていた場合は、影響を受けるフィールドを記載して再確認します
• 探索メモ（探索笔记_{主题}.md）がある場合は、その「システム理解」と「リスク一覧」をモデル作成の入力として利用します
• 不足している入力は open_questions に記載します（例：「性能指標のドキュメントがない」）

2. 初読と要素の抽出

各ドキュメントを通読し、Schema の 10 個のフィールドに沿って要素を収集します：

• goal / scope：目標と成功基準。明示された「対象外」の宣言は個別に記録します（後で検証範囲に反映する必要があります）
• roles：役割ごとに、できること／できないことを整理します（権限マトリクスのたたき台）
• inputs / outputs：データの入力元と出力先、および利用者を整理します（後続の利用者がいない出力は、反証の手がかりです）
• states：状態と遷移。コードがある場合は、コードの状態フィールドから実際の状態遷移を抽出し、ドキュメントと照合します。差異は明確化の対象として記録します
• rules：ビジネスルールを個別に番号付けし、evidence を付記します
• exceptions / dependencies：エラー時の挙動と、上流・下流の依存関係

3. 一貫性の確認（矛盾の発見）

• ドキュメント内の矛盾：同じドキュメント内の異なる箇所で、同じ機能の説明が一致していない
• ドキュメント間の矛盾：PRD と技術設計でルール／フロー／フィールドが一致していない
• ドキュメントとコードの矛盾（コードがある場合）：../core/evidence.md の静的な裁定ルールに従います。原則としてコードを優先し、異なる点を記録して明確化を求めます

4. 明確化（⏸ チェックポイント。推測で補わない）

確認のトリガーとスキャンの唯一の情報源は ../core/clarify-pattern.md です（この段階で読み込みます）：基本的なトリガーは同ファイルの「必ず質問すべき場合」6 項目に従います。詳細スキャンでは、同ファイルの「要件の曖昧さに関する見落としパターン 9 類」A–I に照らして、資料を各パターンごとに確認します（本節では独自のチェックリストを管理しません。skill 間で基準が分裂するのを防ぐためです）。該当した項目は必ず明確化リストに加えます。そのうち I 類（NFR 指標の不足）については、特に注意を促します。性能／互換性の説明は「高速」「安定」「マルチデバイス対応」のように数値がないことがよくあります。指標を確認するか、明示的に対象外とするかのいずれかを質問し、省略してはいけません。

質問の形式と裁定の記録方法も ../core/clarify-pattern.md に統一します（項目ごとに個別カードを作成し、単純な質問は同ファイルの簡潔な一行テンプレートを使います）。ユーザーの回答を待ち、独自に仮定してはいけません。

ユーザーの裁定は open_questions（質問／裁定／根拠）に記録し、最終的な判断として扱います。

5. ファイルへの保存と引き渡し

• Schema に沿って {プロジェクト}/要件モデル.md を作成します。明確化後も曖昧な項目はopen_questions に残し、「未裁定」と記載します。推測でルールに加えてはいけません
• 引き渡し時に、後続の作業（test-strategy／test-case-writing）向けに、モデルのパスと未裁定項目の数を一文で伝えます

よくある間違い

間違い	影響	正しい対応
曖昧な項目を推測して rules に追加する	誤った仮定に基づくモデルとなり、後続の作業すべてに影響します	曖昧な項目は open_questions に加え、ユーザーの裁定を待ちます
PRD だけを読み、コードを読まない（コードがある場合）	ルールと実装が乖離します	コードを優先し、ドキュメントは照合用とします（../core/evidence.md）
テストのアイデアを要件モデルに混ぜる	役割の範囲を逸脱します（それは戦略／テストケースの担当です）	モデルには「システムがどのようなものか／何を求めているか」だけを記載し、「どのようにテストするか」は記載しません
ユーザーの裁定を記録しない	後続の skill が同じ質問を再度行ったり、裁定を覆したりします	裁定を open_questions に記録します。ファイルがパイプラインの状態を示します
対象外の宣言を無視する	テスト範囲が不必要に広がり、「制限の検証」が漏れます	対象外の宣言を scope に個別に記録します
性能／互換性の説明が定性的なだけなのに、そのまま進める	指標のない NFR はテストできず、実行段階でしきい値を場当たり的に設定することになります	9 類のパターンのうち I 類に照らして確認し、数値を尋ねるか、「本バージョンでは検証しない」と明示的に裁定します
新しい事実が出ても、以前の裁定に従い続ける	失効した仮定に基づいて、後続の作業が続いてしまいます	裁定を再度開きます。新旧の証拠を提示してあらためて明確化し、再開分は新しい項目として追加し、既存項目は上書きしません
空のフィールドと抽出漏れを区別できない	後続の作業で「存在しない」のか「調査していない」のか判断できません	保存前に自己確認し、空のフィールドには「確認済み。この種の要素はなし」と記載します