文档功能要求和项目
当您收集要求时，它们通常称为功能要求或非功能要求。 功能要求描述解决方案需要做什么或其行为，而非功能要求通常用于描述解决方案的非行为方面，例如性能要求。 在本课程中，我们将介绍功能要求的一些要考虑事项。
每个功能要求都应该明确捕获要求的人员、内容和原因。 如果要求太大，应将其细分为较小的部分。
功能要求
下面是功能要求的一些简单示例：
- 作为一名销售，我需要能够将商机作为丢单结束，然后了解丢单的原因，以便我们可以在将来改进销售策略。
- 作为一名销售经理，我需要能够审核报价单上的折扣，以便我可以降低总价并向客户提供一个折扣。
- 作为一名会计师，我希望无法关闭具有待定项的批处理，这样我就不必在以后重新打开它。
这些示例传达了人员、内容和原因。
下面是一些措辞不当的要求示例：
- 商机可以赢单，也可以丢单。
- 价格应反映折扣。
- 从批处理项列表中，单击“关闭批处理”按钮（从左边数第三个按钮）应该会关闭批处理，前提是没有阻止批处理发生的项目。
当收集各种各样的要求时，向流程或用户旅程映射而不是仅列出特性和功能将非常有用。 为用户生成一个案例并描述用户将如何成功使用您正在设计的系统。 您可以在白板上涂鸦，使用工具绘制流程图，在您所处的设计阶段使用适用于您的团队的任何方法。 您的团队稍后会将这些片段分解成更小的可操作项。
验收条件
清楚了解如何满足要求很重要。 通常，记录本要求有助于确定要求是否足够详细，大小是否合适。 在测试团队评估要求的实现情况时，本文档也很有用。 最后，应与利益干系人一起审查它，以确保其准确性，因为它可用于帮助防止范围蔓延。 查找无法满足的验收条件，然后通过协商达成可实现的折衷方案很重要。
捕获异常
通常，简单要求（例如关闭交易）可能有一个简单路径，并且只有几个异常路径。 在捕获正常路径时，查找和标识这些异常很重要。 在进入设计阶段时，您不想主要针对异常进行设计。 应该这样处理它们，但如果您不知道它们存在，则必须在以后重现。 此外，在理想情况下，请记住捕获异常发生的频率，因为某些异常最好通过过程和/或流程（而不是软件自定义）来处理。
避免范围蔓延
如果未选中，每个项目都将根据设想和预算增加范围。 项目治理流程应该用于评估在标识后如何处理它们。 通常，接受以便包含这些要求可能会导致顺序发生更改，具体取决于项目的合同结构。 只需忽略范围正在增加很容易导致项目失败。
国际化
Microsoft Power Platform 为制作者提供许多用于使应用实现国际化的选项。 模型驱动应用和门户应用都附带国际化选项，包括语言包和多货币。 准确记录这些要求对于用户采用至关重要。 记录国际化应以要求开头，并包含在质量保证测试计划、用户采用测试和系统文档中。 确保遵循此处列出的最佳做法，还可出于国际化需求记录可操作、可测试的要求。
解决方案项目
为解决方案组件提供逻辑名称被认为是一种最佳做法，在准备此类逻辑名称的文档时，您肯定会看到其价值。 每个项目的这些项目文档之间都略有不同。
本文档的目标应该是确保解决方案随着时间的推移而不断发展，以及让项目团队随时了解情况。 当您参与一组制作者团队并且每个团队成员正在处理一组不同的功能时，这尤其有用。 如果有可预测的名称以及名称和预期行为的一致文档，则记录重要事项将更加容易。
项目计划项目（例如用户案例或积压工作项）可以是帮助快速启动文档的良好资源。 尽管等到项目完成后再编写本文档可能很诱人，但如果至少完成了每个项目里程碑，它将是一个更有帮助的持续资源。 在不一致和错误成为更大的问题之前，您将能够注意到它们并进行纠正。
在记录表（在模型驱动应用中或使用 Dataverse 数据源）时，请考虑包括表描述（例如其预期用途）。 包括每个表中的列及其数据类型和描述。 记录表与已定义行为（例如行删除行为）之间的关系。 还应包括安全角色和列级别安全性的任何注意事项。 记录视图及其查询；窗体及其目标受众/用途；报告和仪表板。
自动化包括业务流程流、Power Automate 流、业务规则和经典工作流。 您不仅应记录其中每个单独的自动化，还应记录它们的协作方式。 还可以在此处记录使用的连接器及其要求。
要记录的画布应用组件包括特定屏幕及其导航、使用的数据源、规则和自动化触发器。 Power Apps 门户具有与画布应用相似的文档需求，但也将区分经过身份验证的用户和匿名用户。
在记录 Power Virtual Agents 时，包括主题级别对话流、目标数据源和呈报计划。
除了特定的技术详细信息，您可能会发现写入用户旅程的叙述很有用。 这不仅仅是“用户单击此处”，更是一种整体的预期体验。 将其视为该用户与解决方案的日常交互的案例。 考虑到本文档的受众，请注意一些注意事项，例如文档中的辅助功能以及提供文字和图形说明。 本文档对于新团队成员入职、创建用户验收条件以及在完成时将项目交接给客户很有帮助。
记录用于迁移和集成的数据
很少在开始一个项目时不考虑遗留问题。 用户具有的应用效率低下，他们使用的都是已了解的业务数据。 根据确切情况，您可以连接数据或迁移数据。 其中任一路径都需要计划和文档。
无论迁移还是集成，数据的质量都非常重要。 数据是否准确？ 是否有不再相关的旧数据？ 是否有要缓解的重复项？ 在迁移之前，我们能否消除重复项？
创建清单（并遵循该清单）将有助于最大限度地降低将旧数据引入新解决方案的影响。
记录数据源：标识数据源和使用的连接。 标识源数据的质量。 标识要迁移的列，请记住，并非所有源数据都将进入新系统。
记录数据类型：将源数据与目标架构进行比较。 标识在开始数据移动之前的潜在转换问题。
记录数据映射：对进入系统的数据完成逐列审查，确认它已正确映射。 协调源和目标数据列元数据中的差异。
记录错误处理：制定计划以纠正导入或集成时的错误。
容纳离群值：并非所有内容都将是数据从源到新环境的精确一对一映射。 标识这些离群值并制定计划。
记录数据质量的持续评估：审查、报告和修复数据质量。