第2章 产品需求文档的基础结构

你是否有过这样的经历：打开一份PRD文档，内容杂乱无章，重要信息淹没在长篇文字中，研发追问细节、测试反复确认、运营看不懂优先级——这正是PRD缺乏标准结构带来的典型痛点。

标准化的PRD结构就像产品的统一蓝图框架，让产品经理、研发、测试、运营等所有角色都能快速定位所需信息，用共同的“语言”对齐认知。

2.1 PRD七大核心组成部分

一份完整的PRD文档由七个核心模块构成，它们按照从宏观到微观、从背景到验收的逻辑顺序排列，形成闭环叙事链：

1. 文档头——文档的元信息与状态标识，方便归档与追溯
2. 修订记录——文档变更的历史轨迹，确保版本可追溯
3. 背景目标——阐述“为什么做”，对齐产品方向和成功标准
4. 范围边界——明确“做什么”与“不做什么”，防止范围蔓延
5. 功能需求——描述产品“要具备哪些能力”，是研发的核心输入
6. 非功能需求——定义质量属性：性能、安全、可用性、兼容性等
7. 验收标准——规定“如何判断需求已实现”，是测试与上线的依据

2.2 各章节编写要点

每个章节都有其特定的表达方式和关注重点，以下是针对各章节的编写指南：

• 文档头：产品名称、版本号、文档编号、负责人、状态（草稿/评审中/已定稿）缺一不可
• 修订记录：每次变更记录版本号、日期、修订人、修订内容摘要，保持追加而非覆盖
• 背景目标：包含项目背景、产品目标、用户价值、1~2个核心成功指标（如：日活提升20%）
• 范围边界：明确功能范围、目标用户、系统边界、明确排除项（用“不做什么”清单）
• 功能需求：采用“用户故事+交互逻辑+优先级”三层结构，避免纯功能列表
• 非功能需求：量化指标优先（如：页面加载<2秒，并发用户1000+），避免模糊描述
• 验收标准：每个需求对应1~3条可测通过条件，用“当…时…应…”句式

2.3 各章节评审要点

在PRD评审会上，每个章节都有对应的检查重点，以下表格汇总了各模块的评审关注点和常见问题：

2.4 结构完整性验收标准

在PRD定稿前，使用以下清单逐项检查文档结构的完整性：

• ✅ 文档头包含：产品名称、版本号、文档编号、负责人、当前状态
• ✅ 修订记录包含：至少一条初始创建记录，版本号与文档头一致
• ✅ 背景目标包含：项目背景、产品目标、至少1个量化成功指标
• ✅ 范围边界包含：目标用户、功能范围、系统边界、明确排除项
• ✅ 功能需求包含：用户故事、交互逻辑描述、优先级标识（P0/P1/P2）
• ✅ 非功能需求包含：性能、安全、可用性三大类中至少两类量化要求
• ✅ 验收标准包含：每个功能需求对应1~3条通过条件，格式统一

2.5 PRD结构模板（交付物）

以下是一个可直接复用的PRD结构模板，涵盖七个核心章节及其子项：

# PRD文档模板

## 1. 文档头
- 产品名称：
- 版本号：
- 文档编号：
- 负责人：
- 状态：[草稿 / 评审中 / 已定稿]

## 2. 修订记录
| 版本 | 日期 | 修订人 | 修订内容 |
|------|------|--------|----------|
| v1.0 |      |        | 初始创建 |

## 3. 背景目标
- 项目背景：
- 产品目标：
- 用户价值：
- 成功指标（含计算公式）：

## 4. 范围边界
- 功能范围：
- 目标用户：
- 系统边界（依赖/约束）：
- 排除项（明确不做的内容）：

## 5. 功能需求
- 功能模块：
- 用户故事（As a…I want…So that…）：
- 交互逻辑说明：
- 优先级：P0 / P1 / P2

## 6. 非功能需求
- 性能要求（响应时间/吞吐量/并发）：
- 安全要求（认证/权限/数据加密）：
- 可用性要求（MTBF/MTTR）：
- 兼容性要求（浏览器/设备/接口）：

## 7. 验收标准
| 需求编号 | 验收用例 | 通过条件 |
|----------|----------|----------|
| FR-001   | 当…时…应… | 实际结果 = 预期结果 |