ユースケース記述は、アクターがシステムと相互作用することで目標を達成する方法を説明します。これはユースケース図を補完するものです：

• ユースケース図：アクター、システムのスコープ、および関係性を示します。

• ユースケース記述：詳細な動作、条件、ルール、および結果を説明します。

図は地図を提供し、記述はルートを提供します。

1. ユースケースとは何か？

ユースケースは、外部アクターがシステムを通じて達成する価値ある目標を表します。

例：

• 顧客が注文を行う

• 従業員が経費精算を提出する

• 患者が予約をスケジュールする

• 管理者がユーザーアカウントを作成する

• 顧客がパスワードをリセットする

良いユースケースは次のようなものです：

• 目標指向である

• アクターにとって価値がある

• ユーザーの視点から記述される

• 特定の画面レイアウトに依存しない

• 観測可能なシステムの動作に焦点を当てる

不適切なユースケース名と改善された名前の比較

“のような短い動詞名詞句を使用する経費精算を提出する, 配送を追跡する、または融資申請を承認する.

2. 主要概念

2.1 アクター

アクターとは、システムと相互作用する外部の役割である。

アクターは次のいずれかである可能性がある：

• 個人

• 組織

• 別のソフトウェアシステム

• ハードウェアデバイス

• スケジュールまたは時間ベースのトリガー

例：

• 顧客

• サポートエージェント

• 倉庫係員

• 決済ゲートウェイ

• メールサービス

• 管理者

アクターとは役割であり、必ずしも特定の個人を指すわけではありません。例えば、「顧客」という表現は、「ジェーン・スミス」という具体的な名前よりも一般的に好まれます。

主役のアクターと支援アクター

支援アクターは目的を達成するためにユースケースを開始します。

支援アクターは実行中にシステムを支援します。

例：

• 主役のアクター：顧客

• 支援アクター：決済ゲートウェイ

• ユースケース：注文を行う

顧客が注文を開始し、決済ゲートウェイが支払いを承認します。

2.2 システム境界

システム境界は、モデル化対象のシステムに含まれるものを定義します。

オンラインストアの場合、境界内には以下が含まれる可能性があります：

• 商品の閲覧

• 商品をカートに追加

• 注文を行う

• 支払いを行う

• 注文を追跡

以下のものは境界の外にあります：

• 顧客

• 決済ゲートウェイ

• 配送会社

• メールプロバイダー

境界線は、システムの責任に関する混乱を防ぎます。

2.3 ユースケース

ユースケースは、意味のある結果を生み出す完全な相互作用を記述すべきです。

例：

注文の発行：顧客が製品を選択し、配送情報を提供し、注文の支払いを行い、注文確認を受領します。

「クレジットカード番号の検証」はシステム機能である可能性がありますが、通常は単独のユーザー目標として小さすぎます。代わりに、次の一部である可能性があります。注文の発行 または 支払いの実行.

2.4 事前条件

事前条件は、ユースケースが始まる前にすでに真でなければならないことを示します。

例：

• 顧客は有効なアカウントを保持しています。

• 製品は販売可能です。

• 従業員は認証されています。

• 予約枠が存在します。

• ショッピングカートには少なくとも1つのアイテムが含まれています。

事前条件は、ユースケースによって実行されるアクションではありません。

不適切な事前条件：

顧客がログインします。

より適切な事前条件：

顧客は認証されています。

2.5 事後条件

事後条件は、ユースケースが終了した後に真となることを示します。

例：

• 注文が記録されます。

• 支払いが承認されます。

• 確認メールが送信されます。

• 経費精算は提出済みステータスです。

• ユーザーアカウントはアクティブとしてマークされています。

事後条件は結果を記述すべきであり、実装の詳細を記述すべきではありません。

不適切な事後条件：

「注文」テーブルが更新されます。

より適切な事後条件：

注文は保存され、履行可能となっています。

2.6 主要成功シナリオ

主要成功シナリオは、「基本フロー」または「ハッピーパス」と呼ばれ、通常の成功した相互作用を記述します。

各ステップは以下を記述すべきです：

1. アクターとシステムとの相互作用

2. システムの応答

3. 意味のあるビジネスアクション

例：

1. 顧客が製品を選択します。

2. システムが現在のショッピングカートを表示します。

3. 顧客が配送情報を入力します。

