实施Microsoft Dynamics 365 CE-4. 准备功能和技术设计文件，解释如何为您的项目准备功能和设计文件
本章将帮助您了解如何编制功能设计文件（FDD）和技术设计文件（TDD）。我们将介绍FDD是什么以及它们是如何使用的。我们还将介绍FDD中通常包含的信息。本章将帮助您更多地了解一个好的FDD的功能。
接下来，您将了解TDD以及TDD中通常包含的信息。您还将了解中型Dynamics 365 CE部署的基础结构图。稍后，您将了解Dynamics365CE应用程序体系结构及其扩展点。
我们将在本章中讨论的主要主题如下：
- 了解功能和技术设计
- 准备FDD
- 准备TDD
技术需求
本章没有任何技术要求，但在为客户准备文档时，建议您使用以下工具（或类似工具）来记录客户要求：
- 用于准备文档的Microsoft Office或Office 365订阅。
- Microsoft Visio或类似工具。
- 生成实体关系（ER）图的工具。
了解功能和技术设计
设计文档对任何软件项目都至关重要，无论是开发新软件还是升级现有软件。这些文档也称为规范文档。它们在升级或维护阶段发挥着关键作用，因此建议创建这样的文档。我们将讨论如何准备这些文件。然而，在了解我们需要准备这些文档之前，让我们先了解FDD和TDD是什么，以及功能设计和技术设计之间的区别。我们还将了解为什么我们需要这些文件，以及它们的用途。
功能设计文件
FDD有助于业务利益相关者和所有团队成员了解Dynamics365CE实现及其功能。它不包括关于系统内部如何工作或系统内部组件是什么的任何细节。相反，它提供了关于系统将如何根据特定输入进行操作的信息。我们可以在本文档中看到将在Dynamics 365 CE中实现的所有功能。本文档主要回答以下问题：使用Dynamics 365 CE将实现哪些功能？
FDD需要确保咨询团队和业务利益相关者站在同一立场。在FDD的审批过程中，准备了许多修订。
利益相关者和关键用户可以提供他们对FDD的反馈，例如信息是否正确呈现，或者是否有不符合他们期望的内容。咨询团队确认FDD中提到的功能是否可行，以及是否可以使用Dynamics 365 CE实现。业务分析师或职能顾问接受他们的反馈并更新FDD。然后将文件发送给相应的团队成员和利益相关者。这一过程一直持续到所有团队成员就FDD达成一致为止。一旦此文档获得批准或签署，它就可以用作Dynamics 365 CE实施和后期更新的基础。
以下是良好的Dynamics 365 CE FDD的功能：
- 为实施Dynamics 365 CE提供业务目标
- 定义Dynamics 365 CE实施愿景和范围
- 提供有关审批人的详细信息
- 探索为FDD做出的任何假设
- 提供Dynamics 365 CE配置所需的规范
- 为Dynamics 365 CE提供通用数据模型
- 提供有关业务部门及其层次结构的详细信息
- 提供所需安全角色的列表
- 提供Dynamics 365 CE实施所需的所有自定义功能
- 为所有必需的实体提供屏幕布局
- 在不同实体的屏幕上提供数据验证
- 提供有关将要实现的业务流程和业务逻辑的详细信息
- 提供有关将要开发的任何自定义扩展和集成的详细信息
- 提供有关客户所需的报告和仪表板的详细信息
技术设计文件
另一个对技术团队特别重要的设计文档是TDD。TDD涵盖了FDD的技术细节。本文档主要回答以下问题：新系统中的功能将如何实现？
TDD为技术问题提供了解决方案，因此它不仅提供了需要开发的内容的指导，还提供了如何开发的指导。本文档是为技术团队准备的，他们负责定制、扩展Dynamics 365 CE并将其与其他系统集成。在使用Dynamics 365 CE时，这些详细信息对利益相关者和关键用户是隐藏的。TDD还提供了有关Dynamics365CE实现的体系结构的详细信息。
以下是良好的Dynamics 365 CE TDD的功能：
- 提供有关Dynamics 365 CE实施基础架构的详细信息
- 有助于了解整个客户应用程序体系结构
- 列出所有可能需要的集成
- 列出使用脚本或服务器端代码编写所需的所有自定义逻辑
- 解释自动化日常业务活动所需的工作流程
- 提供有关开发环境和发布管理的详细信息
既然我们了解了什么是FDD和TDD，那么让我们看看如何准备它们。我们将从如何准备FDD开始。
准备FDD
现在我们知道了什么是FDD和TDD，让我们讨论一下如何准备这些文档以及FDD中有哪些可用信息。FDD的内容可能因项目和需求而异。然而，每个FDD都需要一些通用部分。我们将在HIMBAP汽车服务中心Dynamics 365 CE实施的基础上详细讨论这些问题。让我们逐一讨论这些部分。
介绍
每个FDD文档都应该包含一个介绍部分，其中有许多子部分介绍项目细节，如Dynamics365CE实施细节、需求、受众等。
文件目的
这是对FDD的正式介绍。我们需要提供详细信息，如本文件中提供的信息。
项目细节
在本节中，我们需要提供有关Dynamics365CE实现及其高级目标的详细信息。我们可以在这里包含这些详细信息，也可以在之前生成的另一个文档中简单地提及它们，以参考项目详细信息。
目标受众
此信息是向团队成员通知本文档的受众所必需的。我们可以提供目标受众类别下的所有角色列表，类似于以下内容：
- 项目经理
- 业务分析
- 顾问
- 开发
- 测试
- 架构师
专业术语
在本节中，我们需要包括文件中使用的任何特殊单词或缩写。
假定
本节包括有关此Dynamics 365 CE实现的任何假设。例如，我们可以为HIMBAP自动服务中心的实施提供以下示例：
| 序号 | 描述 |
| 1 | 将为HIMBAP汽车服务中心实施Microsoft Dynamics 365 CE Online。 |
| 2 | 将使用最新版本的流行浏览器和移动设备访问Microsoft Dynamics 365 CE。 |
| 3 | Microsoft Dynamics 365实施不包括在客户所在地安装任何硬件和软件。 |
| 4 | 将对帐户、联系人、服务、服务历史、品牌和案例的初始数据负载进行数据迁移。 |
| 5 | HIMBAP汽车服务中心将负责维护Dynamics 365 CE的代码库和解决方案。 |
风险
在本节中，应提及Dynamics 365 CE实施中涉及的任何风险。例如，Dynamics 365 CE Online实施可能存在以下常见风险：
| 序号 | 描述 |
| 1 | Dynamics 365 CE Online性能取决于网速。 |
| 2 | 无法访问Dynamics 365 CE数据库。 |
| 3 | Dynamics 365 CE Online的可用性不受保证。 |
| 4 | Dynamics 365 CE Online中的自定义实体数量是有限的，但客户可以联系Microsoft调整该限制。 |
| 5 | Dynamics 365 CE Online的报表只能使用FetchXML生成。 |
Dynamics 365 CE设置和配置
在本节中，提供了Dynamics 365 CE设置信息，以便管理员用户可以根据要求配置Dynamics 365 CE的设置。我们需要提供Dynamics 365 CE需要配置的所有主要领域的详细信息。
管理设置
可以通过选择Setting|System|Administration。在这里，可以配置Dynamics 365 CE的所有管理设置。以下屏幕截图显示了Dynamics 365 CE中的管理设置选项：
此处应列出与管理相关的任何配置选项。我们将在第5章“配置您的Dynamics 365 CE组织”中讨论所有这些选项，同时讨论Dynamics 365 CE的配置选项。
系统设置
系统设置区域用于配置全局应用程序设置，如格式选项、数据审核、电子邮件配置、outlook筛选器和日历设置。以下屏幕截图代表Dynamics 365系统设置操作
此处应提及任何特定于组织的设置。我们将在第5章“配置您的Dynamics 365 CE组织”中讨论如何使用这些选项。
数据管理设置
在本节中，我们需要提供业务所需的任何与数据管理相关的配置信息。例如，如果客户希望在创建或更新实体记录时实现重复检测，或者希望在特定时间间隔后删除不需要的历史数据，则可以使用批量删除选项来实现。所有与数据相关的设置都可以通过数据管理设置来完成。以下是Dynamics 365 CE数据管理设置的屏幕截图：
我们将在第5章“配置您的Dynamics 365 CE组织”中详细讨论如何配置这些选项。
业务单元层次结构
Dynamics365CE中的业务单元是用户和团队的逻辑分组。Dynamics 365 CE安全性是基于业务单元实现的。我们可以将业务单元视为企业的各个部门。每个Dynamics 365 CE组织都包含一个默认的业务部门，其名称与Dynamics 365 CE机构相同。这个业务单元被称为根业务单元。本节对于Dynamics 365 CE FDD非常重要。在本节中，我们需要提供有关我们将为客户实现的业务部门结构的详细信息。对于HIMBAP汽车服务中心，我们将实现以下业务单元层次结构：
字段级安全配置文件
字段级安全性用于实现敏感字段的安全性。客户可能希望控制敏感字段的创建和更新操作。例如，您的客户可能只希望允许服务经理创建和更新“服务成本”字段。使用字段级安全配置文件来维护字段级安全。在本节中，应提及所有现场级别的安全配置文件，因为这是我们Dynamics 365 CE实施所必需的。
| 用户 | 描述 |
| 服务经理 | 只有服务经理才能对服务总额进行折扣。 |
我们将在第6章“自定义Dynamics365CE”中讨论更多关于现场级安全性的内容。
安全角色
Dynamics 365 CE实体及其数据的安全性是使用安全角色实现的。这些是一组权限，用于定义Dynamics 365 CE用户可以对实体执行哪些操作。Dynamics 365 CE包含许多开箱即用的安全角色，可以根据客户要求进行修改。
在本节中，我们将提供有关将用于客户的安全角色的详细信息。我们将在第6章“自定义Dynamics365CE”中讨论更多关于安全角色的内容。
对于HIMBAP汽车服务中心，我们将使用以下开箱即用的安全角色：
| 业务部门 | 安全角色 | 更改后名称 |
| HIMBAP Auto |
System Administrator
|
HIMBAP Admin
|
| HIMBAP Auto |
System Customizer
|
HIMBAP Customizer
|
| 支持部门 |
Customer Service Representative
|
HIMBAP Support
|
| 服务部门 |
CSR Manager
|
HIMBAP Service Manager
|
| 服务部门 |
Salesperson
|
HIMBAP Technician
|
ER 图
本节提供了有关实体及其相互关系的信息。实体的数量可能会随着创建而变化，因此顾问可以在与团队讨论后引入或重用实体。FDD必须包括更新的ER图；因此，如果结构发生任何变化，业务分析师或功能顾问需要更新FDD。下图显示了ER图的示例：
此ER图表示我们将主要用于HIMBAP汽车服务中心客户的开箱即用实体和自定义实体。正如您所看到的，我们将重用一些现有实体，并创建一些自定义实体。
Dynamics 365 CE实体设计
本节提供了有关实体及其关系的详细信息。这里提供了关于实体的不同类型的信息，如表单、视图、属性和关系详细信息，这有助于顾问自定义开箱即用的实体或基于此文档创建新的实体。
我们将为HIMBAP汽车服务中心使用以下实体：
客户
属性
详见底部附件
视图
我们将为我们的客户实体使用以下视图：
| 默认视图 | 更改为 | 排序 | 筛选条件 |
| 活动账户 | 活动账户 | 姓名 | 状态=活动 |
| 非互动账户 | 非互动账户 | 姓名 | 状态=非活动 |
| 帐户查找视图 | 客户查找视图 | 姓名 | 状态=活动 |
| 帐户关联视图 | 客户关联视图 | 姓名 | 状态=活动 |
| 帐户高级查找视图 | 客户高级查找视图 | 姓名 | 状态=活动 |
所有视图都将具有以下字段：
- 客户名称
- 客户号码
- 主要联系电话
- 地址1：城市
- 主要联系人
- 电子邮箱
| 主要实体 | 次要实体 | 行为类型 | 关联名称 | 查找字段名称 |
| 用户 | 客户 | 引用 |
him_systemuser_account_Manager
|
经理 |
重复检测规则
将在客户实体上启用以下重复检测规则：
- 具有相同帐户名称的帐户
联系人
我们将使用现有联系人实体来存储与客户关联的联系人。
联系人表单
我们将定制一个开箱即用的联系人表格，如下所示：
属性
详见底部附件
视图
我们将为我们的客户实体使用以下视图：
| 默认视图 | 更改为 | 排序 | 筛选条件 |
| 活动账户 | 活动账户 | 姓名 | 状态=活动 |
| 非互动账户 | 非互动账户 | 姓名 | 状态=非活动 |
| 帐户查找视图 | 客户查找视图 | 姓名 | 状态=活动 |
| 帐户关联视图 | 客户关联视图 | 姓名 | 状态=活动 |
| 帐户高级查找视图 | 客户高级查找视图 | 姓名 | 状态=活动 |
所有视图都将具有以下字段：
- 全称
- 客户名称
- 电子邮件
- 移动电话
汽车服务
如果我们要重用机会实体来存储服务信息，我们需要自定义机会实体表单，如以下示例所示：
属性
详见底部附件
视图
我们将为我们的汽车服务实体使用以下视图：
| 默认视图 | 更改为 | 排序 | 筛选条件 |
| 打开的机会 | 打开的机会 | 主题 | 状态=活动 |
| 已关闭的机会 | 已关闭的机会 | 主题 | 状态=非活动 |
| 机会查找视图 | 汽车服务查找视图 | 主题 | 状态=活动 |
| 机会关联视图 | 汽车服务关联视图 | 主题 | 状态=活动 |
| 机会高级查找视图 | 汽车服务高级查找视图 | 主题 | 状态=活动 |
所有视图都将具有以下字段：
- 车辆
- 主题
- 客户
- 联系人
- 服务日期
关系
在自动服务实体中设置以下自定义N:1关系：
| 主要实体 | 次要实体 | 行为类型 | 关联名称 | 查找字段名称 |
| 汽车 | 汽车服务 | 引用 |
him_vehicle_opportunity_Vehicle
|
汽车 |
汽车服务线
我们将重用机会产品实体来存储汽车服务行项目，并且我们将按原样使用此表单。
案例
我们将使用案例表单来存储汽车服务的服务支持信息。我们需要自定义案例实体表单，如以下屏幕截图所示：
属性：
详见底部附件
视图
我们将为我们的汽车服务实体使用以下视图：
| 默认视图 | 排序 | 筛选条件 |
| 活动的案例 | 案例标题 | 状态=活动 |
| 解决的案例 | 案例标题 | 状态=解决 |
| 案例查找视图 | 案例标题 | 状态=活动 |
| 案例关联视图 | 案例标题 | 状态=活动 |
| 案例高级查找视图 | 案例标题 | 状态=活动 |
- 案例标题
- 案例编号
- 客户
- 车辆
- 原因状态
- 创建日期
关系
在我们的自动案例实体中设置以下自定义N:1关系：
| 主要实体 | 次要实体 | 行为类型 | 关联名称 | 查找字段名称 |
| 车辆 | 案例 | 引用 |
him_vehicle_incident_Vehicle V
|
车辆 |
车辆
这是一个自定义实体，用于保存车辆信息，如车辆注册号、制造商、制造年份等。我们将使用以下实体形式的设计：
属性：
详见底部附件
视图：
将所有视图更改为具有以下列：
- 车辆编号
- 客户
- 制造
- 模型
- 年度
关系
在车辆实体中设置以下自定义N:1关系：
| 主要实体 | 次要实体 | 行为类型 | 关联名称 | 查找字段名称 |
| 客户 | 车辆 | 引用 |
him_account_him_vehicle
|
客户 |
| 模型 | 车辆 | 引用 |
him_model_him_vehicle
|
模型 |
| 制造商 | 车辆 | 引用 |
him_manufacturer_him_vehicle
|
制造 |
| 年度 | 车辆 | 引用 |
him_year_him_vehicle_Year
|
年度 |
制造商
这是一个自定义实体，用于保存与车辆相关的制造商信息。我们将使用以下实体形式的设计：
属性：
详见底部附件
模型
这是一个自定义实体，用于记录车辆的模型详细信息。我们将使用以下实体形式的设计：
属性：
详见底部附件
年度
这是一个用于年度详细信息的自定义实体。我们将使用默认形式，而不对此实体进行任何更改。除了用于存储年份名称的主字段之外，没有为该实体创建其他属性。
我们将按原样使用ER图上存在的所有其他开箱即用的实体，而不进行任何更改。
用户报告
本节包含有关所需记录的信息。Dynamics 365 CE有许多默认记录，这些记录可以按原样使用，也可以根据需要进行自定义。我们将在后面的章节中讨论有关报告选项的更多细节。
我们现在已经研究了如何在FDD中包含这些部分，这可以帮助技术团队设计应用程序。现在，我们将讨论TDD中常见的部分。
准备TDD
正如我们前面所讨论的，TDD为所提出的系统提供技术解决方案，其主要目标是提供需要完成的工作的技术细节。这些信息将呈现给项目团队成员。TDD包括如何针对业务需求实现解决方案的详细信息。与FDD类似，TDD的元素也可能因项目和需求而异，但TDD中需要一些常见的部分。让我们逐一讨论这些部分。
介绍
每个TDD都应该包含这一部分，因为引言提供了有关文档的一般细节。与FDD类似，介绍部分包括有关该项目的一些高级细节，如Dynamics365CE实施细节、需求和受众。我们不打算再讨论这一部分，但您可以参考FDD部分，了解有关设计文档介绍部分的更多详细信息。
拟定技术设计
在本节中，我们将提供该项目的技术设计细节，如拟议的系统服务器细节、基础架构和集成架构。让我们详细讨论这些部分。
基础架构
本节包含Dynamics 365 CE基础架构。如果客户端使用内部部署，这是非常必要的。在客户使用在线部署的情况下，无需提供这些详细信息，因为Dynamics 365 CE云实施不需要基础设施。Dynamics 365 CE本地部署可以在单个服务器上完成，也可以在多个服务器上完成。以下是中型组织内部部署Dynamics 365 CE的典型基础架构：
我们可以在上图中看到，身份验证可以使用Active Directory（AD）身份验证来实现，我们还可以使用Active DirectoryFederationServices（ADFS）服务器来实现面向互联网的部署（IFD）。我们可以根据需要使用不同的客户端来访问Dynamics 365。我们还可以将专用服务器用于其他事务，如应用程序、数据库、报告、SharePoint和电子邮件集成（如上图所示）。根据项目的要求和范围，本节应提供所有基础设施的详细信息。
解决方案架构
在本节中，我们将提供将为客户构建的解决方案体系结构的详细信息。该体系结构的主要目标是让所有项目团队成员了解拟议的系统。此解决方案体系结构应包括所有主要组件和集成细节。例如，以下是HIMBAP汽车服务中心的解决方案架构示例图：
在上图中，我们可以看到第一部分显示了我们的应用程序可以拥有的用户类型。他们可以使用不同的客户端访问Dynamics 365 CE应用程序，如web浏览器、Outlook、移动和平板电脑应用程序。将有一个身份验证层使用Azure Active Directory（Azure AD），就像我们使用在线部署一样。我们还将拥有Dynamics 365 CE安全模型，该模型将根据用户安全角色控制数据的可见性。应用程序层将包含用户界面（UI）组件和Dynamics 365配置。它还将包含具有自定义和扩展功能的业务实体，以及Dynamics365CE数据库。集成层包含集成逻辑，在我们的案例中，我们将使用Microsoft Flow进行集成。
用户
在本节中，我们可以根据客户要求提供用户详细信息。例如，不同类型的用户（如技术人员、支持用户、管理用户和业务用户）可以访问HIMBAP自动服务中心Dynamics 365 CE实施。这些用户将访问Dynamics 365 CE进行日常工作。
用户接口
在本节中，我们可以提供客户想要使用的所有可能的Dynamics 365 CE客户端的详细信息。例如，HIMBAP汽车服务中心的新系统将使用不同的客户端访问，如web浏览器、Outlook、移动和平板电脑客户端。当用户尝试使用这些选项访问Dynamics 365 CE时，将使用Azure AD对其进行身份验证。身份验证后，将应用Dynamics 365 CE安全模型，该模型允许用户仅访问其授权的区域。
他们只能访问具有所需权限的实体。
应用层
在本节中，我们可以提供将包含在应用程序层中的所有组件。例如，HIMBAP自动服务中心的解决方案将具有仪表板、报告、开箱即用的业务实体、自定义实体和其他系统配置，如审计、数据管理和电子邮件。实体的完整列表详见底部附件。
集成层
在这一层中，我们可以提供将为客户完成的所有集成的详细信息。例如，我们为HIMBAP汽车服务中心计划了一个Microsoft Flow集成解决方案，用于向车主发送短信通知。
集成架构
在本节中，我们将提供有关Dynamics 365 CE集成体系结构的更多详细信息，例如我们是否要将Dynamics 365 CE与任何其他Microsoft或非Microsoft产品集成。例如，在我们的案例中，我们将把Dynamics 365 CE与Microsoft Flow集成，以更新车主的车辆服务状态。
您可以在下图中看到示例：
当自动服务记录更新时，它将触发Microsoft Flow集成，并向客户发送短信通知。当我们讨论Dynamics365CE的集成选项时，我们将在后面的章节中进一步讨论这一点。
应用架构
在本节中，我们将提供有关Dynamics 365 CE应用程序体系结构的详细信息，以及可用于扩展Dynamics 365 CE功能的所有可能的扩展点。以下屏幕截图显示了Dynamics 365 CE的应用程序体系结构：
如前所述，我们可以使用不同的客户端访问Dynamics365CE应用程序。我们可以编写不同的客户端扩展，如JavaScript库、HTML web资源、自定义应用程序和SiteMap扩展。我们可以使用Dynamics 365 CE Web API和Web服务来集成内部部署和Azure应用程序。我们可以开箱即用地使用Web API和Web服务，也可以编写自己的扩展进行集成。
我们可以使用插件和自定义工作流编写不同的服务器端扩展，以扩展开箱即用工作流的功能。我们可以在Dynamics365CE中编写同步或异步插件，这些插件可以与自定义和系统业务实体交互。我们将在第7章扩展Dynamics365CE中更详细地讨论这些问题。
Dynamics365CE有两个数据库：配置数据库和组织数据库。配置数据库用于存储有关Dynamics 365 CE的配置信息，而组织数据库用于存储帐户、联系人等实体的客户数据。Dynamics 365 CE包含一种特殊类型的视图，称为筛选视图；我们使用这些为Dynamics365CE开发报告。筛选视图允许用户根据其安全角色访问数据。我们将在第9章“商业智能和报告”中更详细地讨论这些报告。如果我们在本地使用Dynamics365CE，则会创建两个SQL Server数据库；但如果我们使用Dynamics 365 CE Online，则Azure数据库将用于我们的Dynamics 365 CE订阅。
开发环境和发布策略
这是我们需要包含在TDD中的另一条关键信息。根据项目的复杂性，解决方案架构师提供开发环境设置的详细信息。简单的设置可以用于不太复杂的项目，其中一个或两个开发人员正在处理同一个开发实例和他们自己的实体集。稍后，这些更改可以在单元测试后推广到质量保证（QA）环境中。在这种方法中，开发人员在选择他们的实体时需要小心，以确保其他开发人员不会在同一个实体上工作。
另一方面，根据项目的复杂性，开发人员可以有多个开发实例。来自单个开发人员实例的所有更改都可以合并到一个主开发实例中，并从那里升级到QA或系统集成环境（SIT）环境。用于解决方案生命周期管理的Microsoft知识库（KB）可以用作设置开发环境的参考文档。
您可以从下载解决方案生命周期管理知识库：
Download Solution Lifecycle Management from Official Microsoft Download Center
为了保持HIMBAP汽车服务中心的实施，我们可以使用以下简单的开发环境方法：
开发人员可以在单个开发实例上工作，然后在单元测试后将解决方案发布到QA环境中。一旦QA和用户验收测试（UAT）完成，解决方案将发布到生产环境中。所有代码和自定义都将包含在开发解决方案中，并且可以作为非托管解决方案推广到所有环境中。我们将在第6章“自定义Dynamics365CE”中讨论非托管解决方案与托管解决方案。我们可以通过以下流程图来理解解决方案发布管理：
开发解决方案将包括所有组件，如实体、工作流和插件程序集（我们将在第6章“自定义Dynamics 365 CE”中详细讨论解决方案组件）。一旦开发结束，我们将导出非托管解决方案，并在源代码管理中检查解决方案以及我们的代码。导出的非托管解决方案将导入到目标环境中。如果导入成功，则可以将更改提交给源代码管理。如果不是，则可以修复任何解决方案问题，并重新启动部署过程。
数据迁移
如果企业希望将其历史数据引入Dynamics365CE，则TDD中应包含适当的数据迁移计划。我们将在第11章“迁移和升级”中讨论Dynamics 365 CE的数据迁移选项。
Dynamics 365 CE扩展
在本节中，我们需要提供Dynamics 365 CE所需扩展的详细信息。这些扩展可以使用自定义或通过编写客户端/服务器端代码来实现。我们可以为每个需要为客户开发的扩展提供部分，并提供屏幕的详细信息。
脚本
Dynamics365CE允许我们通过使用客户端脚本来实现自定义逻辑。我们使用JavaScript代码来实现我们的自定义逻辑——例如，添加表单字段验证，或从另一个实体获取数据。我们可以对实体窗体和字段事件执行自定义逻辑。我们将在第7章“扩展Dynamics365CE”中对此进行进一步讨论。
本节包括Dynamics 365 CE实现的所有脚本要求。
插件
插件是应用我们的自定义业务逻辑来扩展Dynamics365CE功能的另一种方式。我们可以编写.NET程序集，将其绑定到特定事件，以触发和运行在程序集中编写的自定义逻辑。我们将在第7章扩展Dynamics365CE中讨论更多有关Dynamics365 CE插件的内容。
在我们的文档中，我们应该包括Dynamics365CE实现的所有自定义插件要求。
工作流任务
在Dynamics365中，我们可以使用两个现成的选项来自动化Dynamics365CE任务：工作流和电源自动化。使用工作流可能非常有用，尤其是对于业务用户，并且编写工作流不需要任何技术知识。Dynamics 365 CE提供了一个开箱即用的工作流设计器，我们可以使用它根据我们的需求创建不同的工作流流程。工作流还与特定事件相关联，以触发其逻辑。同样，我们可以从Dynamics 365 CE创建Power Automate工作流。我们可以使用不同的连接器，并在一个Power Automate工作流中处理多个应用程序。我们将在第8章“将Dynamics 365 CE与其他应用程序集成”中讨论有关Dynamics 365 CE工作流和Power Automate功能的更多内容。
在我们文档的本节中，我们需要提供Dynamics 365 CE实施的所有可能的工作流程要求。
这些部分适用于每个Dynamics365CE实现，但根据项目的不同，我们可以提供更多详细信息。例如，如果我们要使用自动化的解决方案发布过程，那么它应该包含在本文档中。我们还可以包括一些关于QA测试过程的细节。
总结
在本章中，我们了解了FDD和TDD，以及为什么Dynamics365CE实现需要这些文档。我们还了解了FDD和TDD中可以包含哪些信息。
在下一章中，我们将讨论如何配置Dynamics365CE组织。