业务需求文档（BRD）模板
这个免费的业务需求文档模板为您提供分为两部分的结构化 BRD：一份 BRD 概览 ，用于目标、范围、相关方和签核；以及一份 需求日志 ，其中每项需求都有 ID、类型、理由、MoSCoW 优先级、来源、验收标准和状态。可下载 Google Sheets、Excel 或 PDF 版本，有初级、高级和专家版本。
要点总结
- 业务需求文档（BRD）记录业务需要从项目中获得什么、为什么需要，以及如何判断每项需求已得到满足。它描述的是需求，而不是解决方案。
- 模板包含两个选项卡：十个部分的 BRD 概述，以及包含八列并带类型、优先级和状态下拉列表的需求日志。
- 好的需求不涉及具体解决方案、可检验、每行一条，并可追溯到业务目标和来源。
- 使用 MoSCoW 进行优先级排序并严格执行：如果一切都是“必须有”，那就等于什么都不是。
- 在设计或采购开始之前取得签核，然后通过变更请求流程控制变更。
免费下载 · 无需注册
获取业务需求文档模板
选择适合您的级别和格式：Google Sheets、Excel 或可直接打印的 PDF。电子表格包含下拉菜单、公式以及可直接覆盖的示例行。
什么是业务需求文档？
A 业务需求文档（BRD） 是一份阐明企业需要从项目或解决方案中获得什么、为什么需要以及如何衡量成功的文档。它涵盖目标、范围、相关方、约束条件以及一份附有验收标准的优先级需求清单。它描述的是需要 什么 ，而不是 如何 构建。
BRD 通常在项目早期编写，即在想法通过以下文档获得批准之后： 商业论证 或 项目章程 ，并在设计、开发或采购开始之前。它为构建或采购解决方案的人员提供一个清晰、商定的目标，并为发起人在最后验收成果提供依据。
BRD 通常由业务分析师编写，但在较小的项目中，常由项目经理或产品负责人编写。无论由谁编写，内容都来自相关方：BRD 是对他们需求的记录，经过核实并达成一致。
关于高层级和详细需求的全面介绍，请参阅我们的 项目需求指南.
BRD 模板预览
第一个选项卡是 BRD 概述。每个部分在“指导”列中都有简短提示；您的回答填写在“您的内容”列中。
| 章节 | 填写指引 | 您的内容 |
|---|---|---|
| 项目名称和负责人 | ||
| 执行摘要 | 需求和拟实现成果的简要说明。 | |
| 业务目标 | 项目所支持的可衡量目标。 | |
| 背景 / 现状 | 当前的运作方式及存在的问题。 | |
| 范围 | 范围内和范围外的内容。 | |
| 相关方 | 受影响的人员和审批人。 |
示例行仅供参考：请替换为您自己的内容。
BRD 模板包含哪些内容
模板是一个包含两个相互配合的选项卡的电子表格。 BRD 概览 用十个简短部分设定背景； 需求 选项卡则在一份结构化、可筛选的日志中列出每项需求。
- BRD 概览：章节、填写指引、您的内容
- 需求：ID、需求、类型、理由、优先级（MoSCoW）、来源、验收标准、状态
“BRD 概述”选项卡
三列（章节, 填写指引, 您的内容）和十个部分：项目名称和负责人、执行摘要、业务目标、背景 / 现状、范围、相关方、假设和约束、需求（指向“需求”选项卡）、成功衡量标准以及签核。
“需求”选项卡
八列： ID, 需求, 类型, 理由, 优先级（MoSCoW）, 来源, 验收标准 和 状态。在高级版和专家版中，有三列带下拉列表：
- 类型： 功能、非功能、约束、数据、报表。
- 优先级（MoSCoW）： 必须有、应该有、可以有、这次不会有。
- 状态： 草稿、评审中、已批准、已拒绝、已推迟。
客户门户项目的四项示例需求展示了如何填写各列；请用您自己的内容覆盖。
应该下载哪个版本？
| 版本 | 包含内容 | 最适合 |
|---|---|---|
| 入门 | 仅“BRD 概述”选项卡：十个带指导的部分，外加空白行 | 需求用几段文字即可说清的小型项目 |
| 高级 | 两个选项卡：BRD 概述以及完整的八列需求日志，带类型、优先级（MoSCoW）和状态下拉列表 | 有业务分析师或多个相关方群体的大多数项目 |
| 专家 | 包含高级版的全部内容，外加使用说明选项卡、自动按类型、MoSCoW 优先级和状态统计需求数量的仪表板、按颜色区分的状态（已批准、评审中、已拒绝）以及修订历史选项卡 | 需要报告需求进展的大型项目、采购项目和 PMO |
业务需求文档应包含哪些内容
十个概述部分为读者提供了在阅读需求本身之前所需的背景。以下是每个部分应写的内容。
| 章节 | 应写的内容 | 示例 |
|---|---|---|
| 项目名称和负责人 | 项目以及对需求负责的业务负责人 | 客户门户；客户服务主管 |
| 执行摘要 | 用几句话说明需求和预期成果。最后再写 | 客户无法自行查看发票或重置密码，因此会致电支持团队。自助门户将减少来电。 |
| 业务目标 | 项目所支持的可衡量目标 | 在上线后 6 个月内将账户相关来电减少 30% |
| 背景 / 现状 | 目前的运作方式及存在的问题 | 所有账户变更都通过电话或电子邮件由支持团队处理 |
| 范围 | 哪些在范围内，哪些在范围外 | 范围内：账户查看、发票、密码重置。范围外：移动应用、支付 |
| 相关方 | 谁受到影响，谁负责审批 | 客户服务部、IT 部、财务部、法务部、客户 |
| 假设和约束 | 您的假设以及必须遵守的限制 | 计费 API 在 2 月前可用；数据必须留在欧盟境内 |
| 需求 | 指向“需求”选项卡 | 参见“需求”选项卡（BR-01 至 BR-04） |
| 成功衡量标准 | 交付后如何评判成功 | 来电量、门户采用率、客户满意度 |
| 签核 | 审批人的姓名、职务和日期 | 发起人、IT 主管、数据保护官 |
许多公开的 BRD 格式还包含 成本效益分析。如果您的项目已有商业论证，请链接到它而不是重复数字；BRD 应专注于需求。如需了解方法，我们关于 成本效益分析 的指南对此进行了解释。
如何写好业务需求
需求日志是 BRD 的核心。一项好的需求应该是：
- 必要的： 它支持某个业务目标。如果您说不出是哪个目标，就对它提出质疑。
- 不涉及解决方案： 它说明需要什么，而不是如何构建。“客户必须能够在不联系支持团队的情况下重置密码”为设计留下了空间。
- 清晰： 只有一种合理的理解。避免使用“用户友好”“快速”或“灵活”之类没有衡量标准的词语。
- 可检验： 有人能够检查它是否已满足。这正是验收标准列的作用。
- 单一： 每行一项需求。将任何用“和”连接的内容拆分开。
- 可追溯： 它有 ID、来源（人员、文档、法规或数据）和理由。
| 薄弱的需求 | 更好的需求 | 为什么更好 |
|---|---|---|
| 门户应该很快 | 页面加载时间必须低于 2 秒（第 95 百分位） | 可衡量且可检验 |
| 使用通过 CRM 发送的密码重置链接 | 客户必须能够在不联系支持团队的情况下重置密码 | 说明的是需求，而不是解决方案 |
| 客户可以查看发票并更新地址 | 分为两行：一行用于查看发票，一行用于更新地址 | 每行一项需求，以便各自排定优先级和进行测试 |
| 遵守数据规则 | 客户数据必须存储在欧盟境内 | 具体，且来源明确（法务 / GDPR 政策） |
需求类型
模板的“类型”下拉列表让日志易于筛选： 功能性 （解决方案必须做什么）、 非功能性 （必须做到什么程度，例如性能、可用性、安全性或易用性）、 制约因素 （法规、技术或预算等限制）、 数据 和 报告.
如果您的组织遵循 IIBA 的《BABOK 指南》，您会看到更宽泛的分类：业务需求（目标和成果）、相关方需求（特定群体的需要）、解决方案需求（分为功能和非功能需求）以及过渡需求（从当前状态过渡到未来状态所需的内容，例如数据迁移或培训）。您可以将这些作为额外选项添加到“类型”列表中。
使用 MoSCoW 进行优先级排序
MoSCoW 将需求分为四组，模板的“优先级”列使用的就是这四组：
| 优先级 | 含义 | 测试 |
|---|---|---|
| 必须有 | 没有它，解决方案就会失败，或不合法、不安全 | 如果缺少这一项，您会取消上线吗？ |
| 应该有 | 重要，但有变通办法 | 舍弃会很痛苦，但解决方案仍然可用 |
| 可以有 | 如果时间和预算允许则最好有 | 锦上添花；压力之下最先被砍掉 |
| 这次不会有 | 已商定目前不在范围内 | 记录下来，使决定可见 |
常见的错误是几乎把所有需求都标记为“必须有”。对每一项都问一问“您会取消上线吗？”。记录“这次不会有”的条目同样有用：它能防止同样的请求每个月都卷土重来。
编写验收标准
验收标准描述您将如何确认需求已得到满足。保持具体且可观察：“2 分钟内完成重置”“可查看自 2024 年以来的所有发票”“托管区域确认为欧盟”。它们是测试以及发起人在项目结束时验收的依据，也自然地与您的 质量管理 方法相衔接。
如何逐步填写 BRD 模板
- 从章程或商业论证开始。 复制目标和范围，使 BRD 与已批准的内容保持一致。
- 识别相关方。 列出所有使用、运营、出资或监管该解决方案的人。我们关于 相关方管理 的指南展示了如何分析他们。
- 描述现状。 记录目前的运作方式以及出现的问题。来电数据或调查结果等证据会有所帮助。
- 收集需求。 使用访谈、研讨会、观察、文档审查和数据。随时记下每项需求的来源；研讨会的 会议纪要 是很有用的记录。
- 每项需求单独写一行。 为其分配 ID，写出清晰的陈述、类型以及与某个目标相关联的理由。
- 排定优先级并添加验收标准。 与业务负责人商定 MoSCoW 优先级，并为每项需求编写一项测试。
- 与相关方一起评审。 逐项过一遍日志，解决冲突，并将状态从“草稿”更新为“评审中”再到“已批准”。
- 取得签核并建立基准。 请指定的审批人在概述上签字。从那时起，变更需经过 变更控制 ，使用 变更请求.
业务需求文档示例
模板的示例行描述了一个客户门户项目。以下是随模板提供的需求日志，并说明了每一行为何这样写。
| ID | 需求 | 类型 | 优先级 | 验收标准 | 状态 |
|---|---|---|---|---|---|
| BR-01 | 客户必须能够在不联系支持团队的情况下重置密码 | 功能性 | 必须有 | 2 分钟内完成重置 | 已批准 |
| BR-02 | 门户必须显示最近 24 个月的发票 | 功能性 | 必须有 | 可查看自 2024 年以来的所有发票 | 已批准 |
| BR-03 | 页面加载时间必须低于 2 秒 | 非功能性 | 应该有 | 第 95 百分位低于 2 秒 | 初稿 |
| BR-04 | 数据必须存储在欧盟境内 | 制约因素 | 必须有 | 托管区域已确认 | 已批准 |
- BR-01 来自支持数据，直接服务于减少来电的目标，因此是“必须有”。
- BR-02 来自客户调查，并有明确的边界（24 个月），避免了无止境的数据迁移。
- BR-03 是来自用户体验研究的非功能需求。它仍是“草稿”，因为 2 秒的目标尚未与 IT 部门达成一致。
- BR-04 是法务部门基于 GDPR 政策提出的约束。它是“必须有”，因为没有它解决方案就无法上线。
每一行都可追溯到一个目标（减少来电）、一个来源和一个理由。正是这种可追溯性，让您在六个月后仍能回答“我们为什么要构建这个？”，并在时间紧张时先舍弃正确的需求。
BRD 与 FRD、SRS、PRD 和用户故事的比较
各种需求文档相互重叠，各组织的叫法也不尽相同。下表显示了通常的区别。
| 文档 | 关注点 | 典型作者 | 主要读者 |
|---|---|---|---|
| 业务需求文档（BRD） | 业务需要什么以及为什么；目标、范围、高层级需求 | 业务分析师 | 发起人、业务相关方、交付团队 |
| 功能需求文档（FRD）/ 功能规格说明 | 解决方案将如何运作以满足业务需求 | 业务分析师或系统分析师 | 设计人员、开发人员、测试人员 |
| 软件需求规格说明（SRS） | 软件系统的详细功能和非功能需求 | 系统分析师或架构师 | 开发人员、测试人员、供应商 |
| 产品需求文档（PRD） | 产品或某次发布应为用户做什么，通常逐个功能描述 | 产品经理 | 产品、设计和工程团队 |
| 用户故事 | 以用户为中心的小块功能，附有验收标准 | 产品负责人与团队共同制定 | Scrum 或敏捷团队 |
| 工作说明书（SOW） | 供应商将交付什么，按什么条款 | 买方，通常与采购部门一起 | 供应商 |
当解决方案需要采购而非自建时，BRD 通常会作为以下文件的输入： RFQ 或 工作说明书 ；在每个项目中，它还会作为以下文件的输入： 项目范围说明书 。
在敏捷项目中使用 BRD
敏捷团队很少在前期编写冗长的 BRD，但其背后的思路仍然有用。一份记录目标、范围边界、约束和主要业务需求的简短 BRD，能为 产品负责人 和团队提供共同的目标。
随后，细节进入 产品待办事项列表 ，以 用户故事的形式呈现，每一项都可追溯到某个业务需求 ID。非功能需求和约束通常会成为团队的 完成的定义的一部分。模板的初级版（仅包含概述选项卡）通常就足够了；可与我们的以下模板配合使用： 用户故事模板 或 产品待办事项列表模板.
BRD 的常见错误
- 设计解决方案。 界面布局和技术选择属于设计范畴，而不是 BRD。
- 措辞含糊。 “简单”“快速”和“安全”需要有衡量标准，否则无法检验。
- 一切都是“必须有”。 没有真正的优先级，团队在时间紧张时就无法做出取舍。
- 遗漏相关方。 来自法务、财务、安全或运营团队的需求常常很晚才浮现，导致返工。
- 没有来源或理由。 无人能够解释的需求难以辩护，也容易被过度加码。
- 跳过签核。 未经批准，BRD 就只是草稿，范围也一直悬而未决。参见 范围蔓延.
- 视其为永久不变。 需求会变化。为已批准的 BRD 建立基准，并公开管理变更，而不是悄悄修改。
相关模板和指南
BRD 位于一系列文档之中。在它之前是 商业论证模板 和 项目章程模板；与之并行的 问题陈述模板 和 差距分析模板 用于界定需求；在它之后， 项目范围模板, 用户故事模板 和 变更请求模板 将需求带入交付。一份 RACI 矩阵模板 帮助您商定由谁编写、评审和批准这些文档。
项目范围说明书模板免费项目范围模板：目标、可交付成果、范围内、范围外、验收…入门 · 进阶 · 专家
用户故事模板免费用户故事模板：作为/我想要/以便、验收标准、史诗、估算…入门 · 进阶 · 专家
差距分析模板免费差距分析模板，比较当前状态和未来状态，为每个差距打分并…入门 · 进阶 · 专家
问题陈述模板免费问题陈述模板：受影响者、问题内容、地点和时间、影响、证据…入门 · 进阶 · 专家
根本原因分析（5 个为什么）模板采用 5 个为什么法的免费根本原因分析模板：问题陈述、追问链、根本…入门 · 进阶 · 专家要了解高层级需求和详细需求如何配合，请阅读我们的 项目需求指南.
常见问题
什么是业务需求文档模板？
业务需求文档模板是一个现成的结构，用于记录项目的业务目标、范围、相关方、约束和需求，每项需求都附有优先级和验收标准。本模板包含一个 BRD 概述选项卡和一份需求日志。
这个 BRD 模板免费吗？
是的。业务需求文档模板可免费下载 Google Sheets、Excel 和 PDF 格式，无需注册。
业务需求文档应包含哪些内容？
执行摘要、业务目标、背景和现状、范围、相关方、假设和约束、带有优先级和验收标准的需求本身、成功衡量标准以及签核。
由谁编写业务需求文档？
通常由业务分析师与相关方、发起人和项目经理合作编写。在较小的项目中，常由项目经理或产品负责人编写。
由谁批准 BRD？
由发起人或业务负责人批准，通常还包括主要相关方群体的负责人，以及其需求被纳入文档的专业人员（如法务或安全部门）。
BRD 和 FRD 有什么区别？
BRD 说明业务需要什么以及为什么。功能需求文档（FRD）则描述解决方案将如何运作以满足这些需求，其详细程度足以供设计人员、开发人员和测试人员使用。
业务需求有哪些类型？
本模板使用功能、非功能、约束、数据和报表五类。IIBA 的《BABOK 指南》将需求分为业务需求、相关方需求、解决方案需求（功能和非功能）以及过渡需求。
BRD 应该写多长？
在保持清晰的前提下尽可能简短。小型项目可能只需要几页；大型系统或采购项目可能需要多得多。将背景放在概述中，将每项需求单独写在日志的一行中。
应在何时编写 BRD？
在项目通过商业论证或章程获得原则性批准之后，并在设计、开发或采购开始之前。
如何对业务需求进行优先级排序？
使用 MoSCoW：必须有、应该有、可以有和这次不会有。与业务负责人商定优先级，并对每项“必须有”进行检验：没有它您是否会取消上线？
敏捷团队可以使用业务需求文档吗？
可以，在高层级使用。用简短的 BRD 记录目标、范围、约束和关键业务需求，然后在产品待办事项列表中以用户故事的形式记录细节。
签核后需求发生变化怎么办？
提出变更请求，评估其对范围、进度和成本的影响，并在更新 BRD 之前获得批准。记录变更及其决定，使基准保持清晰。
我可以在 Word 中使用 BRD 模板吗？
下载文件为电子表格和 PDF。如果您的组织更喜欢 Word，可以将概述部分复制到 Word 文档中，而将需求日志保留在电子表格中，以便于筛选和排序。