ユースケースでユーザーの要求を整理する

はじめに 🔗

前回は、ユーザーの隠れた要求を引き出すためのさまざまな分析手法を学びました。

集めた要求を明確に整理すれば、関係者は同じ完成像を共有でき、開発チームは適切な方向に進めます。

今回は、

ユーザーの視点

から、

システムを使って何を達成したいか

に注目し、要求を整理して表す*ユースケース（Use Case）*を詳しく学びます。

ユースケースの基本、アクターとシナリオの役割、ユースケース仕様書の書き方を扱います。図の書き方は次の記事で説明します。

ユースケース（Use Case）とは？ 🔗

ユースケースは、スウェーデンのコンピューター科学者イヴァー・ヤコブソン（Ivar Jacobson）が概念を確立したもので、システムがユーザーや別のシステムに提供する

価値のある機能

を、利用者の視点で記述します。

ここでいう利用者には、システムとやり取りする人のほか、外部システムや機器も含まれます。これらを*アクター（Actor）*と呼びます。

簡単に言えば、「どのアクターが、システムを使ってどんな目標を達成するか」をシナリオとして表したものです。

例えば、オンライン書店には次のようなユースケースがあります。

「会員が本を検索する。」
「会員が本を注文する。」
「管理者が新刊を登録する。」

ユースケース図では、ユースケースを楕円、アクターを人型のアイコンで表すのが一般的です。この図でシステム全体の機能範囲を視覚化できます。

各ユースケースの詳しい内容を記述する*ユースケース仕様書（Use Case Specification、Use Case Description）*に、ユースケースの本来の価値があります。

ユースケースの主な構成要素 🔗

ユースケースを理解し、書くために、次の3つの構成要素を把握します。

1. アクター（Actor） 🔗

アクターは、システムの

外部

にあり、システムとやり取りして目標を達成しようとする人、システム、機器などです。

ユースケースを開始したり、その結果の影響を受けたりします。

主アクター（Primary Actor） 🔗

ユースケースの目標を達成するため、システムを使う主なアクターです。ユースケースを開始することが多くあります。例えば「本を注文する」の主アクターは会員です。

副アクター（Secondary Actor / Supporting Actor） 🔗

主アクターが目標を達成する過程で、システムが支援を受けたり、情報をやり取りしたりする相手です。例えば「本を注文する」で決済を処理する外部決済システムが副アクターです。

特徴 🔗

アクターはシステムの外部にあり、役割（Role）を表します。1人の人や1つのシステムが複数の役割を担うこともあります。ユースケース図では、通常、人型のアイコンで表します。

2. ユースケース（Use Case） 🔗

特定のアクターがシステムを通じて達成したい

目標

を表し、アクターに提供される完結した機能の単位です。

「ユーザーがログインする」「投稿を書く」「商品を検索する」など、通常は動詞句で名前を付けます。

特徴 🔗

アクターにとって意味のある結果をもたらす必要があります。

1つのユースケースに複数のシナリオを含められます。

図では楕円で表します。

3. シナリオ（Scenario） 🔗

シナリオは、ユースケースが始まってから終わるまでの、アクターとシステムの

一連のやり取り

を具体的に記したものです。

劇の1場面のように、どんな条件で誰が何をし、その結果何が起こるかを順に示します。

基本フロー（Basic Flow / Main Success Scenario） 🔗

最も一般的で、問題なく成功する「ハッピーパス（Happy Path）」です。例外やエラーがなく、アクターが目標を達成する手順を記述します。

代替フロー（Alternative Flows） 🔗

基本フローから外れても、目標を達成できる別の経路を記述します。別の選択肢を選ぶ場合や、特定の条件で処理が変わる場合などです。

例外フロー（Exception Flows / Error Flows） 🔗

実行中にエラーが発生したり、目標を達成できなかったりする場合を記述します。不正な入力やシステムエラーなどが例です。

ユースケースには必ず1つの基本フローがあり、代替フローや例外フローは複数持てます。
これらのシナリオを詳しく記述することが、仕様書の中心です。

ユースケース仕様書を書く 🔗

ユースケース仕様書は、各ユースケースの詳しい情報をまとめた文書です。

