2. 需求澄清与验证目标对齐

适用场景

• 产品需求文档（PRD）初稿完成，进入技术评审阶段
• 硬件原型启动前，需将业务需求转化为可验证的技术指标
• 跨职能团队（产品、硬件、测试）首次对齐验证目标
• 已有历史项目需求复用，需评估其在新产品中的可测性与覆盖范围

前置条件

• 已输出初步《产品需求规格说明书》或同等效力需求列表
• 已确定产品关键用例（Use Case）及验收标准初稿
• 项目角色（产品经理、系统架构师、硬件负责人、验证负责人）已确认
• 需求管理工具（如 Jira、Confluence、飞书文档）已就绪

操作步骤

Step 1：需求清单梳理

1. 收集原始需求：从 PRD、竞品分析、客户反馈、法规标准等渠道汇总所有需求条目。
2. 结构化编号：为每条需求分配唯一 ID，格式建议 REQ-XXX，并标注来源。
3. 分类打标：按类型标注——功能需求（F）、性能需求（P）、硬件需求（H）、安全需求（S）、接口需求（I）。
4. 优先级评定：由产品经理与系统架构师共同确认 P0/P1/P2 优先级。
5. 输出清单：生成《需求清单（初版）》，进入下一步可测性检查。

Step 2：可测性检查

1. 逐条审查：验证工程师与硬件工程师共同逐条审查需求的可测性。
2. 判定标准：是否具备明确的测量指标、测试方法、判定阈值；是否可在原型阶段搭建测试环境。
3. 标记结果：在需求清单中增加“可测性”列，标记为 可测 或 不可测。
4. 不可测处理：对标记为“不可测”的需求，提出修改建议并返回产品经理修正描述或指标。

Step 3：验证范围界定

1. 汇总可测需求：将 Step 2 中标记为“可测”的需求全部纳入候选验证范围。
2. 资源约束评估：结合项目周期、样机数量、测试设备资源，判断是否可全覆盖。
3. 范围分级：按优先级和资源情况，将验证范围分为 必测（P0 全量 + P1 关键项）、选测（P1 非关键 + P2 部分）、延后（P2 剩余项或依赖后续版本）。
4. 对齐确认：组织产品、硬件、验证三方评审会，确认最终《验证范围界定书》。

输入输出物

责任边界

记录材料

• 需求清单模板：包含 ID、需求描述、类型、优先级、可测性标记、状态。
• 可测性检查记录表：每条需求的检查项、判定依据、结论、修改建议。
• 验证范围界定书模板：必测/选测/延后三级分类，附带资源匹配说明。
• 三方评审会议纪要：记录争议点、决策结论、待办事项。

【需求清单示例片段】
REQ-001 | 温度采集周期    | 温度传感器每10秒上报一次数据        | F | P0 | 可测
REQ-002 | 续航时间        | 电池续航 ≥ 72 小时（连续工作模式）   | P | P0 | 可测
REQ-003 | 防护等级        | 整机防护等级 ≥ IP65                 | H | P1 | 不可测（需明确测试标准）
REQ-004 | OTA升级成功率   | OTA升级成功率 ≥ 99.5%               | P | P0 | 可测
REQ-005 | 极端温度工作    | -20°C ~ 60°C 环境下正常工作          | H | P1 | 可测

异常处理

验收标准

• 需求清单完整性：所有已识别需求均被收录，无遗漏；每条需求均包含 ID、描述、类型、优先级、可测性标记。
• 可测性检查通过率：P0 需求 100% 通过可测性检查；P1 需求通过率 ≥ 90%。
• 范围界定明确：验证范围界定书经过产品、硬件、验证三方签字确认，必测/选测/延后分类清晰可执行。
• 文档归档：需求清单、可测性检查报告、范围界定书、会议纪要全部上传至项目知识库，版本号一致。
• 可追溯：每条可测需求均可追溯到对应的测试用例或验证方法，形成双向追溯矩阵初稿。