该文档对于描述需求以及有关新功能和变更请求的详细讨论很有用。广管局准备的文件有很多不同类型。下面列出了一些重要的内容-

• 业务需求文件（BRD）
• 用户故事
• 用例规范文档
• 功能需求文档（FRD）
• 需求追踪矩阵（RTM）
• 市场需求文件（MRD）
• 产品需求文件（PRD）

除这些之外，Business Analyst还创建了其他一些文档。它有助于理解业务流程和业务事件。业务事件是催生需求的触发器。然后，通过选择IT解决方案来满足这些要求。

这些文件可以用图解的形式描绘成一张简单的纸，其中包含一些有用的内容。

让我们看一下BRD和FRD之间的异同。

业务需求文件

• BRD强调了“业务需求”-即组织在IT的帮助下开发产品或解决方案的高层业务目标。
• 换句话说，它以很高的层次描述了软件的功能规格
• 正式文件，说明客户提供的要求
• 这些要求可以通过口头或书面或两种方式收集
• 通常由与客户互动的业务分析师创建
• 整个工作在项目经理的监督下执行
• 它源于客户的互动和需求

BRD非常重要，因为它是所有后续项目可交付成果的基础，描述了与每个流程功能相关的输入和输出。它从业务角度描述了系统的外观。以下是BRD最常见的目标-

• 与利益相关者达成共识
• 为项目的下一阶段提供意见
• 解释解决方案如何满足客户/业务需求
• 在策略的帮助下全面满足业务需求的方法将为客户提供一些价值

基本上，利益相关者的要求可以大可小。因此，无论何时何地都需要打破它，并应将其视为多重要求。

BRD格式-

组织遵循许多格式或模板。但是，这取决于组织中采用的实践。对于基于产品的公司，BRD格式与基于服务的公司相比是不同的。大多数组织遵循的标准格式如下所示。重要的是要注意，为了清楚地理解文档，我们应包括使用的首字母缩写词列表。

BRD模板包含-

• 文件修订
• 批准
• RACI图
• 介绍
• 商业目标
• 商业目标
• 商业规则
• 背景
• 项目目标
• 项目范围
• 范围内功能
• 范围外的功能
• 假设
• 约束
• 风险
• 业务流程概述（例如，建模图，用例和活动图）
• 遗留系统
• 建议的建议
• 业务需求
• 附录
• 缩写列表
• 专业术语
• 相关文件

现在，让我们尝试进一步探索FRD。

功能需求文件

• FRD着重强调了“功能要求”，即软件的功能
• 根据产品的不同，FRD文档可能在10到100页之间
• 它也高层描述了软件的功能和技术规范
• 通常由业务分析师在技术专家的监督下创建，例如系统架构师
• 在中小型组织中，文学学士学位负责这一工作
• 很少有公司没有创建FRD，而是使用BRD，因为它足够详细，也可以用作FRD。
• FRD来自BRD

实际上，达到BRD预期的过程是FRD本身。在与利益相关者和项目经理讨论后，分析师在思考以下问题：

• 我们如何制定预期要求？
• 有哪些特征和功能？
• 使用了哪些工具和/或系统以及它们之间的依赖关系？
• 客户开始使用该解决方案时会如何反应？
• 有任何假设或约束吗？

FRD最常见的目标-

• 为每个活动描绘每个流程流的相互依存关系
• 全面了解每个需求，构建步骤
• 估算每个新变更请求的详细风险
• 如果项目运行状况较弱，请突出​​显示后果，以避免范围蔓延

FRD应该记录系统必须能够执行的操作和活动。

FRD的格式-

与BRD类似，FRD的格式略有不同，更多地关注风险和接口。尽管没有业务分析师应该选择的标准格式。属于不同域的公司使用其自己的模板。例如，您会发现许多点会像在BRD中一样重复。

但是，广管局准备这份文件不应有任何困惑。

FRD模板包含-

• 简介-应包含目的，范围，背景，参考，假设和限制，文档概述
• 方法
• 功能要求
• 建模插图-上下文，用户需求，数据流程图，逻辑数据模型/数据字典，功能需求
• 其他要求-接口要求，硬件/软件要求，
• 词汇表

现在，在组织中使用BRD或FRD取决于组织政策，项目团队和利益相关者遵循的实践。就像在我的组织中一样，希望从瀑布到敏捷的所有项目。如果利益相关者对文件持肯定态度，那么BA将设计相同的文件。但是，如果需要持续交付工作产品，那么文档将不是首选。

但是，在不久的将来，文档仍将是任何项目的有效伪像。