次の方法で共有


モデルユーザーの要件

Visual Studio は、ユーザーのアクティビティやシステムが目標を達成するのに役立つ部分について図を描くことで、ユーザーのニーズを理解し、話し合い、伝えるのに役立ちます。 要件モデルは、これらの図のセットであり、それぞれがユーザーのニーズのさまざまな側面に焦点を当てています。

各種類のモデルをサポートする Visual Studio のバージョンについては、 アーキテクチャおよびモデリング ツールのバージョンのサポートに関するページを参照してください。

要件モデルは、次の場合に役立ちます。

  • 内部設計とは別に、システムの外部動作に焦点を当てます。

  • ユーザーと利害関係者のニーズを、自然言語で行うよりもはるかにあいまいさを少なく記述します。

  • ユーザー、開発者、テスト担当者が使用できる用語の一貫性のある用語集を定義します。

  • 要件のギャップと不整合を減らします。

  • 要件の変更に対応するために必要な作業を減らします。

  • 機能を開発する順序を計画します。

  • システム テストの基礎としてモデルを使用し、テストと要件の間に明確な関係を築きます。 要件が変更されると、この関係はテストを正しく更新するのに役立ちます。 これにより、システムが新しい要件を満たすことができます。

要件モデルを使用して、ユーザーまたはその担当者とのディスカッションに集中し、各イテレーションの開始時に再検討すると、最大の利点が得られます。 コードを記述する前に、詳細に仕上げる必要はありません。 部分的に動作するアプリケーションは、非常に単純化された場合でも、一般に、ユーザーとの要件の議論のための最も刺激的な基礎を形成します。 モデルは、これらの議論の結果を要約する効果的な方法です。 詳細については、「 開発プロセスでモデルを使用する」を参照してください

これらのトピック全体を通して、"system" とは、開発しているシステムまたはアプリケーションを意味します。 これは、多くのソフトウェアおよびハードウェア コンポーネントの大規模なコレクションである可能性があります。または単一のアプリケーション。または大規模なシステム内のソフトウェア コンポーネント。 どの場合も、要件モデルは、ユーザー インターフェイスまたは API を介して、システムの外部から表示される動作を記述します。

一般的なタスク

ユーザーの要件を複数の異なるビューで作成できます。 各ビューには、特定の種類の情報が表示されます。 これらのビューを作成するときは、頻繁に移動することをお勧めします。 任意のビューから開始できます。

図またはドキュメント 要件モデルでの説明 セクション
概念クラス図 要件を説明するために使用される型の用語集。システムのインターフェイスに表示される型。
その他のドキュメントまたは作業項目 パフォーマンス、セキュリティ、使いやすさ、信頼性の基準。 サービスの品質要件の説明
その他のドキュメントまたは作業項目 特定のユース ケースに固有ではない制約とルール ビジネス ルールの表示

ほとんどの種類のダイアグラムは、他の目的で使用できることに注意してください。 ダイアグラムの種類の概要については、 アプリのモデルの作成に関するページを参照してください

ビジネス ルールの表示

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

多くのビジネス ルールは、概念クラス間のリレーションシップに対する制約です。 これらの 静的ビジネス ルール は、概念クラス図の関連クラスに関連付けられたコメントとして記述できます。 例えば次が挙げられます。

Order クラスに添付されたコメントのルール。

動的ビジネス ルール は、イベントの許容されるシーケンスを制限します。 たとえば、シーケンス図またはアクティビティ図を使用して、システムで他の操作を実行する前にユーザーがログインする必要があることを示します。

ただし、多くの動的ルールは、静的ルールに置き換えることで、より効果的かつ汎用的に記述できます。 たとえば、概念クラス モデルのクラスにブール属性 'Logged In' を追加できます。 ログインは、ログインユース ケースの事後条件として追加し、他のほとんどのユース ケースの前提条件として追加します。 この方法では、一連のイベントの可能なすべての組み合わせを定義することを回避できます。 また、モデルに新しいユース ケースを追加する必要がある場合にも、柔軟性が高くなります。

ここでの選択は、要件を定義する方法に関するものです。これは、プログラム コードで要件を実装する方法とは無関係であることに注意してください。

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

詳しくは、こちらをご覧ください。 Read
ビジネス ルールに準拠するコードを開発する方法 アプリのアーキテクチャをモデル化する

サービスの品質要件の説明

サービスの品質要件には、いくつかのカテゴリがあります。 これには次のものが含まれます。

  • Performance

  • セキュリティ

  • ユーザビリティ

  • Reliability

  • 堅牢性

これらの要件の一部は、特定のユース ケースの説明に含めることができます。 その他の要件はユース ケースに固有ではなく、別のドキュメントで最も効果的に記述されます。 可能な場合は、要件モデルで定義されているボキャブラリに従うと便利です。 次の例では、要件で使用される主な単語が、前の図のアクター、ユース ケース、およびクラスのタイトルであることに注意してください。

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

サービスの品質要件に準拠するコードを開発する方法については、 アプリのアーキテクチャのモデル 化に関するページを参照してください。