決まったテンプレートはありませんが、一般に次の項目を含めます。

ユースケースID（Use Case ID）
個々のユースケースを識別する番号です。例はUC-001です。
ユースケース名（Use Case Name）
「会員登録」のように、目的を簡潔に表す名前です。
アクター（Actors）
関係する主アクターと副アクターです。
概要（Brief Description）
目的と主な機能を1〜2文でまとめます。
事前条件（Preconditions）
開始前に満たす条件です。例えば、ユーザーがログイン済みであることです。
事後条件（Postconditions）
正常に終わったあとのシステムの状態や、保証する条件です。例えば、新規会員の情報がデータベースに保存され、歓迎メールが送られることです。
基本フロー（Basic Flow / Main Success Scenario）
正常に進む場合の主要な手順を順に書きます。
代替フロー（Alternative Flows）
基本フローと異なる、別の成功経路を書きます。
例外フロー（Exception Flows）
エラー時の処理や、失敗するシナリオを書きます。
特別な要件（Special Requirements）
関連する性能やセキュリティなどの非機能要件、業務上のルールなどを書きます。
補足と課題（Notes and Issues）
追加の説明や未解決の課題を書きます。

ユースケース仕様書の例 - オンライン書店で本を注文する 🔗

会員がオンライン書店で本を注文する場合の、簡単な仕様書です。

1. ユースケースID

UC-ORD-001

2. ユースケース名

本を注文する

3. アクター

主アクターは会員。
副アクターは決済システムと在庫管理システム。

4. 概要

会員が欲しい本を選び、支払って注文を完了する。

5. 事前条件

会員がシステムにログインしている。
カートに注文する本が1冊以上入っている。

6. 事後条件

成功したら、注文情報をシステムに記録する。
成功したら、注文された本の在庫が減る。
成功したら、注文完了の通知を表示し、会員にメールを送る。
失敗したら、注文を記録せず、理由をユーザーに伝える。

7. 基本フロー（Main Success Scenario）

会員がカートの「注文する」ボタンを押す。
システムが注文する商品と支払総額を表示し、配送先情報の入力画面を出す。
会員が配送先情報を入力して「支払いに進む」を押す。
システムが支払方法を選ぶ画面を出す。
会員が支払方法を選び、情報を入力して「支払う」を押す。
システムが、注文された本の在庫確認を在庫管理システムに依頼する。
在庫管理システムが、在庫は十分だと返す。
システムが決済システムに支払いを依頼する。
決済システムが、支払いに成功したと返す。
システムが注文情報を保存し、在庫管理システムに在庫を減らすよう依頼する。
注文完了画面を会員に表示し、注文確認メールを送る。

8. 代替フロー（Alternative Flows）

8.1. 配送先を変える
基本フローの手順3で、既存の配送先の代わりに、新しい配送先を入力または選択できる。システムが新しい配送先情報を保存する。
8.2. クーポンを使う
基本フローの手順4で、持っている割引クーポンを適用できる。システムが割引後の最終金額を計算して表示する。

9. 例外フロー（Exception Flows）

9.1. 在庫不足
基本フローの手順7で、在庫管理システムが特定の本の在庫不足を返した場合。
1. システムが対象の本の在庫不足を会員に表示する。
2. 会員はその本を除いて注文を続けるか、注文を取り消せる。
9.2. 決済失敗
基本フローの手順9で、決済システムが失敗を返した場合。
1. システムは失敗のメッセージと、限度額超過や無効なカード情報などの理由を表示する。
2. 会員は別の支払方法を選ぶか、決済情報を修正して再試行できる。
9.3. システムエラー
注文処理中に予期しないエラーが発生した場合。
1. システムは「一時的なエラーが発生しました。時間を置いて再試行してください」などのメッセージを表示する。
2. システムはエラー情報をログに記録する。

10. 特別な要件

注文処理中の個人情報や決済情報など、機密情報をすべて暗号化する。
注文完了までの平均応答時間は5秒以内とする。

ユースケース仕様書は機能ごとの詳しいシナリオを示し、開発チームがユーザーの要求を正確に理解してシステムを実装するための基準になります。

