WEBサービス創造記

WEBサービスを作ったり保守したりしてる人のメモブログです。

ユースケース記述の作成

      2015/05/17

ユースケース記述とは

ユースケース記述は、ユースケース図に描かれたユースケース1つにつき1つ作られるもので、ユースケースが具体的にどのようなものかを説明したものです。

ユースケース記述では、アクターの動作・システムの振る舞いを具体的且つ明確に文章として記述します。
ユースケース図とユースケース記述を併せて参照することで、よりシステムのユースケースが理解しやすくなります。
ユースケース図とユースケース記述を合わせたものは、”ユースケースモデル”と呼ばれることもあるようです。

引用文にもありますが、1つのユースケースにつき、1つのユースケース記述が対応します。1つのユースケース図につき1つのユースケース記述ではありません。
ユースケース記述を仕上げるのには割りと時間がかかりますが、ユースケース記述を書くことにより下記のメリットを享受できます。

  • アクターの挙動やシステムの振る舞いが理解しやすくなる
  • (しっかり書けば)エンドユーザでも開発者でも読めるため、システムのイメージを誰とでも共有することができる
  • 開発の単位が明確化される

※UMLでは

ユースケース図は標準化されているものの、ユースケース記述は特に取り決めがない

ようですが、前述のようにユースケース図と併せて利用するものであるため、UMLカテゴリーに記事を置きました。

ユースケース記述の書き方

ユースケース記述の形式

ユースケース記述は以下のようなフォーマットで作られます。

ユースケース名 ここにユースケース図のユースケースと対応するようにユースケース名を書く。
「(システムは)YをXする」という風に体言止めせずに記述する。
概要 ユースケースの内容を要約したものを書く。
目的 ユースケースを実行する目的を書く。
「Zしたい」「Zするため」という風に書く。こうすることで、ユースケース全体を「Zするために、(システムが)YをXする」と読むことができる。この形式を XYZ公式 と呼ぶことがある。
アクター ユースケースに関係するアクター(ユースケース図上でユースケースと関連線で結ばれたアクター)をリストアップして書く。
開始条件 ユースケースが開始する条件を書く。開始のきっかけ・引き金(トリガー)。
事前条件 ユースケースが開始する前に満たされているべき条件を書く。
イベントフロー
メインフロー ユースケースの実行に伴って起きるアクターとシステムとの間のやり取り(イベントフロー)のうち、正常に処理が進んだ場合を書く。
主語をアクターまたはシステムと明示し、アクターのやることとシステムのやることを順序を表す番号をつけて書く。
代替フロー イベントフローのうち、途中でシステム内でエラーが発生した場合などに分岐する、メインフローの代わりとしてはたらくステップを書く。
※代替フローを実行しても事後条件は満たされる。
例外フロー イベントフローのうち、ユースケースの実行を断念しなければならないような場合の手順を書く。ユーザから見えるシステムのエラーで、代替するフローがない例外のもの。
※例外フローを実行した場合、事後条件は満たされない。
事後条件 ユースケースが実行された後に満たされているべき条件を書く。
備考 何を書いてもよい。例えば、上記の項目に収まらないような記述や、詳細な解説などを書く。
シナリオ このユースケースを使用する行為の事例(正常ケース、異常ケースの具体例)を書く。
イベントフローのインスタンスと考える。
ユースケースそのもののテストや、ソフトウェアの動作テストに利用することができる

各項目を書くときに大まかな注意点は以下の通りです。

  • 目的の内容がユースケースと同じににならないようにする
  • 異音同義語、異音異義語は読み手の混乱を招くので避ける
  • イベントフローの書き出しでは「アクターは~」、「システムは~」というように動作の主語を必ず書く
  • シナリオでは「A社」「Bさん」「X円」などとは書かず「海山商事」「磯野さん」「500円」といったように人物名やデータの単位を具体的に書く
  • シナリオでは典型的な成功ケース(メインフローを順調に進行して終了のようなケース)だけではなく、アンチシナリオ(途中でエラーが起きるなど起きて欲しくない状況)も積極的に考える
  • 空欄は作らない。各内容が決まっていない場合は「T.B.D(To Be Determined)」、特に書くことがない場合は「なし」と記述する

