効果的なユースケースの書き方

公開: 2015-08-21

効果的なユースケースの書き方

ユースケースは、ビジネスロジックとシステムプロセスを文書化するために広く使用されています。しかし、それらが有用であるかどうか、そしてそれらをどのように構成すべきかについては多くの意見があります。一部のプロジェクトでは、開発者は、冗長であるとか、実際にはあまり理解していないと言って、ユースケースを見ることはありません。ユースケースを本当に効果的にするために、ビジネスアナリストは何ができるでしょうか。

私たちのほとんどは、ユースケースがビジネスプロセスを説明し、特定の目標に対するシステムとアクター間の相互作用の仕様であることを認識しています。ユースケースドキュメントは要件ドキュメントとは異なり、デザインドキュメントと同じではありません。

要件のユースケースの2つの例を見てみましょう。どちらが良いと思いますか。

例– 1

ユースケースの詳細	コメントコメント
ユースケース名–チケットの注文	名前はいいです。ユースケースが何であるかを明確に示します
目標–顧客はウェブサイトでサッカーの試合のチケットを正常に予約します説明-俳優がウェブサイトにアクセスし、スケジュール、一致を選択しますと座席、本チケットとサッカーの試合の支払いを行います	目標と説明が明確に記載されています。これは、設計者を支援します開発者は何であるかを理解しています彼らの設計文書とコードの目標
アクター–顧客、顧客サービス担当者前提条件–システムは稼働しています。トリガー–アクターがシステムにアクセスしてチケットを予約しました。事後条件–俳優はチケットを予約することができます。システムが情報を更新します。	アクターなどの他のすべてのユースケースの詳細、前提条件、事後条件、トリガーが言及されていますアプリケーションの設計と開発が容易になります。
メインフロー–ステップ俳優はウェブサイトにアクセスし、チケットの予約を選択しますシステムは予約情報を表示しますアクターは試合の詳細を確認します（UI仕様の詳細）アクターが座席の詳細を確認します（UI仕様の詳細）システムが可用性を確認しますシステムはユーザー情報を取得するためのフォームを提示しますアクターはユーザー情報を提供します（別のユースケースの詳細）システムは支払い情報のフォームを提示しますアクターは支払い情報を提供します（別のユースケースの詳細）システムが詳細を確認し、予約IDを提供します俳優はチケットを保存しますアクターはシステムを終了します。含まれるユースケース - 支払う –予約IDを生成します拡張されたユースケース –支払い失敗メモの生成 –チケットを印刷する	メインフローのステップは明確ですが UIの詳細は省略されています。ユースケースのUIの詳細座席の選択と試合について選択すると、ユースケースが扱いにくくなる可能性があります。ユースケースは、アクターが何をしなければならないか、そしてシステムが何をするかを明確に示しています支払いプロセスの詳細は、タスクができるように異なるユースケースさまざまな設計コンポーネントに簡単に分解できます。含まれるユースケースと拡張されたユースケースには名前が付けられていますできるように詳細については、それらを参照してください。
代替フロー -チケットをキャンセルするアクターがトランザクションをキャンセルしますシステムがトランザクションをキャンセルします例外フロー -選択した試合/選択した座席のチケットは利用できません 1.システムはエラーメッセージを表示します	代替フローと例外フローについて詳しく説明します。
ユースケースは、参照と代替および例外フローの観点からより詳細にすることができます。この例は、適切に記述されたユースケースに含まれるべきものを強調するためのものです。*

例– 2

