需求边界评审总体流程

适用场景

需求边界评审适用于机器人产品开发周期中的以下典型场景：

• 新立项的机器人整机产品需求文档（PRD）初版完成时
• 重大功能变更或扩展（如新增视觉导航、机械臂控制）影响原边界定义时
• 跨部门（硬件、软件、算法、测试、市场）对需求理解存在显著分歧时
• 项目进入详细设计前，必须冻结需求边界并锁定资源投入时

前置条件

需求边界评审启动前必须满足以下条件：

• 产品经理已完成《机器人产品需求规格说明书》初稿，并通过内部预审
• 核心干系人（硬件负责人、软件负责人、测试负责人）已分配并确认参与
• 至少提前 2 个工作日将需求文档和评审议题发送至所有评审参与人
• 评审会议室/在线会议工具已预定，且具备白板或共享屏幕功能

操作步骤（泳道流程）

需求边界评审按以下泳道流程执行，各角色责任明确：

1. 触发条件判断（产品经理）：检查前置条件是否满足，若满足则发起评审预约；若不满足则退回补充。
2. 提交评审材料（产品经理）：将《需求规格说明书》、边界定义清单、验收初步标准发送至评审组。
3. 预审与问题收集（评审组）：各角色（硬件、软件、测试、市场）独立阅读文档，记录模糊或矛盾点。
4. 召开评审会议（产品经理主持）：逐条过需求边界，重点讨论触发条件、输入输出物、责任边界；形成新增/修改/删除的决议。
5. 记录与确认（产品经理/记录员）：使用《需求边界评审记录表》记录所有决议、待办项、责任人及截止日期；评审组当场签字/确认。
6. 验收与发布（产品经理）：所有待办项闭环后，更新需求文档，锁定边界版本号，发布至项目基线库。

输入输出物

类别	名称	格式/载体	说明
输入	《机器人产品需求规格说明书》	PDF / 在线文档	包含功能需求、性能指标、接口定义、边界约束
输入	需求边界定义清单	表格（Excel/在线表单）	明确哪些属于当前版本、哪些属于后续版本、哪些明确排除
输入	验收初步标准草案	文档	定义每项需求的通过/失败判据
输出	《需求边界评审记录表》	PDF / 在线表单	含评审日期、参与人、议题、决议、待办项、签字
输出	更新后的需求规格说明书	版本号 V2.0+	锁定边界、增加评审备注、修改标记
输出	待办项跟踪清单	Jira / 任务管理	每项待办关联责任人、截止日、状态

责任边界

角色	职责	权限边界
产品经理	主持评审、提交材料、记录决议、发布基线	不得私自调整已冻结的边界定义
硬件工程师	评估硬件资源约束、功耗、接口可行性	可对影响硬件选型的需求提出否决或延迟
软件工程师	评估算法与软件架构复杂度、性能瓶颈	可对不合理计算资源需求提出修改建议
测试工程师	评估可测试性、测试环境搭建成本	可对不能充分验证的需求要求补充规范
市场/销售代表	提供客户真实场景、竞品对标信息	不可直接决定技术实现方案，仅提供输入

记录材料

• 《需求边界评审会议纪要》——格式：时间、地点、参与人、会议议程、每项讨论结果、待办项。
• 《需求边界变更申请单》——如评审中发生边界调整，需填写此单，注明原边界、新边界、原因、影响范围。
• 现场白板/电子白板截图——保留讨论中的关键草图、流程图等视觉记录。

异常处理

异常类型	触发条件	处理方式
关键角色缺席	硬件/软件/测试负责人未出席	暂停评审，重新安排时间；不可缺人审议其负责领域
需求文档预审未通过	超过 2 人提出文档不完整或逻辑矛盾	退回产品经理修改，再次预审后方可召开正式会议
边界无法达成共识	45 分钟过 1 个需求仍无结论	记录双方观点，升级至项目总监决策，24 小时内回复
评审记录丢失	会议记录未在 24h 内上传	产品经理需直播回放或笔记手动补录，并承担通报责任

验收标准

一次成功的需求边界评审应符合以下所有标准：

• 所有参与人在《需求边界评审记录表》上签字确认（如不在场则事后 1 个工作日内邮件确认）。
• 所有待办项均有明确的责任人、截止日期和可验证的输出。
• 更新后的需求规格说明书版本号已升版，并标注“已评审·边界冻结”。
• 评审会议纪要中无任何未关闭的争议项（已升级或已关闭）。
• 基线库中已上传最终版文档，且权限可见范围正确。