こんにちは。ネオシステムの高橋です。
今回はユースケース図を作成したいと思います。
前回の記事も併せてご活用ください。
目次
- なぜユースケース図を作るのか
- ユースケース図作成の注意点
- アプリの機能を整理する
- ユースケース図を書く
- 追加情報を書く
- ユースケース記述を書く
- まとめ
なぜユースケース図を作るのか
ユースケース図とはユーザーの視点でアプリの利用例を表現する図解術です。
また、ユースケース図はUMLの一つであり、全世界共通で用いられています。
これを作成することによって以下のメリットが得られます。
顧客の要求を明確化できる
アプリ開発では、ユーザ自身が要求を明確にできていないケースが多いです。
ユースケース図を活用することで、顧客の要求を視覚化したり、隠れた要求を引き出したりすることができます。
また、口頭や文章だけでは認識に齟齬が必ず出るため、齟齬を減らすためにもユースケース図は役立ちます。
アプリの開発範囲を明確化できる
前回の記事ではアプリの範囲について記載しましたが、ユースケース図を使うことでより分かりやすく表現することができます。
アプリでできることとできないことが明確になり、メンバ全員の理解度を上げることができます。
ユースケース図作成の注意点
注意点は大きく分けて2つあります。
システム利用者視点で書く
ユースケース図はアプリユーザのための図解術です。
開発者向けの図ではないということを念頭に置きましょう。
シンプルに書く
エンジニアは、条件分岐などのシステム内部のロジカルなところに目が行きがちですが、ユースケース図はそのような細かいところを表現する図ではありません。
シンプルすぎるのではと心配になるくらいで問題ないです。
アプリの機能を整理する
前回の記事では、必要な機能をピックアップし、その優先度を決めました。
まずはこれらの機能の詳細を洗い出します。
これらの機能に対して誰がどんなことをするのか整理していきましょう。
ここまでできればユースケース図作成の準備は完了です。
ユースケース図を書く
上のセクションで整理した機能を基にユースケース図を作成します。
機能の関連性を見直す
次に、ユースケースそれぞれの関連性を見直していきます。
ある機能Aが他の機能Bを包含していたり、拡張した機能であるか見ていきましょう。
今回は3点修正しました。
- 工事管理者が承認を完了する作業は、その作業の中に承認を受け取りも含まれている
- 工事受注者が補修情報を一時保存する機能は、補修機能登録機能の一部ととらえる
- 事故報告の承認申請は、補修情報を登録する機能の拡張機能としてとらえる
<<include>>や<<extend>>の矢印を活用することで、ユースケースの関係性を表すことができます。
ユースケース記述を書く
冒頭にユースケース図はシンプルに書くことが大事であると書きましたが、ユースケース記述も用意しておきましょう。
ユースケース図とユースケース記述を切り離して管理することで、図はシンプルな状態を保つことができます。
以下にユースケース記述の項目の例を列挙します。
必要に応じて項目を取捨選択しましょう。
- ユースケース名
- 概要
- アクター
- 事前条件
- トリガー
- 基本フロー
- 備考
- 代替フロー
- 例外フロー
- シナリオ
ユースケースが増えるとアプリの機能や利用シーンも増えることにつながり複雑なアプリになっていくので、本当に必要なユースケースなのかを確かめながらユースケース記述を記載しましょう。
まとめ
今回はユースケース図についてまとめました。
ユースケース図は非エンジニア向けの図解術であるため、UMLの中では簡単に作成できる方ではないかと思っています。
またアプリ開発のプロジェクトにおいて、ユースケース図は上流工程で活躍する図であるため、プロジェクト資料の中では重要性が高いものであるとも言えます。
皆さんもぜひユースケース図を書いてみてください。
また、ER図の作成方法も記事にしていますのでこちらも参考にしてみてください。