ユースケース記述の例

実際にユースケース記述を作ってみました。
ここでは、チェスゲームのシステムでの「駒を移動する」というユースケースを基に作成してみました。

ユースケース名 駒をマスへ移動する
概要 手持ちの駒をその駒が移動可能な任意のマスへ移動する。
目的 手持ちの駒を移動して、移動先のマスにある敵の駒を取ったり、敵のキングの駒をチェックするなどしてゲームを有利に進めるため。
アクター プレイヤー
開始条件 ・敵のターンが終了し、プレイヤーのターンが回ってくる
事前条件 ・動かせる手持ちの駒が存在すること(チェックメイトされていないこと)
イベントフロー
メインフロー
1.アクターが移動したい手持ちの駒を選択する(Alt-1)(Ex-1)
2.システムはアクターが選択した駒が移動可能なマスを確認し、アクターに提示する(Alt-2,Alt-3)
3.アクターはシステムから提示された移動可能なマスを確認し、移動先のマスを確定する
4.システムは移動先のマスに駒を進め、画面に反映する(Alt-4)
5.アクターのターンを終了し、敵のターンとなる
代替フロー
Alt-1:キングが敵からチェックされている状態であるとき
    1.選択する駒は、必ずキングが敵のチェックから逃れられるようにするために移動しなければならない
      つまり、
        キングを移動してチェックから逃げる
        敵の駒の効き筋とキングの間に手持ちの駒を割り込ませるように移動してチェックを防ぐ
        チェックをかけている敵の駒を取るために移動する
      のいずれかの手段をとらなければならない
    2.ステップ2へ進む
Alt-2:選択した駒を移動することによってキングが敵からチェックされる場合
    1.システムは選択した駒を移動するとチェックがかかってしまうことをアクターに警告する
    2.ステップ1へ戻る
Alt-3:選択した駒が移動できるマスがない場合
    1.システムは選択した駒が移動できるマスがないことをアクターに警告する
    2.ステップ1へ戻る
Alt-4:駒の移動先のマスに敵の駒がある場合
    1.システムはアクターの駒が敵の駒を取ることを画面に反映する
    2.ステップ5へ進む
例外フロー
Ex-1:持ち時間内にアクターが移動したい手持ちの駒を選択しなかった場合
    1.システムは時間切れでアクターの敗北となったことをアクターに通知する
    2.システムはこのユースケースを中断する
事後条件 ・キングが敵の駒からチェックされていないこと
備考 なし
シナリオ
シナリオその1.手持ちの駒を移動し、相手の駒を取る(正常処理)
1.中島さんがa1のマスにあるルークの駒を選択する
2.システムは中島さんにルークがa2/a3/b1/b2のマスに移動可能であることを提示する
3.中島さんはルークをa3のマスに移動することを確定し、移動をシステムに要求する
4.システムはa3のマスにルークを移動し、a3にある敵の駒ビショップを取る
5.対局相手である磯野さんの順番となる

シナリオその2.移動不可能な駒が選択された場合
1.中島さんがf2のマスにあるポーンの駒を選択する
2.システムは中島さんに、f2のポーンを動かすとh4にある敵の駒クイーンからキングがチェックを受けてしまうことを指摘し、駒の再選択を要求する

シナリオその3.制限時間内に駒が選択されなかった場合
1.中島さんは持ち時間である5分いないに移動する駒を選択しなかった
2.システムは中島さんに、時間切れにより対局に敗北したことを通知する

以上、ユースケース記述の例でした。
はじめて書いたユースケース記述なので誤った点もいくつかあると思います。
間違いに気づき次第修正していきたいと思います。

今回の問題点

  • メインフロー内のひとつのステップに2つ代替フローが呼び出されているが、これはUMLの仕様では許されるのか?

 - UML ,