功能需求文档


功能需求文档 (FRD) 是应用程序功能需求的正式声明。它与合同具有相同的目的。在此,开发人员同意提供指定的功能。如果产品提供了 FRD 中指定的功能,客户同意对产品感到满意。

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

功能需求文件(FRD)具有以下特点 -

  • 它表明该应用程序在未来几年的业务目标和业务流程方面提供了价值。

  • 它包含一整套应用程序的要求。它没有给任何人留下任何空间来假设 FRD 中未规定的任何内容。

  • 它是独立于解决方案的。ERD 是应用程序要做什么的声明,而不是它如何工作的声明。FRD 不向开发人员承诺设计。因此,在 FRD 中任何提及特定技术的使用都是完全不合适的。

功能要求应包括以下内容 -

  • 要输入系统的数据的描述

  • 各画面的操作说明

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

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

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

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

该功能规范旨在供普通读者阅读。读者应该了解该系统,但不需要任何技术知识即可理解本文档。

功能需求交付成果

业务需求文件(BRD)包括 -

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

  • 业务流程模型- 流程当前状态的模型(“原样”模型)或流程应成为什么的概念(“成为”模型)

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

  • 流程图(按现状或未来) - 图表以图形方式描述业务流程的操作顺序或数据移动。根据模型的复杂程度,包含一个或多个流程图。

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

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

  • 概念模型- 业务功能的不同实体的高级显示以及它们如何相互关联。

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

  • 数据字典和术语表- 有关构成数据库或类似数据管理系统底层数据模型的数据元素、字段、表和其他实体的详细信息的集合。

  • 利益相关者地图- 识别受拟议变更影响的所有利益相关者及其对需求的影响/权限级别。该文件是在项目管理方法 (PMM) 的初始阶段开发的,由项目经理拥有,但需要由项目团队更新,因为在整个过程中确定了新的/变更的利益相关者。

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