ユーザー要求のモデリング

[アーティクル]
08/09/2011

Microsoft Visual Studio Ultimate を使用すると、ユーザーのアクティビティおよびユーザーの目標達成を支援するシステムの役割に関する図を生成することで、ユーザーのニーズを把握し、話し合って、関係者に伝達することができます。要求モデルはこうした図のセットであり、それぞれの図はユーザーニーズの異なる側面に対応しています。

ビデオデモについては、「Modeling the Business Domain (ビジネスドメインのモデリング)」を参照してください。

要求モデルには、次のような利点があります。

システムの外部動作を内部の設計とは別に操作できる。
ユーザーと関係者のニーズを、自然言語を使用した場合よりもはるかに明確に記述できる。
ユーザー、開発者、およびテスト担当者が使用できる用語をまとめた、一貫性のある用語集を作成できる。
要求の矛盾点と不整合を減らすことができる。
要求の変更に応答するのに必要な作業を減らすことができる。
機能の開発順序を計画できる。
モデルをシステムテストの基盤として使用し、テストと要求の間に明確な関係を設定できる。この関係は、要求が変更されたときにテストを適切に更新するのに役立ちます。これにより、確実にシステムが新しい要求に対応できます。

要求モデルの最大の利点は、ユーザーまたはその代表者との話し合いの焦点を定め、各イテレーションの開始時にモデルを見直すために使用できることです。コードを記述する前に詳細な要求モデルを完成させる必要はありません。通常、部分的に機能するアプリケーションは、かなり単純化されたものであっても、要求にについてのユーザーとの活発な話し合いを最大限に促進する基盤として使用できます。モデルを使用すると、こうした話し合いの結果を効果的に要約できます。詳細については、「開発プロセス内でのモデルの使用」を参照してください。

注意

この記事のトピックでは、"システム" は開発中のシステムまたはアプリケーションのことを表します。多数のソフトウェアコンポーネントとハードウェアコンポーネントの大規模なコレクション、単一のアプリケーション、上位のシステムに組み込まれたソフトウェアコンポーネントなども、まとめて "システム" と呼びます。どの場合も、要求モデルには、ユーザーインターフェイスまたは API を介してシステムの外部から参照できる動作が記述されています。

一般的なタスク

生成できるユーザーの要求のビューは数種類あります。各ビューには、それぞれ特定の種類の情報が表示されます。これらのビューを生成ときは、必要に応じて頻繁にビュー間を移動することをお勧めします。どのビューからでも開始できます。

図またはドキュメント	記述する要求モデルの内容	セクション
ユースケース図	システムのユーザーと使用目的。	システムの使用方法の記述
概念クラス図	要求について記述する際に使用される型 (システムのインターフェイスで参照できる型) の用語集。	要求の記述に使用される用語の定義
アクティビティ図	ユーザーが実行するアクティビティとシステムまたはそのパートが実行するアクティビティの間の作業と情報のフロー。	ユーザーとシステムの間のワークフローの表示
シーケンス図	ユーザーとシステムまたはそのパートの間の相互作用のシーケンス。アクティビティ図の代替ビューです。	ユーザーとシステムの間の相互作用の表示
その他のドキュメントまたは作業項目	パフォーマンス、セキュリティ、使用性、および信頼性の基準。	サービス品質要求の記述
その他のドキュメントまたは作業項目	特定のユースケースに限定されない制約と規則。	ビジネスルールの表示

ほとんどの種類の図は、他の用途でも使用できます。図の種類の概要については、「ソフトウェア設計のためのモデルの開発」を参照してください。図の生成に関する基本情報については、「方法: UML モデルおよび UML 図を編集する」を参照してください。

システムの使用方法の記述

システムのユーザーと使用目的を記述するには、ユースケース図を生成します。ユースケースは、システムのユーザーの目的と、ユーザーがそれを達成するために実行する手順を表します。

たとえば、料理のオンライン販売システムの場合、顧客がメニューから品目を選択できるようにすると同時に、販売側のレストランがメニューを更新できるようにする必要があります。これを、ユースケース図では次のようにまとめることができます。

"顧客" と "レストラン" のユースケース

ユースケースが複数のより小さいケースで構成されていることを示すこともできます。たとえば、料理の注文は料理の購入作業の一部であり、支払いや宅配も伴います。

