制定要求

要求用于描述利益干系人对产品的预期。 在表述要求时，您应采用可使您和业务利益干系人围绕您的要求展开轻松讨论的术语，并使用业务领域的词汇和概念。 要求不应讨论和依赖于实现。 要求不仅包括用户的行为预期和服务质量预期，而且还包括法规约束和商业标准。

通过使用要求工作项在 Visual Studio Team Foundation Server 中记录要求，您可以获得以下优势：

• 验证是否已将要求链接到测试用例来满足这些要求。

• 将要求链接到任务工作项来监视在实现这些要求方面的进展情况。

• 将要求构造成更详细的整体要求，以便可以更轻松地管理这些要求，并使进度报表能够汇总相应信息。

• 通过在 Team Foundation Server 中将模型元素链接到要求，在 Visual Studio 旗舰版中对要求进行建模。

本主题不会尝试复制已有的有关要求确定主题的长篇大论， 而将重点介绍根据 CMMI 使用 Visual Studio 工具的重要领域。有关 CMMI 的更多信息，请参见 CMMI 背景信息。

本主题介绍的活动（如任何开发活动）不应按严格顺序执行。 由于一个活动将有助于您改进其他活动，因此，请在编写方案时开发域模型。 请在即将编写方案代码之前制定这些方案。 使用已编写的用于演示尚未实现的方案的代码进行体验。

主题内容

何时制定要求

编写远景描述

编写方案

对业务领域进行建模

制定服务质量要求

评审要求

验证

检查和编辑要求

何时制定要求

Team Foundation Server 支持迭代工作，并且使用早期迭代获取潜在用户和其他利益干系人的反馈时，此做法的效率最高。这些反馈可用于改进已为未来迭代声明的要求。 这会使产品在最终安装时的效率比相同时间段开发的未经过任何用户试用的产品的效率要高得多。 如果您的项目是较大程序中的多个组件之一，在早期与其他组件集成使程序架构师可以改进整个产品。

必须在上述灵活性和在并行项目中向客户或合作伙伴提供坚定承诺的要求之间进行权衡。

因此，应在可控范围内在整个项目中制定和完善要求。 由于详细要求可能会在项目期间发生变化，因此，要在正确实现这些要求之前确定要求细节很可能会徒劳无功。

• 在迭代 0 中，制定一组用于描述主要功能的要求，并仅赋予一些足以制定产品计划的详细信息。 产品计划指派迭代要求，并声明将在每次迭代结束时实现哪些要求。 创建主要概念和活动的域模型，并确定在与用户的讨论和实现过程中这些概念将采用的词汇。 确定普遍适用于每个功能的广泛要求，例如，安全性和其他服务质量要求。

• 在每次迭代开始或快要开始时，为这些功能制定更详细的要求。 借助活动图或序列图，确定用户将遵循的步骤。 确定在异常情况下将发生何种状况。

• 尽可能频繁地验证是否已实现所有要求。 必须通过已针对每个新功能进行扩展的测试验证普遍要求，如安全性。 如有可能，请自动执行测试，这是因为自动测试可以持续运行。

管理要求更改

下面的指南使您可以运行并监视渐进式过程，以便满足 CMMI 要求。

• 不要更改为迭代设置的要求。 在环境突然变化的极少数情况下，您可能需要取消某次迭代，查看产品计划，并开始新的迭代。

• 查找要求中的不确定因素。 尝试安排计划，使对早期迭代的用户体验能够生成可减少不确定因素的信息。

• 使用更改请求工作项记录对已经实现的更改行为的请求，除非请求的改进已成为计划的一部分。 将每个更改请求链接到相应的要求工作项。 有关更多信息，请参见更改请求 (CMMI)。

• 请在每次迭代之前查看产品时查看更改请求。 查看请求对依赖项目和用户的影响，并估计代码更改的相关成本。 如果接受更改请求，则请更新要求。

• 更新测试，以便符合每项要求更改。

• 指定一个截止日期（例如，在迭代 2 或 3 之后），在此截止日期之后，要求更改必须提供更多强有力的证据以证明其有效性。 如果客户需要向您的项目付费，应让客户在此日期审批一组基本要求，并将支付方式从按小时支付改为按固定价格支付。

