4. 验证目标与范围定义

4.1 适用场景

本环节适用于以下情况：

• 新建功能原型：首次提交的 MVP 或 Demo 版本
• 关键迭代节点：用户反馈整改后的大版本更新
• 风险控制节点：涉及核心逻辑、性能、安全改造的中间版本
• 验收提交前：向业务方或客户正式演示前的最终验证轮次

4.2 前置条件

4.3 核心流程：验证目标与范围定义

下图为验证目标与范围定义的标准工作流：

4.4 验证目的书写模板

每个验证目的必须包含 “期望行为 + 衡量指标 + 验收方” 三个要素。标准书写模板如下：

要素	书写规范	示例
期望行为	明确描述原型应满足的用户操作或系统响应	用户可在3步内完成支付
衡量指标	可量化的标准（时间、成功率、覆盖率等）	成功率 ≥ 99%
验收方	负责确认该目标是否达成的角色或角色组	产品经理 + 测试代表

完整书写模板（Markdown 格式）：

## 验证目的 [ID]
- **期望行为**：[描述用户或系统在原型中应完成的操作]
- **衡量指标**：[具体的数字或速率标准]
- **验收方**：[角色名称]

4.5 功能点清单

功能点清单应覆盖所有待验证的交互、逻辑和数据处理点。按以下结构组织：

1. 功能模块：归属的上层模块名（如：登录模块、购物车模块）
2. 功能描述：一句话说明功能目的
3. 功能类型：新增 / 修改 / 修复 / 优化
4. 关联需求 ID：对应 PRD 中的需求编号

4.6 边界条件

边界条件定义了验证的 适用范围 和 排除范围。分为两类：

类别	说明	示例
包含条件	本次验证必须涵盖的场景或数据范围	Android 9.0 及以上、网络延迟 ≤ 200ms
排除条件	明确不在验证范围内的内容	iOS 端、多语言适配、管理员后台

4.7 优先级标注规则

优先级采用 P0 / P1 / P2 三级标注体系：

优先级	定义	典型场景	验收要求
P0	核心功能，必须通过	登录、支付、关键流程断点	一票否决，不可阻塞
P1	重要功能，建议通过	列表展示、搜索、基础交互	可允许小缺陷但不影响主干
P2	辅助功能，可后续优化	视觉细节、非高频操作	通过非必须，可放入 lower backlog

4.8 操作步骤

1. 步骤 1：编写验证目的
   组织产品、设计、测试三方团队，按 4.4 模板书写每个验证目的，每个目的独立编号。
2. 步骤 2：罗列功能点清单
   基于 PRD 和原型拆解功能点，归类到模块下，同步关联需求 ID。
3. 步骤 3：界定边界条件
   明确包含条件与排除条件，由技术负责人签字确认。
4. 步骤 4：标注优先级
   使用 P0/P1/P2 规则对每个功能点进行优先级标注，标注人须为项目负责人。
5. 步骤 5：产出《验证范围定义表》
   将以上内容整合输出，作为后续验证执行的唯一依据。

4.9 输入输出物

类别	名称	责任方
输入	原型交付物、PRD、上一轮验证报告（可选）	产品经理 / 设计师
输出	《验证范围定义表》	项目负责人

4.10 责任边界

• 产品经理：提供 PRD 及原型，明确业务价值目标
• 设计师：确保原型交互与 PRD 一致
• 测试负责人：参与书写验证目的，把关可测试性
• 技术负责人：确认边界条件的技术可行性
• 项目负责人：最终审核《验证范围定义表》

4.11 记录材料

所有过程记录归档至版本管理平台（如 Confluence / 飞书文档），文件名规范：

[项目名]_验证范围定义表_v[版本号]_[日期].xlsx
示例：NovaPay_验证范围定义表_v2.3_2025-04-21.xlsx

4.12 异常处理

异常情况	处理策略
边界条件与 PRD 冲突	以 PRD 为准，记录差异并通知产品经理
优先级标注不一致	组织评审会议，投票决定最终优先级
功能点清单遗漏	在后续验证轮次中补充，当前轮次不做新增
验收方无法确认	由项目负责人指定临时验收方，并记录责任归属

4.13 验收标准

• 所有验证目的已按模板规范书写，并包含三要素
• 功能点清单完整覆盖本次迭代的所有变更
• 边界条件清晰记录包含与排除范围
• 每个功能点已标注 P0/P1/P2 优先级
• 《验证范围定义表》已由项目负责人签字或电子签章