3. 功能与非功能需求拆解

适用场景

本章适用于以下典型场景：

• PRD 初稿完成，需要将笼统的需求描述拆解为可落地、可验证的功能与非功能条目。
• 技术方案评审前，产品经理与研发/测试对齐需求边界，避免遗漏非功能约束。
• 验收标准编写前，必须先行完成需求分类，才能为每类需求匹配对应的验收方法。
• 需求变更或迭代时，快速识别新增需求属于功能类还是非功能类，评估影响范围。

前置条件

• 已有一份经过初步评审的 PRD 文档（包含需求描述、业务目标、用户故事或用例）。
• 已确认 需求颗粒度基准（例如：每个需求条目应独立可测、不可再分）。
• 参与拆解的角色（产品经理、技术负责人、测试负责人）已明确并到位。
• 已准备 需求分类检查表（本章提供模板）和记录工具（Wiki / 文档 / 电子表格）。

操作步骤

步骤1：逐条标记需求类型

将 PRD 中的每条需求描述读一遍，判断其核心属性：

• 功能需求：系统“做什么”——用户操作、业务逻辑、数据流转、界面交互。
• 非功能需求：系统“做得怎么样”——性能、安全、可用性、可维护性、兼容性。

步骤2：功能需求子类拆解

将标记为“功能需求”的条目，按以下维度进一步归类：

步骤3：非功能需求子类拆解

将标记为“非功能需求”的条目，按以下维度归类：

步骤4：交叉验证与边界对齐

组织产品、研发、测试三方进行快速核对：

• 是否有需求同时包含功能和非功能属性？拆分为两条独立条目，分别归类。
• 是否有需求描述模糊，无法判断类型？退回补充，直至满足分类条件。
• 是否有明显的非功能需求缺失（如性能指标、安全要求）？补充录入。

步骤5：输出需求分类矩阵

将已归类并验证过的所有需求条目整理为结构化表格，作为后续编写验收标准的唯一输入源。

分类矩阵至少包含以下列：需求编号、需求描述、所属主类（功能/非功能）、子类、优先级、来源PRD章节。

输入输出物

责任边界

记录材料

使用以下模板记录每条需求的拆解结果：

需求编号：REQ-0037
需求描述：用户登录成功后 2 秒内跳转至首页
主类：非功能需求
子类：性能
优先级：P1
来源章节：4.2 用户登录
备注：需明确 2 秒是 95 分位还是平均值

所有记录材料统一存放在项目 Wiki 或共享文档中，版本号与 PRD 保持一致。

异常处理

验收标准

需求拆解工作完成时，必须满足以下所有标准才算合格：

• 每个需求条目只属于 一个主类（功能或非功能），无遗漏、无重叠。
• 所有非功能需求均包含 可量化指标或明确约束，不接受“高性能”“高安全”等模糊描述。
• 需求分类矩阵已通过 产品 + 技术 + 测试 三方会签确认。
• 拆解过程记录完整，所有争议点均有结论，且结论可追溯。
• 分类矩阵中的每个需求均可 直接映射到后续的验收标准，无需再次解释或补充。

附：功能与非功能需求检查表

在完成拆解后，逐项核对以下清单，确保无遗漏：

所有检查项打 ✓ 后，需求分类矩阵方可进入下一阶段（验收标准编写）。