功能需求文档

功能需求文档 (FRD) 是应用程序功能需求的正式声明。它的作用与合同相同。在这里，开发人员同意提供指定的各项功能。如果产品提供了 FRD 中指定的各项功能，则客户同意认为产品令人满意。

功能需求捕获了系统的预期行为。此行为可以表示为系统需要执行的服务、任务或功能。该文档应根据特定项目的需要进行调整。它们定义了诸如系统计算、数据操作和处理、用户界面以及与应用程序的交互等内容。

功能需求文档 (FRD) 具有以下特征：

• 它证明了应用程序在未来几年内能够根据业务目标和业务流程提供价值。

• 它包含了应用程序的一整套需求。它不留任何空间让人假设 FRD 中未陈述的任何内容。

• 它是与解决方案无关的。ERD 是关于应用程序要做什么的声明，而不是关于它是如何工作的声明。FRD 不会将开发人员绑定到某个设计。因此，在 FRD 中引用任何特定技术的用法都是完全不合适的。

功能需求应包括以下内容：

• 输入系统的数据的描述

• 每个屏幕执行的操作的描述

• 系统执行的工作流程的描述

• 系统报表或其他输出的描述

• 谁可以将数据输入系统？

• 系统如何满足适用的监管要求？

功能规格旨在供一般受众阅读。读者应该理解系统，但不需要任何技术知识就能理解此文档。

功能需求交付成果

业务需求文档 (BRD) 包括：

• 功能需求 - 包含正在开发的系统的详细需求的文档。这些需求定义了系统必须具备的功能特性和能力。确保在业务案例中确定的任何假设和约束仍然准确并已更新。

• 业务流程模型 - 当前流程状态的模型（“现状”模型）或流程应如何发展的概念（“目标”模型）

• 系统上下文图 - 上下文图显示了系统边界、与系统交互的外部和内部实体以及这些外部和内部实体之间相关的数据流。

• 流程图（现状或目标） - 图表以图形方式描述业务流程的操作序列或数据移动。根据模型的复杂性，包含一个或多个流程图。

• 业务规则和数据需求 - 业务规则定义或约束业务的某些方面，并用于定义数据约束、默认值、值范围、基数、数据类型、计算、异常、必需元素和数据的关系完整性。

• 数据模型 - 实体关系图、实体描述、类图

• 概念模型 - 业务功能的不同实体及其相互关系的高级显示。

• 逻辑模型 - 说明业务功能中涉及的特定实体、属性和关系，并表示业务、技术或概念环境中所有数据的定义、特征和关系。

• 数据字典和词汇表 - 关于构成数据库或类似数据管理系统基础的数据模型中的数据元素、字段、表和其他实体的详细信息的集合。

• 利益相关者地图 - 确定所有受拟议变更影响的利益相关者及其对需求的影响/权限级别。此文档在项目管理方法 (PMM) 的起源阶段开发，由项目经理拥有，但需要在整个过程中由项目团队更新，以识别新的/更改的利益相关者。

• 需求可追溯性矩阵 - 一个表格，说明各个功能需求与其他类型的系统工件之间的逻辑链接，包括其他功能需求、用例/用户故事、架构和设计元素、代码模块、测试用例和业务规则。