4. 需求拆解与功能点梳理：从场景到功能点
需求拆解是PRD编写的核心工序。一个模糊的“用户想让系统更好用”经过逐层分解后，变成可开发、可测试、可验收的功能点。本章讲解如何从用户场景出发，通过用户故事拆分和粒度控制，最终输出结构化的功能清单。
4.1 拆解的目标：从“做什么”到“怎么做”
需求拆解不是简单的列表罗列，而是要回答三个层次的问题：
| 层次 | 对应问题 | 产出物 |
|---|---|---|
| 业务层 | 用户期望达成什么业务目标？ | 业务目标、KPI |
| 场景层 | 在什么情境下使用？谁来用？ | 用户旅程图、场景描述 |
| 功能层 | 系统需要提供哪些具体操作？ | 功能清单、用户故事 |
关键判断：如果一条需求描述里包含“用户可”、“系统自动”或“支持XX”，它很有可能还处于业务层或场景层，需要进一步拆解到具体的功能操作。
4.2 用户故事拆分：INVEST 原则
用户故事是连接场景与功能点的桥梁。好的用户故事符合 INVEST 原则：
- Independent（独立的）：故事之间尽可能解耦，便于优先级排序。
- Negotiable（可协商的）：保留实现细节的讨论空间，不写成固定方案。
- Valuable（有价值的）：从用户视角描述价值，而非技术动作。
- Estimable（可估算的）：团队能在故事点或工时上做出合理评估。
- Small（小的）：颗粒度足够小，能在单一迭代内完成。
- Testable（可测试的）：有明确的验收标准，开发完成后可验证。
用户故事标准格式：
“作为 [用户角色]，我希望 [功能操作]，以便 [业务价值]。”
“作为 [用户角色]，我希望 [功能操作]，以便 [业务价值]。”
示例 — 拆分前后对比：
| 阶段 | 描述 | 问题 / 改进 |
|---|---|---|
| 原始需求 | 支持用户在工单列表页筛选 | “筛选”包含多种维度，故事颗粒度太大 |
| 拆分后故事1 | 作为工单处理员，我希望按创建日期筛选工单，以便快速定位近3天新增工单 | 具有独立价值、可估算、可测试 |
| 拆分后故事2 | 作为工单处理员，我希望按紧急程度筛选工单，以便优先处理高优工单 | 痛点驱动、场景明确 |
4.3 功能点梳理：从故事到功能清单
用户故事确认后，需要进一步将其拆解为原子级的功能点。功能点描述的是系统的一个具体行为或交互节点。一个用户故事通常会拆解出 3–8 个功能点。
常见功能点类型：
- 数据型功能点：新增、修改、删除、查询、列表、导出、导入
- 流程型功能点：提交、审批、驳回、转交、关闭、重开
- 配置型功能点：开启/关闭开关、设置阈值、选择模板
- 交互型功能点：下拉框、复选框、拖拽、弹窗确认、分页
- 通知型功能点：站内信、短信、邮件、应用内提醒
功能清单模板示例（简版）：
| ID | 功能点名称 | 所属用户故事 | 功能类型 | 优先级 |
|---|---|---|---|---|
| F-001 | 按日期范围筛选工单 | US-101 | 查询 | P0 |
| F-002 | 按紧急程度筛选工单 | US-102 | 查询 | P1 |
| F-003 | 工单列表日期排序切换 | US-101 | 交互 | P2 |
| F-004 | 筛选条件重置按钮 | US-101 | 交互 | P2 |
常见陷阱：在功能清单中混入 UI 文案、视觉动效或技术实现细节（如“使用Redis缓存”）。功能清单只描述“系统做什么”，不描述“内部怎么做”。
4.4 需求粒度控制：多大算合适？
功能点粒度过粗会导致估算不准、开发返工；粒度过细则陷入细节迷宫，失去全局视角。以下粒度对照表可供参考：
| 粒度级别 | 举例 | 开发工时估算 | 适合阶段 |
|---|---|---|---|
| 史诗级（Epic） | “工单管理模块” | 数周至数月 | 产品规划、Roadmap |
| 故事级（Story） | “支持按紧急程度筛选工单” | 2–5 天 | 迭代计划 |
| 功能点级（Feature） | “下拉框列出紧急程度选项” | 0.5–1 天 | 每日开发拆解 / 验收 |
粒度控制实践建议：
- 按层拆解：Epic → Story → Feature 逐层细化，保持每层颗粒度一致。
- 按边界切分：一个功能点只对应一个用户操作确认（如点击按钮、输入完数据），不要包含连续多个步骤。
- 按验收点切分：能用一条验收标准覆盖的功能点，通常就是合适的粒度。
- 避免“并且”：如果一个功能点的描述中出现“并且”，极大概率需要继续拆分。
4.5 功能点拆分核心流程
下图展示了一个完整的从场景到功能点的拆解路径：
4.6 需求优先级矩阵：场景 vs 价值
功能点梳理完成后，需要结合用户场景的严重程度与业务价值，对功能点进行优先级排序。推荐使用以下优先级矩阵：
| 高频场景 | 中频场景 | 低频场景 | |
|---|---|---|---|
| 高业务价值 | P0（必须做） 例：核心筛选功能 | P1（应该做） 例：筛选条件保存 | P2（可以放到下个版本） 例：筛选项的隐藏/显示切换 |
| 中业务价值 | P1（应该做） 例：筛选条件自定义排序 | P2（可以放） | P3（未来考虑） |
| 低业务价值 | P2（可以放） | P3（未来考虑） | P3（不排队） |
优先级标签说明：
P0 — 缺少该功能则场景无法跑通，产品无法发布。
P1 — 场景体验不完整但可用，建议本版本包含。
P2 — 增强性体验，可酌情放在下一个迭代。
P3 — 锦上添花，进入需求池备选。
P0 — 缺少该功能则场景无法跑通，产品无法发布。
P1 — 场景体验不完整但可用，建议本版本包含。
P2 — 增强性体验，可酌情放在下一个迭代。
P3 — 锦上添花，进入需求池备选。
4.7 交付物检查表
完成需求拆解与功能点梳理后，检查以下交付物是否完整：
| 序号 | 交付物 | 检查标准 |
|---|---|---|
| 1 | 用户故事列表 | 每个故事均包含角色、操作、价值描述 |
| 2 | 功能清单 | 清单内每个功能点可独立验收，不包含技术实现描述 |
| 3 | 优先级矩阵 | 各功能点均有明确的优先级标签（P0/P1/P2/P3） |
| 4 | 场景-功能追溯表 | 每个功能点都能追溯到原始场景需求 |
| 5 | 验收检查要点 | 对 P0 功能点已列出初步的验收条件 |
场景-功能追溯表示例（局部）：
| 场景编号 | 场景描述 | 关联故事 | 功能点 ID |
|---|---|---|---|
| SC-001 | 工单处理员上班后筛选今日待办 | US-101 | F-001, F-003, F-004 |
| SC-002 | 主管查看高紧急度未处理工单 | US-102 | F-002 |
需求拆解不是一次性工作。在原型对稿、评审和开发过程中，还会发现场景中的遗漏或理解偏差，应持续回退到本章的拆解结构中进行迭代补充。第四章的核心能力在于：将模糊的“想要”变成清晰的“要做”，这是后续所有PRD章节的基础。