4. システムが配送情報を検証します。

5. 顧客が注文を提出します。

6. システムが支払いの承認を要求します。

7. 決済ゲートウェイが支払いを承認します。

8. システムが注文を記録します。

9. システムが注文確認を表示します。

要件に不可欠でない限り、インターフェース固有の詳細は避けてください。

不適切なステップ：

顧客が右下隅の青いボタンをクリックします。

より適切なステップ：

顧客が注文を提出します。

2.7 代替フロー

代替フローは、メインシナリオの有効なバリエーションを記述します。

例：

• 顧客は配送ではなく店舗受取を選択します。

• 顧客は保存された支払い方法で支払います。

• 管理者が条件付きで請求を承認します。

• ユーザーはワンタイムコードを使用して認証します。

代替フローはメインフローに再接続する場合があります。

例：

A1. 顧客は保存された支払い方法を使用します
ステップ6で、顧客は保存された支払い方法を選択します。システムはその方法で承認を要求し、その後ステップ7に進みます。

2.8 例外フロー

例外フローは、不成功または異常な状況を記述します。

例：

• 支払いが拒否されました。

• 商品が在庫切れです。

• 認証に失敗しました。

• 外部サービスが利用できません。

• 必要なデータが無効です。

例外フローは以下の点を説明すべきです：

• 問題が発生する場所

• システムが何を行うか

• アクターが何を見るか

• ユースケースが終了するか、再開するか

例：

E1. 支払いが拒否されました
ステップ7で、決済ゲートウェイが取引を拒否します。システムは理由を表示し、注文を未払いとしてマークし、顧客に別の支払い方法を選択できるようにします。

2.9 include 関係と extend 関係

include

使用 includeは、あるユースケースが常に別の再利用可能な振る舞いを呼び出す場合に使用します。

例：

• 注文作成は合計計算を含みます

• 注文作成は顧客認証を含みます

• 現金引き出しは PIN 確認を含みます

含まれる振る舞いは必須です。

注文作成 <<include>> 合計計算

extend

使用 extendは、オプションまたは条件付きの振る舞いが基本のユースケースを補完する場合に使用します。

例：

• 注文作成は割引コード適用によって拡張される場合があります

• チェックアウトはギフトメッセージ追加によって拡張される場合があります

拡張される振る舞いは常に実行されるわけではありません。

割引コード適用 <<extend>> 注文作成

有用なルール：

• include：「これはユースケースの一部として常に発生します。」

• extend：「これは特定の条件下で発生する場合があります。」

使用しないでください includeおよび 拡張単にすべてのフローを小さな部分に分割するため。過度な分解はモデルを理解しにくくする。

2.10 一般化

一般化は、アクターまたはユースケース間の継承を表す。

例：

• 従業員は一般的なアクターである。

• マネージャーは、従業員の振る舞いを継承する専門的なアクターである。

マネージャー --|> 従業員

専門的な要素が一般化された要素の真のタイプである場合にのみ一般化を使用すること。単に2つの要素がいくつかのステップを共有しているからといって使用してはならない。

3. 標準的なユースケース記述テンプレート

以下のテンプレートは、要件定義書、プロジェクト仕様書、および分析モデルに適切に機能する。

ユースケースID:
ユースケース名:
目的:
範囲:
レベル:
主要アクター:
支援アクター:
利害関係者と関心:

トリガー:

事前条件:

最小保証:

成功保証:

主要成功シナリオ:
1.
2.
3.

代替フロー:
A1.
A2.

例外フロー:
E1.
E2.

特別要件:
- パフォーマンス
- セキュリティ
- 使いやすさ
- 可用性
- 準拠

ビジネスルール:

データ要件:

頻度と量:

前提条件:

未解決の質問:

関連ユースケース:

フィールドの説明

4. 例：注文を行う

UC-001 — 注文を行う

目的：
顧客が1つ以上の製品を購入できるようにする。

範囲：
オンラインストア

レベル：
ユーザーの目標

主要アクター:
顧客

支援アクター:

• 決済ゲートウェイ

• 在庫サービス

• メールサービス

• 配送サービス

利害関係者と関心事項:

• 顧客:製品を正常に購入し、確認を受け取りたい。

• 店舗:有効な注文を記録し、代金を回収したい。

