在产品计划中安排要求
在对您的客户要求进行充分分析并了解产品的预期功能之后，必须制定一份实现该产品的计划。 或者，对于现有产品，必须找出所缺少的功能并制定一份更改计划。 不过，要求不会自动告诉您该计划。
本主题从一组要求着手，概述了一种获取计划的方法。 这仅仅是将在 Visual Studio 上有效运行的诸多方法之一，您应对此进行调整以使其能够满足您的需求。
可以使用 积压工作 (backlog) 和 组合积压工作 定义和映射要求和功能。
要求和功能
此方法涉及两类要求：客户要求和功能。 客户要求是您通过对客户的产品预期功能进行分析所获得的。 功能是产品计划中与一小部分客户要求相对应的项。 每个功能可能包含多个客户要求片段，这些片段源自用户体验的不同方面和不同功能区域。
客户要求
客户要求通过与预期用户和其他利益干系人进行商讨来确定。
为了帮助您分析这些要求，您通常需要创建演示图板和模型，并将方案分解为多个更细小的步骤，从而形成一个树。 可以将建模元素（如用例和活动）链接到这些方案工作项。
客户要求包括两种：
方案（也称为用例），用于表示为实现特定目标而在用户和产品之间进行交互的序列。 示例方案可以采用类似于“用户购买书籍”这样的标题。
服务质量要求，包括性能、安全性、可用性和其他条件。
可以将这些要求表示为要求类型的工作项，并将“要求类型”字段设置为“方案”或“服务质量”。 有关详细信息，请参阅开发要求。
应将这些要求工作项链接到系统测试，以便可以确保测试所有要求。 请参见 使用 Team Web Access 计划手动测试。
查看积压工作或打开客户要求查询列出这些要求工作项。
使用“要求进度”报表 (CMMI) 报表监视已满足的要求。
功能
功能是产品计划中表示一组任务的项。 制定产品计划时，开发团队代表和利益干系人为迭代指派功能。 有关详细信息，请参阅规划项目 (CMMI)。
将功能输入为要求工作项，并将“要求类型”字段设置为“功能”。
功能标题应采用用户术语指定用户通过该产品将能实现在早期迭代中无法实现的功能。 计划中不包含任何无法提供新用户价值的项，或者包含很少这样的项。
例如，以下功能序列可形成一个实现计划：
“购买者可以从列表中挑选书籍，并将其添加到意愿清单中。”
“书籍列表显示价格。 在意愿清单中显示总价。”
“供应商可以为书籍附加标签。 购买者可以按照标签筛选书籍列表。”
请注意，没有任何功能仅涉及用户体验中的一个步骤，并且没有任何功能仅涉及产品体系结构的一个部分。 相反，在实现功能时，将重新访问多个功能，并为这些功能扩充新的用户价值。
功能在产品计划期间指派给迭代。 必须将某一功能下的所有任务指派给同一迭代。
功能描述对客户要求的部分实现。 它是客户要求的一部分，并且可能会在有限范围内实现每个客户要求。
每个功能都可以链接到一个或多个测试用例，以测试该功能表示的部分要求。 这些测试用例是链接到客户要求的系统测试的一部分。
功能状态不能标记为已完成，直到已完全定义和通过其测试。
每个功能都是一组开发和测试任务。 它是任务树的根。 开发任务实现该功能描述的部分要求。 测试任务设计和执行相应测试用例。
使用“产品要求”查询可以列出功能。
查找功能
将要求划分到渐进式功能中是一项创造性任务，它需要开发人员、分析人员和利益干系人的共同参与才能完成。 功能 (feature) 定义了产品的某一部分功能 (functionality)，可以切合实际地独立于周边其他功能独立实施。 因此，一组可行的功能定义和计划排序部分取决于系统体系结构。
由于这个原因，产品计划和初始设计必须同时进行，特别是在迭代 0 中，在此期间，将制定大部分计划的草图。
方案分解
为了帮助您将要求安排到功能中，将方案分解为多个更小的步骤会很有帮助。
使用演示图板常常有助于此活动的开展。 演示图板是用于演示方案的图片序列。 UML 活动图有助于显示备选路径，UML 序列图有助于讨论多个参与者之间的交互。 在使用这些工具分析方案之后，您可以将分解后的方案输入到团队资源管理器中。 这样，您可以将测试用例链接到这些方案，从而确保要求已满足。 有关更多信息，请参见UML 活动图：准则和UML 序列图：准则。
功能 - 在每次迭代中完成的要求
功能是对用户在每次迭代完成后可执行的功能进行汇总的要求。 您可以为每次迭代创建多个功能。 将功能输入为要求工作项，并将“要求类型”设置为“功能”。
使用方案到工作项的指派方式帮助您定义功能。 下面的示例功能计划派生自上一部分中方案到迭代的指派方式：
迭代 1
- 客户从菜单中选择菜单项，将其添加到订单中，并添加配送地址。
迭代 2
客户首先显示一个餐馆列表，并选择其中一家餐馆。
客户完成订单之后，将在所选餐馆的屏幕上显示订单。
将在订单上显示菜单项价格和总价。
迭代 3
在配送准备好的餐点之后，餐馆将订单标记为“已完成”。 针对餐馆记录餐点。
每家餐馆可以输入和更新其菜单。
客户可以浏览各餐馆的菜单，然后选择某家餐馆。
迭代 4
客户在完成订单之后输入支付详细信息。 餐馆将订单标记为“已完成”之后，将在客户提供的卡中扣除相应费用。
针对标记为“已完成”的订单向餐馆付款。
迭代 5
- 餐馆可以设置其配送区域。 客户会话开始时输入邮政编码。 网站仅显示可向当地提供配送服务的餐馆。
部分实现的方案
将方案分解为多个小步骤有助于您将某些可在早期实现的步骤与其他可在稍后实现的步骤区分开来。
但是，有时您可以区分方案的其他方面。 在本示例中，团队可以在早期迭代中实现用户体验的基本版本，并在稍后进行改进。 因此，您可以添加以下功能：
- 迭代 6 - 餐馆可以选择其菜单的配色方案和字体，并上载它自己的徽标和餐点图片。
此类功能并非从步骤分解过程直接形成，而往往在演示图板讨论中形成。 用户体验功能适用于后续迭代。
输入并检查功能
创建工作项类型为要求的工作项，并将“要求类型”字段设置为“功能”。 将功能标题设置为简短说明。
跟踪要求的功能
可以通过以下方式将功能链接到要求：
将功能工作项链接到其迭代的叶方案要求。 由于页方案已具有父级，因此必须使用“相关项”链接来链接功能工作项。
将测试用例工作项链接到这些工作项所测试的方案和服务质量要求。 在开发功能时，请将功能链接到应通过的部分测试用例。 通过这种方式，测试用例充当功能和客户要求之间的链接。
服务质量功能
在软件设计方面，服务质量要求通常具有普遍性。 例如，安全性要求一般不与特定开发任务相关。
尽管如此，应为每个服务质量要求创建一个功能工作项，该工作项的子级主要为测试任务，用于确保满足服务质量条件。 这些工作项称为服务质量功能。
某些服务质量功能可以包含开发任务。 例如，在早期迭代中，您可以实现仅处理少数用户的系统版本，并将其作为概念证明。 在后续迭代中，您可以按照客户要求规定添加指定目标功能的功能。
产品计划
请在每次迭代开始之前召开产品计划评审会议。 首次产品计划会议创建计划，后续会议基于早期迭代对该计划进行评审。 有关详细信息，请参阅规划项目 (CMMI)。
在产品计划评审中，围绕功能与业务利益干系人展开讨论，做好重新设置功能优先级的准备，并将这些功能安排到不同迭代。 会议应包括业务利益干系人和开发团队代表。
会议讨论开发各个功能的顺序。 可以对“产品要求”查询的 Office Excel 视图进行投影或屏幕共享，并按迭代对功能进行排序，从而展开讨论。
备选方法是按特定序列放置功能，然后考虑可在每次迭代中实现的功能数。 例如，开发人员可以讨论是否应将迭代 2 中的“客户可以显示价格”移至迭代 3，而不在此序列中移动它。 若要按顺序放置项，请在电子表格中添加一个名为“级别”的额外的列，并插入表示顺序的整数。 按此列对电子表格进行排序。 不会将这些等级存储在 Team Foundation Server 中，但是，您可以保存电子表格。 当再次打开电子表格时，请单击工作项表中的任何单元格，然后单击“团队”选项卡上的“刷新”。
产品计划会考虑功能优先级和开发成本。 优先级由业务利益干系人提供，并辅以开发人员提供的有关风险的某些指南。 成本估计由开发人员提供。 为了准确估计成本，开发团队必须已对产品体系结构开展了某些工作，并且可能需要从早期迭代中汲取一些经验。 为此，应在每次产品计划评审中完善成本估计。
迭代计划
请在产品计划评审之后计划迭代。 产品计划确定迭代结束时将交付的功能。 迭代计划确定团队为实现和测试功能将开展的工作。
下面的活动隶属于迭代计划的一部分：
创建开发和测试任务，并将这些任务作为子级链接到功能要求。
针对要在每个功能中制定的客户要求方面创建测试用例。 应将测试用例链接到客户要求，以便可以监视要求的完成情况。
也可以将测试用例链接到相应功能，以便可以跟踪功能和客户要求之间的对应关系。 不能将功能标记为已完成，直到已通过链接的测试用例为止。
有关详细信息，请参阅规划迭代 (CMMI)。