コンテンツにスキップ

3. ユースケースの書き方ガイド

このドキュメントは、ユースケーステンプレート を使用して、 プロジェクトのユースケースを記述するための具体的な方法とベストプラクティスを解説します。

1. 基本的な考え方

ユースケースは、システムがユーザーや他のシステム（アクター）にどのような価値を提供するかを、具体的なシナリオを通じて物語形式で記述するものです。 良いユースケースは、以下の問いに答えることができます。

  • 誰が (アクター): この機能を使うのは誰か？
  • 何を (目的): そのアクターは何を達成したいのか？
  • どのように (フロー): どのような手順で目的を達成するのか？

ユースケースは、技術的な詳細（「どのDBテーブルを更新するか」など）ではなく、システムの外部から見た振る舞いに焦点を当てて記述します。

2. テンプレートの使い方

  1. ファイルの作成:
    • Docs/00_はじめに/02_ドキュメント作成ガイド/テンプレート/から02_ユースケーステンプレート.mdをコピーします。
    • Docs/02_ユースケース/配下に、UC[番号]_[ユースケース名].mdという形式で配置します。（例: UC001_ユーザーの新規登録.md）
  2. 各セクションの記述:
    • テンプレート内のコメント（<!-- ... -->）を参考に、各セクションを埋めていきます。

3. 各セクションの書き方詳細

3.1. アクター

  • アクターは、システムの「外側」にいて、システムと対話する「何か」です。
  • 人間（例: 一般ユーザー, 管理者）だけでなく、外部システム（例: 決済ゲートウェイ, 認証サービス）や、時間（例: 日次バッチのトリガー）もアクターになり得ます。

3.2. 事前条件と事後条件

  • 事前条件: ユースケースを開始するための前提条件です。これが満たされていないと、ユースケースは開始できません。（例: 「ユーザーが商品をカートに入れる」ユースケースの事前条件は「ユーザーがログイン済みであること」）
  • 事後条件: ユースケースが成功裏に完了した後の、システムの最終的な状態です。これは、このユースケースが保証すべきゴールとも言えます。（例: 事後条件は「カートに指定した商品が追加され、在庫数が減少していること」）

3.3. 基本フロー (主成功シナリオ)

  • これは、ユースケースがエラーなく、最も一般的なルートを辿った場合の「ハッピーパス」です。
  • アクターの操作とシステムの応答を、交互に、時系列で具体的に記述します。
  • 良い例:
    1. ユーザーが「カートに入れる」ボタンをクリックする。
    2. システムは、対象商品の在庫を確認する。
    3. システムは、カートに商品を追加し、ユーザーのカート情報を更新する。
    4. システムは、「商品がカートに追加されました」というメッセージを表示する。
  • 悪い例:
    • 商品をカートDBに追加する (←これは内部設計であり、ユースケースで記述すべきことではありません)

3.4. 代替フロー (例外フロー)

  • 基本フローの特定のステップから分岐する、エラーケースや異なるシナリオを記述します。
  • これを洗い出すことで、設計の考慮漏れを防ぎ、システムの堅牢性を高めることができます。
  • 例 (在庫切れの場合):
    • トリガー: 基本フローのステップ2で、対象商品の在庫が0だった場合。
    • フロー:
      1. システムは、「在庫切れです」というエラーメッセージをユーザーに表示する。
      2. ユースケースはここで終了する。

4. システム仕様とのトレーサビリティ

ユースケースは、システム仕様書で定義された要求を実現するための具体的なシナリオです。両者のトレーサビリティを確保することが非常に重要です。

  • 「関連する機能要件」セクション:
    • このユースケースが、どの要求IDを満たすために存在するのかを、必ずリンク付きで明記してください。
    • 複数の要求IDが関連することもあります。

例:

## 9. 関連する機能要件

- [FUNC-CART-1-0](../01_システム仕様/01_機能要件.md#FUNC-CART-1-0)
- [PERF-CART-1-1](../01_システム仕様/02_非機能要件.md#PERF-CART-1-1)