在Azure Boards中制定要求

项目
07/19/2022

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

需求描述利益干系人对产品的期望。使用业务域的词汇和概念，以方便与业务利益干系人讨论这些要求。要求不应讨论或依赖于实现。要求不仅包括用户的行为和服务质量预期，还包括法定约束和商业标准。

通过在 TFS 中创建要求，可获得以下好处：

通过将要求链接到测试用例来验证它们是否得到满足。
通过将要求链接到任务工作项来监视实现要求的进度。
将需求构造为总体需求和更详细的需求，以便你可以更轻松地管理它们以及进度报告可以汇总信息。
对Visual Studio Ultimate中的要求建模，将模型元素链接到Team Foundation Server中的要求。

本文不会尝试复制在确定要求的主题上可用的大量文献。相反，它侧重于以符合 CMMI 的方式使用Visual Studio工具非常重要的方面。有关 CMMI 的详细信息，请参阅 CMMI 的背景。

本文中所述的活动（如任何开发活动）不应严格执行。编写方案时开发域模型，因为一个活动将帮助你改进另一个活动。随着编码时间的临近而制定方案。将针对已编写并演示的代码的体验反馈到尚未实现的方案中。

确定何时制定要求

TFS 支持迭代工作，这种做法在使用早期迭代从潜在用户和其他利益干系人处获取反馈时最有效。这种反馈可以用于改进已针对未来迭代而陈述的需求。此反馈会导致最终安装的产品比在同一时间段内开发的产品更有效，而无需任何用户试用。如果项目是较大程序中许多个组件之一，则与其他组件的早期集成会使程序架构师可以改进总体产品。

必须针对在并行项目中向客户或合作伙伴做出坚定承诺的需要来平衡这种灵活性。

在受控范围内，在整个项目中开发和优化要求。因为详细需求可能会在项目进行期间更改，因此在进行相应实现之前确定它们可能会徒劳无功。

在迭代 0 中，开发一组描述主要功能的要求，其中包含足够的详细信息来形成产品计划。产品计划将需求分配给迭代并陈述在每次迭代结束时将满足的需求。创建主要概念和活动的域模型。定义将在与用户和实现中讨论这些概念的词汇。确定涉及每个功能的宽泛要求，如安全性和其他服务质量要求。
在每次迭代开头处或附近，更详细地为这些功能制定要求。确定用户将遵循的步骤，在活动或序列图的帮助下定义它们。定义在例外情况下发生的行为。
尽可能频繁地验证是否实现了所有要求。普遍需求（例如安全性）必须使用针对每个新功能而扩展的测试进行验证。如果可能，请自动执行测试，因为自动测试可以连续执行。

管理要求更改

以下准则使你可以运行增量过程，同时监视它以满足 CMMI 要求。

