实施Microsoft Dynamics 365 CE-3. 需求收集与分析，涵盖了不同的需求收集和分析技术。

本文链接：https://blog.csdn.net/mwjcxl/article/details/132531190

本章将帮助您了解项目管理方法的要求以及项目管理工具对成功交付任何项目的重要性。我们还将讨论用于实现Dynamics365CE的各种方法。

本章将帮助您选择适合Dynamics 365 CE项目的项目方法。

我们将在本章中讨论的主要主题如下：

了解需求
需求收集和分析
Dynamics 365 CE的拟合差距分析
准备项目计划

技术需求

本章没有任何技术要求，但在为客户收集要求时，建议使用以下工具（或类似工具）来记录客户要求：

Microsoft Office或Office 365订阅文档项目活动
Microsoft Visio或类似工具
Microsoft项目管理或类似的项目管理工具

了解需求

在理解需求收集过程之前，让我们先了解什么是需求。需求基本上是来自客户或最终用户的请求。该请求可以用于在系统中添加新功能或者修改系统的现有功能。根据所使用的项目管理方法，使用不同的术语来指代需求，如用户故事、用例、功能等

我们需要需求来设计、开发和测试Dynamics365CE实施或任何产品。毫无疑问，需求为新系统的实施或构建奠定了基础。如果要求不正确，则会增加Dynamics 365 CE实施失败的风险。

需求可分为以下不同类别：

业务需求
功能性需求
非功能性需求

让我们讨论一下这些不同类别的需求。

业务需求

业务需求代表了Dynamics 365 CE实施、对现有Dynamics 365 CE实现的增强或开发新的Dynamics 365 CE解决方案的业务自动化流程的高级理念。

我们将在后面的章节中讨论Dynamics365CE的自定义和配置详细信息。这些需求由业务分析师收集，并记录在业务需求文档（BRD）中。本文档从业务角度解释了拟议系统的外观。

业务需求包括功能性需求和非功能性需求，也包括组织的需求。应该收集业务需求，因为它们为整个项目提供了基础。BRD的主要目标如下：

提供有关现有系统的背景详细信息和更改原因，以及业务背景和愿景。
列出高级业务需求，并解释项目范围内的内容和范围外的内容。
提供有关组织内使用的业务流程、基础架构和技术的详细信息。
为成功实施Dynamics 365 CE提供指标。
提供更改当前系统的预期时间表。
提供有关Dynamics 365 CE实施计划的详细信息，包括客户是希望逐个部门实施发布，还是希望为所有部门实施单一发布。

BRD还包括来自业务部门的批准。

为了进一步了解业务需求，让我们以一家自行车服务公司HIMBAP汽车服务中心为例，该公司希望在其组织和所有服务中心中实施Dynamics 365 CE。他们对新系统的业务要求如下：

改进客户服务的操作工具，实现客户服务管理的自动化和标准化。
它应该支持客户细分。
一种分析工具，用于改进客户关系管理，使用360度视图分析客户信息，并报告客户服务中心的客户服务绩效。
允许实时捕获客户端信息并跨多个设备进行通信。
所有员工登录后都可以立即访问该系统，并突出显示客户的关键关系管理任务和提醒。
系统必须提供客户活动摘要，包括现有服务历史、当前服务计划、沟通历史和其他相关客户联系信息，以便制定销售优先级和策略。
客户购买的服务视图提供了识别所有客户的能力，无论他们是企业还是个人，并确定他们的地理位置。
该系统应能够获取基本的竞争对手信息。

前面的所有要求都解释了客户想要什么。我们也可以说，业务需求基本上讲的是客户的痛点。一旦我们知道了所有的业务需求，它们就会在BRD中被捕获。

功能性需求

一旦我们有了业务需求，这让我们对所提出的系统有了一个高级的概念，另一个需求类别（称为功能需求）就会出现。这些需求来自于在日常工作中实际使用该系统的最终用户或业务用户，因此这些需求基本上是关于系统如何运行的。它描述了使用拟议系统可以执行的主要功能，新系统的功能，当特定数据输入系统时，它将如何表现，等等。

