DAY11 · 需求文档的 5 个核心要素

需求文档的 5 个核心要素

前 10 天我们聊了"看懂数字化""识别需求""过滤伪需求"。
从今天开始，进入第三阶段：需求分析、需求文档。
第一篇讲最基础的问题：一份合格的需求文档，到底应该包含什么？

一、先说结论：5 个要素，缺一不可

很多数字化负责人都遇到过这种场景：

业务部门提了需求，开发埋头做了 3 个月。
上线时，业务说："这不是我要的。"
开发说："你需求文档里没写啊。"
老板说："你们怎么沟通的？"
最后谁都不满意。

根源往往不是沟通不到位，而是需求文档缺东西。

一份合格的需求文档，不是"长篇大论"，而是"5 个核心要素"缺一不可：

1. 要素 1：背景与目标（Why）
   ——为什么做？要解决什么？成功的标准？
2. 要素 2：用户与场景（Who/Where）
   ——谁用？在什么场景下用？
3. 要素 3：功能需求（What）
   ——具体要做哪些功能？
4. 要素 4：非功能需求（How well）
   ——性能、安全、可用性等要求
5. 要素 5：验收标准（Done）
   ——怎么算"做完了"？

5 个要素缺 1 个，做出来的东西就有 1 个方向会跑偏。

二、要素 1：背景与目标（Why）

回答的核心问题：我们为什么要做这件事？做完之后世界会变成什么样？

3 个必须答清的小问题：

1. 业务背景:
   现在业务上有什么痛点？为什么"现在"要做？
2. 项目目标:
   做完后要达到什么业务结果？（如:"客户投诉率降 30%"）
3. 成功标准:
   用什么数字衡量"成功"？（如:"客诉响应时长 ≤ 2 小时"）

为什么这一要素最容易被忽略？

业务部门常常觉得"反正大家都懂"——其实懂不懂大家都不一样。
一个新人加入项目，看完背景与目标，应该能在 5 分钟内讲清楚"为什么做"。

举例：

业务部门提"我们要一套客服系统"。
差的写法：
"做一个客服系统，让客服处理工单更高效。"

好的写法：
"业务背景：当前客户投诉响应时长平均 8 小时，客户满意度 78 分（低于行业 85 分）。
项目目标：响应时长降至 2 小时，满意度提升至 88 分。
成功标准：上线 3 个月后，响应时长 ≤ 2 小时的比例 ≥ 90%，满意度 ≥ 88 分。"

判断要点：

没有数字的目标 = 伪目标。
写不出"做完是什么样"的需求 = 没法验收。

三、要素 2：用户与场景（Who/Where）

回答的核心问题：谁会用？在什么时间、什么地点、做什么事？

2 个必须答清的小问题：

1. 用户画像:
   谁是核心用户？他们的角色、工作内容、使用频率是什么？
2. 典型场景:
   3~5 个最常见的使用场景，每个场景讲清时间/地点/动作/输出。

为什么这一要素关键？

没有用户画像，开发做出来的东西是"想象中的用户"用的。
没有典型场景，做出来的东西是"在错误的时间、错误的地点"被使用。

举例：

用户画像:

- 客服专员：每天处理 30+ 工单，主要在 PC 端工作；
- 客服主管：每天巡检 5~10 个复杂工单，主要在 PC 端；
- 客户：偶尔查询工单进度，主要在手机端。

典型场景：
- 场景 1：客服收到新工单 → 在 PC 端查看详情 → 回复客户（≤ 10 分钟）
- 场景 2：客服主管巡检 → 发现超时工单 → 介入处理
- 场景 3：客户在手机端查询 → 看到进度 → 评价满意度

判断要点：

答不出"谁在用"的需求 = 不知道为谁做。
答不出"在哪用"的需求 = 系统用不对场景。

四、要素 3：功能需求（What）

回答的核心问题：具体要做哪些功能？每个功能怎么用？

这是需求文档的"主干"，通常用功能列表 + 用户故事两种方式表达：

3 条经验：

1. 每个功能都要可测:

