k2works/analyzing-usecases

ユースケース・ユーザーストーリー作成

要件定義からユースケースを抽出し、ユーザーストーリーまで一貫したトレーサビリティを維持しながら作成する。

ビジネスユースケース→システムユースケース→ユーザーストーリーの 3 段階で具体化することで、「ビジネス要求」と「実装タスク」の間の論理的なつながりを保証する。

参照ドキュメントとテンプレート

| 種類 | パス | 備考 | |------|------|------| | ガイド | @docs/reference/ユースケース作成ガイド.md | ユースケース作成の進め方詳細 | | テンプレート | @docs/template/完全形式のユースケース.md | 編集禁止。参照のみ | | 入力 | @docs/requirements/requirements_definition.md | 要件定義 | | 成果物 | docs/requirements/business_usecase.md | ビジネスユースケース | | 成果物 | docs/requirements/system_usecase.md | システムユースケース | | 成果物 | docs/requirements/user_story.md | ユーザーストーリー |

作成の 3 ステップ

ステップ 1: ビジネスユースケース作成

要件定義からビジネスレベルのユースケースを抽出する。システムの詳細には踏み込まず、業務目標とアクターの関係を定義する。

• 要件定義のシステム外部環境（層 2）を起点にアクターとユースケースを識別する
• アクターとユースケースの関係を PlantUML で図示する

ステップ 2: システムユースケース作成

ビジネスユースケースをシステム境界の視点で詳細化する。「システムが何を提供するか」を明確にする。

• ビジネスユースケースの各項目をシステムレベルに分解する
• システム境界を明確にし、テンプレートの完全形式で記述する

ステップ 3: ユーザーストーリー作成

システムユースケースから開発可能な粒度のユーザーストーリーを導出する。

• 「〜として、〜したい。なぜなら〜だからだ」の形式で記述する
• 各ストーリーに受け入れ基準を定義する
• ユースケースとの対応関係を明記してトレーサビリティを確保する

途中から再開・更新

既存の成果物がある場合は、まず現在の状態を確認する。不足しているステップや更新が必要な部分のみを修正する。

Example:

ユーザー: 「ビジネスユースケースは作った。ユーザーストーリーを書きたい」
回答: ステップ 2（システムユースケース）の存在を確認する。
      未作成ならステップ 2 から開始。作成済みならステップ 3 に進む。
      既存のビジネスユースケースのアクターとユースケースを起点に、
      システムユースケースを詳細化してからユーザーストーリーを導出する。

注意事項

• 入力の requirements_definition.md が存在しない場合は analyzing-requirements を先に実行する
• テンプレートは編集禁止。参照のみとし、成果物は別ファイルに作成する
• user_story.md にはユーザーストーリーのみ記述する。リリース計画・イテレーション計画は planning-releases で別途作成する
• タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）

関連スキル

• analyzing-requirements — 前段の要件定義（RDRA 2.0）
• planning-releases — 後続のリリース・イテレーション計画
• orchestrating-analysis — 分析フェーズ全体のワークフロー案内