功能要求记录在功能要求文件（FRD）中。功能需求还包含有关新系统应该具有的业务流程自动化的信息。它规定了数据将如何在系统的不同组件之间流动，以及使用它的安全要求。功能要求通常集中在以下要求上：

应用程序接口
新系统的安全要求
数据输入和输出方法
报表需求
业务流程和规则

如果我们以HIMBAP汽车服务中心为例，我们可以描述一些功能需求，例如：

序号	分类	描述
1	用户管理	管理员用户应该能够创建和更新用户。
2	用户管理	管理员用户应该能够为执行成员、办公室工作人员和服务工程师等用户创建不同的配置文件。
3	用户管理	用户应该能够根据其权限访问数据。
4	数据管理	用户应该能够手动输入数据，也能够导入数据。
5	数据管理	应用程序应允许用户迁移客户的现有数据、服务历史记录和服务计划购买历史记录。
6	客户管理	用户应该能够为客户建立多关系结构。
7	客户管理	系统应允许将客户细分为企业或个人。
8	客户管理	用户应该能够使用该应用程序与客户进行通信。
9	客户管理	与客户的所有沟通都应可用于报告目的。
10	潜在客户管理	应用程序必须能够根据地理区域自动将潜在客户记录路由到服务中心。

我们可以看到，前面的所有需求都集中在新应用程序或解决方案中应该可用的系统行为和操作上。

非功能性需求

另一类关键需求是非功能性需求，主要关注新解决方案或应用程序的操作。任何关于新应用程序应该如何使用的客户需求都属于这一类。非功能性需求涉及应用程序的以下特征：

应用的可用性：此要求涉及在任何停机或故障期间的应用程序可用性。例如，任何应用程序维护的时间不得超过1小时。我们还可以定义哪些特定功能是关键的，应该尽快提供。
安全：这个要求讨论了应用程序应该具有哪些安全功能。这是一个关键需求，因为它对存储在应用程序中的客户数据有直接影响。应用程序的安全要求确保保护客户数据不受任何未经授权的访问。用户还可以根据其安全权限访问应用程序数据。
可靠性：此要求涉及应用程序在没有任何故障的情况下工作的能力。故障可能是由于代码错误、补丁更新或任何硬件故障。每一个新的应用程序或对现有应用程序的升级都有望长期运行，不会出现任何问题。
易用性：这是任何应用程序的关键要求。大多数业务应用程序都会失败，因为用户无法轻松学习和使用它们。可用性要求包括应用程序的简单性、用户界面的简单性以及应用程序中帮助的可用性。
性能：这个需求讨论了系统基于不同用户操作的响应能力，以及应用程序对用户操作的反应速度。应用程序的糟糕性能会导致负面的用户体验，因此应用程序的响应时间应该很快。
可扩展性：此要求涉及在需要时增加应用程序的容量以支持更多的工作负载。这可能涉及支持更多的用户，在特定时间内支持更多的请求，或者在不影响应用程序的情况下处理更多的事务。大多数情况下，应用程序的可扩展性是通过使用硬件来提高的。例如，我们可以通过添加更多的硬件资源（如内存、服务器或磁盘空间）来提高可扩展性。
可维护性：此要求涉及应用程序的维护能力。这主要包括修复任何现有的错误，在出现故障时恢复应用程序数据，添加补丁，以及将应用程序升级到最新版本。

基于这些特点，我们可以将HIMBAP汽车服务中心的非功能需求定义如下：

序号	分类	描述
1	可访问性	应用程序应全天候为用户提供。
2	可访问性	应用程序应可通过流行的web浏览器和移动设备访问
3	可用性	无论是否经过最少的用户培训，新系统都应该易于使用。
4	可用性	应用程序应该有内置的帮助说明。
5	可维护性	任何应用程序升级或维护都应在办公时间后进行
6	安全性	办公室工作人员应该被迫每月更改他们的应用程序密码。
7	安全性	只有服务中心负责人才能添加或修改应用程序用户。
8	安全性	只有服务中心负责人才能更改用户权限。
9	可扩展性	如果节日期间需要，应用程序应该能够支持更多的交易。
10	可靠性	如果任何支付交易失败，则任何帐户更新应回滚。

