需求分析与 PRD 编写指南
【摘要】 需求分析与 PRD 编写指南PRD 不是「把想法写长」，而是把模糊诉求翻译成开发能实现、测试能验证、各方能对齐的契约。 一、先分清四层概念层次回答的问题例子业务目标为什么做提升下单转化率 5%用户需求用户想达成什么我想少填几次地址功能需求系统要提供什么支持从历史订单一键带入地址非功能需求要做到多好首屏 < 1.5s、支持千人并发、可审计最常见的失败：直接从「用户需求」跳到「功能需求」，跳过...
需求分析与 PRD 编写指南
PRD 不是「把想法写长」，而是把模糊诉求翻译成开发能实现、测试能验证、各方能对齐的契约。
一、先分清四层概念
| 层次 | 回答的问题 | 例子 |
|---|---|---|
| 业务目标 | 为什么做 | 提升下单转化率 5% |
| 用户需求 | 用户想达成什么 | 我想少填几次地址 |
| 功能需求 | 系统要提供什么 | 支持从历史订单一键带入地址 |
| 非功能需求 | 要做到多好 | 首屏 < 1.5s、支持千人并发、可审计 |
最常见的失败：直接从「用户需求」跳到「功能需求」，跳过目标，结果做出一个功能完整但没人用的东西。
二、一份够用的 PRD 结构
# XX 功能需求文档
## 1. 背景与目标
现状数据 / 痛点 / 期望指标（可度量）
## 2. 范围
本期做什么（In Scope）
本期明确不做什么（Out of Scope） ← 最容易被省略、也最重要
## 3. 用户与场景
角色、主流程、异常流程
## 4. 功能说明
页面/接口逐一描述，配状态机或流程图
## 5. 规则与边界
字段校验、权限、并发、幂等、数据量上限
## 6. 非功能要求
性能、兼容、安全、埋点、灰度
## 7. 验收标准（Given-When-Then）
## 8. 依赖与风险
## 9. 变更记录
三、把验收标准写成可测试的句子
模糊写法与合格写法对比：
| ❌ 模糊 | ✅ 可验证 |
|---|---|
| 加载要快 | 4G 网络下首屏可交互时间 P95 < 2s |
| 提交后给出提示 | 提交成功显示「已提交」Toast 并在 1.5s 后返回列表 |
| 异常情况友好处理 | 网络失败保留表单内容，展示重试按钮，不重复创建订单 |
| 支持大批量 | 单次导入 ≤ 5000 行，超限提示且不入库 |
推荐 Given-When-Then 格式：
场景：重复点击提交
Given 用户已填完表单且网络正常
When 在 1 秒内连续点击「提交」3 次
Then 只生成 1 条记录，按钮在首次点击后置灰直至响应
这类句子直接就是测试用例，开发、测试、产品三方不会再对「什么叫做完」产生分歧。
四、必须显式写清的五类「隐形需求」
- 状态机：订单 / 审批类需求，把所有状态与合法流转画成表，标出谁可以触发。
- 权限矩阵：角色 × 操作（查看 / 新增 / 编辑 / 删除 / 导出），尤其是「只能看自己的」。
- 幂等与并发：重复提交、双端同时操作、库存超卖。
- 空态与极端值：列表为空、超长文本、0 / 负数、跨天跨月、时区。
- 数据与合规：留存期限、脱敏展示、操作日志、可否导出。
五、常见坑与对策
| 坑 | 对策 |
|---|---|
| 用截图代替规则 | 截图只能说明样式，交互与边界必须文字化 |
| 只写主流程 | 每个主流程至少配 2 条异常流程 |
| 需求频繁插入 | 设变更窗口，变更同步更新「变更记录」并重新评估排期 |
| 把技术方案写进 PRD | PRD 描述「要什么」，方案文档描述「怎么做」，分开 |
| 没有不做的清单 | 明确 Out of Scope，是控制范围蔓延最有效的一句话 |
六、评审前自检清单
- [ ] 每个需求都能回答「不做会怎样」，答不上来的优先级存疑
- [ ] 所有形容词（快、友好、智能）都已换成可度量或可观察的描述
- [ ] 状态、权限、异常、幂等四项都有明确结论
- [ ] 埋点指标和验收标准一一对应，上线后能验证目标是否达成
- [ ] 开发、测试、设计各有一人确认过文档，且在变更记录里留痕
七、小结
PRD 的质量不看篇幅，看歧义密度：评审会上被追问「那这种情况呢」的次数越少，文档越好。写完不妨自己扮演测试，逐条问「这条我怎么测」，测不出来的就重写。
【声明】本内容来自华为云开发者社区博主，不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息，否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）