用户需求建模

需求模型具有以下作用：

将系统的外部行为与其内部设计区分开来进行重点关注。

与使用自然语言相比，在描述用户和利益干系人的需求方面产生的歧义更少。

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

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

降低响应需求更改所需的工作量。

计划开发各个功能的顺序。

使用模型作为系统测试的基础，并在测试和需求之间建立一种明确的关系。在需求发生更改时，这种关系有助于您准确地更新测试。这样可确保系统满足新的需求。

如果您使用需求模型关注与用户或其代表进行的讨论，并在每次迭代的开头重新查看需求模型，则使用需求模型将获得最大好处。在编写代码之前，不必详细完成需求模型。即使是非常简单的部分工作的应用程序，通常也能构成与用户讨论需求时的最具激励性的基础。模型是汇总这些讨论结果的一种有效方法。有关更多信息，请参见 在开发过程中使用模型。 

 说明 

在所有这些主题中，“系统”表示将要开发的系统或应用程序。它可以是许多软件和硬件组件的大型集合，也可以是单个应用程序，或者可以是更大系统中的软件组件。在每种情况下，需求模型都描述了在系统外部可以通过用户界面或 API 看到的行为。

常规任务可以为用户需求创建多种不同的视图。每个视图都提供特定类型的信息。当您创建这些视图时，最好经常在各个视图之间进行切换。创建时，可以从任何视图开始。

关系图或文档

 需求模型中描述的内容

 节

用例图

 谁使用系统以及使用系统执行什么操作。

 描述系统的使用方式

概念类图

 用于描述需求的类型的术语表；可在系统界面看到的类型。

 定义用于描述需求的术语

活动图

 由用户与系统或其部件执行的活动之间的工作流和信息。

 显示用户和系统之间的工作流

序列图

 用户与系统或其部件之间的交互的序列。活动图的替代视图。

 显示用户和系统之间的交互

附加文档或工作项

 性能、安全性、可用性和可靠性条件。

 描述服务质量要求

附加文档或工作项

 非特定于具体用例的约束和规则

 显示业务规则

请注意，大多数关系图类型都可用于其他目的。有关关系图类型的概述，请参见 开发软件设计模型。 有关绘制关系图的基本信息，请参见 如何：编辑 UML 模型和关系图。 

描述系统的使用方式创建用例图以描述谁将使用系统以及使用系统实现的目的。用例表示系统用户的目标以及为实现该目标所执行的步骤。

例如，在线售餐系统必须允许顾客从菜单中点菜，且必须允许供应餐饮的餐馆更新菜单。您可以在用例图中概括这一切：

还可以显示用例如何由多个更小的事例组成。例如，订餐是购餐的一个部件，而购餐还包括付款和送餐：

还可以显示在正开发的系统范围中包括哪些用例。例如，插图中的系统未参与“送餐”用例。这有助于设置开发工作的上下文。（在用例图中，可以使用子系统容器表示系统或其组件。）

它还可帮助您的团队讨论将在后续版本中包括的内容。例如，您可以讨论是否在系统的初始版本中而不是在整个系统中，直接在餐馆和顾客之间安排“付餐费”。这种情况下，您可以将初始版本的“付餐费”移到“立即就餐”系统矩形的外部。

用例图仅提供用例的摘要。若要提供更详细的说明，可将关系图上的用例链接到单独的文档或链接到其他关系图。若要了解如何执行此操作，请参见 如何：将用例链接到文档和关系图。 

绘制用例图可帮助团队：

关注用户需要对系统执行的操作，而不是将注意力集中在实现的细节方面。

讨论系统的范围或系统的特定版本。

下列主题提供了更多信息：

要了解

 请阅读

有关如何创建用例的更详细信息

 UML 用例图：准则

用例图中的元素

 UML 用例图：参考

如何通过用例开发代码

 建立软件系统体系结构模型

定义用于描述需求的术语您可以使用 UML 类图来帮助开发一致的、用于以下用途的业务概念术语：

由用户自身讨论系统要作用于的业务。

描述用户的需求，例如描述用例、业务规则和用户情景。

在系统的 API 或通过用户界面交换的信息的类型。

描述系统或验收测试。

当用于此目的时，UML 类图的内容称为“概念类图”。（也称为“域模型”或“分析类模型”。）

在概念类图中，您只需显示描述需求所需的那些类，而无需显示系统内部设计的任何细节。该关系图不显示系统内部设计的任何细节。通常不必显示与概念类有关的操作或界面。

例如，您可以为“立即就餐”系统绘制以下概念类：

概念类图提供您在整个需求模型中用到的术语。例如，在“订餐”用例的详细说明中，您可能会编写：

顾客选择一个可从中构造“订单”的“菜单”，然后从“菜单”中选择“菜单项”，从而在“订单”中创建“订单项”。

请注意，术语在描述中的使用方式是模型中的类的名称。通过该关系图可以清楚地了解这些类之间的关系。例如，它清楚地显示了每个订单只与一个菜单关联。

对用户需求的错误理解通常是由于对单词详细含义的理解错误造成的。例如，大多数餐馆都对“菜单”和“订单”这两个术语的意思有共同的理解，但对订单项和菜单项之间的差别不太清楚。当与业务利益干系人讨论需求时，公开这些差别非常重要。类图是一个非常有用的工具，可帮助您澄清术语及其关系。

概念类模型可以构成基本术语，您可以按照这些术语描述系统的业务逻辑。但是软件中的类通常比概念模型复杂得多，这是因为实现必须考虑性能、分布、灵活性和其他因素等问题。一个系统中通常存在一个概念类的多个不同实现。

