はじめに
はじめまして、テクノロジー本部ITエンジニア部の妹尾と申します。エムティーアイに入社して約1年が経ちました。現在、開発者として各プロジェクトの保守、開発を行っております。本記事では社内でアジャイルトレーニングを受けて要求モデリングという言葉を学んだため、学習内容と実際に経験した要求モデリングについての流れを書きたいと思います。
要求モデリングとは
まず最初に、要求モデリングとは顧客からの要求をモデル化し単純化、汎化することで情報を共有する作業になります。顧客からの要求は顧客自身にも想像していない要件が存在することが多く、システム開発者との認識齟齬が発生します。この事象を発覚することが遅くなるほど、取り返しがつかなくなってしまい、いわゆるプロジェクトの炎上ということになってしまいます。要求モデリングでは業務分析や要求整理を行いながら情報を出力、共有することでこの認識齟齬、仕様漏れを低減します。
要求モデリングの手法の一つにユースケースを使ったユースケースモデリングがあります。ユースケースモデリングではユースケース図とユースケース記述を作成します。以下でその内容について紹介したいと思います。
ユースケース図
ユースケース図は機能的な要求に対して関係者や関係機能を洗い出したものになります。主に企画職の担当者が顧客との業務分析、要求整理の際に情報の整理、図の作成を行います。システムの基本的な流れをモデル化することで「誰が何を行うか」「作業を行った結果、誰に影響があるか」「必要な機能に漏れはないか」等がわかりやすくなります。
以下の図では次のことがわかります。
- 受注担当者は商品の検索、受注ができる。
- 発注担当者は商品の検索、発注、在庫の登録、検索ができる。
- 納品担当者は商品の納品、売上の登録ができる。
ユースケース記述
ユースケース記述は一つのユースケースに焦点を当て、具体的にどのように動作するかを説明したものになります。それぞれのユースケースの内容を整理することで「事前に行わなければならないことはあるか」「作業内容に無駄や不足はないか」等がわかりやすくなります。ユースケース記述では主に以下の内容を整理します。
| 項目 | 内容 |
|---|---|
| ユースケース | ユースケース名を記載 |
| 概要 | ユースケースの内容を要約したものを記載する |
| アクター | ユースケースに関係するアクター。複数人の場合も存在する |
| 事前条件 | このユースケースが開始されるときに満たされているべき条件 |
| 基本フロー | イベントフローの一つ。ユースケースの実行に伴って起きるアクターと システムとの間のやり取りのうち、想定通りのもの |
| 代替フロー | 条件分岐で基本フローの代わりとしてはたらくフロー |
一例として「商品を発注する」について上記を用いて記述すると以下になります。
| 項目 | 内容 |
|---|---|
| ユースケース | 商品を発注する |
| 概要 | 発注情報を作成する |
| アクター | 発注担当者 |
| 事前条件 | 「在庫を検索する」で該当商品の在庫がないこと |
| 基本フロー | １． 商品を検索する ２．発注先、数量、価格を設定する ３．発注情報を作成する ４．発注先に通知を行う |
| 代替フロー | ２．発注先が商品を扱わなくなった Ⅰ．別の発注先、価格を設定する |
まとめ
本記事では要求モデリング、ユースケースモデリングについて紹介しました。
- 要求モデリングは情報を出力し、共有することで認識齟齬を低減すること。
- ユースケース図は関係者、関係機能を洗い出し、業務分析や要求整理の際に利用できる。
- ユースケース記述はユースケースの内容を整理することで無駄や不測の洗い出し、業務改善に利用できる。
ユースケースモデリングを行うことで、普段自身の業務に注力している顧客は全体の業務を俯瞰する機会を得ることができ、業務改善につながります。また、日常業務とユースケース図、ユースケース記述を比較することで認識齟齬、仕様漏れを発見、改善することが可能になります。
注意点は要求モデリングでは非機能要件は洗い出しにくい点です。特に問題として表面化しやすい「可用性」「性能・拡張性」「運用・保守性」「セキュリティ」はあらかじめ注視する必要があります。
最後までお読みいただきありがとうございました。