• 使用 Bug 工作项记录未按照明确或暗示要求执行的已实现行为。 如有可能，请新建一个将捕获 Bug 的测试。

编写远景描述

与团队讨论远景描述，并在 Team Foundation Server 的项目 Web 门户网站上公开它。

远景描述简要概述了产品将带来哪些优势。 用户将能实现哪些以往无法实现的功能？ 远景描述有助于说明产品的适用范围。

如果产品已存在，请针对此版本编写一份远景描述。 产品用户将能实现哪些以往无法实现的功能？

编写方案

请与您的客户及其他利益干系人合作创建方案，以要求工作项的形式输入这些方案，并将“要求类型”字段设置为“方案”。

方案或用例是描述一个事件序列的叙述，用于演示如何实现特定目标，并且常常涉及与相关人员、组织和计算机的交互。

请为方案指定一个描述性标题，当在列表中查看该方案时，该描述性标题可将其与其他方案明显区分开来。 确保已对主要参与者进行介绍，并明确这些参与者的目标。 例如，以下标题便是一个很好的标题：

客户购买餐点。

可以按如下形式编写方案。 有时采用多种形式会很有帮助：

• 在工作项描述中用一两个句子进行描述：

  客户在网上订餐，并使用信用卡支付。 向餐馆递交订单，餐馆准备并配送餐点。

• 在工作项描述中用带有编号的步骤进行描述：

  客户访问网站并订餐。 该网站将客户重定向到支付站点付款。 订单被添加到餐馆的工作列表中。 餐馆准备并配送餐点。

• 演示图板。 演示图板实质上是用于叙述故事的连环漫画。 可在 PowerPoint 中绘制演示图板。 将演示图板文件附加到要求工作项，或者将该文件上载到团队门户网站，并添加一个指向该工作项的超链接。

  演示图板对演示用户交互尤其有用。 但是，对于业务方案而言，建议采用草图样式，以便阐明此草图并非是用于用户界面的最终设计。

• 要求文档。 要求文档使您可以自由地为每个要求提供适当级别的详细信息。 如果您决定使用文档，请为每个要求创建一个 Word 文档，并将该文档附加到要求工作项，或者将该文件上载到团队门户网站，并添加一个指向该工作项的超链接。

• 统一标记语言 (UML) 序列图。 序列图在多方交互时尤其有用。 例如，订餐要求客户、DinnerNow 网站、支付系统和餐馆按特定序列进行交互。 请在 UML 模型中绘制序列图，并将其签入到 Team Foundation Server，然后在要求工作项中输入一个链接。 有关更多信息，请参见 UML 序列图：准则。

特定方案

请从编写特定方案开始，这些方案按特定序列采用一组特定参与者。 例如，“Carlos 在 DinnerNow 网站上订购了一个蒜香比萨饼。 该网站将 Carlos 重定向到 Woodgrove Bank 的支付服务。 Fourth Coffee 准备并配送比萨饼。”

特定方案可帮助您设想所采用的系统，这些方案在首次研究某个功能时最为有用。

此外，在创建用于描述人员和组织的背景和其他活动的指定人物时，特定方案也非常有用。 Carlos 在上网咖啡厅过了一夜；Wendy 居住在一个封闭式社区；Sanjay 为忙于工作的妻子订餐；Contoso 在全球运营有 2,000 家连锁餐馆；Fourth Coffee 由一对夫妇运营，并通过自行车配送餐点。

使用“一名客户”或“一个菜单项”等术语编写的更具一般性的方案可能会更加方便，但是这些方案导致发现有用功能的可能性也将较低。

详细级别

在迭代 0 中，编写几个重要方案的某些详细信息，但概括地编写大多数方案的大纲。 当将完全实现或部分实现的某个特定方案所在的迭代到来时，请添加更多详细信息。

当初次考虑某个方案时，描述业务环境可能会很有帮助，即便是产品未涉及的领域也是如此。 例如，描述 DinnerNow 的配送方式：各餐馆是否自行安排其配送，或者 DinnerNow 是否提供配送服务？ 对此类问题的答复可以为开发团队提供有用环境。

在迭代开始时制定的较详细的方案可以描述用户界面交互，并且演示图板可以显示用户界面布局。

组织方案

可使用以下方法组织方案：

