ユーザー要件のモデリング
Visual Studio を使用すると、ユーザーの目標達成を支援する際に、彼らのアクティビティやシステムが果たしている役割に関する図を描画することで、ユーザー ニーズを理解し、検討し、やり取りすることができます。 要求モデルとはこのような一連の図のことで、それぞれの図では、ユーザー ニーズの異なる側面に注目しています。
どのバージョンの Visual Studio が各モデルの種類をサポートしているかについては、「 Version support for architecture and modeling tools」を参照してください。
要求モデルの特長:
システムの内部の設計とは別に、システムの外部動作に焦点を当てます。
自然言語を使用した場合と比べて、ユーザーのニーズと利害関係者のニーズをより明確に記述します。
ユーザー、開発者、テスト担当者が使用できる、一貫した用語集を定義します。
要求と照らし合わせた際のギャップと不整合を軽減します。
要求の変更に応答するために必要な作業を削減します。
機能の開発順序を計画します。
システム テストのベースとしてモデルを使用して、テストと要求間の関係を明確にします。 要求が変更された場合、この関係により、テストを正しく更新できます。 これにより、システムが新しい要求を満たしていることを確認します。
要求モデルは、ユーザーまたはユーザーの代表者との話し合いに集中する場合や、各反復処理の開始時に再検討する場合に使用すると、最大のメリットが得られます。 コードを作成する前に、要求モデルを細部まで完成させる必要はありません。 通常、非常に簡略化された状態で部分的にしか動作していないアプリケーションでも、ユーザーと要求について検討する場合に、非常に効果の上がるベースとなります。 このモデルは、これらの話し合いの結果を要約する効果的な方法です。 詳細については、「開発プロセス内でのモデルの使用」を参照してください。
注意
これらのトピックでは、"システム" という用語は、開発中のシステムまたはアプリケーションを意味します。 システムは、数多くのソフトウェアおよびハードウェア コンポーネントが大規模に収集されたものを指す場合があります。また、1 つのアプリケーションの場合もあれば、大規模なシステム内の 1 つのソフトウェア コンポーネントを指すこともあります。 いずれの場合でも、要求モデルは、ユーザー インターフェイスを使用するか、API を使用するかにかかわらず、システムの外側から確認できる動作を記述します。
一般的なタスク
ユーザー要求について、複数の異なるビューを作成することができます。 各ビューは、特定の種類の情報を提供します。 これらのビューを作成するときは、頻繁にビューを切り替えることをお勧めします。 任意のビューから開始することができます。
| 図またはドキュメント | 要求モデルに記載されている内容 | Section |
|---|---|---|
| 概念クラス図 | 要求の記述に使用する型の用語集。システムのインターフェイスで確認できる型。 | |
| 追加のドキュメントまたは作業項目 | パフォーマンス、セキュリティ、使いやすさ、および信頼性の条件。 | サービス品質要求の記述 |
| 追加のドキュメントまたは作業項目 | 特定のユース ケースに固有でない制約とルール | ビジネス ルールの表示 |
ほとんどの種類の図が、他の目的に使用できることに注意してください。 図の種類の概要については、「アプリのモデルを生成する」を参照してください。
ビジネス ルールの表示
ビジネス ルールとは、特定のユース ケースに関連付けられておらず、システム全体で認められる要求です。
多くのビジネス ルールは、概念クラス間の関係に関する制約です。 概念クラス図では、これらの "静的なビジネス ルール" を、関連するクラスに関連付けられたコメントとして記述できます。 次に例を示します。
動的ビジネス ルール は、イベントの許容可能なシーケンスを制約します。 たとえば、シーケンス図やアクティビティ図を使って、ユーザーがシステムにログインしてから他の操作を実行する必要があることを示すとします。
しかし、多くの動的ルールは、より効果的かつ一般的に静的ルールに書き換えることができます。 たとえば、概念クラス モデルのクラスに 'Logged In' ブール値属性を追加することができます。 Log in ユース ケースの事後条件として Logged In を追加し、他のほとんどのユース ケースには事前条件としてそれを追加します。 この方法を使用すると、イベントのシーケンスのすべての可能な組み合わせを定義する必要はなくなります。 また、新しいユース ケースをモデルに追加する場合に、柔軟性も向上します。
ここでの選択は、要求をどのように定義するかということであり、これはプログラム コードへの要求の実装方法とは無関係であることに注意してください。
以降のトピックで詳しく説明します。
| 詳細 | Read |
|---|---|
| ビジネス ルールに準拠しているコードを開発する方法 | アプリのアーキテクチャをモデル化する |
サービス品質要求の記述
サービス品質要求には、いくつかのカテゴリがあります。 次に例を示します。
パフォーマンス
セキュリティ
使いやすさ
[信頼性]
保全性
これらの要求のいくつかを、特定のユース ケースの説明に含めることができます。 その他の要求は、ユース ケースに固有のものではなく、個別のドキュメントに記載することが最も効果的です。 可能であれば、要求モデルで定義されているボキャブラリに準拠すると便利です。 次の例では、要求で使用されている主な単語が、前のイラストのアクターのタイトル、ユース ケース、およびクラスである点に注意してください。
Customer が Meal を Ordering 中に、Restaurant が Menu Item を削除すると、その Menu Item を参照する Order Item が赤色で表示されます。
サービス品質要求に準拠するコードを開発する方法については、「アプリのアーキテクチャのモデル化」を参照してください。