既然我们已经了解了什么是需求，并学习了三类需求，那么让我们看看如何收集这些需求并进行分析。

需求收集和分析

需求收集是任何Dynamics365CE实施或任何其他项目的关键部分。所有其他阶段都在很大程度上依赖于需求收集和分析，因此，如果要求收集和分析不正确，就会对Dynamics365CE的实施产生重大影响。

让我们详细讨论需求收集和分析过程的两个步骤。

需求收集

需求收集是一个过程，旨在捕获不同类型的需求，以实现Dynamics 365 CE或解决现有Dynamics 365 CE实现中的问题。需求收集由业务分析师（BA）完成。需求收集之前，识别利益相关者和关键用户至关重要。重要的是，从需求收集开始就让利益相关者和关键用户参与进来，以避免任何形式的混淆或误解。

需求收集涉及多种活动，如公开讨论、故事板、构建原型和讨论不同的场景。这些技术在不同的实现中可能有所不同。在使用这些技术时，我们应该首先清楚地了解需求，并在提出任何解决方案之前与团队进行确认。根据BA在特定领域的经验，可以做出与客户需求相关的一些假设，但始终建议与相关团队讨论这些假设，并获得他们的批准，以避免任何混淆。
您可以在下图中看到这个过程：

可以使用以下不同的技术进行需求收集：

访谈
问卷调查
研讨会
头脑风暴
原型

让我们逐一详细讨论这些技术。

访谈

这是最常见和最有效的需求收集方法。使用此技术，我们可以直接与利益相关者和关键用户进行沟通，以了解他们实施Dynamics365CE应用程序的需求和目标。
访谈是通过面对面的互动进行的；这可以是一对一的，也可以是分组的。访谈应始终根据各自团队的可用性进行预先计划。在准备访谈问题时，我们可以在访谈中包括以下类型的问题：

开放性问题
封闭性问题

开放性问题

开放性问题是了解团队对当前系统的看法、他们如何使用该系统以及他们希望通过Dynamics 365 CE实现什么目标的重要方式。这些问题不能用一个词来回答——例如，是或否。
这些问题的答案可以用一行或两行提供。这些问题取决于他们将要使用的Dynamics 365 CE应用程序。以下是HIMBAP汽车服务中心Dynamics 365 CE实施的一些开放性问题示例：

您实施Dynamics 365 CE的目标是什么？
主要的业务流程是什么？
你的日常活动是什么？
在当前系统中，您的痛点是什么？
有多少用户将使用Dynamics 365 CE？
您的销售生命周期是什么？
你从事哪些营销活动？
您采取了哪些措施来解决客户问题？
您当前使用的Microsoft技术是什么？
是否要将Dynamics 365 CE与其他应用程序集成？

封闭性问题

需要具体答案的访谈问题属于封闭性问题类别。这些问题的答案可能很简短。团队可以用单个或多个单词回答这些问题。封闭性问题的答案可以设计为简单地有是/否或多个选项的答案。以下是HIMBAP汽车服务中心Dynamics 365 CE实施的一些封闭性问题示例：

您希望使用哪种Dynamics 365 CE部署（云/内部部署）？
您使用Microsoft Office 365吗？
您的客户如何与您正常沟通（电子邮件/电话/传真/个人）？
目前服务请求是如何生成的（使用电子邮件/电话/展会）？
你们提供服务合同吗？
合同是否基于您的服务类别？
你们提供全天候服务吗？
你在节假日或周末安排服务吗？
您如何分配服务请求（基于地区/邮政编码/客户）？
您是否有要迁移到Dynamics 365 CE的现有数据？

我们始终建议您提前将访谈问题发送给各自的团队，以便他们为访谈做准备。与直接进行访谈相比，如果问题提前发送，团队可能会向您提供更多细节。你也可以使用录音软件记录团队访谈，这总是一个好主意，可以确保没有遗漏任何内容。

问卷调查