• 绘制用例图，该用例图将每个方案显示为一个用例。 此方法可以极其轻松地呈现和讨论方案，因此建议采用此方法。 有关更多信息，请参见 UML 用例图：准则。

  • 将每个用例链接到用于定义方案的工作项。 有关更多信息，请参见链接模型元素和工作项。

  • 绘制扩展关系，以演示某个方案是另一个方案的变化形式。 例如，“客户指定单独的支付和配送地址”是对“客户下订单”基本用例的扩展。 扩展功能对分离出将在后续迭代中实现的方案尤其有用。

  • 绘制包括关系，以便分离多个用例的公用过程（如“客户登录”）。

  • 绘制通用方案（如“客户支付”）和特定变化形式（如“客户使用卡支付”）之间的泛化关系。

• 在 Team Foundation Server 中的各个方案工作项之间创建父子链接。可以在团队资源管理器中查看该层次结构。 有关更多信息，请参见在产品计划中安排要求。

对业务领域进行建模

创建一个 UML 模型，该模型描述在产品使用过程中涉及的主要活动和概念。 在方案、与利益干系人的讨论、用户界面和任何用户手册以及代码自身中，使用在上述模型中定义的术语作为“通用语言”。

许多要求都不是由您的客户明确规定的，对暗示要求的领悟取决于您对业务领域的了解，即对产品将运行的环境的了解。 因此，在陌生领域中收集要求的某些工作与获取对相应环境的认识相关。 在建立此类认识之后，您可以将其应用于多个项目。

在版本控制中保存该模型。

有关更多信息，请参见用户需求建模。

建模行为

绘制活动图以汇总多个方案。 使用泳道组合不同参与者执行的操作。 有关更多信息，请参见 UML 活动图：准则。

虽然方案往往描述特定序列的事件，但活动图却显示所有可能情况。 绘制活动图可以提示您考虑备选序列，并向您的业务客户咨询在这些情况下应采取哪些操作。

下图演示了一个简单的活动图示例。

在消息交换非常重要的情况下，采用针对各参与者和主要产品组件包含一条生命线的序列图可能会更加有效。

用例图使您可以汇总您的产品所支持的不同活动流。 该关系图上的每个节点表示为实现特定用户目标而在用户和应用程序之间进行的一系列交互。 也可以将一般序列和可选扩展纳入到单独的用例节点中。 有关更多信息，请参见 UML 用例图：准则。

下图演示了一个简单的用例图示例。

建模概念

绘制域类图的目的是为了描述方案中提及的重要实体及其关系。 例如，DinnerNow 模型演示“餐馆”、“菜单”、“订单”、“菜单项”等。 有关更多信息，请参见 UML 类图：准则。

使用名称和基数标记关系的角色（端）。

在域类图中，通常不会将操作附加到类。 在域模型中，活动图用于描述行为。 为程序类指派责任是开发工作的一部分。

下图演示了一个简单的类图示例。

静态约束

增加用于管理特性和关系的类图约束。 例如，某个订单中的项目必须全部来自同一餐馆。 这些规则类型对产品设计非常重要。

模型一致性

确保模型和方案相互一致。 模型最强大的功用之一在于解决了多义性问题。

• 方案描述使用在模型中定义的术语，这些术语与模型定义的关系相一致。 如果模型定义了菜单项，方案不能将同一内容称为产品。 如果类图演示的菜单项只属于一个菜单，方案不能提及在不同菜单之间共享菜单项。

• 各方案介绍活动图允许的一系列步骤。

• 方案或活动介绍如何创建和销毁类图中的每个类和关系。 例如，哪个方案创建菜单项？ 何时销毁订单？

制定服务质量要求

创建用于指定服务质量要求的工作项。 将“要求类型”字段设置为“服务质量”。

服务质量或非功能要求包括性能、可用性、可靠性、有效性、数据完整性、安全性、可承受性、耐用性与可升级性、可交付性、可维护性、设计以及精确性和完整性。

请针对每个方案考虑其中每个类别。

每个服务质量要求的标题应通过呈现环境、操作和度量值来捕获其定义。 例如，您可以创建以下要求：“当执行目录搜索时，搜索结果应在 3 秒钟之内返回”。