例如，可以在系统的不同部件中以及部件之间的不同接口上用 XML、SQL、HTML 和 C# 表示订单。可以通过多种不同方式表示订单和菜单之间的关联，例如 C# 代码中的引用、数据库中的关系或 XML 中的交叉引用的 ID。尽管存在这些变化，但是概念模型在软件的每个部件中提供的都是重要信息。示例中的类图告诉我们，在每个实现中，每个订单只有一个菜单与之关联。

绘制需求类图可帮助团队：

定义和标准化在讨论用户需求时使用的基本术语。

澄清这些术语之间的关系。

下列主题提供了更多信息：

要了解

 请阅读

有关查找需求类的更详细信息

 UML 类图：准则

概念类图中的元素

 UML 类图：参考

如何通过概念类开发代码

 建立软件系统体系结构模型

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

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

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

但是，许多动态规则都可以替换为静态规则，以便更高效、更泛地指定它们。例如，您可以将 Boolean 特性“已登录”添加到概念类模型中的类。将“已登录”作为登录用例的后置条件以及大多数其他用例的前置条件添加。通过此方法可以避免定义事件序列的所有可能组合。这种方法在需要将新用例添加到模型时也更为灵活。

请注意，此处的选择说的是您定义需求的方式，与您通过程序代码实现需求的方式无关。

下列主题提供了更多信息：

要了解

 请阅读

有关查找和记录静态业务规则的更详细信息

 UML 类图：准则

概念类图中的元素

 UML 类图：参考

如何开发遵循业务规则的代码

 建立软件系统体系结构模型

描述服务质量要求有多种类别的服务质量要求。这些类别包括：

性能

安全性

可用性

可靠性

稳定性

您可以在描述特定用例时包括其中一些需求。其他需求不特定于用例，可以更有效地在单独的文档中编写。如果可能，遵循需求模型定义的术语非常有用。在下面的示例中，请注意，需求中使用的主要单词是上面的插图中的参与者、用例和类的标题。

如果某个餐馆在顾客订餐时删除了一个菜单项，则引用该菜单项的任何订单项都将显示为红色。

下列主题提供了更多信息：

要了解

 请阅读

有关记录服务质量要求的更详细信息

 Guidelines for Defining Quality of Service Requirements

将其他文档附加到用例

 如何：将用例链接到文档和关系图

如何开发遵循服务质量要求的代码

 建立软件系统体系结构模型

显示用户和系统之间的工作流可以使用活动图显示不同用例之间的工作流。通过绘制活动图（显示用户在系统内外执行的主要任务）来开始建立需求模型，通常十分有用。

例如：

您可以绘制用例图和活动图以显示同一信息的不同视图。用例图对于显示在较大的活动中嵌套较小的操作更有效，但不显示工作流。例如：

请注意，您也可以使用活动图来描述软件中的算法，但是如果将此类图用于业务进程，则应侧重于系统外部可见的操作。

下列主题提供了更多信息：

要了解

 请阅读

有关如何定义业务工作流的更多信息

 UML 活动图：准则

活动图中的元素

 UML 活动图：参考

如何通过活动图开发代码

 建立软件系统体系结构模型

显示用户和系统之间的交互

可以使用序列图显示在系统与外部参与者之间或系统的各部件之间交换的消息。序列图提供用例中的步骤视图，该视图可以非常清晰地显示交互序列。当用例中有多个交互方且系统有 API 时，序列图尤为有用。

例如：

序列图的一个优点是可以方便地看到传入您所构造的系统的消息。若要设计系统，您可以将单个系统生命线替换为每个系统组件的独立生命线，然后显示各生命线之间用来响应每个传入消息的交互。

下列主题提供了更多信息：

要了解

 请阅读

有关如何定义交互的更多信息

 UML 序列图：准则

序列图中的元素

 UML 序列图：参考

如何通过序列图开发代码

 建立软件系统体系结构模型

使用模型减少不一致创建模型通常可显著减少用户需求方面的不一致和多义性。不同利益干系人通常对系统工作的业务范围具有不同的理解。因此，您的首要任务就是消除客户之间的这些差异。

您将会发现，当您创建模型时自然会出现很多有关业务领域的问题。通过向用户提出这些问题，将在项目的后续阶段减少更改需求。下面是一些特定问题，您可以先进行自问，如果答案不确定则可以询问业务利益干系人：

对于需求模型中的每个类，询问“哪个用例创建此类的实例？”例如，对于在线订餐服务，您可能会问，“哪个用例创建‘餐馆菜单’类的实例？”这将导致讨论新餐馆如何向服务注册并提供菜单。您可以询问有关哪个用例创建或更改特性和关联的类似问题。

对于需求模型中的每个用例，尝试用类图提供的单词描述每个用例的结果或后置条件。在用例匹配项前后绘制类实例的草图，对于显示用例的效果通常十分有用。例如，如果用例后置条件表示“已将菜单项添加到顾客的订单”，则绘制订单和菜单项类实例的草图。以不同的颜色或在新绘图中显示用例的效果（例如新链接或新对象）。这通常会导致讨论有关哪些信息在模型中是必需的。尽管需求类不与实现直接相关，但它们描述系统将需要存储和传输的信息。

询问特性和关联的约束，尤其是涉及多个特性或关联的约束。

询问有效和无效的用例序列，绘制序列图或活动图以演示这些用例序列。

通过检查不同关系图提供的视图之间的关系，您可以快速理解用户使用的主要概念，并帮助他们理解他们需要从系统中获得什么。您还可以更好地理解利益干系人最不确定的需求。您可以计划在项目的早期阶段至少以简化的形式开发这些功能，从而允许用户体验这些功能。