• 倉庫:正確な出荷情報が必要である。

• 決済ゲートウェイ:有効な支払いリクエストが必要である。

• 配送サービス:完全な配送住所が必要である。

トリガー:
顧客がショッピングカートをチェックアウトのために提出する。

事前条件:

• 顧客はカートに少なくとも1つの商品を保有している。

• 製品は注文可能である。

• 顧客は有効な配送住所を提供する。

• システムは決済サービスと通信できる。

最小保証:

• 未払いの注文は確認済みとして扱われない。

• 注文が完了できない場合、顧客は通知される。

• 支払いが失敗した場合、予約された在庫は解放される。

成功の保証：

• 支払いが承認されました。

• 注文が記録されました。

• 在庫が予約されました。

• 顧客は確認を受け取ります。

• 納品情報が倉庫に提供されます。

主要な成功シナリオ

1. 顧客はショッピングカートを確認します。

2. システムは商品、数量、価格、税金、送料、合計を表示します。

3. 顧客は配送情報を提供します。

4. システムは配送情報を検証します。

5. 顧客は支払い方法を選択します。

6. 顧客は注文を提出します。

7. システムは商品の在庫状況を確認します。

8. システムは決済ゲートウェイに対して支払いの承認を要求します。

9. 決済ゲートウェイが支払いを承認します。

10. システムは注文を作成します。

11. システムは注文された商品を予約します。

12. システムは顧客に注文確認を送信します。

13. システムは注文番号と推定配送日を表示します。

代替フロー

A1. 顧客は保存された住所を使用します

ステップ3で、顧客は以前保存された住所を選択します。システムはその住所を表示し、ステップ4に進みます。

A2. 顧客は保存された支払い方法を使用します

ステップ5で、顧客は保存された支払い方法を選択します。システムはその方法を使用し、ステップ6に進みます。

A3. 顧客は店舗受取を選択します

ステップ3で、顧客は配送ではなく店舗受取を選択します。システムは利用可能な店舗と受取日を表示し、その後ステップ5に進みます。

例外フロー

E1. 商品が利用できません

ステップ7で、システムは商品が利用できないことを判断します。システムは利用できない商品を特定し、カートを更新して、顧客に注文の確認を求めます。

E2. 支払いが拒否されました

ステップ9で、決済ゲートウェイが支払いを拒否します。システムは注文を確認せず、在庫予約を解放し、失敗メッセージを表示し、顧客に別の支払い方法を選択させます。

E3. 決済ゲートウェイが利用できません

ステップ8で、決済ゲートウェイが設定されたタイムアウト内に応答しません。システムは支払い試行を保留中とマークし、顧客に通知し、注文の重複送信を防ぎます。

ビジネスルール

• 注文には少なくとも1つの商品が含まれている必要があります。

• 商品の数量は0より大きくなければなりません。

• 在庫が不足している場合、商品は注文できません。

• 注文が確定する前に支払いの承認が必要です。

• 価格と税金は、現在の価格設定ルールに基づいて計算されます。

• 顧客は、納品処理が始まる前のみ注文をキャンセルできます。

特別な要件

• 注文サマリーは、通常の負荷下で2秒以内に表示される必要があります。

• 支払い情報は平文で保存してはなりません。

• 重複した送信は重複した注文を作成してはなりません。

• システムは、支払いと注文ステータスの変更に対する監査証跡を記録する必要があります。

5.ユースケースのレベル

ユースケースの説明は、異なる詳細レベルで記述できます。

要約レベルのユースケース

要約ユースケースは、広範なビジネスプロセスを記述します。

例：

顧客注文の履行

これには以下が含まれる場合があります：

• 注文の受領

• 商品のピッキング

• 注文のパッキング

• 注文の出荷

ユーザー目標レベルのユースケース

これは通常、要件分析において最も有用なレベルです。

例：

注文を確定する

これは、主要なアクターが一度のセッションで達成できる目標を記述したものです。

サブ関数レベルのユースケース

これは、より小さく再利用可能なシステム動作を記述したものです。

例：

• 注文合計の計算

• 支払いの検証

• 請求書の生成

動作が再利用される場合や技術的に複雑な場合に、サブ関数レベルのユースケースは有用ですが、ユーザー目標ユースケースを置き換えるべきではありません。

6. 高品質なユースケース記述の作成