此外，捕获用于说明要求必不可少的原因的更多详细信息也会很有帮助。 描述相关人员重视要求的原因和此服务级别必不可少的原因。 提供相应环境和证据。 此说明可能包括有用的风险管理信息，例如，来自市场调研、客户焦点小组或可用性研究的数据；咨询台报表/票证；或其他观察性证据。

将服务质量要求链接到该服务质量影响的任何方案（要求工作项）。 通过链接相关工作项，Team Foundation Server 用户可以跟踪依赖要求。 查询和报表可以演示服务质量要求如何影响作为方案捕获的功能要求。

评审要求

要求在编写或更新之后应交由相应利益干系人评审，确保它们准确描述与产品的所有用户交互。 一般利益干系人可能包括行业专家、业务分析人员和用户体验架构师。 此外，还应当对方案进行评审，确保可以在项目中实现这些方案，而不会产生任何混淆或问题。 如果发现有任何问题，必须对方案进行修复，使其在修复活动结束时有效。

创建用于跟踪评审的评审工作项。 该项将为 CMMI 过程改进标准评估方法 (SCAMPI) 评估提供重要证据，并且可在将来为根源分析提供有用的信息源。

评审每个方案的以下特性：

• 结合用户必须执行的任务、用户已知内容及其与产品的预期交互方式来编写方案。

• 方案对问题进行了概述，并且不会被建议的问题解决方案所遮盖。

• 已标识与产品相关的所有用户交互。

• 行业专家、业务分析人员和用户体验架构师应在项目环境中评审每个方案，以便验证是否可以成功实现所有方案。 如果方案无效，则应进行修改以使其有效。

• 可以使用可用技术、工具和资源实现方案，并且应符合预算和时间表。

• 方案不能暗含任何其他解释，且简单易懂。

• 方案不能与其他方案冲突。

• 可以测试方案。

验证

在最终发布之前，应在产品工作环境中计划部署产品的 beta 版本。 根据利益干系人对此部署的反馈，计划更新要求。

验证意味着确保产品在其操作环境中实现其预期用途。 在 MSF for CMMI 中，验证是通过在整个项目中、在每次迭代结束时向利益干系人演示工作软件来实现的。 应当以如下方式来安排日程表：在早期演示中反馈给开发人员的问题可以在计划的其余迭代中解决。

为了实现真正意义上的验证，产品不能只在演示或模拟环境中运行。 还应当尽可能在实际条件下测试。

检查和编辑要求

方案和服务质量要求可用于生成大多数开发任务，可使用客户要求查询来检查这些要求。 如果您希望显示所有要求，则可以编写一个返回要求工作项类型的所有工作项的查询。 设置结果列以显示迭代路径。 有关更多信息，请参见共享查询 (CMMI)。

除在团队资源管理器或 Team Web Access 中直接查看查询以外，还可以在 Office Excel 或 Office Project 中打开查询。 对于批量编辑和添加工作项而言，这些工具更加方便。 有关更多信息，请参见在连接到 Team Foundation Server 的 Microsoft Excel 和 Microsoft Project 中工作和使用工作项的树列表执行自顶向下的规划（在 Excel 中）。

应在项目的早期迭代中创建大多数要求。 从早期版本获取反馈之后，将添加新要求并调整其他要求。

其他资源

有关更多信息，请参见以下 Web 资源：

• A Practical Guide to Feature Driven Development（功能驱动开发实践指南），Stephen R. Palmer 和 Malcolm J. Felsing；Prentice-Hall PTR，2002 年。

• Streamlined Object Modeling: Patterns, Rules and Implementation（简化对象建模：模式、规则和实现），Jill Nicola、Mark Mayfield 和 Mike Abney；Prentice Hall PTR，2001 年。

• Agile Modeling: Effective Practices for Extreme Programming and the Unified Process（敏捷建模：极限编程和统一过程的有效实践），Scott Ambler；Wiley，2002 年。

• Domain Driven Design: Tackling Complexity in the Heart of Software（域驱动设计：软件核心复杂性应对之道），Eric Evans；Addison Wesley Professional，2003 年。

• Object Design: Roles, Responsibilities and Collaborations, Rebecca Wirfs-Brock and Alan McKean（对象设计：角色、责任和协作），Rebecca Wirfs-Brock 和 Alan McKean；Addison Wesley Professional，2002 年。