工作项跟踪管理系统需求
WIT （Work Item Track）
包含：缺陷跟踪、任务指派、突发事件处理、需求管理、客户定制
体现：流程性、规范性、流程可定制性
目的：帮助大家把工作做好、让工作更轻松、使得工作具有可管理性
原则：
用户场景
工作项：用于跟踪工作的分配和状态的数据库记录
工作项类型：
- Bug（缺陷）
- Task（任务）
- Requirement（需求）
- Accident（突发事故）
Bug（缺陷）：
| 字段 | 英文名称 | 说明 |
| 标题 | Title | 必选。标题提供要修复的问题的简要概述。标题应具有足够的描述性以使会审团队能够了解该产品的哪个区域受影响以及如何受影响。 |
| 区域 | Area | 区域用于根据项目层次结构中的功能或团队对 Bug 进行分组。区域必须是项目层次结构中的有效节点。 |
| 迭代 | Iteration | 迭代标识在其中修复 Bug 的迭代。 |
| 指派给 | Assigned To | 此字段标识该 Bug 当前指派给的人员。如果该 Bug 需要多次开发修复，则可将其视作方案并指派给依赖项链中的下一位人员。当所有部分合为一体时，Bug 报表发回到测试人员。 |
| 优先级别 | Priority | 必选。优先级别是主观重要性分级。优先级别 1 指示产品不可正式发布，并且必须尽快修复。优先级别 2 表示重要的 Bug，该 Bug 无需立即修复，但必须在版本发布前修复。优先级别 3 表示可选 Bug，根据资源、时间和风险的不同，该 Bug 可以修复也可以不修复。 |
| 状态 | State | 必选。Bug 可处于“活动”、“已解决”或“已关闭”状态。 |
| 原因 | Reason | 必选。Bug 处于当前状态的原因。例如，因为 Bug 为“已修复”，所以它可处于已解决状态。 |
| 说明 | Description | 说明提供了一个区域以描述问题以及重现该问题的步骤。 |
| 历史记录 | History | 此历史记录是有关 Bug 报表的持续进行的论述，它积累了随着所做的更改而额外写入的项。每当对 Bug 进行更改时，“历史记录”字段中就会生成一项，该项描述所进行的更改和更改的原因，以及关于此次更改的任何额外相关信息。 |
| 问题 | Issue | “问题”是一个“是”或“否”值，它指示对 Bug 的修复是否以某种方式被阻止。如果此字段设置为“是”，则该方案将出现在项目经理的问题报告中。 |
| 发现版本 | Found in Build | 此字段显示在其中发现 Bug 的版本号。 |
| 解决版本 | Resolved in Build | 此字段保存在其中解决 Bug 的版本号。 |
| 测试名称 | Test Name | 此字段标识与此 Bug 关联的测试的名称。 |
| 测试 ID | Test ID | 此字段标识与此 Bug 关联的测试的 ID。 |
| 测试路径 | Test Path | 此字段标识与此 Bug 关联的测试的路径。 |
| 链接 | Links | 指向相关工作项、超链接、变更集或源代码文件的链接。 |
| 文件附件 | File Attachments | 附加相关文件，这些文件提供围绕风险的附加文档。 |
| 级别 | Rank | 相对于其他工作项的相对优先级别。 |
| 会审 | Triage | 会审会议的结果。空白会审意味着 Bug 未会审。 |
Task（任务）：
| 字段 | 英文名称 | 说明 |
| 标题 | Title | 必选。标题提供要完成的任务的简要概述。标题应具有足够的描述性以使团队能够了解该产品的哪个区域受影响以及如何受影响。 |
| 专业领域 | Discipline | 指示该任务是开发任务、测试任务，还是仅仅是普通任务。将“专业领域”字段设置为开发或测试将产生有关任务关闭时的工作状态的独特意义。 |
| 区域 | Area | 用于将任务分组到相应的功能或团队区域中。区域必须是项目层次结构中的有效节点。 |
| 迭代 | Iteration | 预定的迭代是在其中修复 Bug 报表的迭代。 |
| 指派给 | Assigned To | 任务所指派给的当前人员。 |
| 状态 | State | 必选。任务可处于“活动”或“已关闭”状态。 |
| 原因 | Reason | 必选。任务处于当前状态的原因。例如，因为任务为“已完成”、“已推迟”、“去除”、“已推迟”或“已过时”，所以该任务可以为“已关闭”。 |
| 级别 | Rank | 必选。“级别”字段是主观重要性分级。如果“级别”字段设置为 1，则该任务为必须完成的任务，并且应尽快完成。如果级别设置为 2，则该任务为应该完成的任务，应在级别为 1 的所有任务完成之后完成。如果级别设置为 3，则该任务为可以完成的任务，应在级别为 1 和 2 的任务完成之后完成。 |
| 摘要 | Summary | 任务的简短摘要。 |
| 详细说明和历史记录 | Detailed Description and History | 工作项的详细信息和历史记录。 |
| 文件附件 | File Attachments | 指向文件或其他工作项的链接。在开发任务或测试任务的情况下，应附加支持方案或服务质量要求。它还包含对任务的注释之类的任何附件。 |
| 问题 | Issue | 问题是一个“是”或“否”值，它指示任务是否以某种方式被阻止。如果此字段设置为“是”，则该任务将显示在项目经理的问题报告中。 |
| 退出条件 | Exit Criteria | “退出条件”字段指示任务对于开始或结束迭代是否重要。当迭代由于时间的消逝而退出时，应合理地使用此字段。但是，某些任务（尤其是在项目开始时）被标记为退出条件以指示它们必须在项目开始之前完成。如果“退出条件”字段设置为“是”，则该任务将显示在项目经理的项目检查表中。 |
| 集成版本 | Integration Build | 对开发任务的更改出现在所显示的版本号中。 |
| 剩余工作量（小时） | Remaining Work (hours) | 完成任务之前剩余的工作量。此字段与 Microsoft Project 同步，并且可在选择了 Microsoft Project 版本的迭代计划时使用。 |
| 已完成工作量（小时） | Completed Work (hours) | 任务中已完成的工作量。此字段与 Microsoft Project 同步，并且可在选择了 Microsoft Project 版本的迭代计划时使用。 |
Requirement（需求）：
| 字段 | 英文名称 | 说明 |
| 标题 | Title | 必选。标题应尽可能具有描述性。 |
| 区域 | Area | 区域用于将服务质量要求分组到一个相应的功能或团队区域中。区域必须是项目层次结构中的有效节点。 |
| 迭代 | Iteration | 在代码中实现服务质量要求时所在的迭代。 |
| 类型 | Type | 有六种类型的服务质量要求：“负载”、“压力”、“性能”、“平台”、“其他”和“安全”。 |
| 指派给 | Assigned To | 服务质量要求所指派给的当前人员。 |
| 状态 | State | 必选。服务质量要求可处于“活动”、“已解决”或“已关闭”状态。 |
| 原因 | Reason | 服务质量要求处于当前状态的原因。例如，因为要求为“已完成”，所以它可处于“已关闭”状态。 |
| 说明 | Description | 说明提供一个区域以描述服务质量要求。应提供尽可能多的详细信息以确保开发人员可实现该要求，并且测试人员可测试该要求。 |
| 历史记录 | History | 此历史记录是有关服务质量要求的持续进行的论述，它积累了随着所做的更改而额外写入的项。每当对要求进行更改时，“历史记录”字段中就会生成一项，该项描述所进行的更改和更改的原因，以及关于此次更改的任何额外的相关信息。 |
| 问题 | Issue | “问题”是一个“是”或“否”值，它指示方案在进行过程中是否被阻止。如果此字段设置为“是”，则该方案将显示在项目经理的问题报告中。 |
| 退出条件 | Exit Criteria | “退出条件”是一个“是”或“否”值，它指示服务质量要求是否为退出条件列表的一部分。如果此字段设置为“是”，则该要求出现在项目检查表中。 |
| 级别 | Rank | “级别”指示此服务质量要求相对于软件产品的所有要求的重要程度。有效值为从 1 到 3。 |
| 集成版本 | Integration Build | “集成版本”是开发团队在其中集成该要求的版本号。 |
| ID | ID | ID 是指派给服务质量要求的唯一标识号。 |
| 量值的粗略预定 | Rough Order of Magnitude | 量值的粗略预定估计是方案或服务质量要求复杂性的度量值。如果工作项要求实现 6 个或 6 个以下的 1-2 日开发任务，则选择 1。如果工作项要求实现 6 到 12 个 1-2 日开发任务，则选择 2。如果比这更多，则选择 3 并考虑拆分方案或服务质量要求。 |
Accident（突发事故）：
...)
