ユースケースでそのシステムの振る舞いを整理する

n-ozawan

2025.02.05

開発手法 UML

皆さん、こんにちは。技術開発グループのn-ozawanです。
外務省のHPによると世界遺産は2024年8月現在で1223件あり、日本だけでも26件あるとのことです。連休の際には世界遺産に赴いて、その歴史に思いをはせるのも良いのではないでしょうか。

本題です。
行き当たりばったりでシステムを開発していると、そのシステムに過剰なほどの機能を実装して効率が低下したり、実装したはいいけど誰も使わなかった、なんてことがよくあります。事前にシステムの振る舞いを整理することで、本来そのシステムが持つべき機能を知ることが出来ます。今回はそんなユースケースのお話です。

ユースケース

概要

ユースケースはそのシステムの振る舞い（機能）を整理して把握するための手法です。UMLを勉強された方はユースケース図を見たことがあると思います。ユースケース図はシステムの振る舞いを図に書き起こしたものになります。

ユースケースは主に上流工程で行われ、その目的は、主体（アクター）がそのシステムとどのようなやり取りをするのか、そのシステムが何をするのかを明らかにすることです。

書き方、コツ

ユースケースではシステムをブラックボックスとし、そのシステムを外部から観測した内容を記述します。その為、データベースやファイルなどと言った、システム内部に関する内容が記述されることはありません。あくまでアクターとシステムとのやり取りを記述します。

主体（アクター）は人や物、外部システムでもありますが、表現すべきは「役割」です。例えばAさんがサービスを利用する人でもあれば、システム管理者でもある場合（兼任している場合）、アクターは「システム利用者」と「システム管理者」の２つで表現します。

テンプレート

ユースケースを記述する上での標準的なテンプレートは存在しません。そのプロジェクトに合わせて記述しています。以下の項目はユースケースを記述するにあたって最低限必要となる項目です。

項目名	説明
ユースケース名	ユースケースを一意に識別するための名前。「（システムは）XをYする」という文章にするのが望ましい。
概要	このユースケースの内容を要約する。
アクター	このユースケースのアクター
事前条件	このユースケースが開始するときに、どういう状況になっているか
トリガー	このユースケースを開始するための条件
基本経路	このユースケースの基本的なシナリオ、もしくは典型的なシナリオ。アクターとシナリオのやり取りを記述する。例） ①システムは購入可能な商品を提示する。 ②アクターは商品を選択して購入する。 ③システムは購入結果（代金や消費税など）を提示する。
代替経路	基本経路とは異なる他のやり方があれば、ここに記載する。また、基本経路で例外などが発生した場合もどういうやり取りが必要となるかをここに記載する。
事後条件	このユースケースが完了した時点での状況

その他にも、「補足事項」「作者」「作成日」「例外」「技術的要求」などがあり、プロジェクトに合わせて追加します。

ユースケース図

せっかくなので、ユースケース図について簡単に触れておきます。ユースケースは先ほどのテンプレートで記述するのですが、それだけではアクターやユースケース間の関連性が分かり辛いです。それらを図として表現することにより、よりユースケースを把握しやすくなります。

図	説明
	主体（アクター）
	ユースケース
	「has-a」の関係であることを示しています。上記の図であれば、商品を購入する際、必ず購入対象の商品を選択しますので、「商品の購入」には「商品の選択」というユースケースが含まれていることになります。
	そのユースケースに対して拡張したユースケースです。上図の図であれば、商品を購入する際、興味のある商品を検索することが考えられます。一方で、単にお勧めされた商品を購入するケースも考えられ、必ずしも検索する訳ではありません。そういったケースでは、「商品の購入」を拡張したユースケースとして「商品の検索」をextendとして表現します。

ユースケースで表現できないもの

ユースケースはアクターとシステムとのやり取りをまとめたものです。よって、非機能要件などはユースケースでは表現されません。もちろん、システムのアーキテクチャも表現されません。

ユースケースはアクターとシステムとのやり取りをまとめたものではありますが、UIなどのインターフェースは対象外です。例えば「アクターはプルダウンで商品を選択して、購入ボタンを押下する」という文章だとUIまで言及していることになります。ユースケースはそういったUIをどうするかまでは言及せず、UIは後工程で決めるものとしています。