Analyzing Requirements

---
name: analyzing-requirements
description: ユーザー要件を分析し、システム設計ドキュメント(DESIGN.md)を生成します。ユーザー要件が曖昧または不明確な場合、システムアーキテクチャの設計が必要な場合、大規模な機能開発の設計仕様が必要な場合、技術的実現可能性の検証が必要な場合に使用します。不明点はAskUserQuestionツールで確認します。
---

# 要件分析

## 概要

曖昧なユーザーリクエストを具体的で実行可能な設計仕様に変換する。要件を深く理解し、技術的実現可能性を検証し、アーキテクチャを設計し、開発者が従える詳細な設計ドキュメント(DESIGN.md)を生成する。

注: タスク分解とTODO.md生成は planning-tasks スキルで行う

## 参照ルール

- 設計原則: `rules/core/design.md`（SOLID、高凝集度、低結合度）

## コアワークフロー

### ステップ0: 前提ドキュメントの読み込み

前のステップの出力ファイルを読み込む。

#### 読み込み対象
- `docs/USECASES.md`
- `docs/FEASIBILITY.md`
- `docs/GLOSSARY.md`
- `docs/DOMAIN_MODEL.md`

```javascript
Read({ file_path: "docs/USECASES.md" })
Read({ file_path: "docs/FEASIBILITY.md" })
Read({ file_path: "docs/GLOSSARY.md" })
Read({ file_path: "docs/DOMAIN_MODEL.md" })
```

#### ファイルが存在する場合

読み込んだ内容から以下を抽出：
- ユースケース: 機能要件の元
- 技術検証結果: 技術選定の制約
- 用語集: データモデルの元
- ドメインモデル: エンティティ設計の元

**遷移条件**: ステップ1へ（要件理解を効率化）

#### ファイルが存在しない場合

ステップ1でAskUserQuestionを使って要件を確認。

**遷移条件**: ステップ1へ

### ステップ1: 要件の理解と分析

ユーザーリクエストを複数の観点から分析する：

**何を構築するか（What）**
- コア機能の特定
- 機能スコープの定義
- ユーザーインターフェース要件

**目的と価値（Why）**
- ビジネス価値の分析
- 解決する問題
- 成功指標

**使用パターン（How）**
- ユーザーインタラクションフロー
- 統合ポイント
- パフォーマンス要件

**タイムライン（When）**
- 納品期待値
- マイルストーン計画
- 依存関係のタイミング

**対象ユーザー（Who）**
- ユーザーペルソナ
- アクセスパターン
- スキルレベルの考慮

### ステップ2: 不確実性の解消

**必須: 決して仮定を立てない**

利用可能なツールを使用して既存の実装を調査する：
```bash
# 関連する実装を検索
Grep(pattern="relevant-keyword")
Read(file_path="related-file")
Glob(pattern="**/*.{js,ts,py}")
```

情報が不足している場合、AskUserQuestionツールを使用してユーザーに確認する：
```javascript
AskUserQuestion({
  questions: [
    {
      question: "この機能の認証方式はどれを使用しますか？",
      header: "認証方式",
      options: [
        {
          label: "JWT",
          description: "JSON Web Tokenを使用したステートレス認証"
        },
        {
          label: "Session",
          description: "サーバーサイドセッション管理"
        },
        {
          label: "OAuth 2.0",
          description: "外部認証プロバイダーとの連携"
        }
      ],
      multiSelect: false
    }
  ]
})
```

不明点が複数ある場合は、一度に複数の質問（最大4つ）を行うことができる
質問がなくなるまで繰り返して確認する

### ステップ3: 要件定義の作成

要件を明確に構造化する：

#### 機能要件
- 必須機能（MUST have）
- オプション機能（NICE to have）
- 将来の拡張性の考慮

#### 非機能要件
- パフォーマンス目標
- セキュリティ要件
- 保守性基準
- スケーラビリティニーズ

#### 制約
- 技術的制約（言語、フレームワーク、依存関係）
- 時間的制約（締め切り、マイルストーン）
- リソース制約（チームサイズ、インフラ）

### ステップ4: アーキテクチャ設計

システム全体の構成と技術選定を行う：

**システム構成**
- コンポーネント構成と責務分担
- レイヤーアーキテクチャ（プレゼンテーション層、ビジネスロジック層、データアクセス層）
- モジュール間の依存関係
- 通信プロトコルとインターフェース