おわりに 🔗

今回は、ユーザーの視点でシステムの機能を定義し、分析するためのユースケースを学びました。アクター、ユースケース、シナリオの基本と、詳しい仕様書を書く方法を見てきました。

次回は、システムの全体像と外部との関係を定義する
システムモデリング - コンテキスト図とアクティビティ図の使い方
を扱います。

参考 🔗

Use case - Wikipedia↗（英語。ユースケースの解説）
Use Case Tutorial - Visual Paradigm↗（英語。ユースケースのチュートリアル）

はじめに 🔗

前回は、ユーザーの隠れた要求を引き出すためのさまざまな分析手法を学びました。

集めた要求を明確に整理すれば、関係者は同じ完成像を共有でき、開発チームは適切な方向に進めます。

今回は、

ユーザーの視点

から、

システムを使って何を達成したいか

に注目し、要求を整理して表す*ユースケース（Use Case）*を詳しく学びます。

ユースケースの基本、アクターとシナリオの役割、ユースケース仕様書の書き方を扱います。図の書き方は次の記事で説明します。

ユースケース（Use Case）とは？ 🔗

価値のある機能

を、利用者の視点で記述します。

ここでいう利用者には、システムとやり取りする人のほか、外部システムや機器も含まれます。これらを*アクター（Actor）*と呼びます。

簡単に言えば、「どのアクターが、システムを使ってどんな目標を達成するか」をシナリオとして表したものです。

例えば、オンライン書店には次のようなユースケースがあります。

「会員が本を検索する。」
「会員が本を注文する。」
「管理者が新刊を登録する。」

各ユースケースの詳しい内容を記述する*ユースケース仕様書（Use Case Specification、Use Case Description）*に、ユースケースの本来の価値があります。

ユースケースの主な構成要素 🔗

ユースケースを理解し、書くために、次の3つの構成要素を把握します。

1. アクター（Actor） 🔗

アクターは、システムの

外部

にあり、システムとやり取りして目標を達成しようとする人、システム、機器などです。

ユースケースを開始したり、その結果の影響を受けたりします。

主アクター（Primary Actor） 🔗

副アクター（Secondary Actor / Supporting Actor） 🔗

特徴 🔗

2. ユースケース（Use Case） 🔗

特定のアクターがシステムを通じて達成したい

目標

を表し、アクターに提供される完結した機能の単位です。

「ユーザーがログインする」「投稿を書く」「商品を検索する」など、通常は動詞句で名前を付けます。

特徴 🔗

アクターにとって意味のある結果をもたらす必要があります。

1つのユースケースに複数のシナリオを含められます。

図では楕円で表します。

3. シナリオ（Scenario） 🔗

シナリオは、ユースケースが始まってから終わるまでの、アクターとシステムの

一連のやり取り

を具体的に記したものです。

劇の1場面のように、どんな条件で誰が何をし、その結果何が起こるかを順に示します。

基本フロー（Basic Flow / Main Success Scenario） 🔗

最も一般的で、問題なく成功する「ハッピーパス（Happy Path）」です。例外やエラーがなく、アクターが目標を達成する手順を記述します。

代替フロー（Alternative Flows） 🔗

基本フローから外れても、目標を達成できる別の経路を記述します。別の選択肢を選ぶ場合や、特定の条件で処理が変わる場合などです。

例外フロー（Exception Flows / Error Flows） 🔗

実行中にエラーが発生したり、目標を達成できなかったりする場合を記述します。不正な入力やシステムエラーなどが例です。

ユースケースには必ず1つの基本フローがあり、代替フローや例外フローは複数持てます。
これらのシナリオを詳しく記述することが、仕様書の中心です。

ユースケース仕様書を書く 🔗

ユースケース仕様書は、各ユースケースの詳しい情報をまとめた文書です。

決まったテンプレートはありませんが、一般に次の項目を含めます。

