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