模型用户要求

Visual Studio 通过绘制有关其活动的关系图以及系统在帮助他们实现目标方面所扮演的部分，帮助你了解、讨论和传达用户的需求。 要求模型是一组这些关系图，每个关系图都侧重于用户需求的不同方面。

若要查看 Visual Studio 哪些版本支持每种类型的模型，请参阅 对体系结构和建模工具的版本支持。

要求模型可帮助你：

• 专注于系统的外部行为，独立于其内部设计。

• 描述用户和利益相关者的需求时，应该比自然语言更加清晰明确，减少歧义。

• 定义可供用户、开发人员和测试人员使用的术语的一致术语表。

• 减少要求中的差距和不一致。

• 减少响应要求更改所需的工作。

• 规划将开发功能的顺序。

• 使用模型作为系统测试的基础，明确测试与要求之间的关系。 当要求发生更改时，此关系有助于正确更新测试。 这可确保系统满足新要求。

在与用户或其代表进行讨论时，如果通过需求模型来引导讨论，并在每次迭代开始时重新审视它，需求模型将能提供最大的益处。 在编写代码之前，无需详细完成设计。 部分工作的应用程序（即使非常简化）通常构成了与用户讨论要求的最刺激的基础。 该模型是总结这些讨论结果的有效方法。 有关详细信息，请参阅 在开发过程中使用模型。

常见任务

可以创建用户要求的多个不同视图。 每个视图都提供特定类型的信息。 创建这些视图时，最好经常从一个视图移动到另一个视图。 可以从任何视图开始。

请注意，大多数关系图类型可用于其他目的。 有关关系图类型的概述，请参阅 为应用创建模型。

显示业务规则

业务规则是一项不与特定用例关联的要求，应在整个系统中观察。

许多业务规则是概念类之间的关系的约束。 可以将这些 静态业务规则 编写为与概念类图上相关类关联的注释。 例如：

动态业务规则 约束允许的事件序列。 例如，使用序列图或活动图来显示用户必须先登录，然后才能执行系统中的其他操作。

但是，通过将动态规则替换为静态规则，可以更有效地和通用声明许多动态规则。 例如，可以将布尔属性“Logged In”添加到概念类模型中的类。 将 "已登录" 添加为登录用例的后置条件，并将其作为大多数其他用例的前提条件。 使用此方法，可以避免定义事件序列的所有可能组合。 当你需要向模型添加新用例时，它还更灵活。

请注意，此处的选择是关于如何定义要求，这与如何在程序代码中实现要求无关。

以下主题提供了详细信息：

描述服务质量要求

有几种类别的服务质量要求。 这些因素包括：

• Performance

• 安全性

• Usability

• Reliability

• 稳定性

可以在特定用例的说明中包含其中一些要求。 其他要求不特定于用例，并且最有效地用单独的文档编写。 当可能时，遵循按照要求模型定义的词汇非常有用。 ** 在以下示例中，请注意，需求中使用的主要词汇是前面插图中演员、用例和类的名称：

如果餐厅在客户订购餐时删除菜单项，则引用该菜单项的任何订单项将以红色显示。

请参阅 应用体系结构的模型 ，了解如何开发符合服务质量要求的代码。

相关内容

• 在开发过程中使用模型
• 为应用的体系结构建模