システムは支払いに関与するが納入には関与しない

どのユースケースが開発中のシステムの対象範囲に含まれているかを示すこともできます。たとえば、図中のシステムは、"料理の宅配" ユースケースには関与していません。これは開発作業のコンテキストを設定するうえで役立ちます (ユースケース図では、システムまたはそのコンポーネントを表すためにサブシステムコンテナーを使用できます)。

ユースケース図は、チームが後続のリリースに含めるものを話し合うときにも役立ちます。たとえば、システムの最初のリリースで、"代金の支払い" をシステムの中に組み込む代わりに、レストランと顧客の間に直接配置するかどうかを話し合うことができます。この場合は、最初のリリースの "料理宅配システム" ボックスの外に "代金の支払い" を移動できます。

ユースケース図で示すことができるのは、ユースケースの概要だけです。詳細な説明を示す必要がある場合は、図のユースケースを他のドキュメントおよび図にリンクさせることができます。これを行う方法については、「方法: ユースケースをドキュメントおよび図にリンクする」を参照してください。

ユースケース図は、チームに以下の利点をもたらします。

実装の詳細に気を取られることなく、ユーザーがシステムに望む機能の開発に注力できる。
システムまたはシステムの特定のリリースの対象範囲について話し合うことができる。

詳細については、以下のトピックを参照してください。

内容	トピック
ユースケースの生成方法の詳細	UML ユースケース図: ガイドライン
ユースケース図の要素	UML ユースケース図: リファレンス
ユースケースからコードを開発する方法	ソフトウェアシステムのアーキテクチャのモデリング

要求の記述に使用される用語の定義

UML クラス図を使用すると、次の目的で使用される、一貫性のあるビジネス概念の語彙を定義できます。

システムが使用されるビジネス環境についてユーザーが話し合う。
ユースケース、ビジネスルール、ユーザーストーリーなどの記述においてユーザーのニーズを記述する。
システムの API で、またはユーザーインターフェイスを介して交換される情報の種類を指定する。
システムまたは承認テストについて説明する。

こうした目的で使用されるとき、UML クラス図の内容は概念クラス図と呼ばれます (ドメインモデルまたは分析クラスモデルとも呼ばれます)。

概念クラス図では、要求の説明に必要なクラスだけを表示し、システムの内部設計の詳細は省きます。図には、システムの内部設計の詳細は一切示されません。通常、概念クラスでは、操作またはインターフェイスは表示しません。

たとえば、"料理宅配システム" の場合は次のような概念クラスを生成できます。

クラスメニュー、注文、メニュー項目、注文項目

概念クラス図は、要求モデル全体で使用する用語の語彙を示します。たとえば、"料理の注文" ユースケースについて詳しく説明する際には、次のように記述します。

顧客は、メニューを選択し、それから注文を作成します。次に、メニューからメニュー品目を選択して、注文の注文品目を作成します。

この説明で使用されている用語は、モデルにおけるクラスの名前であることがわかります。この図により、これらのクラス間の関係が明確になります。たとえば、それぞれの "注文" は 1 つの "メニュー" だけに関連付けられていることがはっきりわかります。

ユーザー要求に関する誤解の原因は、多くの場合、単語のニュアンスが同じように理解されないことにあります。たとえば、ほとんどのレストランでは、"メニュー" と "注文" という用語については共通の理解がありますが、"注文" の品目と "メニュー" の品目の違いはそれほど明確ではありません。ビジネス上の関係者と要求について話し合う際には、こうした違いを明らかにすることが重要です。クラス図は、用語と用語間の関係を明確化するのに役立つ便利なツールです。

概念クラスモデルでは、システムのビジネスロジックの記述に使用できる基本的な語彙を定義できます。ただし、ソフトウェアにおけるクラスは、実装でパフォーマンス、分散性、柔軟性などの懸念事項を考慮する必要があるため、通常は概念モデルよりもはるかに複雑です。概念クラスの複数の異なる実装が 1 つのシステム内に共存することはよくあります。

たとえば、"注文" は、システム内の複数の異なるパートにおいて、およびパート間の複数の異なるインターフェイスにおいて、XML、SQL、HTML、および C# で表現されることがあります。また、"注文" と "メニュー" の関連付けは、C# コード内の参照、データベース内のリレーション、XML 内の相互参照 ID など、さまざまな方法で表現される場合があります。このようなバリエーションがあるにせよ、概念モデルは、ソフトウェアのすべてのパートに当てはまる重要な情報を提供します。この例のクラス図からわかるのは、すべての実装において、それぞれの "注文" に関連付けられる "メニュー" は 1 つだけだということです。

