第4章 需求拆解与功能清单
需求拆解是连接用户访谈与方案表达的核心枢纽。一次高质量的拆解，能把模糊的“用户想要更好体验”转化为可落地的功能列表、可度量的非功能指标和可验证的体验标准。本章围绕需求分类、颗粒度原则和功能清单模板，给出可直接套用的拆解方法。
核心认知：需求拆解不是“分得越细越好”，而是让每个需求原子具备可独立开发、可单独验证、可关联原型的能力。拆解质量直接影响后续Figma原型的页面划分和交互逻辑。
4.1 需求分类三维度
任何一个业务问题，拆解后都会落在三个维度之一。三类需求在PRD中的写法、验证方式和原型关联策略完全不同。
| 分类 | 定义 | 典型表述 | 验证方式 | 原型关联 |
|---|---|---|---|---|
| 功能需求 | 系统“做什么”的具体行为 | “用户可上传PDF合同” | 功能验收测试 | 直接对应Figma页面/组件 |
| 非功能需求 | 系统“做得怎么样”的质量属性 | “上传后3秒内完成解析” | 性能压测/安全审计 | 在原型标注中补充指标说明 |
| 体验需求 | 用户“感受如何”的主观标准 | “上传状态反馈清晰不焦虑” | 可用性测试/满意度评分 | 体现在原型动效、空状态、错误态设计 |
常见误区：将非功能需求和体验需求混为一谈。非功能面向系统质量（性能、安全、可用性），体验面向用户主观感受（易用、愉悦、清晰）。两者在验收标准和原型表达上差异显著，务必分开记录。
4.2 需求颗粒度原则
颗粒度决定需求的可执行性。过粗导致开发理解偏差，过细则陷入“需求清单即设计稿”的冗余陷阱。
- 单一职责原则：每个需求仅描述一个完整的能力或约束，不出现“同时…且…”的复合句式。
- 可验证原则：每个需求必须附带验收标准，验收条件应可测试、可度量、可观察。
- 层级对齐原则：遵循史诗 → 特性 → 用户故事 → 子任务四级分层，不同层级服务于不同角色。
| 层级 | 适用角色 | 颗粒度示例 | 对应原型阶段 |
|---|---|---|---|
| 史诗 | 产品总监/投资人 | “合同全生命周期管理” | 概念线框 |
| 特性 | 产品经理/交互设计 | “合同上传与自动解析” | 低保真原型 |
| 用户故事 | 开发/测试 | “作为法务，我上传PDF后能实时看到解析进度” | 高保真原型 |
| 子任务 | 开发人员 | “实现PDF文件格式校验（≤20MB，页数≤200）” | 原型交互细节标注 |
实操建议：在PRD中，功能清单统一使用用户故事层级书写。该层级既保留业务语义，又能直接对应Figma原型的一个独立页面或弹窗，方便开发和测试逐条核对。
4.3 功能清单模板
功能清单是需求拆解后的交付物核心，也是PRD与Figma原型之间的索引地图。每个清单项都应能追溯到用户场景，并指向具体的原型画板。
| 需求ID | 分类 | 需求描述（用户故事） | 优先级 | 关联原型画板 | 验收标准 |
|---|---|---|---|---|---|
| F-001 | 功能 | 作为法务，我可在合同详情页点击“下载原件”以获取原始PDF | P0 | 合同详情页 / v2.3 | 点击后浏览器下载包含原始水印的PDF文件 |
| NF-001 | 非功能 | 合同详情页加载时间≤1.5秒（含附件元数据） | P1 | 合同详情页 / 性能标注 | JMeter压测90%请求响应≤1.5s |
| E-001 | 体验 | 下载过程中页面展示进度条，用户可感知文件大小与剩余时间 | P2 | 合同详情页 / 下载交互原型 | 可用性测试中5/5用户可准确判断下载状态 |
模板字段说明：
- 需求ID：按分类前缀（F/NF/E）+ 三位序号编码，唯一且可排序。
- 分类：功能 / 非功能 / 体验，决定验收方式和原型表达深度。
- 关联原型画板：精确到Figma页面名称或画板ID，实现PRD→原型双向跳转。
- 验收标准：每条标准应可独立执行，不依赖其他需求上下文。
清单与原型映射：功能清单中的每一条“关联原型画板”字段，在Figma中对应一个命名画板。课程后续章节将演示如何在Figma中通过画板命名规范和原型链接实现清单与设计的一键追溯。
4.4 从拆解到清单的映射流程
下图概括了从用户场景出发，经业务问题定位、需求拆解分类，最终输出功能清单的完整路径。每个环节都对应具体的PRD章节和Figma原型阶段。
映射流程中的关键检查点：
- 用户场景是否真实：场景来源于用户访谈记录，未被产品经理主观臆造。
- 业务问题是否聚焦：每个场景聚焦一个核心痛点，不扩散。
- 拆解是否有遗漏：三类需求（功能/非功能/体验）均被覆盖，不存在“只写了功能，忘了非功能和体验”的情况。
- 清单是否可索引：每条需求ID在Figma原型中都能找到对应画板，画板命名与ID一致。
避坑提醒：功能清单不是需求堆砌。若一条需求同时包含“用户可上传文件”和“上传后自动触发解析”，应拆为两条——前者是功能需求，后者是包含非功能约束（解析时间）的独立需求。合并书写会导致验收时无法单独判定哪个环节失败。
4.5 需求拆解的自检清单
提交功能清单前，用以下条目逐项自检，确保拆解质量满足PRD交付标准：
- ✅ 每条需求都归属到功能/非功能/体验之一，无模糊地带。
- ✅ 每条需求都附带验收标准，标准不依赖其他需求上下文。
- ✅ 所有需求均能追溯到用户场景或业务问题，无凭空需求。
- ✅ 功能清单中的关联原型画板字段已填写，且画板在Figma中真实存在。
- ✅ 优先级标注清晰，P0/P1/P2 有明确的分界定义（如P0为上线阻塞项）。
- ✅ 非功能需求标注了具体指标（如响应时间≤1.5s，可用性≥99.9%），而非模糊表述。
- ✅ 体验需求包含可观测的行为标准（如“用户无需帮助即可在3步内完成”）。