第4章 需求功能点拆分规范
4.1 适用场景
- PRD 初稿完成、进入开发排期前，需将粗粒度需求拆解为可独立估时、开发、测试的原子功能点。
- 多人协作的大型 PRD，需要统一功能点标识以便跨团队沟通和追踪需求变更。
- 当需求之间存在前序/后序或数据依赖时，必须显式标记依赖关系，避免开发阻塞或返工。
4.2 前置条件
| 编号 | 条件 | 说明 |
|---|
| 1 | PRD 已通过内部评审 | 业务逻辑、用户故事、验收标准已初步确认 |
| 2 | 需求列表已按模块归类 | 至少包含模块名称、需求描述、优先级 |
| 3 | 已有产品架构图或系统交互图 | 用于辅助判断功能点边界及依赖方向 |
| 4 | 团队已约定编码前缀规则 | 例如模块代码+序号（如 LOG-001） |
4.3 操作步骤
- 确定颗粒度标准：每个功能点应是 单个用户可完成的独立操作（如“登录页-短信验证码输入框”），避免合并多个操作或拆到字段级。
- 为每个功能点分配唯一 ID：按照
模块代码-三位序号 格式（例 ORDER-042），不允许跳号或重复。
- 填写功能点描述与验收边界：一行描述，明确输入、操作、预期输出。
- 标记依赖关系：使用
Depends-On: ID 或依赖矩阵，指明前置功能点。示例：
功能ID: ADDR-003
描述: 地址选择器-从已有地址列表中选择默认地址
Depends-On: ADDR-001, AUTH-010
- 生成功能点清单：输出为可校验的表格或 JSON 结构，供开发/测试团队使用。
4.4 输入输出物
| 类型 | 名称 | 描述 |
|---|
| 输入 | 已评审 PRD / 需求列表 | 包含模块、功能标题、详细描述 |
| 输入 | 产品架构图 | 模块依赖关系可视化参考 |
| 输出 | 功能ID清单（Excel/JSON） | 含 ID、名称、描述、依赖列表、负责人 |
| 输出 | 依赖关系图/矩阵 | 清晰展示功能点间的顺序或数据依赖 |
提示：功能点清单建议版本控制（Git + Markdown/CSV），每次变更通过 PR 审核，避免 ID 混乱。
4.5 责任边界
- 产品经理： 主导功能点拆分，定义颗粒度、编码规则、依赖关系，输出最终清单。
- 开发负责人： 参与依赖关系评审，确保技术可行性，补充隐式依赖。
- 测试负责人： 确认功能点可测试性，标记影响测试用例的依赖。
- 项目管理人员： 维护功能 ID 登记簿，确保唯一性与版本一致性。
4.6 记录材料
- 功能ID登记表：包含 ID、模块、描述、依赖、创建人、创建日期、状态。
- 依赖关系表：二维矩阵，行/列均为功能ID，交叉格标记依赖类型（前置/数据/引用）。
- 变更日志：每次新增/修改/删除功能点均需记录原因、决策、影响范围。
4.7 异常处理
| 异常场景 | 处理方案 |
|---|
| 功能点粒度过大（一个功能点包含多个独立操作） | 退回产品经理重新拆分至原子操作，不可合并为“登录模块”这样的粗粒度节点。 |
| 功能点粒度过小（拆分到字段级如“输入框内阴影颜色”） | 合并至上一级操作，或作为前置条件的细节说明，避免 ID 爆炸。 |
| 依赖冲突（A→B 且 B→A 形成循环依赖） | 暂停该组功能点评审，由产品+技术重划依赖路径或合并为同一功能点。 |
| ID 重复或跳号 | 使用自动编号工具或 CI 脚本检查，发现后重置序号段并通知所有成员更新引用。 |
| 依赖未标注导致开发阻塞 | 项目管理人员每日同步，发现未标记依赖的 PRD 片段要求补标后方可进入开发。 |
4.8 验收标准
- 所有功能点均已获得唯一 ID，且遵循
模块代码-XXX 格式。
- 每个功能点描述清晰，包含输入、操作、预期结果，无歧义。
- 依赖关系表无循环依赖、无未标记的隐藏依赖。
- 功能ID清单已通过产品、开发、测试三方评审并签字确认。
- 清单已上传至项目共享空间（如 Confluence / GitLab Wiki），版本号与 PRD 一致。
警惕：跳过依赖标记直接开发，可能导致后端接口未就绪、前端无法调试等问题。在开发排期会上必须逐条确认依赖状态。
4.9 功能点拆分流程（SVG）