BRD Creation

BRD 编写技能

目的

此技能可帮助 AI 助手创建全面、专业的业务需求文档（BRD），向利益相关者和开发团队清晰传达业务需求、目标和高层级要求。

何时使用此技能

• 完成需求收集后
• 启动新项目或重大计划时
• 寻求高管审批和资金支持时
• 确定项目范围和边界时
• 创建详细的 FRS 文档之前

什么是 BRD？

**业务需求文档（BRD）**是一份正式文档，用于：

• 描述业务问题或机会
• 定义业务目标和成功标准
• 概述高层级业务需求
• 确定项目范围（范围内和范围外）
• 识别利益相关者及其需求
• 记录假设、约束和依赖关系

BRD 与 FRS 的区别：

• BRD：业务需要什么以及为什么需要（业务视角）
• FRS：系统将如何满足这些需求（技术视角）

BRD 结构

1. 执行摘要

目的：为繁忙的高管提供简明概述

内容：

• 项目名称和简要描述
• 业务问题或机会（2-3 句话）
• 拟议解决方案概述（2-3 句话）
• 预期业务收益
• 高层级时间线和预算
• 关键成功指标

长度：最多 1 页

写作技巧：

• 最后撰写本节（完成 BRD 其余部分后）
• 使用业务语言，避免技术术语
• 聚焦业务价值和 ROI
• 让内容引人注目——高管可能只会阅读这一部分

示例：

项目：开发客户自助服务移动应用

业务问题：客户目前必须致电我们的支持中心，咨询账户、跟踪订单和办理退货，导致每月有 15,000 多通支持电话，年度支持成本高达 $450K。客户对支持服务的满意度评分为 3.2/5。

拟议解决方案：开发一款移动应用（iOS 和 Android），让客户能够自行处理常见咨询、实时跟踪订单，并在无需客服人员协助的情况下发起退货。

预期收益：将支持电话量减少 60%（每月减少 9,000 通），每年节省 $270K 的支持成本，将客户满意度提升至 4.5/5，并将客户留存率提高 15%。

投资：开发成本 $180K，周期 4 个月

ROI：8 个月内收回成本，2 年内节省 $540K

---

2. 业务目标

目的：明确业务希望实现的目标

内容：

• 主要业务目标
• 次要目标
• 与公司战略的契合度
• 成功标准（可衡量）

格式：使用 SMART 标准（具体、可衡量、可实现、相关且有时限）

示例：

主要目标：在移动应用发布后的 6 个月内将客户支持成本降低 60%

次要目标：

1. 在应用发布后的 3 个月内，将客户满意度评分从 3.2 提高到 4.5
2. 在 12 个月内将客户留存率提高 15%
3. 提供全天候客户自助服务能力

战略契合度：支持公司的数字化转型计划和以客户为先的战略

成功标准：

• 6 个月内，70% 的客户下载并激活该应用
• 支持电话量减少 60%
• 应用商店评分达到 4.5+
• 80% 的用户无需联系支持团队即可完成任务

---

3. 背景与上下文

目的：说明为什么需要这个项目

内容：

• 当前情况说明
• 问题的历史及演变
• 以往解决问题的尝试（如有）
• 市场或竞争驱动因素
• 监管或合规驱动因素（如适用）

示例：

我们的客户支持中心目前每月处理 15,000 通电话，其中 70% 是常规咨询（订单状态、账户余额、退货申请），无需人工专业知识。行业基准数据显示，提供自助服务移动应用的公司可降低 50-70% 的支持成本，同时提升客户满意度。

我们的主要竞争对手（CompanyX 和 CompanyY）已于 2024 年推出移动应用，客户满意度和留存率均有显著提升。客户调查显示，65% 的客户更喜欢通过移动端自助服务，而不是致电支持中心。

2023 年，我们曾尝试通过 Web 门户解决这一问题，但由于移动体验不佳，且缺少订单更新推送通知，用户采用率仅为 15%。

---

4. 利益相关方分析

目的：明确受影响的群体及其需求

格式：使用表格列出利益相关方的角色、关注点和要求

利益相关方群体	主要代表	兴趣/关注点	主要要求
客户	终端用户	便捷地查看账户信息、跟踪订单	直观的 UI、快速响应、离线访问
客户支持	支持经理	减少来电量、获得更好的工具	与支持系统集成、升级处理路径
IT 运维	IT 总监	系统稳定性、安全性	安全认证、API 性能、监控
市场营销	市场营销副总裁	客户互动、留存	推送通知、个性化、分析
执行团队	CEO、CFO	投资回报率、战略一致性	节省成本、提升客户满意度

---

5. 范围定义

5.1 范围内

目的：明确定义将包含的内容

格式：按类别列出功能/能力

电子商务移动应用示例：

账户管理：

• 用户注册和登录
• 个人资料管理
• 重置密码
• 生物识别认证（Face ID、Touch ID）

订单管理：

• 查看订单历史记录
• 实时跟踪订单
• 查看订单详情并下载发票
• 重新下单功能

商品浏览：

• 浏览商品目录
• 搜索和筛选商品
• 查看商品详情和图片
• 管理心愿单

