第3章 产品需求规格（PRD）评审：确认功能列表、性能指标、交互原型、验收标准

PRD评审是硬件产品开发从概念阶段进入设计阶段的关键质量闸门。本章围绕PRD文档的四大核心要素——功能列表、性能指标、交互原型、验收标准，建立标准化的评审操作流程，确保需求在进入详细设计前被充分确认、无歧义、可验证。

3.1 适用场景

• 新产品立项完成后：市场调研与产品定义初稿已输出，需要形成正式PRD文档。
• 重大需求变更触发：原PRD中功能/性能/交互发生实质性调整，需重新评审确认。
• 竞品对标后需求刷新：竞品分析发现关键差距，需补充或修改已有需求条目。
• 跨代际产品迭代：在上一代产品基础上进行功能增删或性能升级。
• 定制化/OEM项目启动：客户需求明确，需将客户输入转化为内部PRD并评审锁定。

3.2 前置条件

3.3 操作步骤

PRD评审按以下 7个子步骤 逐项执行，每个步骤由指定角色主导并形成阶段性结论。

1. 需求条目完整性核查：产品经理逐条宣读功能列表，评审组对照用户场景清单与市场定义文档，确认无遗漏核心场景。
2. 功能依赖与冲突分析：系统工程师识别功能间互斥或强依赖关系（如多传感器并发采集与总线带宽冲突），标记需调整的条目。
3. 性能指标可测性评审：测试工程师针对每条性能指标（如功耗、响应延迟、测量精度）确认是否有明确测试方法与设备资源。
4. 交互原型走查与确认：交互设计师演示高保真原型，评审组从操作路径、反馈逻辑、异常提示三个维度给出意见。
5. 验收标准对齐：项目经理逐条核对验收标准与功能/性能/交互的对应关系，确保每条标准可量化、可验证。
6. 风险评估与优先级裁定：硬件负责人与软件负责人联合评估需求实现风险，输出需求优先级-风险矩阵。
7. 评审结论签署：全体评审人投票，结论分为“通过”、“有条件通过（记录遗留项）”、“不通过（需二次评审）”。

3.4 输入输出物

3.5 责任边界

3.6 记录材料

评审过程需完整记录以下材料，归档至项目Wiki或受控文档库，保存期限不少于产品生命周期+2年：

• PRD评审会议纪要：包含时间、地点、参会人、逐条评审意见、结论、遗留项、责任人、计划关闭日期。
• 需求变更跟踪表：记录评审中所有修改/新增/删除的需求条目，标注变更原因与发起人。
• 可测性评估表：每条性能指标的测试方法、测试设备、测试工况、预期值、实际值（预留列）。
• 评审签到与投票记录：各角色签字或电子签名，投票结果（通过/有条件通过/不通过）需存档。
• 交互原型评审标记版：标注了评审意见的原型文件或截图，附修改标记与责任人。

归档文件命名规范示例：
PRD_v2.1_R3_评审纪要_2025-03-21.pdf
PRD_v2.1_R3_需求变更跟踪表.xlsx
PRD_v2.1_R3_可测性评估表.xlsx
PRD_v2.1_R3_原型评审标记版.png

3.7 异常处理

3.8 验收标准

本章（PRD评审流程）的验收标准用于衡量评审工作本身是否被有效执行，而非PRD文档的验收。满足以下全部条件方可认定本章流程执行通过：

• 完整性检查：PRD文档已包含功能列表、性能指标、交互原型、验收标准四个独立章节，且每章节均通过评审会逐条审议。
• 可测性确认：所有性能指标均附有明确的测试方法、测试设备、测试工况，且测试负责人已签署“可测”意见。
• 原型确认：交互原型已根据可用性走查意见修改，且评审会上无功能性逻辑异议。
• 验收标准对齐：每条验收标准均可追溯到具体的功能或性能条目，形成需求-验收双向追溯矩阵。
• 遗留项管理：所有“有条件通过”的遗留项均已指定责任人、计划关闭日期，并录入跟踪表。
• 文档归档：评审纪要、变更跟踪表、可测性评估表、原型标记版、签到投票记录等材料齐全，命名规范。