这是另一种类型的需求收集技术，其中基于需求准备问题列表。与面试技巧相比，这种技巧非常有用，可以在更短的时间内获得更多信息。对于这种技术，不需要面对面的互动，当我们需要从大型团队获得需求时，就会使用这种技术。

编制了一份带有问题清单的调查表文件，并将其发送给各个小组。有时，也会创建在线调查来获得特定问题的答案。此问题列表是根据特定模块或功能集编制的。

以下是两种类型的问卷：

开放式问卷
封闭式问卷

让我们详细讨论一下这两种类型的问卷。

开放式问卷

顾名思义，这些问题为团队提供了自由表达想法的灵活性。开放式问题的答案留有空格。以下是我们的HIMBAP汽车服务中心Dynamics 365 CE实施的开放式问卷示例：

你希望新系统有什么改进？请提供详细信息。____________________________
哪些不同类型的用户将使用Dynamics 365 CE？请提供详细信息。______________________
您的领域是如何定义的？请提供详细信息。_________________________________
您为客户提供什么类型的服务？请提供详细信息。______________________________
您的服务外包了吗？如果是，请提供详细信息。_________________________________
你为团队设定目标吗？如果是，这些目标是如何定义的？请解释。________________________
使用了哪些类型的报告以及为什么生成这些报告？请提供详细信息。______________________
你对客户进行分类吗？如果是，请解释。_________________________
您是否在系统中创建竞争对手的详细信息？如果是，您如何维护它们？____________________
你有汽车服务的价目表吗？如果是，请提供详细信息。____________________________

封闭式问卷

在这种类型的问卷中，我们有多种选项可用于回答问题。
用户可以根据自己的需求选择可用的选项，但与开放式问卷相比，他们无法自由提供自己的意见或答案。以下是我们可以用于HIMBAP自动服务中心Dynamics 365 CE实施的一些问题示例：

用户将如何访问Dynamics 365 CE应用程序？请选择适当的选项
1. 浏览器
2. 手机
3. 邮箱
4. 平板
5. 所有
请选择您计划使用的Dynamics 365 CE的所有应用程序：
1. 销售
2. 市场
3. 服务
4. 现场服务
5. 客户之声
6. 项目服务自动化
你有知识库吗？
1. Yes
2. No
在文章发表在知识库中之前，您是否遵循任何流程来批准文章？
1. Yes
2. No
你提供路边救援吗？
1. Yes
2. No
服务工程师轮班工作吗？
1. Yes
2. No
您如何与客户沟通？
1. 电子邮件
2. 电话
3. 写信
4. 传真
5. 其他选项_____________
你们的销售渠道是什么？
1. 公司站点
2. 邮件
3. 电话
4. 经销商
5. 零售商
6. 其他________________
您如何获取客户反馈？
1. 使用反馈表单
2. 使用在线调查
3. 通过社交媒体
4. 通过电话
5. 其他_________________
您是否正在使用忠诚度管理计划？
1. Yes
2. No

一旦收集了问卷回复，就可以对其进行汇编，以查看需求。这是一种非常有用的技术，可以快速收集更多信息。

研讨会

另一种从大量人员那里收集需求的技术是举办研讨会。研讨会可以根据组织的部门进行，团队可以提供他们的观点，我们可以在小组讨论后获得高质量的信息。在一些需求收集技术中，我们处理的是可能提供个人想法的个人，这些想法可能与实现Dynamics365CE的目标不匹配。在研讨会的情况下，由于涉及多人，我们只会得到符合组织目标的要求。在举办研讨会时，我们需要确保让合适的人参与进来。

与其他方法相比，由于涉及大量人员，这是一种收集需求的昂贵方法，但它肯定有助于在有限的时间内获得正确的信息。在举办讲习班之前应进行适当的规划；例如，研讨会的讨论主题应该提前规划，研讨会的地点和持续时间应该在预定的活动之前确定。

头脑风暴

有时，在收集业务需求时，倾听主题专家的想法以解决特定的业务问题是至关重要的。头脑风暴是主题专家为解决特定的业务问题、问题或需求而贡献想法的过程。在头脑风暴中，人们可以毫不犹豫地表达他们对主题的想法。我们可以针对一个或多个主题进行头脑风暴，并为解决方案准备想法。不同的想法可以根据与团队的讨论进行优先排序，最后，我们可以通过选择最适合业务的解决方案得出结论。