**技術選定**
- プログラミング言語とフレームワーク
- データベース選定（RDBMS、NoSQL、キャッシュ）
- 外部サービス連携（認証、決済、通知など）
- インフラストラクチャ（クラウド、コンテナ、CI/CD）

**データ設計**
- データモデル定義
- エンティティ関係図（ER図）
- データフロー図
- API設計（エンドポイント、リクエスト/レスポンス仕様）

**非機能要件の設計**
- セキュリティ対策（認証、認可、暗号化、脆弱性対策）
- パフォーマンス最適化（キャッシング、クエリ最適化、非同期処理）
- スケーラビリティ（負荷分散、水平スケール、垂直スケール）
- 可用性と信頼性（冗長化、バックアップ、障害復旧）

**エラー戦略**
- エラー分類（回復可能/不可能、ユーザー起因/システム起因）
- エラーハンドリング方針（例外処理、Result型、エラーコード）
- リトライポリシー（回数、間隔、バックオフ戦略）
- フォールバック処理（代替動作、グレースフルデグラデーション）
- エラーログ・通知（ログレベル、アラート条件）

**テスト戦略**
- テストピラミッド（単体/統合/E2Eの比率と範囲）
- カバレッジ目標（ライン、ブランチ、重要パスの基準）
- テストデータ戦略（フィクスチャ、ファクトリ、シード）
- モック/スタブ方針（外部依存の扱い）
- CI統合（テスト実行タイミング、失敗時の動作）

### ステップ5: ドキュメント生成

設計ドキュメント(DESIGN.md)を生成する。

テンプレートは [design-template.md](references/design-template.md) を参照。

### ステップ6: ファイル出力

設計ドキュメントを書き出す：
```javascript
// docsディレクトリにDESIGN.mdを出力
Write(
    file_path="docs/DESIGN.md",
    content=designContent
)
```

### ステップ7: セルフレビュー

生成したDESIGN.mdをセルフレビューし、問題がなくなるまで修正を繰り返す。

#### レビュー観点

1. **完全性**: すべての要件がカバーされているか
2. **一貫性**: 用語・表記・設計方針が統一されているか
3. **実現可能性**: 技術的に実装可能な設計か
4. **明確性**: 曖昧な表現や不明確な箇所がないか
5. **整合性**: 各セクション間で矛盾がないか

#### レビュープロセス

```
1. DESIGN.mdを読み返す
2. 以下のチェックリストで問題を洗い出す
3. 問題があれば修正してファイルを更新
4. 問題がなくなるまで1-3を繰り返す（最大3回）
```

#### セルフレビューチェックリスト

**要件の完全性**
- [ ] 機能要件がすべて網羅されている
- [ ] 非機能要件が具体的な数値で定義されている
- [ ] エラー戦略とテスト戦略が定義されている

**設計の明確性**
- [ ] アーキテクチャ図または構成が理解しやすい
- [ ] データモデルとAPI設計が具体的
- [ ] 技術選定の理由が明記されている

**実装への橋渡し**
- [ ] planning-tasksスキルでタスク分解できる粒度になっている
- [ ] 開発者が迷わず実装を開始できる情報量がある
- [ ] 依存関係と制約が明確

#### 問題発見時の対応

問題を発見した場合：
1. 問題箇所を特定
2. 修正内容を決定
3. DESIGN.mdを更新
4. 再度レビューを実行

3回のレビューで解決しない問題がある場合は、AskUserQuestionツールでユーザーに確認する。

## 品質チェックリスト

設計完了前に確認：
- [ ] すべての要件が設計に反映されている
- [ ] 技術的実現可能性が確認されている
- [ ] アーキテクチャ設計が明確で実装可能
- [ ] 非機能要件（セキュリティ、パフォーマンス等）が考慮されている
- [ ] エラー戦略とテスト戦略が定義されている
- [ ] データ設計とAPI設計が明確
- [ ] 技術スタックの選定理由が明確
- [ ] 制約と前提が文書化されている
- [ ] 不明点はAskUserQuestionツールで確認済み
- [ ] DESIGN.mdが生成されている
- [ ] セルフレビューが完了し、問題が解消されている

### 関連スキル
- **planning-tasks**: DESIGN.md完成後、このスキルを使用してタスク分解とTODO.md生成を行う