不要更改为迭代设置的要求。在极少数情况下突然更改的情况下，可能需要取消迭代。如果是，请查看产品计划并开始新的迭代。
查找需求中的不确定性。尝试安排计划，以便针对早期迭代的用户体验形成可减少不确定性的信息。
使用更改请求工作项可记录对已实现的更改行为的请求（除非请求的改进已是计划的一部分）。将每个更改请求链接到相应的需求工作项。
在每次迭代之前检查产品时，应检查更改请求。检查请求对依赖项目和用户的影响，并估算与代码更改相关的成本。如果接受更改请求，则更新要求。
更新测试以符合每个需求更改。
例如，在迭代 2 或 3) 之后，选择截止日期 (，之后要求更改必须更合理。如果你的项目适用于付费客户，则此日期是使客户批准一组基线要求并从每小时付款切换到固定价格的日期。
使用 bug 工作项来记录不符合显式或隐式要求的行为实现的行为。在可行中，请创建捕获 bug 的新测试。

编写远景声明

与团队讨论视觉声明，并将其显示在项目的 Web 门户上，以便Team Foundation Server。

远景声明是产品会带来的好处的简短摘要。他们以前无法执行哪些操作？远景声明有助于阐明产品的范围。

如果产品已存在，则为此版本编写远景声明。产品用户以前无法执行哪些操作？

编写方案

与客户和其他利益干系人合作创建方案，并输入它们作为要求工作项（“要求类型”字段设置为“方案”）。

方案或用例是描述一系列事件、演示如何实现特定目标以及通常涉及到人员或组织与计算机之间的交互的叙述。

为它提供描述性标题，以便在列表中查看时可清楚地将它与其他内容区分开来。请确保陈述主要参与者，并且其目标清晰明白。此标题是一个很好的示例：

客户购买了一顿饭。

可以采用以下形式编写方案。有时使用多种形式可能会有所帮助：

工作项描述中的一个或两个句子：

客户在网站上订餐，并使用信用卡进行支付。订单传递给一家餐馆，该餐馆会准备并交付这顿饭。
工作项描述中的编号步骤：
1. 客户访问网站并为一顿饭创建了订单。
2. 网站将客户重定向到付款站点进行付款。
3. 订单添加到餐馆的工作列表中。
4. 餐馆会准备并交付这顿饭。
情节提要。情节提要实质上是讲述情节的连环漫画。可以在 PowerPoint 中绘制它。将情节提要文件附加到要求工作项，或将该文件上载到团队门户，并添加指向工作项的超链接。

情节提要对于显示用户交互尤其有用。但对于业务方案，建议使用草图样式，以便清楚地看到情节提要不是用户界面的最终设计。
要求文档。需求文档使你可以自由地为每个需求提供适当级别的详细信息。如果你决定使用文档，请为每个要求创建一个 Word 文档，将该文档附加到要求工作项，或将文件上载到团队门户并添加指向工作项的超链接。
统一标记语言 (UML) 序列图。序列图在多方进行交互的情况下尤其有用。例如，订餐要求客户、DinnerNow 网站、付款系统和餐馆按特定顺序进行交互。在 UML 模型中绘制序列图，将其签入Team Foundation Server，并在要求工作项中输入链接。有关详细信息，请参阅 UML 序列图：指南。

编写特定方案

首先编写特定方案，这通过特定顺序遵循一组特定的参与者。例如，“Carlos 在 DinnerNow 网站上订购一个比萨和蒜蓉面包。该网站将 Carlos 重定向到 Woodgrove Bank 的付款服务。 Fourth Coffee 会准备好比萨并交付它。”

特定方案可帮助设想所使用的系统，在你首先探索一个功能时最有用。

它还可用于创建描述人员和组织的背景和其他活动的命名角色。卡洛斯睡得很粗糙，使用网吧：温迪住在封闭社区：桑杰为妻子下班吃饭：Contoso 在全球经营着 2，000 家餐馆的连锁店：第四杯咖啡由一对骑自行车交付的夫妇经营。

为“客户”、“菜单项”等编写的更通用方案可能更方便，但不太可能发现有用的功能。

详细级别

在迭代 0 中，详细地编写几个重要方案，但概括地编写大多数方案。当特定方案即将在其中完全或部分实现的迭代临近时，添加更多详细信息。

首先考虑某个方案时，描述业务上下文（甚至是产品不涉及的方面）可能会很有用。例如，描述 DinnerNow 交付方法：每个餐馆组织自己的交付还是 DinnerNow 运行交付服务？此类问题的答案可为开发团队提供有用的上下文。

在迭代开始时制定的更详细方案可以描述用户界面交互，情节提要可以显示用户界面布局。

组织方案

可以使用以下方法来组织方案：

绘制将每个方案显示为用例的用例图。建议使用此方法，因为它使演示和讨论方案变得容易。有关详细信息，请参阅 UML 用例关系图：指南。
- 将每个用例链接到定义方案的工作项。有关详细信息，请参阅链接模型元素和工作项。
- 绘制“扩展”关系可显示一个方案是另一个方案的变体。例如，“客户指定单独付款和交付地址”是基本“客户进行订购”用例的扩展扩展可用于分离将在以后迭代中实现的方案。
- 绘制“包含”关系可分离对多个用例通用的过程（如“客户登录”）。
- 在常规方案（如“客户支付”）与特定变体之间（如“客户用卡支付”）之间绘制泛化关系。
在方案工作项之间创建父子链接。可以在团队资源管理器中查看层次结构。有关详细信息，请参阅将要求排列到产品计划中。

对业务领域建模

创建 UML 模型，它描述产品使用中涉及的主要活动和概念。在方案中、与利益干系人的讨论中、用户界面和任何用户手册中以及代码本身中，使用此模型中定义的术语作为“通用语言”。

很多要求未由你的客户明确陈述，理解隐含要求取决于对业务领域（即，产品将在其中工作的环境）的理解。在不熟悉的域中收集的一些要求工作是了解该上下文。建立这种类型的知识之后，它可以用于多个项目。

在版本控制中保存模型。

有关详细信息，请参阅用户需求建模。

模型行为

绘制方案的活动关系图。使用泳道可对不同参与者执行的操作进行分组。有关详细信息，请参阅 UML 活动关系图：指南。

虽然方案通常描述一系列特定事件，但是活动图可显示所有可能性。绘制活动图可以提示你考虑备选序列并向你的业务客户询问在这些情况下应进行的操作。

下图显示一个简单的活动图示例。

Activity with three actions and a loop.

在消息交换很重要的情况下，使用为每个参与者和主要产品组件包含生命线的序列图可能会更加有效。

用例图使你可以汇总产品支持的不同活动流。图上的每个节点表示用户与应用程序之间为实现特定用户目标而进行的一系列交互。还可以将常见序列和可选扩展纳入单独用例节点。有关详细信息，请参阅 UML 用例关系图：指南。

下图显示一个简单的用例图示例。

Use cases for previous actions

模型概念

绘制域类关系图以描述方案中提及的重要实体及其关系。例如，DinnerNow 模型显示“餐厅”、“菜单”、“订单”、“菜单项”等。有关详细信息，请参阅 UML 类图：指南。

使用名称和基数标记关系的角色（各端）。

在域类图中，通常不会将操作附加到类。在域模型中，活动图描述行为。向程序类分配职责是开发工作的一部分。

下图显示一个简单的类图示例。

Rule in Comment attached to Order class.

静态约束

向类图添加控制特性和关系的约束。例如，订单中的项必须全部来自同一家餐馆。这些类型的规则对于产品设计非常重要。

模型一致性

确保模型和方案一致。模型最强大的用途之一是解析多义性。

方案描述使用模型中定义的术语，与它定义的关系保持一致。如果模型定义菜单项，则方案不应引用与产品相同的内容。如果类图显示菜单项完全属于一个菜单，则方案不应讨论在菜单之间共享项。
每个方案描述活动图允许执行的一系列步骤。
方案或活动描述如何创建和销毁类图中的每个类和关系。例如，哪些方案创建菜单项？何时销毁订单？

制定服务质量要求

创建指定服务质量要求的工作项。将“要求类型”字段设置为“服务质量”。

服务质量或非功能要求包括性能、可用性、可靠性、可用性、数据完整性、安全性、负担能力、服务能力和升级能力、交付能力、可维护性、设计和完善性。

请为每个方案考虑以上每个类别。

每个服务质量要求的标题都应通过提供上下文、操作和度量值来捕获其定义。例如，可以创建以下要求：“在目录搜索过程中，在三秒内返回搜索结果。”

捕获更多详细信息非常有用，它解释了为什么需要要求。描述角色为何重视需求以及为何需要此服务级别。提供上下文和理由。此说明可能包括有用的风险管理信息，例如市场调查中的数据或客户焦点组。或者，它可能包括可用性研究、技术支持报告/票证或其他传闻证据。

将服务质量要求链接到任何受服务质量影响的方案（要求工作项）。链接相关的工作项允许用户Team Foundation Server跟踪依赖性要求。查询和报告可以显示服务质量要求如何影响作为方案捕获的功能需求。

审查要求

编写或更新了要求时，应由合适的利益干系人评审它们，以确保它们可充分描述与产品进行的所有用户交互。常见利益干系人可能包括行业专家、业务分析人员和用户体验架构师。还应评审方案以确保它们可以在项目中实现而不会出现任何混淆或问题。如果发现任何问题，则必须修复方案，以便在此活动结束时有效。

创建评审工作项以跟踪评审。此项为标准 CMMI 过程改进鉴定方法 (SCAMPI) 鉴定提供重要证据，可以为将来的根本原因分析提供良好的信息来源。

针对以下特性评审每个方案：

此方案是在任务用户必须完成的任务、他们已知道的内容以及预期如何与产品交互的上下文中编写的。
方案概括了一个问题，提议的问题解决方案未遮盖该问题。
标识与产品进行的所有相关用户交互。
行业专家、业务分析人员和用户体验架构师在项目上下文中评审每个方案，以验证是否可以成功实现所有方案。如果方案无效，则会对其进行修订，使其有效。
可以使用可用技术、工具和资源，并在预算和时间表范围内实现方案。
方案具有易于理解的单个解释。
此方案与另一种方案不冲突。
方案可进行测试。

验证

计划在最终发布之前将产品的 beta 版本部署到工作环境中。基于来自该部署的利益干系人反馈来计划更新需求。

验证意味着确保产品在其运行环境中符合其预期用途。在 MSF for CMMI 中，通过在整个项目的每次迭代结束时向利益干系人演示工作软件来实现验证。安排计划的方式应使从早期演示反馈到开发人员的问题可以在剩余迭代的计划中得到处理。

若要实现真实验证，产品必须不只在演示或模拟上下文中运行。就可用性而言，它应在实际条件下进行测试。

检查和编辑要求

方案和服务质量要求（会形成大多数开发任务）可以使用客户要求查询进行检查。如果想要显示所有要求，可以编写返回要求工作项类型的所有工作项的查询。设置结果列以显示迭代路径。

团队应在项目的早期迭代中创建大多数要求。从早期版本获得反馈时，会添加新要求并调整其他要求。