ユースケースの詳細	コメントコメント
ユースケース名–チケットの注文	この名前はユーザーの観点からではなく、ビジネスプロセスの定義のようです。
説明–俳優はウェブサイトにアクセスし、スケジュールを表示し、試合と座席を選択し、チケットを予約し、サッカーの試合の支払いを行います	ユースケースの目標がありません。設計者、テストアナリスト、および開発者は、この機能を開発する必要がある理由を理解できません。
アクター–顧客、顧客サービス担当者トリガー–アクターがシステムにアクセスしてチケットを予約しました。事後条件–俳優はチケットを予約することができます。システムが情報を更新します。	前提条件がありません。
メインフローステップ顧客はWebサイトにアクセスし、オプション「チケットの予約」を選択してチケットを予約します一致するもののリストがドロップダウンに表示されます。カスタマーサービス担当者はドロップダウンから選択します座席の地図に座席の詳細が表示されます俳優は座席を選択します。座席が空いておらず、エラーメッセージが表示された場合。俳優は支払いの詳細を提供します俳優はチケットを予約し、そうでない場合はチケットをキャンセルします。システムは、顧客の名とランダムに生成された4桁の番号を使用して予約IDを生成します含まれるユースケース - 支払う	ユースケースの手順では、読者を混乱させる可能性のある実際のUI要素への参照がいくつかあります。代替フローはメインフロー内に記述されているため、プロセス全体を理解するのは困難です。アクターは多くの名前で呼ばれます–'顧客、アクター、カスタマーサービス担当者は混乱を招きます。予約IDの生成についてはここで説明しますが、チケットの注文に関連するアクターには関係ありません。代替フロー、例外フロー、および関連するすべてのユースケースについての言及はありません。
このユースケースは明確さと詳細が欠けており、チームが機能を適切に開発するのに役立ちません。

ユースケースの内容	ユースケースにすべきではないこと
名前説明/目標前提条件引き金基本フローと代替フロー例外シナリオ投稿条件特別な要件がある場合 UIの詳細およびその他の関連モデル/図へのリンク	実装の詳細内部処理非機能要件ユーザーインターフェイスの詳細は、ユースケースと同時に行う必要がありますが、別のドキュメントで行う必要があります。

ユースケースの内容

ユースケースにすべきではないこと

名前
説明/目標
前提条件
引き金
基本フローと代替フロー
例外シナリオ
投稿条件
特別な要件がある場合
UIの詳細およびその他の関連モデル/図へのリンク

実装の詳細
内部処理
非機能要件
ユーザーインターフェイスの詳細は、ユースケースと同時に行う必要がありますが、別のドキュメントで行う必要があります

。

有用なユースケースを作成するために従うべきいくつかのヒント：

アクターの観点からユースケースのステップを記述します。
ユースケースには、設計やアーキテクチャの詳細を含めるべきではありません。それはビジネスプロセスに集中する必要があります。
ユースケースのステップが時間順に書かれているとよいでしょう
要件と複雑さに応じて、CRUD（作成、読み取り、更新、削除）操作を別々のユースケースに保持する必要があるか、1つに組み合わせることができるかを決定します。
ビジネス設計を完了するために、代替フロー、例外フロー、含まれるユースケース、および拡張ユースケースへの参照とそれらからの参照を提供することが重要です。
テンプレート（プロジェクト定義、会社定義、または詳細なテンプレート）を選択し、すべてのユースケースの構造に従います。
ユースケース図を用意することが重要です。
アジャイルでは、要件を把握するためのユーザーストーリーがあります。ユーザーストーリーは、無駄のないユースケースを繰り返し使用して詳細に説明できます。
検証について詳しく説明する必要があります。

ユースケースを作成したら、これらの質問をします。すべての質問に対する答えが「はい」の場合、これは効果的なユースケースです。

ユーザーは、ユースケースに存在するビジネスフローがいつ実行されるかを知ることができますか？
誰がユースケースのどのステップを実行するかについて明確ですか？
分析、設計、開発、およびテストに十分な情報があるようなビジネスロジックの説明はありますか？
メインフローから代替フローおよび例外フローへの適切な参照はありますか？
ユースケース図はありますか？

ユースケースは、要件を把握し、適切に記述されている場合はビジネスプロセスを正式に文書化するための効果的な方法です。チーム全体が、ユースケースを使用してタスクを実行するように指導する必要があります。ユースケースとユースケース図は、クライアントとビジネスプロセスについて話し合うための優れた方法です。ユースケースの作成に関するガイドラインを含む標準のユースケーステンプレートを用意することをお勧めします。このように書かれたユースケースは、すべてのプロジェクトチームメンバーと利害関係者によって評価されます。