アクター中心の言語を使用する

アクターの視点から記述する：

顧客が注文を提出する。

実装中心の表現を避ける：

OrderController が注文サービスを呼び出す。

後者は設計ドキュメントに属するものであり、ビジネスユースケースには含まれるべきではありません。

各ステップを原子（単一）に保つ

多くのアクションを組み合わせない：

顧客は詳細を入力し、支払いを選択し、注文を確認し、メールを受け取る。

インタラクションを分離することで改善する：

1. 顧客は配送情報を入力する。

2. システムは情報を検証する。

3. 顧客は支払い方法を選択する。

4. 顧客は注文を確認する。

5. システムは確認を送信する。

観測可能な動作を記述する

読者は、要件が実装されたかどうかを判断できるべきである。

弱い：

システムはリクエストを処理する。

より強い：

システムはリクエストを検証し、請求を記録し、請求番号を割り当て、送信ステータスを表示します。

早すぎるUIデザインを避ける

使用：

顧客は配送情報を提供します。

～ではなく：

顧客は住所をテキストボックスに入力し、緑色の「続ける」ボタンをクリックします。

2番目のバージョンは、不必要にインターフェースを制約しています。

メインフローを成功させる

基本フローにありとあらゆるエラーを詰め込まないでください。エラーは例外フローに含めてください。

ビジネスルールを別々に特定する

ビジネスルールは複数のユースケースに適用されることがよくあります。それらを分離しておくことで、繰り返しや矛盾するテキストを防ぎます。

失敗時の挙動を明確にする

重要な失敗ごとに、以下を指定してください：

• データが保存されるかどうか

• トランザクションがロールバックされるかどうか

• アクターが再試行できるかどうか

• 管理者に通知されるかどうか

• ユースケースが終了するか、再開されるかどうか

7. 要件からユースケースへ

実用的なワークフローは次の通りです：

1. モデル化するシステムを特定する。

2. 外部アクターをリストアップする。

3. 各アクターが達成したいことを尋ねる。

4. 各目標をユースケース名に変換する。

5. システムの境界を定義する。

6. 主要な成功シナリオを書く。

7. 代替フローと例外フローを追加する。

8. ビジネスルールと特別要件を追加する。

9. ユースケース図を描く。

10. ステークホルダーとモデルを検証する。

11. ユースケースを要件、テスト、設計アーティファクトにリンクします。

アクター・ゴール分析

有用な質問は次の通りです：

このアクターがシステムから必要とするビジネス上の成果は何ですか？

8. ユースケース図の記法

最も一般的な要素は次の通りです：

• アクター：外部の役割

• ユースケース：システム機能またはアクターの目標

• システム境界:システムの範囲

• 関連:アクターがユースケースに参加する

• 包含:必須の再利用可能な振る舞い

• 拡張:オプションまたは条件付きの振る舞い

• 一般化:専門化されたアクターまたはユースケース

ユースケース図は以下のことを示そうとすべきではありません:

• すべてのワークフローステップ

• データベーステーブル

• クラスの属性

• 詳細なビジネスルール

• 画面レイアウト

• 内部アルゴリズム

それらはアクティビティ図、クラス図、シーケンス図、または書面による要件に含まれるべきです。

9. PlantUML ダイアグラムの例

以下の例は、注文の発行ユースケースおよび関連する振る舞いをモデル化しています。

@startuml
左から右の方向

skinparam packageStyle rectangle
skinparam shadowing false
skinparam usecase {
    BackgroundColor #F8FBFF
    BorderColor #2F5597
    ArrowColor #555555
}

actor Customer
actor "Payment Gateway" as Payment
actor "Inventory Service" as Inventory
actor "Email Service" as Email
actor "Delivery Service" as Delivery

rectangle "Online Store" {
    usecase "Browse Products" as Browse
    usecase "Manage Cart" as Cart
    usecase "Place Order" as PlaceOrder
    usecase "Calculate Order Total" as CalculateTotal
    usecase "Check Product Availability" as CheckStock
    usecase "Authorize Payment" as AuthorizePayment
    usecase "Reserve Inventory" as ReserveInventory
    usecase "Send Order Confirmation" as SendConfirmation
    usecase "Track Order" as TrackOrder
    usecase "Apply Discount Code" as ApplyDiscount
}