1. 优先级要明确:
   用 P0/P1/P2 分级（P0 = 必须有 / P1 = 应该有 / P2 = 最好有）。
2. 范围要克制:
   80% 价值来自 20% 功能，先做核心场景。

举例：

客服系统功能需求（P0 级）：
- F1：客户提交工单（多渠道：电话/网页/微信/邮件）
- F2：客服接收并处理工单（创建、回复、转交、关闭）
- F3：工单超时提醒（按 SLA 自动触发）
- F4：客户满意度评价（关闭工单后推送）
- F5：客服工作台（每日待办、统计、个人绩效）

判断要点：

功能太多 = 项目失控。
80/20 法则：80% 价值来自 20% 核心功能。

五、要素 4：非功能需求（How well）

回答的核心问题：系统要做到什么"程度"？性能、安全、可用性怎么定？

4 类常见非功能需求：

1. 性能:
   响应时间（如 ≤ 2 秒）、并发数（如 ≥ 1000）、吞吐量
2. 安全:
   数据加密、权限控制、操作审计、合规要求
3. 可用性:
   可用率（如 99.9%）、故障恢复时间、备份策略
4. 兼容性:
   浏览器/设备支持范围、与现有系统集成方式

为什么这一要素最容易被忽略？

因为它"看起来不重要"。但真出问题就要命——
系统跑得慢、泄漏客户数据、宕机 1 天损失 100 万……全是没写非功能需求的代价。

举例：

客服系统非功能需求：
- 性能：工单列表加载 ≤ 2 秒；高峰期支持 500 并发；
- 安全：客户手机号加密存储；所有操作留痕；权限按角色分配；
- 可用性：可用率 ≥ 99.9%（年宕机 ≤ 8.7 小时）；
- 兼容性：支持 Chrome / Edge / Safari 最新版本；移动端 H5 适配。

判断要点：

答不出"系统做到什么程度"的需求 = 上线后到处救火。

六、要素 5：验收标准（Done）

回答的核心问题：怎么算"做完了"？谁说"合格"？

3 类必须答清的问题：

1. 验收方:
   谁签字说"合格"？一般是业务部门负责人。
2. 验收标准:
   用哪些指标判断？必须可量化（动词 + 数字）。
3. 验收周期:
   上线后多久验收？一般是 1~3 个月试运行。

举例：

客服系统验收标准：
- 验收方：客服中心负责人 + IT 负责人联合签字
- 核心指标：
  客诉响应时长 ≤ 2 小时（≥ 90% 工单）
  客户满意度 ≥ 88 分
  系统可用率 ≥ 99.9%
- 验收周期：上线后 3 个月试运行，达到以上指标方为合格

判断要点：

没有验收标准的需求 = 永远做不完。
验收标准必须是"动词 + 数字"，不能是形容词。

七、5 个要素速查表

八、Day 11 行动建议

1. 找一份现有需求文档，对照 5 个要素打分
   （每个要素 0~3 分）：
• 总分 ≥ 12 :合格，可以过会；
• 总分 8~11：要补强，至少补 2 个要素；
• 总分 < 8：打回重写。
2. 把 5 个要素做成"需求文档模板":
   以后所有需求都按这个模板写，缺项直接打回。
3. 每季度抽 3 个项目复盘:
   5 个要素缺哪个最致命？补哪个 ROI 最高？用结果反向修正模板。

九、下一期预告

第 12 天：

《BRD vs PRD vs FSD：3 类需求文档的区别》

业务需求文档（BRD）、产品需求文档（PRD）、功能规格说明书（FSD）——三种文档到底写什么？什么时候用？互相怎么配合？

关注我，连续 100 天，一起把数字化讲透。

需求文档不是"给开发看的"，是"给所有人看的对齐文档"。

#数字化转型#需求文档#PRD#产品设计#数字化人100天实战笔记

作者介绍

数字化负责人 / 产品经理 / 项目经理，长期从事企业数字化建设、产品设计、项目管理与数据治理工作。

持续记录 100 天实战经验，目标是把"数字化"从口号变成可执行的方法论。