ユースケース分析とは
※一般的には要件定義（主にユーザー企業）として行われる。設計者の仕事ではない。ただし、ユースケースから画面や外部システムI/Fなどの外部仕様を導き出すので「ユースケースは何で、どういうものか」という概要は知る必要がある。
・従来では要件定義書はWordで標準的な基準も規約もなく設計者の頭の中の構成が文章となって記載されているだけ。それをユースケースを使うことで、要件の粒度や表記方法に統一感ができ、見積りも正確になる。その後の開発が行いやすくなる。
・ユースケースはシステムの利害関係者（システムの利用者、外部システム）に対するシステムの振る舞いを表現したもの。
・振る舞いとはシステムの動的な側面、「システムの挙動」
・その利害関係者とシステム間でどのようなやりとりが行われるか順序に沿ったシナリオで表現する。
・利害関係者の中でシナリオの中心になるものを主アクターと呼ぶ。
・ユースケースのアクターには目的があり、シナリオのステップは手順を書くよりアクターの意図を記載する
・ユースケースにはビジネスレベルのユースケース（上流工程と業務分析のためのもの）とシステムレベル（システムの設計のため）のユースケースがあり、該当書籍ではシステムレベルのユースケースについて記載する。

ユースケースとして最低限記載しなければならない内容
・ユースケース名
・主アクター
・主シナリオ
・拡張シナリオ

ユースケースのサンプル

サンプル解説
・作成者と作成日はユースケースとして必要ではないが設計ドキュメントとして必要
・ユースケースの特徴：文章で書かれたシナリオである。シナリオは文章ごとにステップで分かれており、順番に数字が振られている。ステップごとに主アクターとシステムが行うことを簡潔な文章で記述する。
※シナリオは失敗することもある。サンプルの場合、クレジットカード決済だとすれば、与信が通らなければ失敗する。→拡張シナリオ（決済エラー）
・ユースケースでは画面遷移や具体的なシステムの実現方法にはできるだけ言及しない。そうすることで、画面設計などの具体的な実現方法が変わっても影響を受けない本質的な要件を表現できる。

●アクター
・ユースケースを作成する際にはアクターの視点で記述することが重要。
アクターがシステムに何をやらせるのかを考える。
・アクターはシステムの利害関係者。ユースケースのシナリオの主体になるアクターを主アクターと呼ぶ。それ以外のシナリオに登場するアクターを支援アクターと呼ぶ。アクターは人間だけでなく、別システムやバッチスケジューラの場合もある。
・シナリオに登場するのはシステムを直接利用するアクターだけ。間接的に利害が発生するような操作代行の利用者、システム所有者、システム監査人
、シナリオに登場しない。
・ユースケースの視点
ユースケースは主アクターの視点で記述する。システムの視点よりもアクターの視点の方がシステムの目的に近い。
・足りないユースケースを発見するために
「抽出されたユースケースはアクターの目的を全て満たしているか」
「アクターのライフサイクルを考えた時にユースケースが足りているか」
・アクターは誰？
アクターは特定の個人を指すものではない。ロール（役割）でもない。
受注システム運用者とコールセンターが同じように注文できる場合、どちらも発注者アクターのサブクラスである。

ユースケースの事前条件、事後条件、トリガー

ユースケースに対して事前条件や事後条件を付けた方がいい場合がある。

・ユースケースの事前条件とは
ユースケースが始まる前に真であると保証されていることを記述する。
・ユースケースの事後条件とは
ユースケースの結果として満たされていることを記述する。
最低保証と成功時保証がある。

上記の表の例では注文ステータスが「受注済」になっていることが事前条件となる。そして、「１．配送〜」の時点で表示される注文の一覧には
「受注済」のデータのみ表示される、もしくは「受注済」であることが明確に表示され、「受注済」のに注文のみ配送指示が行える。

・ユースケースのトリガー
トリガーにはユースケースを実行するイベントを記述する。トリガーは主シナリオに含まれない場合と主シナリオの最初のステップになる場合がある。

ビジネスルール
ユースケースはシステムの要件を記述する。ビジネスルールとは、企業がその業務を遂行するための従わなければならないルールである。
そのビジネスルールをユースケースの補足として記述する。
ビジネスルール補足はユースケース記述とは異なるドキュメントに記載する。例えば、商品の種類ごとに配送センターが異なる場合はそのルールをビジネスルールとして記述する。

次はユースケースから参照されるビジネスルールの例を記載する。
システムを開発するのに必要な情報は煩雑にならないように下記の表のようにまとめる。

その他ビジネスルールの例

抽出したビジネスルールはビジネスルール一覧を作成して管理する。

ユースケースが難しい点
・ユースケースのレベルがバラバラになる
・どこからどこまでをユースケースとして記述すればいいかわからない

日頃の仕事や業務を定型化しようとすると起こりやすい
・業務担当者が記述するときはレベルが大きくなりすぎる
・システムの担当者が記述するときはレベルが細かくなりすぎてシステムの詳細に踏み込んでいる。

ユースケースのレベル
・ユーザー目的レベル
一番重要で基本となる。システムの利用者が仕事を完了させるための目的を表したレベル
・要約レベル
ユーザー目的レベルよりも大きい。複数のユーザー目的レベルのユースケースが含まれる。どのようなユーザー目的があり、どのようなコンテキストや
順番で実行されるのかがわかる
・サブ機能レベル
ユーザー目的レベルよりも小さい。ユーザー目的レベルのユースケースを実現するのに必要な目的
※要約レベルでは大きすぎ、サブ機能では小さすぎるためユーザー目的レベルが外部設計で必要なレベルとなる。

ユーザー目的レベルの単位
１人の人間が中断なしで行える仕事の時間＝目安は30分
ユースケースとしては１つのユーザー目的が達成されるとその仕事の完了とする。

ユースケース分析の終わり
ユースケースではシステムの機能要件を定義する。画面や外部システムI／Fはユースケースから導き出される。ユースケースの網羅性は重要。
ユースケースの網羅性は抽出方法に関係する。

●ユースケースの抽出方法
・ユースケース図から抽出する方法
B to Cのように業務フローが作成できない場合、ヒアリング等を通してユースケースを抽出する方法。ユースケースといえばユースケース図と思われがちだがユースケース記述の方が大切。
・既存システムから抽出する方法
既存システムがあり、業務フローやユースケースが作成されていない状況で既存システムのリプレース機能拡張を行うケースで使用する方法。
既存システムの要件を整理するために、現状ユースケースを作成し、そこから機能を拡張する部分のユースケースだけを拡張後、（ToBe）ユースケースを作成する
・業務フローから抽出する方法
企業システムのような業務フローが存在する、もしくは業務フローを作成できるケースで使用する方法。UMLのアクティビティ図で記述する。

ユースケース抽出後、不足がないかを確認
次の項目について抽出に不足がないか確認する。
・ある目的を実現するためのユースケースが足りているか
・あるアクターのライフサイクルからユースケースが足りているか
・全てのトリガーに対するユースケースが洗い出せているか
・関係者による承認を得ているか

忘れがちな抽出項目
・商品を返品する　など

以上で第3章外部設計の手法③ユースケース分析を終了します。
次回は④概念モデリングについて記載します。