客户支持：

• 常见问题解答和帮助中心
• 集成实时聊天
• 提交支持工单
• 申请回电

通知：

• 订单状态推送通知
• 促销通知
• 配送更新

5.2 范围外

目的：明确说明不会包含的内容（管理预期）

示例：

• 应用内购买（第 2 阶段）
• 增强现实商品预览（第 2 阶段）
• 社交媒体集成（未来考虑）
• 忠诚度计划管理（独立项目）
• 国际配送（2026 年第 3 季度扩展）

---

6. 业务需求

格式：按类别组织，使用清晰、以业务为导向的语言

6.1 功能需求（高层级）

BR-001：用户身份验证

• 需求：系统应提供安全的用户身份验证
• 业务价值：保护客户数据并确保隐私
• 优先级：必须具备
• 成功标准：身份验证成功率达到 99.9%，登录时间 < 3 秒

BR-002：订单跟踪

• 需求：系统应提供实时订单状态和跟踪信息
• 业务价值：减少“我的订单在哪里”相关的客服来电（目前占来电量的 35%）
• 优先级：必须具备
• 成功标准：状态变更后 5 分钟内提供实时更新

BR-003：推送通知

• 需求：系统应发送订单更新推送通知
• 业务价值：主动沟通可减少客户焦虑和客服来电
• 优先级：必须具备
• 成功标准：通知送达率达到 90%，选择接收通知的比例 > 60%

6.2 非功能需求（高层级）

BR-NFR-001：性能

• App 在 4G 连接下应于 3 秒内加载
• 95% 的请求 API 响应时间 < 2 秒
• 支持 50,000 名并发用户

BR-NFR-002：可用性

• 营业时间（6 AM - 11 PM）内正常运行时间达到 99.9%
• 计划维护窗口安排在营业时间之外

BR-NFR-003：安全性

• 支付数据须符合 PCI DSS
• 对所有传输中的数据进行加密（TLS 1.3）
• 支持生物识别身份验证
• 闲置 15 分钟后会话超时

BR-NFR-004：易用性

• 支持 iOS 15+ 和 Android 12+
• 符合 WCAG 2.1 AA 级无障碍标准
• 支持英语和西班牙语
• UI 直观，无需培训即可使用

BR-NFR-005：合规性

• 符合欧盟客户的 GDPR 要求
• 符合加利福尼亚州客户的 CCPA 要求
• 符合 SOC 2 Type II 要求

---

7. 假设

目的：记录我们假定为真的事项

示例：

1. 客户拥有运行 iOS 15+ 或 Android 12+ 的智能手机
2. 现有后端 API 经过少量增强后即可满足移动 App 需求
3. 客户支持团队将接受新升级流程的培训
4. 市场营销团队将通过电子邮件和社交媒体活动推动 App 使用
5. IT 基础设施能够承受预计的用户负载
6. 第三方服务（推送通知、分析）将持续可用

---

8. 约束

目的：记录限制和约束条件

类别：

• 技术：必须使用现有 AWS 基础设施，必须与旧版订单管理系统集成
• 预算：总预算 $180K（开发、测试、部署）
• 时间表：必须在 2026 年第 2 季度前上线，以配合季节性营销活动
• 资源：可用人员为 2 名移动开发人员、1 名 QA、1 名 BA
• 法规：必须遵守应用商店指南（Apple、Google）
• 业务：开发期间不得影响当前 Web 体验

---

9. 依赖项

目的：确定本项目所依赖的事项

示例：

依赖项	描述	负责人	状态	风险
后端 API 增强	订单跟踪 API 需要支持实时更新	IT 团队	进行中	中
推送通知服务	需要采购服务（OneSignal 或 Firebase）	IT 团队	尚未开始	低
App Store 账户	Apple Developer 和 Google Play 账户	市场营销	待处理	低
客户数据迁移	清理客户数据以便迁移到 App	数据团队	已计划	中
支持系统集成	与 Zendesk 集成以创建工单	IT 团队	尚未开始	高

---

10. 风险与缓解措施

风险	影响	概率	缓解策略
应用采用率低	高	中	开展全面的营销活动、提供应用内激励、通过电子邮件推广
后端 API 性能问题	高	中	进行负载测试、优化性能、制定缓存策略
应用商店拒绝上架	中	低	提前审查指南、制定合规检查清单、进行 Beta 测试
与遗留系统的集成延迟	高	高	提前开展技术验证、并行开发、制定备用计划
安全漏洞	严重	低	安全审计、渗透测试、代码审查

---

11. 成功指标与 KPI

采用指标：

• 应用下载量：6 个月内达到活跃客户的 70%
• 月活跃用户（MAU）：下载量的 60%
• 日活跃用户（DAU）：MAU 的 25%

业务影响指标：

• 支持电话量减少：3 个月内下降 60%
• 成本节省：每年 $270K
• 客户满意度：从 3.2 提升至 4.5
• 客户留存率：提升 15%

技术指标：