原型

这是另一个非常重要的技术，也是目前需求收集中最常见的技术。在这种技术中，概念验证是建立在初始需求收集的基础上的。该原型包括最终提出的解决方案的基本功能，通常用于提供实际系统的感觉。原型是通过遵循迭代过程来构建的，每次迭代都会根据客户的反馈来增强原型，直到它到达最后阶段。

分析

在得到“需要什么”的答案后，下一步是找出如何实现要求。对所有文件进行分析，以检查所提供信息的质量，确保对要求没有混淆或误解。在任何信息不完整的情况下，在进入下一步之前进行更正。可以执行以下活动进行需求分析。

分析文档

在本活动中，将分析所有现有文档，以了解有关当前业务流程和业务规则的更多信息。它也有助于提供更清晰的用户需求。我们可以根据需求或特性确定利益相关者。
有时，用户不太清楚当前系统中存在的内容，因此在这种情况下，分析现有文档会非常有帮助。但是，如果文档由于过时而没有与当前系统同步，有时可能会浪费时间。

分析现有应用程序

这是分析现有应用程序时需要的另一项活动。在该活动中，对于任何现有服务器，都会根据收集到的需求分析遗留应用程序。例如，假设我们正在升级一个项目，需要将早期的客户关系管理（CRM）版本升级到Dynamics 365 CE。从早期的Microsoft CRM版本升级需要代码升级和自定义升级。我们需要分析现有的Microsoft CRM代码，以检查它是否在服务器端代码和客户端代码中都使用2011 service endpoint。客户可能已经为一些现在现成的功能开发了自定义解决方案，因此我们可以删除旧的解决方案，转而使用现成的功能。

准备评估报告是很常见的，其中所有信息都是与开发的自定义组件、现有客户端代码、服务器端代码、任何集成以及任何遗留应用程序详细信息相关的文档。同样，如果客户正在使用遗留应用程序，并且现在想要使用Dynamics 365 CE，我们需要查看遗留系统数据库及其表，以计划将其数据迁移到Dynamics 365 CE。

拟合差距分析

收集所有需求后执行的另一项重要活动是拟合差距分析。Fit Gap分析基本上用于了解业务需求和拟议系统之间的差距。根据收集到的需求，它验证所提出的系统是否符合业务需求。所有的差距都记录在案，并制定了适当的行动计划来填补这一差距。拟合间隙分析过程可以通过下图来理解：

我们将在下一节中讨论更多关于拟合差距分析的内容，在下一部分中，我们将更详细地了解拟合差距分析活动。

Dynamics 365 CE的拟合差距分析(Fit-Gap)

在实施Dynamics365CE时，在不同级别进行了拟合差距分析。在每个级别中，我们都会比较这些功能，看看它是否最适合Dynamics 365 CE功能。如果Dynamics 365 CE不符合要求，则会为我们需要进行的定制和开发提供适当的估计，以填补空白。以下是为HIMBAP汽车服务中心准备的拟合间隙分析表样本。您可以看到需求是如何与不同的Dynamics 365 CE类别映射的：

让我们详细讨论一下为Fit Gap分析执行的活动列表。

开箱即用功能–拟合差距分析

在此活动中，将所有要求与Dynamics365CE功能进行比较。Dynamics365CE提供了各种开箱即用的功能，可用于满足许多业务需求。例如，可以使用普通功能来实现为客户、联系人、潜在客户、产品和活动创建记录的简单业务需求。

类似地，Dynamics 365 CE支持使用不同选项搜索实体数据，如快速查找视图、全局搜索、相关性搜索和高级查找搜索。但是，如果客户需要在传统数据库中搜索数据，这将被视为一个缺口，我们需要有一个自定义解决方案，允许客户在自定义数据库中搜索。

配置拟合间隙分析