要求クラス図を生成することにより、チームは以下のことができるようになります。

ユーザーのニーズに関する話し合いの際に使用される基本的な用語を定義し、標準化する。
それらの用語間の関係を明確化する。

詳細については、以下のトピックを参照してください。

内容	トピック
要求のクラスを見つける方法の詳細	UML クラス図: ガイドライン
概念クラス図の要素	UML クラス図: リファレンス
概念クラスからコードを開発する方法	ソフトウェアシステムのアーキテクチャのモデリング

概念クラス図では、通常、誘導可能性を表すために関連に矢印を配置しても役に立ちません。これは、図が実装を表さないためです。関連は、現実世界のオブジェクトの関係を表します。「Sample: UML Domain Modeling features (サンプル: UML ドメインモデリング機能)」の Visual Studio 拡張機能は方向性のない矢印を既定にします。

ビジネスルールの表示

ビジネスルールは、特定のユースケースに関連付けられていない要求であり、システム全体で従う必要があります。

多くのビジネスルールは、概念クラス間の関係に対する制約です。こうした静的ビジネスルールは、概念クラス図上の関連するクラスに関連付けられるコメントとして記述できます。次に例を示します。

Order クラスにアタッチされたコメント内のルール

動的ビジネスルールは、許容できるイベントのシーケンスを制限します。たとえば、システムにログインしないと他の操作を実行できないという制限を示す場合は、シーケンス図かアクティビティ図を使用します。

ただし、多くの動的ルールを静的ルールに置き換えることで、その効果と汎用性を高めることができます。たとえば、"Logged In" ブール属性を概念クラスモデルのクラスに追加できます。 "Logged In" は、ログインユースケースでは事後条件として、それ以外のほとんどのユースケースでは事前条件として追加します。この方法により、イベントのシーケンスの考えられるすべての組み合わせを定義する必要がなくなります。また、新しいユースケースをモデルに追加する際の柔軟性も高まります。

ただし、ここでの選択は要求の定義方法に関係するものであり、要求をプログラムコードで実装する方法とは無関係です。

詳細については、以下のトピックを参照してください。

内容	トピック
静的ビジネスルールの特定と記録の詳細	UML クラス図: ガイドライン
概念クラス図の要素	UML クラス図: リファレンス
ビジネスルールに準拠したコードを開発する方法	ソフトウェアシステムのアーキテクチャのモデリング

サービス品質要求の記述

サービス品質要求は、いくつかのカテゴリに分けられます。そのカテゴリは以下のとおりです。

パフォーマンス
セキュリティ
使用性
信頼性
保全性

これらの要求の一部は、特定のユースケースの記述に含めることができます。それ以外の要求は、ユースケースに固有ではないので、別のドキュメントに記述する方がより効果的です。可能な限り、要求モデルで定義されている語彙に準拠すると便利です。次の例の要求で使用されている主な単語は、前の図のアクター、ユースケース、およびクラスのタイトルです。

"顧客が料理を注文している" ときに "レストラン" が "メニュー品目" を削除した場合、その "メニュー品目" を参照する "注文品目" は、すべて赤色で表示されます。

詳細については、以下のトピックを参照してください。

内容	トピック
サービス品質要求の記録の詳細	Guidelines for Defining Quality of Service Requirements
ユースケースへの追加のドキュメントの関連付け	方法: ユースケースをドキュメントおよび図にリンクする
サービス品質要求に準拠したコードを開発する方法	ソフトウェアシステムのアーキテクチャのモデリング

ユーザーとシステムの間のワークフローの表示

アクティビティ図を使用すると、複数の異なるユースケース間のワークフローを示すことができます。要求モデルを生成するときは、通常、ユーザーがシステムの内外で実行する主要タスクを示すアクティビティ図を最初に生成することをお勧めします。

次に例を示します。

3 つのアクションと 1 つのループがあるアクティビティ

ユースケース図とアクティビティ図を生成すると、同じ情報が異なるビューで表示されます。ユースケース図の方が入れ子の状態 (大きなアクティビティに含まれる小さなアクション) を効果的に示すことができますが、ワークフローを示すことはできません。次に例を示します。

