シリーズ: 要件定義とはそもそも何か
- 要件定義の目的とゴールとは
- 要件定義の重要ポイント〜要望・要求・要件を見極める
- 事業・業務・システムの3階層で要件を捉える
- 業務フロー図で見える化する業務プロセスからシステム要件への道筋
- ユースケースとロバストネス図によるシステム要件定義（本記事）
TRACERYプロダクトマネージャーの haru です。
前記事の業務フロー図で見える化する業務プロセスからシステム要件への道筋では、業務フロー図からユースケースを抽出しました。
システムの要件定義では、ユースケースを起点にロバストネス図を活用することで、システムを構成する要素を抽出でき、設計にスムーズにつなげることができます。
本記事では、ユースケースとロバストネス図を用いて、システムの要件を具体化する方法を説明します。
ユースケースの記述
ユースケース（use case）とは、利用者の視点でシステムの振る舞いを整理したものです。
ユースケースには、システムの動作やユーザーの操作の流れを具体的に記述し、どのように機能が利用されるかを明確に表現します。
ユースケースは、以下の要素で構成されます。
| 要素 | 説明 |
|---|---|
| アクター（Actor） | システムを利用する主体（ユーザー、外部システムなど） |
| ユースケース（Use Case） | アクターとシステムのやり取りを表す具体的なシナリオ |
| 事前条件（Preconditions） | ユースケース実行前に満たすべき条件 |
| 事後条件（Postconditions） | ユースケース完了後に満たすべき状態 |
| 基本フロー（Main Flow） | 通常の操作フロー（成功パターン） |
| 代替フロー（Alternative Flow） | 基本フローとは異なる分岐（例：異なる操作の選択肢） |
| 例外フロー（Exception Flow） | エラーや異常時の振る舞い |
ユースケース「売上ダッシュボードを参照する」の記述
前記事で抽出したユースケース「売上ダッシュボードを参照する」の記述例を以下に示します。
| 項目 | 内容 |
|---|---|
| ユースケース名 | 売上ダッシュボードを参照する |
| アクター | 管理者、営業担当者 |
| 事前条件 | ユーザーがログイン済みで、ダッシュボード閲覧権限を持っている |
| 事後条件 | システムはユーザーに対して最新の売上データを表示した状態となる。 ダッシュボードの閲覧履歴がシステムに記録される。 |
| 基本フロー | 1. ユーザーは管理画面にログインする 2. メニューから「売上ダッシュボード」を選択する 3. システムは売上データを取得し、ダッシュボードを表示する 4. ユーザーは売上の推移や各種指標を確認する |
| 代替フロー | 売上レポートの出力 1. ユーザーは売上ダッシュボード上で「PDFエクスポート」ボタンをクリックする。 2. システムは現在表示されている売上データをPDF式でダウンロードして保存する。 |
| 例外フロー | 1. ユーザーが閲覧権限を持っていない場合、アクセス拒否エラーメッセージを表示 2. 売上データの取得に失敗した場合、エラーメッセージを表示し、管理者に通知する |
ロバストネス図によるシステムを構成する要素の抽出
ユースケースを元にシステム要件を詳細化していくには、ロバストネス図の作成が有効です。ロバストネス図によってシステムを構成する要素（UI、機能、データ等）を導き出します。
ロバストネス図を構成する要素は以下の3つです。
- バウンダリオブジェクト（Boundary Object：以下「バウンダリ」）
- UIやAPIなど、外部とのインターフェース（境界）を担うもの（例：画面、APIエンドポイント）。
- エンティティオブジェクト（Entity Object：以下「エンティティ」）
- システム内部の主要なデータを表すもの（例：注文、顧客、商品）。
- コントロールオブジェクト（Control Object：以下「コントロール」）
- バウンダリとエンティティの間で、処理の流れを制御するもの（例：注文処理、在庫更新）。定時起動のバッチ処理もコントロールで表現する事が多い。
下図は、ユースケース「売上ダッシュボードを参照する」の記述をもとに作成したロバストネス図です。
ロバストネス図による開発品目の抽出
要件定義の目的とゴールとは - TRACERY Lab.（トレラボ）では、要件定義の最低限必要な要件定義の成果物について以下のように説明しました。
要件定義の成果物の一つである『開発品目の一覧』がロバストネス図で抽出できます。
前述の「開発品目をロバストネス図で抽出する」からは、以下の開発品目が抽出されました。
- 売上ダッシュボード画面
- 売上データ抽出処理
- 売上レポートPDF出力処理
さらなる要件の検討
上図のロバストネス図では、まずシステムの大まかな振る舞いを整理しました。ここから解像度を高め、機能要件や非機能要件の検討を進めます。
機能要件
検討1
売上ダッシュボードにどのような情報を表示するのか？
検討結果 → 日別の売上推移、商品別売上、地域別売上
非機能要件
検討1
ダッシュボード表示は、最大何秒で表示できれば良いか？（性能要件）
検討結果 → 3秒以内
検討2
最新の売上データの数値が反映されるまでの遅延はどこまで許容されるのか（運用要件）
検討結果 → 最大24時間。月ごとの傾向を分析することが主な目的であり、常に最新である必要はない。そのため、集計は1日1回とする。
これらを検討した結果、1回のクエリでは抽出に3秒以上の時間がかかり、ダッシュボード表示の前段階として「売上データ集計処理」が必要であることが明らかになりました。
さらに、集計や表示のためには、商品、顧客、エリアなどのデータも必要であることがわかりました。これらの詳細化した結果をロバストネス図で表すと、下図のようになります。
要件を検討した結果、開発品目は以下のようになりました。
- 売上ダッシュボード画面
- 売上データ抽出処理
- 売上レポートPDF出力処理
- 売上データ集計処理 （追加）
ここではこの程度の詳細化にとどめますが、実際の開発では、以下のような話が検討されるかもしれません。
最後に
本記事では、ユースケースを詳細化し、ロバストネス図を用いてシステムの要件を抽出する方法を具体例とともに説明しました。
ロバストネス図を活用することで、開発品目を明確にし、機能要件や非機能要件を整理できます。
ユースケースとロバストネス図は、システム要件定義を進めるうえで取り組みやすい手法です。ぜひ、実務で活用してみてください。
*1:品目という言葉は聞き慣れないかもしれないが、ここでは共通フレーム2013の用語に従っている
*2:システムが提供すべき具体的な機能やサービス、操作に関する要件のこと。システムが「何をするか」に関する要件であり、ユーザーやクライアントが期待する具体的な動作や結果を定義する。データ入力、データ処理、データ出力、データ検索、データ保存、ユーザー認証、通知、インターフェース（他のシステムやアプリケーションとの連携）などの機能があげられる。
*3:システムの動作や性能、品質に関する要件のこと。機能要件が「システムが何をするか」に焦点を当てるのに対して、非機能要件は「システムがどのようにそれをするか」に焦点を当てる。セキュリティ、性能、信頼性、可用性、保守性、ユーザビリティ、互換性、移植性、法令遵守などがある。
*4:https://aws.amazon.com/jp/redshift/
*5:https://cloud.google.com/bigquery?hl=ja
*6:Business Intelligenceツール。企業に蓄積されている膨大なデータを集約し、経営や業務に活用できるように分析・共有するためのツール
