ビジネス分析-ユースケース

UMLの9つの図のうちの1つは、ユースケース図です。これらは重要なだけでなく、ソフトウェアプロジェクトに必要な要件です。基本的にソフトウェアのライフサイクルで使用されます。私たちが知っているように、開発サイクルにはさまざまなフェーズがあり、ユースケースで最も使用されるフェーズは要件収集フェーズ中です。

ユースケースとは何ですか？

ユースケースは、アクターに価値を提供するシステムによって実行される一連のアクションを記述します。ユースケースは、*プライマリアクター*と呼ばれる利害関係者の1人からのリクエストに応答するときのさまざまな条件下でのシステムの動作を説明します。

アクターはシステムのWhoです。言い換えれば、彼はエンドユーザーです。

ソフトウェアおよびシステムエンジニアリングでは、ユースケースはステップのリストであり、通常、ロール（UMLでは「アクター」と呼ばれる）とシステムの間の相互作用を定義して目標を達成します。アクターは、人間または外部システムです。

ユースケースは、システム内のイベントのフローを指定します。一連のアクションを実行するためにシステムで実行される内容に関心があります。

ユースケースの利点

ユースケースには次の利点があります-

これは、ユーザーに付加される価値に焦点を合わせて機能要件を取得する簡単な手段です。
ユースケースは、従来の要件方法と比較して、比較的簡単に読み書きできます。
ユースケースにより、開発者はエンドユーザーの観点から考える必要があります。
ユースケースは、要件プロセスにユーザーを関与させます。

ユースケースの構造

名前：ユースケースの目的を説明する説明的な名前。

説明：ユースケースが何をするかをいくつかの文で説明します。

Actor：ユースケースに参加するすべてのアクターをリストします。

前提条件：ユースケースを開始する前に満たす必要がある条件。

イベントの流れ：システムとアクター間の相互作用の説明。

事後条件：ユースケースがコースを実行した後のシステムの状態を記述します。

ユースケーステンプレートのガイダンス

この章の最後にあるテンプレートを使用して、各ユースケースを文書化します。このセクションでは、ユースケーステンプレートの各セクションについて説明します。

ユースケース識別

*ユースケースID *-各ユースケースに一意の数値識別子を階層形式で与えます：X.Y. 関連するユースケースは、階層内でグループ化できます。機能要件は、ラベル付けされたユースケースにまでさかのぼることができます。
ユースケース名-ユースケースの簡潔で結果指向の名前を述べてください。これらは、ユーザーがシステムを使用して達成する必要があるタスクを反映しています。アクション動詞と名詞を含めます。いくつかの例-
部品番号情報を表示します。
ハイパーテキストソースを手動でマークし、ターゲットへのリンクを確立します。
更新されたソフトウェアバージョンのCDを注文します。

ユースケース履歴

ここでは、ユースケース文書の利害関係者である人々の名前について言及します。

作成者-このユースケースを最初に文書化した人の名前を指定します。
作成日-ユースケースが最初に文書化された日付を入力します。
最終更新者-ユースケースの説明に最新の更新を行った人の名前を入力します。
最終更新日-ユースケースが最後に更新された日付を入力します。

ユースケース定義

以下は、ユースケースの重要な概念の定義です-

俳優

アクターとは、システムと対話し、ユースケースを実行してタスクを実行する、指定されたソフトウェアシステムの外部の個人またはその他のエンティティです。多くの場合、異なるアクターは、製品を使用する顧客コミュニティから特定された異なるユーザークラスまたはロールに対応します。このユースケースを実行するアクターに名前を付けます。

説明

このユースケースの理由と結果の簡単な説明、またはアクションのシーケンスとユースケースの実行結果の高レベルの説明を提供します。

前提条件

ユースケースを開始する前に、実行する必要のあるアクティビティ、または真でなければならない条件をリストします。各前提条件に番号を付けます。

例

ユーザーの身元が認証されました。
ユーザーのコンピューターには、タスクを起動するのに十分な空きメモリがあります。

投稿条件

ユースケース実行の終了時のシステムの状態を説明します。各投稿条件に番号を付けます。

例

ドキュメントには有効なSGMLタグのみが含まれています。
データベース内のアイテムの価格が新しい値に更新されました。

優先度

このユースケースの実行を許可するために必要な機能を実装する相対的な優先度を示します。使用される優先度スキームは、ソフトウェア要件仕様で使用されているものと同じでなければなりません。

使用頻度

適切な時間単位ごとにアクターがこのユースケースを実行する回数を見積もります。

イベントの通常コース

通常の予想される条件下でのユースケースの実行中に行われるユーザーアクションとシステム応答の詳細な説明を提供します。このダイアログシーケンスは、最終的にユースケースの名前と説明に記載されている目標の達成につながります。この説明は、「どうすれば<ユースケース名に記載されているタスクを達成するのですか？」という仮説的な質問への回答として記述できます。システムによって。

代替コース

このセクションでは、このユースケース内で個別に行うことができる他の正当な使用シナリオを文書化します。代替コースを記述し、実行される一連の手順の違いを説明します。ユースケースIDを接頭辞として使用して各代替コースに番号を付け、その後に「代替コース」を示す「AC」を続けます。例：X.Y.AC.1。

例外

ユースケースの実行中に発生する可能性のある予想されるエラー条件を説明し、システムがそれらの条件にどのように応答するかを定義します。また、予期しない理由でユースケースの実行が失敗した場合のシステムの応答方法を説明します。ユースケースIDをプレフィックスとして使用して各例外に番号を付け、その後に「例外」を示す「EX」を続けます。例：X.Y.EX.1。

含む

このユースケースに含まれる（「呼び出される」）他のユースケースをリストします。複数のユースケースに現れる共通機能は、その共通機能を必要とするユースケースに含まれる個別のユースケースに分割できます。

特別な要件

設計または実装中に対処する必要があるかもしれないユースケースについて、非機能要件などの追加要件を特定します。これらには、パフォーマンス要件またはその他の品質属性が含まれる場合があります。

仮定

このユースケースを製品の説明に受け入れ、ユースケースの説明を作成することになった分析で行われた仮定をリストします。

メモと問題

このユースケースに関する追加のコメント、または解決する必要がある残りの未解決の問題またはTBD（未定）をリストします。誰が各問題を解決するか、期日、最終的に解決策は何かを特定します。

変更管理とバージョン管理

バージョン管理とは、ドキュメント、大規模なWebサイト、およびその他の情報収集に対する変更の管理です。通常、変更は、リビジョン番号またはリビジョンレベルと呼ばれる番号または文字コードで識別されます。各リビジョンは、タイムスタンプと変更者に関連付けられています。

Business-analysis-usecases

目次