ユースケースID（Use Case ID）
個々のユースケースを識別する番号です。例はUC-001です。
ユースケース名（Use Case Name）
「会員登録」のように、目的を簡潔に表す名前です。
アクター（Actors）
関係する主アクターと副アクターです。
概要（Brief Description）
目的と主な機能を1〜2文でまとめます。
事前条件（Preconditions）
開始前に満たす条件です。例えば、ユーザーがログイン済みであることです。
事後条件（Postconditions）
正常に終わったあとのシステムの状態や、保証する条件です。例えば、新規会員の情報がデータベースに保存され、歓迎メールが送られることです。
基本フロー（Basic Flow / Main Success Scenario）
正常に進む場合の主要な手順を順に書きます。
代替フロー（Alternative Flows）
基本フローと異なる、別の成功経路を書きます。
例外フロー（Exception Flows）
エラー時の処理や、失敗するシナリオを書きます。
特別な要件（Special Requirements）
関連する性能やセキュリティなどの非機能要件、業務上のルールなどを書きます。
補足と課題（Notes and Issues）
追加の説明や未解決の課題を書きます。

ユースケース仕様書の例 - オンライン書店で本を注文する 🔗

会員がオンライン書店で本を注文する場合の、簡単な仕様書です。

1. ユースケースID

UC-ORD-001

2. ユースケース名

本を注文する

3. アクター

主アクターは会員。
副アクターは決済システムと在庫管理システム。

4. 概要

会員が欲しい本を選び、支払って注文を完了する。

5. 事前条件

会員がシステムにログインしている。
カートに注文する本が1冊以上入っている。

6. 事後条件

成功したら、注文情報をシステムに記録する。
成功したら、注文された本の在庫が減る。
成功したら、注文完了の通知を表示し、会員にメールを送る。
失敗したら、注文を記録せず、理由をユーザーに伝える。

7. 基本フロー（Main Success Scenario）

会員がカートの「注文する」ボタンを押す。
システムが注文する商品と支払総額を表示し、配送先情報の入力画面を出す。
会員が配送先情報を入力して「支払いに進む」を押す。
システムが支払方法を選ぶ画面を出す。
会員が支払方法を選び、情報を入力して「支払う」を押す。
システムが、注文された本の在庫確認を在庫管理システムに依頼する。
在庫管理システムが、在庫は十分だと返す。
システムが決済システムに支払いを依頼する。
決済システムが、支払いに成功したと返す。
システムが注文情報を保存し、在庫管理システムに在庫を減らすよう依頼する。
注文完了画面を会員に表示し、注文確認メールを送る。

8. 代替フロー（Alternative Flows）

8.1. 配送先を変える
基本フローの手順3で、既存の配送先の代わりに、新しい配送先を入力または選択できる。システムが新しい配送先情報を保存する。
8.2. クーポンを使う
基本フローの手順4で、持っている割引クーポンを適用できる。システムが割引後の最終金額を計算して表示する。

9. 例外フロー（Exception Flows）

9.1. 在庫不足
基本フローの手順7で、在庫管理システムが特定の本の在庫不足を返した場合。
1. システムが対象の本の在庫不足を会員に表示する。
2. 会員はその本を除いて注文を続けるか、注文を取り消せる。
9.2. 決済失敗
基本フローの手順9で、決済システムが失敗を返した場合。
1. システムは失敗のメッセージと、限度額超過や無効なカード情報などの理由を表示する。
2. 会員は別の支払方法を選ぶか、決済情報を修正して再試行できる。
9.3. システムエラー
注文処理中に予期しないエラーが発生した場合。
1. システムは「一時的なエラーが発生しました。時間を置いて再試行してください」などのメッセージを表示する。
2. システムはエラー情報をログに記録する。

10. 特別な要件

注文処理中の個人情報や決済情報など、機密情報をすべて暗号化する。
注文完了までの平均応答時間は5秒以内とする。

ユースケース仕様書は機能ごとの詳しいシナリオを示し、開発チームがユーザーの要求を正確に理解してシステムを実装するための基準になります。

おわりに 🔗

次回は、システムの全体像と外部との関係を定義する
システムモデリング - コンテキスト図とアクティビティ図の使い方
を扱います。

参考 🔗

Use case - Wikipedia↗（英語。ユースケースの解説）
Use Case Tutorial - Visual Paradigm↗（英語。ユースケースのチュートリアル）