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

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

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

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

• システムの外部動作を内部の設計とは別に操作できる。

• ユーザーと関係者のニーズを、自然言語を使用した場合よりもはるかに明確に記述できる。

• ユーザー、開発者、およびテスト担当者が使用できる用語をまとめた、一貫性のある用語集を作成できる。

• 要求の矛盾点と不整合を減らすことができる。

• 要求の変更に応答するのに必要な作業を減らすことができる。

• 機能の開発順序を計画できる。

• モデルをシステム テストの基盤として使用し、テストと要求の間に明確な関係を設定できる。この関係は、要求が変更されたときにテストを適切に更新するのに役立ちます。これにより、確実にシステムが新しい要求に対応できます。

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

[!メモ]

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

一般的なタスク

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

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

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

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

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

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

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

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

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

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

• 実装の詳細に気を取られることなく、ユーザーがシステムに望む機能の開発に注力できる。

• システムまたはシステムの特定のリリースの対象範囲について話し合うことができる。

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

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

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

• システムが使用されるビジネス環境についてユーザーが話し合う。

• ユース ケース、ビジネス ルール、ユーザー ストーリーなどの記述においてユーザーのニーズを記述する。

• システムの API で、またはユーザー インターフェイスを介して交換される情報の種類を指定する。

• システムまたは承認テストについて説明する。

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

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

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

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

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

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

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

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

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

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

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

• それらの用語間の関係を明確化する。

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

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

ビジネス ルールの表示

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

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

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

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

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

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

サービス品質要求の記述

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

• パフォーマンス

• セキュリティ

• 使用性

• 信頼性

• 保全性

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

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

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

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

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

次に例を示します。

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

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

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

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

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

次に例を示します。

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

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

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

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

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

• 要求モデルのクラスごとに、"このクラスのインスタンスはどのようなユース ケースで生成されるのか" とたずねます。たとえば、オンラインの料理注文サービスの場合は、"レストランのメニュー クラスのインスタンスはどのようなユース ケースで生成されるのか" という質問が考えられます。この質問は、新しいレストランによるサービスへのサインアップ方法や、メニューの登録方法に関する話し合いに発展します。属性と関連付けを生成または変更する要素についても同様の質問をたずねることができます。

• 要求モデルのユース ケースごとに、クラス図で定義した用語を使用して、成果または事後条件を記述するようにします。多くの場合、ユース ケースの発生前後にクラスのインスタンスのスケッチを作成することでユース ケースの効果を示すと便利です。たとえば、ユース ケースの事後条件が "メニュー品目が顧客の注文に追加されている" である場合は、"注文" クラスと "メニュー品目" クラスのインスタンスをスケッチで示します。新しいリンクや新しいオブジェクトなどのユース ケースの効果は、別の色か、新しい図で示します。多くの場合、これからモデルに必要な情報に関する話し合いに発展します。要求のクラスは実装に直接関係するわけではありませんが、クラスにはシステムで格納および送信する必要のある情報が示されます。

• 属性または関連付けに対する制約、特に複数の属性または関連付けに関係する制約について質問します。

• ユース ケースの有効なシーケンスと無効なシーケンスについて質問し、シーケンス図またはアクティビティ図を生成してそれらを図示します。

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

参照

概念

方法: UML モデルおよび UML 図を編集する

モデルからのテストの作成

開発プロセス内でのモデルの使用

ソフトウェア システムのアーキテクチャのモデリング

その他の技術情報

Sample VS Extension: UML Domain Modeling features (サンプル VS 拡張機能: UML ドメイン モデリング機能)

Sample VS Extension: Color UML Elements by Stereotype (サンプル VS 拡張機能: ステレオタイプにより UML 要素を色分けする)

Sample VS Extension: Link UML Elements to Diagrams, Files, and other Elements (サンプル VS 拡張機能: UML 要素を図、ファイル、および他の要素にリンクする)

Sample VS Extension: Align Shapes on a UML Diagram (サンプル VS 拡張機能: UML 図で図形を整理する)

Video: Modeling the Business Domain (ビデオ: ビジネス ドメインのモデリング)