要求 (CMMI)
在本主题中，您可以学习如何填写要求工作项的详细信息。 要求可传达对于产品或系统的客户有价值的功能。 每个要求都应简要陈述用户希望使用软件的某个功能来做什么，并从用户的角度对其进行描述。 有关更多信息，请参见规划项目 (CMMI)。
有关如何创建此类工作项的信息，请参见工作项和工作流 (CMMI)。
主题内容 |
相关主题 |
|---|---|
|
过程指南 工作簿 面板和报表 字段参考 |
必需的权限
若要查看要求，您必须是**“Readers (访问者)”组的成员，或者您的“查看此节点中的工作项”权限必须设置为“允许”。 若要创建或修改要求，您必须是“Contributors (参与者)”组的成员，或者您的“编辑此节点中的工作项”权限必须设置为“允许”**。 有关更多信息，请参见管理权限。
定义要求
当您编写要求时，应关注功能面向的用户、他们要达到的效果以及原因。 您应避免采用指定应如何开发功能的描述。
创建要求时，只有标题是必须指定的。 但是，您可通过指定各种其他信息来进一步定义要求，如下图所示：
.png "要求工作项窗体")
在定义要求时，必须定义**“标题”**。 可以将所有其他字段保留为空白，也可以接受其默认值。
定义要求
在**“标题”**（必需）中，键入简短的说明。
好的要求标题应反映出对客户的价值或团队必须实现的功能。
在工作项窗体的正确部分中，指定一个或多个以下类型的信息:
在 指派给 列表中，选择拥有要求的团队成员的名字。
备注
只能为“Contributors (参与者)”组的成员分配工作项。
如果未指派要求的拥有者，则该要求将自动指派给您。
在**“状态”列表中，保留默认值“已建议”。 在“原因”列表中，保留默认值“新建”**。
有关**“状态”**字段以及如何使用该字段来跟踪工作流的更多信息，请参见本主题后面的更改要求的状态。
在 优先级 请按1列表中，选择要求的重要性级别(最重要)到4 (最不重要)。
在 会审 列表中，选择会审子状态。
有效值包括**“挂起”（默认值）、“详细信息”、“收到信息”和“已会审”。 此字段标识处于“已建议”**状态的要求的会审级别。
在 已阻止，如果问题使实现要求的进度受阻，列表中，选择 是。
在 已提交，如果提交实现要求，列表中，选择 是。
在 区域 和 迭代 列表中，选择相应的区域和迭代。
备注
每个团队项目的项目管理员为该项目定义区域和迭代路径，以便团队可以根据这些指定跟踪进度。有关更多信息，请参见创建和修改区域和迭代。
在 类型，选择您定义要求的类型。
默认值为 功能性的。
在 说明 选项卡上，描述团队将使用验证的要求和标准它是否执行。
您应根据需要提供尽可能详细的信息，以确保开发人员能够实现要求，并且测试人员能够对要求进行测试。
您的团队将使用此信息为任务和测试用例创建工作项。 有关更多信息，请参见任务 (Agile)和测试用例 (Agile)。
在 分析 选项，因此，如果该要求未实现，描述对客户产生的影响。
您可能希望包括有关 Kano 模型的详细信息，描述此要求是处于“惊喜”（Surprise）、“必需”（Required）还是“明显”（Obvious）类别中。
在 其他 选项卡上，指定以下类型的信息:
在 行业专家下，选择熟悉问题区域和预期该客户对此要求三名团队成员姓名。
在**“初始估计”**框中，键入一个数字，用于表示实现要求需要花费的工时数。
备注
通常，您将在开发周期的后期定义以下两个字段，而不是在第一次定义要求时进行定义。
在 集成版本 列表中，选择开发团队将要求集成于其中的生成的名称或内部版本号。
在 测试 列表中，选择用户验收测试的状态此要求。
有效的值为**“通过”、“未通过”、“未就绪”、“就绪”或“已跳过”。 如果要求处于“活动”状态，您应指定“未就绪”，如果要求处于“已解决”状态，则应指定“就绪”**。
在**“实现”、“更改请求”、“测试用例”和“所有链接”**选项卡上，可以创建从要求到其他工作项（例如任务、更改请求、测试用例、Bug 和问题）的链接。
在**“附件”**选项卡上，可以附加能够为要实现的要求提供详细信息的规范、图像或其他文件。
有关更多信息，请参见本主题后面的以下各节：
将要求链接到其他工作项
向要求添加详细信息、附件或超链接
选择
.png "保存")
保存工作项。备注
在保存要求之后，标识符出现在工作项工具栏下方的标题中。
将要求链接到其他工作项
通过在要求和其他工作项之间创建关系，可以更有效地计划项目、更准确地跟踪依赖项、更清楚地查看分层关系以及更快速地查找相关信息。 从要求的工作项窗体中，您可以创建自动链接到要求的工作项，或者可以创建指向现有工作项的链接。
使用**“实现”、“更改请求”、“测试用例”和“所有链接”**选项卡可创建指向特定类型工作项和特定类型链接的链接。 有关每个选项卡的限制的更多信息，请参见Linking Work Items (CMMI)。
备注
“要求概述”和“要求进度”报表要求您在要求与任务之间以及要求与测试用例之间创建链接。
创建任务、Bug、更改请求、测试用例或其他工作项并将其链接到要求
打开要求的工作项窗体，然后执行以下操作之一：
若要创建并链接到任务，bug或子要求，选择 实现 选项卡，然后选择
.png "添加新链接工作项")
新建。与若要创建并链接到更改请求，选择 更改请求 选项卡，然后选择
新建。若要创建并链接到测试用例，选择 测试用例 选项卡，然后选择
新建。若要创建并链接到其他任何类型的工作项，选择 所有链接 选项卡，然后选择
新建。
将打开**“添加新的链接工作项”**对话框。
.png "“添加新的链接工作项”对话框")
在 链接类型 列表中，保留默认值或选择下列选项之一:
与若要链接到任务，bug或子要求，选择 子级。
与若要链接到更改请求，选择 影响者。
若要链接到测试用例，请选择 测试方。
与任何其他类型的工作项要链接，请选择 相关 或表示要跟踪的关系的其他链接类型。
在 工作项类型 列表中，选择要创建的工作项的类型。
在**“标题”**中，键入待执行工作的简短但具体的说明。
(可选) 注释，键入附加信息，然后选择 确定。
打开一个与您指定的工作项类型相对应的工作项窗体，其中含有您提供的信息。
按下列主题所述，指定其余字段：
选择
保存工作项。
将若干现有工作项链接到要求
打开要求的工作项窗体，然后执行以下操作之一：
与一个或多个若要链接到任务，bug或子要求，选择 实现 选项卡，然后选择
.png "添加链接")
链接到。与一个或多个若要链接到更改请求，选择 更改请求 选项卡，然后选择
链接到。与一个或多个测试用例若要链接，请选择 测试用例 选项卡，然后选择
链接到。与一个或多个其他类型工作项要链接，请选择 所有链接 选项卡，然后选择
链接到。
**“将链接添加到要求”**对话框随即打开。
.png "“添加指向要求的链接”对话框")
在 链接类型 列表中，保留默认值或选择下列选项之一:
与若要链接到任务，bug或子要求，选择 子级 或 父级。
与若要链接到更改请求，选择 影响者。
若要链接到测试用例，请选择 测试方。
与任何其他类型的工作项要链接，请选择 相关 或表示要跟踪的关系的其他链接类型。
选择**“浏览”**。
将显示**“选择链接工作项”**对话框。
.png "“将任务链接到用户情景”对话框")
在**“工作项 ID”**中键入工作项，或者浏览到要链接的工作项。
也可以运行团队查询来查找要链接的工作项。 这些查询包括“活动 Bug”、“更改请求”、“打开的任务”、“打开的测试用例”和“打开的任务”。
选中要链接到要求的每个工作项旁边的复选框。
有关更多信息，请参见查找要链接或导入的工作项。
（可选）键入对链接目标工作项的说明。
选择 确定，然后单击
保存工作项。备注
要求和与之链接的工作项都将更新。
将详细信息、文件和超链接添加到要求
可以通过以下方式将详细信息添加到要求：
在**“详细信息”选项卡上的“说明”字段或“历史记录”**字段中键入信息。
附加文件。
例如，可以附加电子邮件线索、文档、图像、日志文件或其他类型的文件。
添加指向网站或存储在服务器或网站上的文件的超链接。
向要求中添加详细信息
选择选项，详细信息，因此，在 历史记录，添加作为历史记录一部分，要捕获的注释。
每次团队成员更新该工作项时，其历史记录都会显示更改日期、进行更改的团队成员和所更改的字段。
您可以设置信息格式以强调重点或获取项目符号列表。 有关更多信息，请参见要求字段引用 (CMMI)。
选择
保存工作项。
将文件附加到要求
在**“附件”**选项卡中，执行以下操作之一：
将文件拖动到附件区。
复制文件，然后选择
.gif "粘贴")
或按CTRL+V粘贴。选择
.png "添加附件")
添加，然后选择 浏览。 在**“附件”**对话框中，键入名称或浏览到要附加的文件。（可选）在**“注释”**框中，键入有关附件的更多信息。
若要关闭 附件 对话框中，选择 确定。
选择
保存工作项。
向要求中添加超链接
在 所有链接 选项卡中，选择
链接到。.png "“添加超链接”对话框")
在 链接类型 列表中，选择 超链接。
在**“地址”**框中，键入链接目标的地址。
如果目标是网站，请键入 URL，或者从 Internet 浏览器中复制该 URL，然后将其粘贴到**“地址”**框中。 如果目标是服务器位置，请键入 UNC 名称格式的地址。
（可选）在**“注释”**框中键入有关超链接的更多信息。
选择 确定，然后选择
保存工作项。
更改要求的状态
团队可以通过将要求的**“状态”**字段设置为以下值之一来跟踪要求的进度：
已建议
活动
已解决
已关闭
当您创建要求时，默认情况下要求将处于**“已建议”状态。 当团队接受当前迭代的要求时，团队会将工作项更改为“活动”状态，并创建任务来实现该工作项。 当团队完成任务，并且系统测试显示团队已成功实现要求后，团队会将要求更改为“已解决”状态。 最后，当团队验证要求后，团队会将要求更改为“已关闭”**状态。
任何团队成员都可对要求的状态进行更改。
有关可用于跟踪工作项状态的数据字段的更多信息，请参见指派、工作流和计划 (CMMI)。
更改要求的状态
打开要求的工作项窗体。
在 状态 列表中，选择 活动、 已解决 或 已关闭。
如果将状态从**“已建议”更改为“活动”，“原因”字段会自动更改为“已接受”**。
如果将状态从**“活动”更改为“已解决”，“原因”字段会自动更改为“代码完成且系统测试通过”**。
如果将状态从**“已解决”更改为“已关闭”，则“原因”字段更改为“通过验证测试”**。
如果从 活动 更改为状态。已关闭，应选择与您在 原因 的目的列出的选项。
有效的选项为**“拆分”（默认）、“已放弃”和“超出范围”**。
选择
保存工作项。
典型工作流进度：
非典型转换：
|
要求状态图 .png "要求工作流") |
.gif "Ee332491.collapse_all(zh-cn,VS.110).gif")
已建议（新建）
在团队成员创建要求时会自动捕获以下数据字段：
创建者：创建要求的团队成员的名字。
创建日期：创建要求时的日期和时间（按服务器时钟记录）。
由“已建议”改为“活动”
由于下表所述的原因，团队成员可以将要求的状态从**“已建议”更改为“活动”**：
原因 |
何时使用 |
要采取的其他操作 |
|---|---|---|
已接受 |
当会审委员会批准在当前迭代中实现要求时。 |
将要求指派给将实现要求的团队成员。 |
调查 |
当会审委员会认为在委员会决定团队是否应实现要求之前团队必须先调查客户影响时。 |
在调查完成后将要求恢复为“已建议”状态。 |
在团队成员将要求的状态更改为**“活动”**时会捕获以下数据字段：
激活者：激活要求的团队成员的名字。
激活日期：激活要求时的日期和时间（按服务器时钟记录）。
状态更改日期：要求的状态更改日期和时间。
由“已建议”改为“已关闭”
由于下表所述的原因，团队成员可以关闭处于**“已建议”**状态的要求：
原因 |
何时使用 |
要采取的其他操作 |
|---|---|---|
已拒绝 |
当会审委员会认为团队无法实现要求或者客户不再需要要求时。 |
无。 |
在团队成员关闭要求时会捕获以下数据字段：
关闭者：关闭要求的团队成员的名字。
关闭日期：关闭要求的日期和时间（按服务器时钟记录）。
状态更改日期：要求的状态更改日期和时间。
活动
团队只应实现处于**“活动”状态的那些要求。 对于活动要求，团队成员应创建用于编写代码、测试和记录要求的任务。 当所有任务完成后，要求将更改为“已解决”**状态。 如果要求已拆分、被放弃或被认为超出范围，团队成员也可以关闭要求。
由“活动”改为“已解决”
由于下表所述的原因，团队成员可以解决活动要求：
原因 |
何时使用 |
要采取的其他操作 |
|---|---|---|
代码完成且通过系统测试 |
当团队签入实现要求的代码并且所有系统测试已通过时。 |
将要求指派给将测试要求的团队成员。 |
在团队成员解决活动要求时会捕获以下数据字段：
解决者：解决要求的团队成员的名字。
解决日期：解决要求时的日期和时间（按服务器时钟记录）。
状态更改日期：要求的状态更改日期和时间。
从活动到关闭
由于下表所述的原因之一，团队成员可以关闭活动要求：
原因 |
何时使用 |
要采取的其他操作 |
|---|---|---|
拆分（默认值） |
当要求太大或需要更精确的定义时。 |
创建一个或多个附加要求，并从原始要求链接到这些要求。 接受这些新要求时其状态应为“活动”。 |
已放弃 |
当团队不再需要实现要求时。 |
无。 |
超出范围 |
当团队没有足够的时间来实现当前迭代的要求或已发现阻止实现要求的问题时。 |
指定可能在哪个迭代中实现要求。 如果已将要求推迟到软件的下一版本，则将“迭代”字段留空，但要详细说明要求推迟的原因以及团队应在何时实现要求。 |
在团队成员关闭活动要求时会捕获以下数据字段：
关闭者：关闭要求的团队成员的名字。
关闭日期：关闭要求的日期和时间（按服务器时钟记录）。
状态更改日期：要求的状态更改日期和时间。
由“活动”改为“已建议”
由于下表中的原因之一，团队成员可以将活动要求的状态更改为**“已建议”**：
原因 |
何时使用 |
要采取的其他操作 |
|---|---|---|
已推迟 |
当团队将不会在当前迭代中实现要求，但可能在将来的迭代中实现要求时。 |
无。 |
调查完成（默认值） |
当团队已调查了要求并重新提交要求以供会审时。 |
无。 |
在团队成员关闭活动要求时会捕获以下数据字段：
更改者：更改了要求状态的团队成员的名字。
状态更改日期：要求的状态更改日期和时间。
已解决
当要求已在代码中实现并通过系统测试后，开发人员主管将要求的状态设置为**“已解决”**，并将要求指派给测试人员。 然后，测试人员依据客户的期望验证要求是否已实现。 如果要求已实现，测试人员将关闭要求。 如果未实现，则测试人员将重新激活要求以进行进一步工作。
由“已解决”改为“已关闭”
由于下表所述的原因，团队成员可以关闭已解决的要求：
原因 |
何时使用 |
要采取的其他操作 |
|---|---|---|
验证测试已通过 |
当要求通过与之关联的所有验证测试时。 |
将要求指派给产品所有者。 |
在团队成员关闭解决的要求时会自动捕获以下数据字段：
关闭者：关闭要求的团队成员的名字。
关闭日期：关闭要求的日期和时间（按服务器时钟记录）。
状态更改日期：要求的状态更改日期和时间。
由“已解决”改为“活动”
由于下表所述的原因，团队成员可以重新激活已解决的要求：
原因 |
何时使用 |
要采取的其他操作 |
|---|---|---|
验证测试未通过 |
当验证测试指明要求未满足一项或多项客户期望时。 |
将问题记录为 Bug，并将要求指派给开发人员主管。 |
在团队成员重新激活解决的要求时会自动捕获以下数据字段：
激活者：重新激活要求的团队成员的名字。
激活日期：重新激活要求时的日期和时间（按服务器时钟记录）。
状态更改日期：要求的状态更改日期和时间。
已关闭
团队不应再处理任何已关闭的要求，因为该要求已被拒绝，或已得到成功实现、确认和验证。
团队可以重新激活回到范围内的已关闭要求。 通常由业务分析人员或程序经理来重新激活已关闭的要求。
从关闭到活动
由于下表中所述的原因，团队成员可以重新激活已关闭的要求：
原因 |
何时使用 |
要采取的其他操作 |
|---|---|---|
重新引入范围 |
当提供了用于实现要求的资源时。 |
确保为要求定义的实现任务、测试用例和详细信息完整并且是最新的。 |
错误地关闭 |
当要求被意外关闭时。 |
确保为要求定义的实现任务、测试用例和详细信息完整并且是最新的。 |
在团队成员重新激活已关闭的要求时会自动捕获以下数据字段：
激活者：重新激活要求的团队成员的名字。
激活日期：重新激活要求时的日期和时间（按服务器时钟记录）。
状态更改日期：要求工作项的状态更改时的日期和时间。
请参见
概念
使用 team Web access，请求并处理利益干系人反馈