前のアクションのユースケース

アクティビティ図を使用すると、ソフトウェア内のアルゴリズムも図示できますが、ビジネスプロセス用に図を使用するどきは、システム外部で参照可能なアクションに重点を置くようにしてください。

詳細については、以下のトピックを参照してください。

内容	トピック
ビジネスワークフローの定義方法の詳細	UML アクティビティ図: ガイドライン
アクティビティ図の要素	UML アクティビティ図: リファレンス
アクティビティ図からコードを開発する方法	ソフトウェアシステムのアーキテクチャのモデリング

ユーザーとシステムの間の相互作用の表示

シーケンス図を使用すると、システムと外部アクターの間、またはシステムのパートの間におけるメッセージのやり取りを示すことができます。シーケンス図は、ユースケースの手順を示すビューであり、このビューには、相互作用のシーケンスが明確に示されます。シーケンス図は、相互に対話するパーティがユースケースに複数存在する場合や、システムに API が含まれる場合に特に役立ちます。

次に例を示します。

システムとアクターを含むシーケンスダイアグラム

シーケンス図の利点の 1 つは、構築中のシステムでどのようなメッセージを受け取るかを簡単に確認できることです。システムを設計する場合は、1 つのシステムの生存線をそのコンポーネントごとの生存線に置き換え、各受信メッセージへの応答としてコンポーネント間の相互作用を示すことができます。

詳細については、以下のトピックを参照してください。

内容	トピック
相互作用を定義する方法の詳細	UML シーケンス図: ガイドライン
シーケンス図の要素	UML シーケンス図: リファレンス
シーケンス図からコードを開発する方法	ソフトウェアシステムのアーキテクチャのモデリング

モデルを使用した整合性の向上

モデルを生成すると、通常は、ユーザーの要求の一貫性と明瞭性が大幅に高まります。システムが使用されるビジネス環境についての理解が関係者によって異なることはよくあります。したがって、クライアント間のこうした相違をまず最初に解消しておく必要があります。

モデルの生成中にビジネスドメインに関する数々の疑問が生じるのは当然の成り行きです。それをユーザーに質問することで、プロジェクトの後の段階で変更を加える必要性が少なくなります。ここでは、いくつか具体的な質問を紹介します。まず自分自身で考え、答えがはっきりしない場合には、ビジネス上の関係者にたずねてください。

要求モデルのクラスごとに、"このクラスのインスタンスはどのようなユースケースで生成されるのか" とたずねます。たとえば、オンラインの料理注文サービスの場合は、"レストランのメニュークラスのインスタンスはどのようなユースケースで生成されるのか" という質問が考えられます。この質問は、新しいレストランによるサービスへのサインアップ方法や、メニューの登録方法に関する話し合いに発展します。属性と関連付けを生成または変更する要素についても同様の質問をたずねることができます。
要求モデルのユースケースごとに、クラス図で定義した用語を使用して、成果または事後条件を記述するようにします。多くの場合、ユースケースの発生前後にクラスのインスタンスのスケッチを作成することでユースケースの効果を示すと便利です。たとえば、ユースケースの事後条件が "メニュー品目が顧客の注文に追加されている" である場合は、"注文" クラスと "メニュー品目" クラスのインスタンスをスケッチで示します。新しいリンクや新しいオブジェクトなどのユースケースの効果は、別の色か、新しい図で示します。多くの場合、これからモデルに必要な情報に関する話し合いに発展します。要求のクラスは実装に直接関係するわけではありませんが、クラスにはシステムで格納および送信する必要のある情報が示されます。
属性または関連付けに対する制約、特に複数の属性または関連付けに関係する制約について質問します。
ユースケースの有効なシーケンスと無効なシーケンスについて質問し、シーケンス図またはアクティビティ図を生成してそれらを図示します。

さまざまな図が示すビュー間の関係を確認することで、ユーザーの考える主要な概念をすばやく理解し、ユーザーがシステムに望むものを特定するのを支援できます。また、どの要求が関係者にとって最も不確かであるかをより効果的に把握できます。このような機能をプロジェクトの早い段階で開発することを計画してください。簡易な形式であっても、これによりユーザーは機能を実際に試すことができます。