Customer --> Browse
Customer --> Cart
Customer --> PlaceOrder
Customer --> TrackOrder

Payment --> AuthorizePayment
Inventory --> CheckStock
Inventory --> ReserveInventory
Email --> SendConfirmation
Delivery --> TrackOrder

PlaceOrder ..> CalculateTotal : <<include>>
PlaceOrder ..> CheckStock : <<include>>
PlaceOrder ..> AuthorizePayment : <<include>>
PlaceOrder ..> ReserveInventory : <<include>>
PlaceOrder ..> SendConfirmation : <<include>>

ApplyDiscount ..> PlaceOrder : <<extend>>

@enduml

解釈

• 「顧客 開始する 注文を確定する.

• 注文を確定する 常に計算、在庫確認、支払い承認、在庫予約、および確認を含みます。

• 割引コードを適用する はオプションであるため、これを拡張します 注文を確定する.

• 外部サービスは特定のシステム動作に関与します。

• システム境界は「 オンラインストア」の矩形です。

要素の正確な配置はレンダリングエンジンによって制御されます。重要なモデリングの決定事項は、アクター、ユースケース、境界、および関係です。

10. Visual Paradigm VPasCodeでの図の作成

VPasCodeは、PlantUML、Mermaid、Graphviz、およびその他の図形式をサポートするブラウザベースのテキストから図へのプラットフォームです。ソース編集とライブレンダリングを提供し、コードの変更に応じて図が自動的に更新されます。

基本ワークフロー

1. VPasCodeエディタを開きます。

2. 新しいPlantUML図を作成します。

3. PlantUMLソースを貼り付けます。

4. エディタがPlantUML構文を認識していることを確認します。

5. ライブプレビューを確認します。

6. ソースペインでアクター、ユースケース、関係、およびスタイルを編集します。

7. レンダリングされた図をエクスポートまたはコピーします。

8. 図をプロジェクトドキュメントに追加します。

VPasCodeはPlantUMLユースケース図をサポートし、ブラウザでのリアルタイムレンダリングを提供します。また、PlantUML図の例とスタイルオプションも提供しています。

AI支援生成のためのプロンプト例

AIによる図生成機能を使用する場合、有用なプロンプトは次の通りです：

オンラインストア用のPlantUMLユースケース図を作成してください。

主要アクター:
- 顧客

サポートアクター:
- 決済ゲートウェイ
- 在庫サービス
- メールサービス
- 配送サービス

主要ユースケース:
- 商品閲覧
- カート管理
- 注文を確定する
- 注文追跡

注文を確定するには、以下の処理を含める必要があります:
- 注文合計の計算
- 商品の在庫確認
- 支払い承認
- 在庫の予約
- 注文確認の送信

割引コードの適用は、注文を確定するユースケースを拡張するものとします。

システム境界には「オンラインストア」という名前を使用してください。

生成されたコードを出発点として扱い、以下の点を確認してください:

• アクターは真に外部である

• ユースケースはユーザーの目標を表す

• includeおよびextendが正しく使用されている

• システム境界は正確である

• 関係は実際のビジネス行動を反映している

VPasCodeは、テキストベースの図編集とVisual Paradigmのグラフィカルモデリングツールの間を移動することもサポートしており、チームがバージョン管理のためにソースベースの編集を、レイアウトの微調整のためにビジュアル編集を望む場合に役立ちます。

11. PlantUMLユースケース図の保守

意味のあるエイリアスを使用する

エイリアスを使用すると、関係の保守が容易になります:

usecase "Place Order" as PlaceOrder
Customer --> PlaceOrder

コメントを追加する

' コア顧客取引
usecase "Place Order" as PlaceOrder

コメントは、他のチームメンバーがソースを理解し、図を保守するのを助けます。

図に焦点を絞る

図にユースケースが多すぎる場合:

• コンテキスト図を作成する

• ビジネス領域ごとに別の図を作成する

• パッケージグループを使用する

• ドキュメントを通じて関連する図をリンクする

• すべてのサブ機能を最高レベルで表示しないようにする

一貫した命名規則を使用する

1 つの規約を選択し、一貫して適用してください:

• 注文を確定

• 注文をキャンセル

• 注文を追跡

以下のようなスタイルの混在を避けてください:

• 注文を確定

• OrderCancellation

