第2章 PRD 结构要素拆解：用户故事 · 场景 · 需求 · 验收 · 规则 · 字段
从用户访谈记录到产品需求文档（PRD），最核心的障碍是“口语碎片 → 结构化表达”的转化。PRD 并非一段散文，而是由六个相互关联的要素构成的工程化框架：用户故事、场景描述、需求列表、验收标准、业务规则和数据字段。本章逐一拆解每个要素的定义、转化方法及常见陷阱，并给出它们之间的结构化关系。
2.1 六要素全景对比
下表从回答的问题和典型产出物两个维度概览六要素，后续各节逐一展开。
| 要素 | 回答的核心问题 | 访谈信息转化要点 | PRD 中的典型形态 |
|---|---|---|---|
| 用户故事 | 谁想要什么？为什么？ | 提取角色、意图、价值 | As a… I want… so that… |
| 场景描述 | 在什么情境下使用？ | 还原前置条件、触发事件、操作流 | 结构化场景卡片 |
| 需求列表 | 系统“做什么”？ | 拆分功能点与非功能点，标记优先级 | P0/P1/P2 需求清单 |
| 验收标准 | 怎样算“做完”？ | 将模糊期望转为可测条件 | Given/When/Then |
| 业务规则 | 约束与逻辑是什么？ | 抓取“如果…就…”句式 | if-then 规则表 |
| 数据字段 | 数据长什么样？ | 定义字段名、类型、长度、约束 | 数据字典 |
2.2 用户故事（User Story）
用户故事是 PRD 的“起点”，它回答三个问题：谁（角色）、想要什么（功能）、为什么（价值）。访谈记录中，用户通常会以“我希望能……”或“我们需要一个功能可以……”开头，你需要立刻将其映射到标准故事模板中。
- 转化方法：圈出主语→角色；圈出愿望动词→功能；追问“解决了什么麻烦”→价值。
- 常见陷阱：把用户故事写成需求列表（“用户需要 A、B、C”），丢失了角色与动机。
- 案例：访谈中说“我经常要核对几十张报表，眼睛都花了”，转化为→“作为财务审核员，我想要报表差异自动高亮，以便快速定位异常数据。”
2.3 场景描述（Scenario Description）
用户故事给出“意图”，场景描述给出“剧本”。它包含：前置条件、触发事件、操作步骤、预期结果。访谈中用户常讲“有一次我……然后……最后……”，这正是场景的原型。
- 转化方法：用“5W1H”梳理：When（何时）、Where（何界面）、Who（谁操作）、What（做了什么）、Why（触发原因）、How（步骤）。
- 与用户故事的关系：一个用户故事可以对应多个场景（正常路径、异常路径、边界情况）。
- 案例：前置条件“已登录且拥有管理员权限”，触发事件“点击‘批量导出’”，步骤“选择日期范围→点击导出→系统生成 CSV”，结果“浏览器下载文件”。
2.4 需求列表（Requirement List）
需求列表是将场景和故事中的“功能点”显性化、编号化、优先级化的产物。分为功能需求（系统行为）和非功能需求（性能、安全、兼容性）。
- 转化方法：从每个场景的操作步骤中提取“系统应……”的陈述，去重、合并、分层。
- 优先级标记：P0（无此功能产品不可用）、P1（核心体验，必须做）、P2（增强体验，可延后）。
- 案例：REQ-001（P0）：系统支持选择导出日期范围；REQ-002（P1）：导出文件格式支持 .xlsx 和 .csv。
2.5 验收标准（Acceptance Criteria）
验收标准把“做完了”从主观判断变成客观检测。推荐使用 Given/When/Then 格式：给定前置条件，当触发动作时，则预期结果。访谈中的模糊表述“要快”“要易用”必须转化为可量化的指标。
- 转化方法：对每个需求，问“怎样测？”→ 写出通过/不通过的判定条件。
- 常见陷阱：验收标准写成“系统应正常工作”，无法测试。必须包含具体数值或状态。
- 案例：Given 已勾选 3 条报表记录，When 点击“批量导出”，Then 系统在 5 秒内生成下载链接，且文件内容与勾选记录一致。
2.6 业务规则（Business Rules）
业务规则是产品背后“不可违背的约束”——权限逻辑、计算公式、状态机、合规要求。访谈中用户频繁使用“如果……就……”“只有……才能……”等句式，这些就是业务规则的藏身之处。
- 转化方法：提取条件 + 结果，用 if-then 表记录；多条规则之间注意冲突检测。
- 案例：规则 BR-001：如果用户角色为“访客”，则隐藏“导出”按钮。规则 BR-002：如果订单金额 ≥ 500 元，则免运费；否则运费按 10 元计算。
2.7 数据字段（Data Fields）
数据字段是 PRD 中最容易被忽略但开发最依赖的要素。它定义每个业务对象的字段名、数据类型、长度、默认值、是否必填、枚举值。访谈中的“我们要记录用户的联系电话”直接转化为数据字段。
- 转化方法：从用户故事和场景中圈出所有“名词”（订单、用户、报表…），逐个展开字段结构。
- 案例：字段
user.phone→ 类型 string，长度 11，必填，正则校验 ^1[3-9]\\d{9}$。 - 与需求列表的关系：一个需求通常涉及多个数据字段的增/改/查，在 PRD 中应交叉引用。
2.8 六要素推导链条
上图展示的箭头关系即为一次完整的 PRD 结构化推导：
- 用户故事确定“谁要什么”，它是整个推导的起点。
- 围绕用户故事，撰写场景描述，把“想要”变成“在什么条件下怎么做”。
- 从场景的操作步骤中提取需求列表，每个需求对应一个系统行为。
- 每个需求附带验收标准，确保可测试、可交付。
- 在需求执行过程中，业务规则约束“能做什么、不能做什么”。
- 需求与规则最终落地为数据字段，形成开发可直接使用的数据字典。
2.9 交付物模板建议
为每个用户故事建立一张“六要素卡片”，作为 PRD 的最小交付单元。下表为推荐模板结构：
| 板块 | 内容示例 | 信息来源 |
|---|---|---|
| 用户故事 | 作为财务审核员，我想要报表差异自动高亮，以便快速定位异常 | 访谈录音 00:12:35 |
| 场景描述 | 前置：已登录且有审核权限；触发：打开月报对比页；步骤：选择月份 → 点击“自动比对” → 系统标记差异行 | 访谈录音 00:14:20 |
| 需求列表 | REQ-001（P0）：支持选择两个月份 REQ-002（P0）：系统自动比对并高亮差异 REQ-003（P1）：差异行支持点击查看详情 |
场景步骤拆解 |
| 验收标准 | Given 已选择 2025-03 和 2025-04，When 点击“自动比对”，Then 差异行背景色变为浅红，且差异单元格显示“+/-”符号 | 需求 + 用户期望 |
| 业务规则 | BR-001：仅当用户角色包含“财务审核”权限时，显示“自动比对”按钮 BR-002：比对结果缓存 30 分钟，超时后需重新比对 |
访谈中“只有审核员才能用” |
| 数据字段 | comparison.id (int, PK)comparison.month_a (string, 7)comparison.month_b (string, 7)comparison.diff_count (int, default 0) |
需求列表 + 规则推导 |
使用此模板后，每次访谈结束即可快速产出“六要素填充表”，缺失项即为下一次访谈的追问清单。