此拟合差距分析活动涉及确定可以使用Dynamics 365 CE中的配置选项实现的需求。企业最常见的要求是根据工作角色和职位处理不同的用户权限。Dynamics 365 CE提供开箱即用的安全功能，以保护其数据免受未经授权的访问

Dynamics 365 CE具有许多现成的安全角色，可以根据用户的工作配置文件将这些角色分配给用户。我们可以确定开箱即用的安全角色中的差距，并记录安全角色的配置要求，以根据特定业务需求填补差距。

在处理新的安全角色时，最佳做法是复制最合适的现有安全角色，然后根据要求对其进行修改，而不是创建具有空权限的新安全角色。

另一个常见的要求是，每个企业都必须使用不同的数字通信渠道（如电子邮件、短信）与客户沟通。Dynamics 365 CE为使用电子邮件与客户沟通提供开箱即用的支持。

Dynamics 365 CE不提供SMS集成的开箱即用功能，但我们可以使用其他工具（如Microsoft Flow）或使用Microsoft AppSource的其他独立软件供应商（ISV）解决方案轻松设置SMS集成。同样，我们在Dynamics 365 CE中有不同的配置选项，可以用来满足业务需求。我们将在后面的章节中讨论有关Dynamics365CE配置的更多信息。

自定义拟合差距分析

通过此活动，我们确定了使用配置无法实现的需求，以及需要自定义Dynamics 365 CE的需求。这可能与在Dynamics 365 CE中重新标记实体显示名称或创建工作流以应用业务逻辑有关。
例如，可以使用不同的术语来指代最终客户，如客户、供应商、供应商、广告商、代理商、客户等。我们只需根据业务需求在Dynamics 365 CE中重新标记帐户实体。

Dynamics365CE附带了许多可用于存储数据的业务实体。但是，如果我们的客户希望存储与任何现有实体都不匹配的特定数据，我们可以创建一个自定义实体，并相应地向该实体添加一个字段。
同样，我们可以在不同级别自定义Dynamics365CE。我们将在下一章中进一步讨论定制功能。根据需求，我们可以找出需要进行定制的空白，以填补功能空白。为实现特定需求所需的定制工作提供了适当的估计。

扩展Dynamics 365 CE–拟合差距分析

Microsoft Dynamics 365 CE为我们提供了一个广泛的可扩展平台，该平台支持为Dynamics 365 CE编写自定义扩展。在完成早期的Fit Gap分析活动后，我们可能会发现有些需求无法通过配置或定制来实现。为了实现这些需求，我们可能需要使用Dynamics365CE软件开发工具包（SDK）编写自定义扩展。

Microsoft Dynamics 365 CE SDK提供了一个工具设置，我们可以使用该工具为Microsoft Dynamics 365 CE编写自定义扩展。

您的客户可能希望应用他们希望在特定事件上触发的特定业务逻辑，例如，在生成新的服务请求后立即创建服务任务，或者他们可能希望将Dynamics 365 CE与Azure上托管的自定义应用程序集成。这些类型的需求无法通过自定义或配置来实现。我们需要为此使用代码。

ISV解决方案–适合差距分析

执行另一项分析活动是为了检查是否有任何要求可以使用由Microsoft供应商开发的与Dynamics 365 CE兼容的ISV解决方案来满足。

ISV解决方案是ISV开发的解决方案。您可以在Microsoft AppSource中找到由Microsoft和Microsoft合作伙伴开发的ISV解决方案，网址为：Find the right app | Microsoft AppSource

大多数情况下，使用已经被其他客户使用和测试过的现有ISV解决方案是一个更好的选择，而不是将开发时间和精力投入到从头开始构建功能上。这就是我们如何使用Fit Gap分析并确保Dynamics 365 CE符合业务要求的方法。如果我们看到任何差距，我们可以使用我们之前讨论过的不同选项来填补差距。

准备项目计划

一旦收集了需求并完成了分析，下一步就是开始为Dynamics365CE实施计划做准备。项目规划的主要目标是定义项目范围以及如何实现。因此，在创建项目计划之前，我们需要定义项目范围。

定义项目范围