• tracking_function

ソースをプロジェクトと一緒に保存する

一般的なリポジトリ構造は以下のようになります:

docs/
  use-cases/
    UC-001-place-order.md
    UC-002-track-order.md
  diagrams/
    online-store-use-cases.puml

を保持することで.pumlソースをバージョン管理下に置くことで、変更のレビューと再現が可能になります。

12. 追跡可能性

成熟した要件定義プロセスは、ユースケースを他のプロジェクト成果物と結びつけます。

トレーサビリティは、以下の問いに答えるのに役立ちます：

• どの要件がカバーされていますか？

• どのユースケースがまだテストされていませんか？

• どの設計コンポーネントがビジネス目標をサポートしていますか？

• 要件が変更された場合、何が影響を受けますか？

13. 一般的な間違い

内部コンポーネントをアクターとしてモデル化する

データベースや内部サービスは、システム境界内にある場合、通常はアクターではありません。

アクターは、モデル化されるシステムの外部でなければなりません。

画面をユースケースとして扱う

画面はユーザーインターフェースの要素であり、必ずしもユーザーの目標ではありません。

使用：

経費精算の提出

代わりに：

経費精算画面

使用：includeすべての共有ステップに対して

共通の文言だけでは、include されたユースケースを正当化できません。include動作が必須であり、独立して意味を持つ場合に使用してください。

使用：extend通常のステップに対して

動作が常に発生する場合は、拡張としてモデル化すべきではありません。

実装の詳細を記述する

以下の参照を避けてください：

• コントローラー

• データベーステーブル

• API エンドポイント

• クラス

• 内部メソッド

ただし、文書が明確に技術設計である場合を除く。

失敗動作の省略

成功のみを説明している場合、ユースケースは不完全です。支払い拒否、無効なデータ、タイムアウト、認証失敗、および利用可能なリソースの不足に対処する必要があります。

ユースケースを広すぎにすること

「事業全体を管理する」は実行可能ではありません。広範な目標をユーザー目標レベルのユースケースに分解してください。

ユースケースを小さすぎにすること

「フィールドを検証する」および「メッセージを表示する」は通常、システムステップであり、独立したアクターの目標ではありません。

14. 確認チェックリスト

ユースケース記述を承認する前に、以下を確認してください：

スコープとアクター

• システム境界は明確ですか？

• すべての外部アクターは特定されていますか？

• アクターは個人名ではなく役割ですか？

• 支援システムは、それらが外部である場合にのみモデル化されていますか？

目標の品質

• ユースケースは主要アクターに価値を提供していますか？

• 名称は明確な動詞名詞句ですか？

• ユースケースは適切なレベルにありますか？

フローの品質

• メインシナリオは成功した結果を説明していますか？

• 各ステップは原子的で観測可能ですか？

• 代替パスは文書化されていますか？

• 例外パスは文書化されていますか？

• 回復動作は明確ですか？

条件と結果

• 事前条件はテスト可能ですか？

• 成功保証は明示されていますか？

• 最小保証は定義されていますか？

• ビジネスルールは手順ステップから分離されていますか？

図の品質

• すべてのユースケースは正しい境界内にありますか？

• アクターの関連付けは意味がありますか？

• 「include」関係は必須ですか？

• 「extend」関係は任意または条件付きですか？

• 図は過度な詳細なしで読みやすいですか？

要件の品質

• 各重要なステップはテスト可能ですか？

• 非機能要件は含まれていますか？

• 未解決の質問は記録されていますか？

• ユースケースは要件およびテストケースとリンクされていますか？

15. 推奨納品物構造

完全なプロジェクトパッケージには、以下の構造を使用してください：

1. システムコンテキスト
2. アクターカタログ
3. ユースケース図
4. ユースケースカタログ
5. 詳細なユースケース記述
6. ビジネスルール
7. 非機能要件
8. 追跡可能性マトリックス
9. 未解決の質問と仮定
10. PlantUML ソースファイル

強力なユースケース記述は、アナリストにとって十分精密であり、ステークホルダーにとって理解可能であり、品質保証チームによってテスト可能です。最適なワークフローは、記述された内容で動作を確立し、ユースケース図で範囲と関係性を伝え、VPasCode内のPlantUMLを使用して視覚モデルを編集・維持しやすくすることです。

参照