要求描述利益干系人对产品的期望。 应使用业务领域的词汇和概念，采用可用于与业务利益干系人轻松讨论要求的术语来表达要求。 要求不应讨论也不应依赖于实现。 要求不仅包括用户的行为和服务质量预期，还包括法定约束和商业标准。
通过在 TFS 中创建要求，可获得以下好处：
通过将要求链接到测试用例来验证它们是否得到满足。
通过将要求链接到任务工作项来监视实现要求的进度。
将要求构造为总体要求和更详细的要求，以便你可以更轻松地管理它们以及进度报告可以汇总信息。
可在 Visual Studio 旗舰版 中对要求进行建模，从而在 Team Foundation Server 中将模型元素链接到要求。
本主题不尝试重复可在确定要求的主题方面获得的大量宣传资料。 而是关注于对采用符合 CMMI 的方式使用 Visual Studio 工具十分重要的方面。 有关 CMMI 的详细信息，请参阅 CMMI 背景信息。
不应按严格顺序执行本主题中介绍的活动（如任何开发活动一样）。 在编写方案的同时开发域模型，因为一个活动将有助于改进其他活动。 随着编码时间的临近而制定方案。 将针对已编写并演示的代码的体验反馈到尚未实现的方案中。
制定要求的时间
TFS 支持迭代工作，这种做法在使用早期迭代从潜在用户和其他利益干系人处获取反馈时最有效。 这种反馈可以用于改进已针对未来迭代而陈述的要求。 这样得到的产品在其最终安装中会比在同一时期开发而没有进行任何用户试用的产品有效得多。 如果项目是较大程序中许多个组件之一，则与其他组件的早期集成会使程序架构师可以改进总体产品。
必须针对在并行项目中向客户或合作伙伴做出坚定承诺的需要来平衡这种灵活性。
因此应在受控的范围内，在整个项目中制定和优化要求。 因为详细要求可能会在项目进行期间更改，因此在进行相应实现之前确定它们可能会徒劳无功。
在迭代 0 中，制定一组描述主要功能的要求，其中包含的详细信息只要足以形成产品计划即可。 产品计划将要求分配给迭代并陈述在每次迭代结束时将满足的要求。 创建主要概念和活动的域模型，并定义将在与用户的讨论中和实现中用于这些概念的词汇。 确定涉及每个功能的宽泛要求，如安全性和其他服务质量要求。
在每次迭代开头处或附近，更详细地为这些功能制定要求。 确定用户将遵循的步骤，在活动或序列图的帮助下定义它们。 定义在例外情况下发生的行为。
尽可能频繁地验证是否实现了所有要求。 普遍要求（例如安全性）必须使用针对每个新功能而扩展的测试进行验证。 如果可能，请自动执行测试，因为自动测试可以连续执行。
管理要求更改
以下准则使你可以运行增量过程，同时监视它以满足 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 在全球范围内运营 2000 加连锁餐馆；Fourth Coffee 由一对通过自行车提供服务的夫妇运营。
按照“客户”、“菜单项”等编写的更一般的方案可能会更方便，但不太可能导致发现一些有用功能。
详细级别
在迭代 0 中，详细地编写几个重要方案，但概括地编写大多数方案。 当特定方案即将在其中完全或部分实现的迭代临近时，添加更多详细信息。
首先考虑某个方案时，描述业务上下文（甚至是产品不涉及的方面）可能会很有用。 例如，描述 DinnerNow 交付方法：每个餐馆组织自己的交付还是 DinnerNow 运行交付服务？ 此类问题的答案可为开发团队提供有用的上下文。
在迭代开始时制定的更详细方案可以描述用户界面交互，情节提要可以显示用户界面布局。
组织方案
可以使用以下方法来组织方案：
绘制将每个方案显示为用例的用例图。 建议使用此方法，因为它使方案非常易于呈现和讨论。 有关详细信息，请参阅 UML 用例图：准则。
将每个用例链接到定义方案的工作项。 有关详细信息，请参阅链接模型元素和工作项。
绘制“扩展”关系可显示一个方案是另一个方案的变体。 例如，“客户指定单独付款和交付地址”是基本“客户进行订购”用例的扩展 扩展对于分离出将在以后迭代中实现的方案特别有用。
绘制“包含”关系可分离对多个用例通用的过程（如“客户登录”）。
在常规方案（如“客户支付”）与特定变体之间（如“客户用卡支付”）之间绘制泛化关系。
在方案工作项之间创建父子链接。 可以在 团队资源管理器 中查看层次结构。 有关详细信息，请参阅在产品计划中安排要求。
对业务领域建模
创建 UML 模型，它描述产品使用中涉及的主要活动和概念。 在方案中、与利益干系人的讨论中、用户界面和任何用户手册中以及代码本身中，使用此模型中定义的术语作为“普遍语言”。
很多要求未由你的客户明确陈述，理解隐含要求取决于对业务领域（即，产品将在其中工作的环境）的理解。 因此，在不熟悉的领域中进行的一些要求收集工作与获取该环境的知识有关。 建立这种类型的知识之后，它可以用于多个项目。
在版本控制中保存模型。
有关详细信息，请参阅建立用户需求模型。
建模行为
绘制活动图以汇总方案。 使用泳道可对不同参与者执行的操作进行分组。 有关详细信息，请参阅 UML 活动图：准则。
虽然方案通常描述一系列特定事件，但是活动图可显示所有可能性。 绘制活动图可以提示你考虑备选序列并向你的业务客户询问在这些情况下应进行的操作。
下图显示一个简单的活动图示例。
.png "包含三个操作和一个循环的活动。")
在消息交换很重要的情况下，使用为每个参与者和主要产品组件包含生命线的序列图可能会更加有效。
用例图使你可以汇总产品支持的不同活动流。 图上的每个节点表示用户与应用程序之间为实现特定用户目标而进行的一系列交互。 还可以将常见序列和可选扩展纳入单独用例节点。 有关详细信息，请参阅 UML 用例图：准则。
下图显示一个简单的用例图示例。
.png "前一个操作的用例")
建模概念
绘制域类关系图以描述方案中提及的重要实体及其关系。 例如，DinnerNow 模型显示餐馆、菜单、订单、菜单项等。 有关详细信息，请参阅 UML 类图：准则。
使用名称和基数标记关系的角色（各端）。
在域类图中，通常不将操作附加到类。 在域模型中，活动图描述行为。 向程序类分配职责是开发工作的一部分。
下图显示一个简单的类图示例。
.png "附加到 Order 类的注释中的规则。")
静态约束
向类图添加控制特性和关系的约束。 例如，订单中的项必须全部来自同一家餐馆。 这些类型的规则对于产品设计非常重要。
模型一致性
确保模型和方案一致。 模型最强大的用途之一是解析多义性。
方案描述使用模型中定义的术语，与它定义的关系保持一致。 如果模型定义菜单项，则方案不应将相同内容称为产品。 如果类图显示一个菜单项恰好属于一个菜单，则方案不应提到在菜单之间共享项。
每个方案描述活动图允许执行的一系列步骤。
方案或活动描述如何创建和销毁类图中的每个类和关系。 例如，哪些方案创建菜单项？ 何时销毁订单？
制定服务质量要求
创建指定服务质量要求的工作项。 将“要求类型”字段设置为“服务质量”。
服务质量或非功能性要求包括性能、可用性、可靠性、使用性、数据完整性、安全性、经济性、可服务性和可升级性、可交付性、可维护性、设计以及调整和完成。
请为每个方案考虑以上每个类别。
每个服务质量要求的标题都应通过提供上下文、操作和度量值来捕获其定义。 例如，可以创建以下要求：“在目录搜索过程中，在三秒内返回搜索结果。”
此外，捕获用于说明为何需要该要求的更多详细信息会十分有用。 描述角色为何重视要求以及为何需要此服务级别。 提供上下文和理由。 此说明可能包括有用的风险管理信息，如来自市场调查、客户焦点组或使用性研究的数据；技术支持报告/票证；或其他传闻证据。
将服务质量要求链接到任何受服务质量影响的方案（要求工作项）。 链接相关工作项可允许 Team Foundation Server 的用户跟踪相关要求。 查询和报告可以显示服务质量要求如何影响作为方案捕获的功能要求。
评审要求
编写或更新了要求时，应由合适的利益干系人评审它们，以确保它们可充分描述与产品进行的所有用户交互。 常见利益干系人可能包括行业专家、业务分析人员和用户体验架构师。 还应评审方案以确保它们可以在项目中实现而不会出现任何混淆或问题。 如果发现了任何问题，则必须修复方案，以便它们在此活动结束时有效。
创建评审工作项以跟踪评审。 此项为标准 CMMI 过程改进评估方法 (SCAMPI) 评估提供重要证据，可以为将来的根本原因分析提供良好的信息来源。
针对以下特性评审每个方案：
方案在用户必须执行的任务、他们已了解的内容以及他们期望如何与产品进行交互的上下文中进行编写。
方案概括了一个问题，提议的问题解决方案未遮盖该问题。
标识与产品进行的所有相关用户交互。
行业专家、业务分析人员和用户体验架构师在项目上下文中评审每个方案，以验证是否可以成功实现所有方案。 如果方案无效，请修订它以便有效。
可以使用可用技术、工具和资源，并在预算和时间表范围内实现方案。
方案具有易于理解的单个解释。
方案不与另一个方案冲突。
方案可进行测试。
验证
计划在最终发布之前将产品的 beta 版本部署到工作环境中。 基于来自该部署的利益干系人反馈来计划更新要求。
验证意味着确保产品在其运行环境中符合其预期用途。 在 MSF for CMMI 中，通过在整个项目的每次迭代结束时向利益干系人演示工作软件来实现验证。 安排计划的方式应使从早期演示反馈到开发人员的问题可以在剩余迭代的计划中得到处理。
若要实现真实验证，产品必须不只在演示或模拟上下文中运行。 只要可行，便应在真实条件下进行测试。
检查和编辑要求
方案和服务质量要求（会形成大多数开发任务）可以使用客户要求查询进行检查。 如果要显示所有要求，则可以编写查询以返回具有要求工作项类型的所有工作项。 设置结果列以显示迭代路径。
团队应在项目的早期迭代中创建大多数要求。 从早期版本获得反馈时，会添加新要求并调整其他要求。
其他资源
有关更多信息，请参见以下 Web 资源：
功能驱动开发实践指南，Stephen R. Palmer 和 Malcolm J. Felsing；Prentice-Hall PTR，2002 年。
简化对象建模：模式、规则和实现，Jill Nicola、Mark Mayfield 和 Mike Abney；Prentice Hall PTR，2001 年。
敏捷建模：极限编程和统一过程的有效实践；Wiley，2002 年。
域驱动的设计：解决软件核心的复杂性，Eric Evans；Addison Wesley Professional，2003 年。
对象设计：角色、职责和协作，Rebecca Wirfs-Brock 和 Alan McKean；Addison Wesley Professional，2002 年。