• 应用商店评分：4.5 星以上
• 崩溃率：< 1%
• 应用加载时间：< 3 秒
• API 响应时间：< 2 秒（第 95 百分位）

参与度指标：

• 平均会话时长：> 3 分钟
• 功能使用情况：80% 的用户使用订单跟踪，60% 的用户使用账户管理
• 推送通知选择加入率：> 60%

---

12. 时间表与里程碑

阶段	里程碑	时长	目标日期
规划	BRD 批准	2 周	Feb 1, 2026
设计	UX/UI 设计完成	3 周	Feb 22, 2026
开发	iOS 应用开发	8 周	Apr 19, 2026
开发	Android 应用开发	8 周	Apr 19, 2026
测试	QA 和 UAT	3 周	May 10, 2026
部署	提交至应用商店	1 周	May 17, 2026
发布	公开发布	-	May 24, 2026

---

13. 预算估算

类别	成本	备注
开发（iOS 和 Android）	$120,000	2 名开发人员 x 3 个月
UX/UI 设计	$25,000	设计机构
QA 与测试	$15,000	QA 工程师 + 设备测试
项目管理	$10,000	BA + PM 工时
第三方服务（第 1 年）	$5,000	推送通知、分析
应用商店费用	$200	Apple ($99) + Google ($25) + 预留费用
应急费用（10%）	$17,520	风险备用金
总计	$192,720

---

14. 批准与签字确认

角色	姓名	签名	日期
业务赞助人
产品负责人
IT 总监
财务部
业务分析师

---

领域特定的 BRD 注意事项

电子商务 BRD

重点领域：

• 客户旅程与转化率优化
• 支付与安全要求
• 库存和订单管理集成
• 多渠道一致性
• 季节性流量与可扩展性

关键指标：转化率、购物车放弃率、平均订单价值、客户生命周期价值

ERP BRD

重点领域：

• 业务流程转型
• 变更管理与培训
• 数据迁移与清理
• 与现有系统集成
• 合规与审计要求

关键指标：流程效率、成本降低、数据准确性、用户采用率

CRM BRD

重点领域：

• 销售流程优化
• 潜在客户管理与转化
• 客户 360 度视图
• 市场营销与销售协同
• 报告与分析

关键指标：潜在客户转化率、销售周期时长、客户满意度、销售管道价值

CDP BRD

重点领域：

• 数据统一策略
• 隐私与同意管理
• 细分与个性化
• 营销激活渠道
• 数据治理

关键指标：数据完整性、细分准确性、营销活动效果、投资回报率

移动端/网页 BRD

重点领域：

• 用户体验与参与度
• 性能与响应速度
• 跨平台一致性
• 离线功能
• 应用商店优化

关键指标：用户参与度、会话时长、留存率、应用商店评分

---

BRD 最佳实践

写作风格

✅ 建议：

• 使用清晰、简洁的业务语言
• 面向读者撰写（高管，而非开发人员）
• 聚焦业务价值与成果
• 使用主动语态
• 具体且可衡量
• 加入视觉辅助材料（图表、示意图）

❌ 避免：

• 使用未经解释的技术术语或缩写
• 包含实现细节（留给 FRS）
• 使用含糊的表述（“提高效率”）
• 假设读者具备相关背景知识
• 写过长的句子

结构与格式

• 使用一致的格式和编号
• 对超过 10 页的文档添加目录
• 使用表格呈现结构化信息
• 添加页码并进行版本控制
• 使用标题和留白提升可读性

协作

• 尽早并经常让利益相关者参与
• 与业务负责人审阅草稿
• 获取技术可行性验证
• 根据反馈迭代
• 保留版本历史

质量检查

• 执行摘要有说服力且简洁
• 业务目标符合 SMART 原则
• 范围定义清晰（包含与不包含的内容）
• 需求聚焦业务，而非技术
• 成功指标可衡量
• 假设和约束已记录
• 依赖关系和风险已识别
• 预算和时间安排切合实际
• 文档格式良好且专业
• 所有利益相关者均已审阅并批准

---

BRD 编写工具

Lark

• 使用 Lark Docs 协作编写 BRD
• 使用评论收集利益相关者的反馈
• 使用版本历史跟踪更改
• 分享给利益相关者进行审阅和批准

Notion

• 在 Notion 中创建 BRD 模板
• 使用数据库属性记录元数据（版本、状态、负责人）
• 链接相关需求和用户故事
• 嵌入图表和原型图

Figma

• 创建流程图
• 设计用户旅程图
• 制作线框图来说明概念
• 在 BRD 中嵌入 Figma 链接

---

BRD 获批后的后续步骤

1. 创建详细的功能需求规格说明（FRS）——参见 frs-creation 技能
2. 制定用例——参见 use-case-documentation 技能
3. 为敏捷开发创建用户故事——参见 user-story-writing 技能
4. 设计流程图——参见 process-mapping 技能
5. 规划 UAT——参见 uat-planning 技能

---

参考资料

• BABOK® Guide——业务需求文档标准
• IIBA Standards——专业 BA 文档实践
• PMI PMBOK® Guide——项目章程和商业论证编制
• IEEE 29148——需求工程和文档标准