在开始任何项目之前需要的另一项关键活动是明确定义您的项目范围。项目范围界定是定义Dynamics 365 CE实施所需的所有工作的过程。在定义项目活动时，我们需要牢记项目目标。项目范围的主要目标是为各方、企业和咨询团队清楚地了解项目。为了定义项目范围文件，我们需要确保我们已经确定了以下内容：

项目目标
项目要求
项目阶段
项目活动
各自团队
项目成本
项目计划

项目目标

这是项目范围界定文件所需的主要元素。我们需要对项目目标有一个清晰的概念，因为他们将成为整个项目实施生命周期的决策者。所有定义的项目目标都应该是可衡量的，因为它们决定了项目的成功。它们应用于衡量Dynamics365CE每个实施阶段的成功与否。

假设实施Dynamics365CE的一个目标是实现客户审批流程的自动化。应该明确定义这些业务流程以及成功标准，以验证自动化的成功。在提供有关项目目标的详细信息时，我们需要记住，整个项目目标应该清楚地定义客户对使用Dynamics 365 CE的愿景。

项目要求

项目需求应使用前一节“需求收集和分析”中讨论的方法进行捕获和记录。

验收标准

验收标准也应包含在范围文件中。这些标准明确定义了Dynamics365CE实施是否成功并满足业务需求。这些标准在用户验收测试（UAT）期间进行评估。

例外情况

提到Dynamics365CE实施范围内的内容和实施范围外的内容非常重要。业务和咨询团队应就这些项目达成一致。

项目阶段

如果Dynamics 365 CE的实施将分多个阶段进行，则应明确定义。项目范围应规定每个阶段的交付时间以及成功措施。

项目活动

项目范围界定文件应详细说明项目的所有活动及其基于阶段的持续时间。每个项目任务都应该有详细信息，如任务ID、描述、任务估计和资源。

各自的团队

应确定团队，并将其记录在双方的项目范围界定文件中。它应该明确指定来自业务团队以及咨询团队的成员。这涉及到确定不同的项目资源，例如谁将担任客户方面的项目经理，谁将管理咨询团队、利益相关者、开发团队和QA团队中的项目。

项目成本

项目成本是项目的关键决策者。有时，客户会根据项目成本决定是否要实施Dynamics 365 CE。项目范围界定文件应明确详细说明项目成本。以下是高级别项目成本估算的示例：

您可以在前面的屏幕截图中看到，每个活动都有关于估计时间和成本的详细信息。

项目计划

项目范围文件还应包含项目交付时间表的详细信息。它应该清楚地定义项目任务的开始日期和结束日期。以下是Dynamics 365 CE实施时间表的示例：

项目任务可能因项目而异。例如，项目任务将根据我们执行的是实现还是升级而有所不同。项目计划中应提供有关项目进度和任务责任的完整详细信息。这些详细信息包括Dynamics 365 CE实施中的每个活动以及资源信息，例如谁将参与这些活动。

假设

如果对Dynamics 365 CE做出任何假设，也应在范围文件中提及。这样可以确保利益相关者和其他团队成员充分了解所做的任何假设。

风险

Dynamics 365 CE实施范围所需的另一项关键信息是风险。风险是指可能发生也可能不会发生的事件，但我们需要识别和记录所涉及的任何风险。这是因为它会对Dynamics365CE实施产生重大影响。应制定适当的风险管理计划，以确保团队在发生风险事件时如何沟通和应对。

一旦我们确定了所有需要的项目，我们就准备了一份Dynamics 365 CE实施范围文件，该文件描述了所有可交付要素、实现这些要素所需的工作、验收标准以及其他细节。

确定角色和责任

在准备项目计划时，您应该掌握的另一条信息是确定各个团队成员的角色和责任。项目计划中提供的角色和责任细节，包括业务和利益相关者的任何责任——例如，批准文件；项目经理的责任，例如他们将如何执行整个Dynamics 365 CE实施；等等。它还包括开发团队的责任、处理用户故事或任务的资源、执行测试用例的人员、向开发团队报告错误的人员等等。除了这些信息，我们还需要提供有关UAT的详细信息，诸如将执行UAT的关键用户是谁以及谁将向关键用户提供培训。