需求评审清单需要包含哪些信息

需求评审清单要能支撑一场可判断、可留痕的评审，核心信息分五类：评审对象与版本、参与角色与职责、需求内容检查项、评审结论与遗留问题、证据与归档要求。每项检查都要写明通过标准、证据形式和负责人；验收标准缺失、关键干系人未确认、重大依赖未澄清等情况应列为阻断项。下文按会前、会中、会后给出可直接使用的检查表。

要点总览（TL;DR）

• 需求评审清单应覆盖五类信息：评审对象与版本、参与角色与职责、需求内容检查项、评审结论与遗留问题、证据与归档要求。
• 每项检查都要写明通过标准、证据形式和负责人，通过标准要可观察、可判断，避免“描述清晰”这类无法核验的表述。
• 验收标准缺失或不可验证、关键干系人未确认、重大依赖未澄清、范围与目标冲突属于阻断项，未解决不能判定评审通过。
• 评审结论限定为通过、有条件通过、退回修改三类；遗留问题台账记录问题、负责人、期限、状态和关闭证据。
• 评审完成需同时满足三条：结论明确、遗留问题有负责人和期限、评审记录与需求文档已归档。

谁在什么时点使用这份清单

这份清单服务于需求进入开发排期前的评审会，以及评审后的复核环节。它解决的是“谁在什么时候核对什么”，不替代需求文档本身。使用前需满足两个前提：需求文档已有初稿，评审材料已提前发出。

使用角色	主要使用时点	关注重点
需求提出人	会前准备、会上答疑	背景目标、范围边界、待决问题是否交代清楚
产品负责人	会前自检、会上主持、会后归档	内容完整性、结论记录、遗留问题指派
研发代表	会上评估、会后复核	功能描述、接口依赖、技术约束与风险
测试代表	会上评估、会后复核	验收标准是否可验证、测试要点是否明确
业务方代表	会上确认	业务目标、优先级、范围是否符合预期

评审后的复核同样使用这份清单：对照遗留问题台账逐项确认关闭情况，再决定是否放行进入排期。清单在会前由产品负责人发起自检，会上由主持人逐项过表，会后由记录人补齐结论与证据位置。

评审前准备检查项

会前检查的目标是让评审会聚焦判断，而非现场补信息。以下各项在会议通知发出前完成核对，未通过项应在会前解决或明确列为会上待决问题。

检查项	通过标准	证据形式	负责人
需求文档版本与变更记录	文档有明确版本号，本次变更内容有记录，评审对象指向唯一版本	文档版本页、变更记录条目	需求提出人
背景与目标	写明业务背景、要解决的问题、可衡量的目标	需求文档对应章节	需求提出人
范围边界	明确本次做什么、不做什么，边界可被参会人理解	范围说明段落或列表	产品负责人
验收标准	每条标准可观察、可判断，能对应到测试验证方式	验收标准列表、测试要点	需求提出人与测试代表
评审材料与参会人	材料在会前约定时间发出，参会角色齐全	会议通知、材料发送记录	产品负责人
待决问题清单	已列出需要会上决策的问题，并注明期望决策人	待决问题列表	需求提出人

会前检查发现验收标准缺失或范围描述含糊时，优先补充材料再开会；确实无法会前解决的，把问题带入待决清单，在会上明确由谁决策、何时给出结论。

评审会上的内容检查项

会上按需求内容维度逐项确认，每项给出明确判断，避免以“大家没意见”代替确认。下表覆盖清单需要包含的核心信息。

内容维度	检查要点	确认方式
业务背景与目标	背景与目标一致，目标可衡量，与业务方预期吻合	业务方代表口头确认并记录
范围与非目标	范围内条目清晰，非目标明确列出，无歧义	逐条过范围列表
功能描述与关键流程	主流程、异常流程描述完整，角色与操作可对应	研发与测试提问确认
验收标准与测试要点	每条验收标准可验证，测试要点覆盖主要场景	测试代表逐条判断
优先级与排期意向	需求优先级有依据，排期意向与资源情况不冲突	产品负责人与研发共同确认
依赖、接口与外部约束	外部系统、接口、数据依赖已识别，约束条件写明	研发代表确认依赖方与时间
风险与假设	主要风险有应对思路，关键假设写明并有人验证	会上记录风险条目与责任人
干系人确认情况	关键干系人已到场或书面确认，未确认的明确补确认方式	签到记录、书面确认记录

会上确认的结果直接写入评审记录：通过的维度标注确认人，存在分歧的维度转为待决问题或遗留问题，涉及阻断条件的按下一节处理。

每项检查的通过标准与证据

检查项能否勾选，取决于通过标准是否可观察、可判断。写法上避免“描述清晰”“考虑周全”这类无法核验的表述，改为指向具体产物或具体判断动作。

检查项	通过标准示例	证据形式	负责人	检查时点
验收标准可验证	每条标准能对应至少一个测试场景，测试代表判断可执行	验收标准列表与测试要点对照	测试代表	会前自检、会上确认
范围边界明确	范围内与非目标各有条目，参会人无新增歧义提问	范围章节、会议记录	产品负责人	会上确认
依赖已澄清	每个外部依赖有对接方、接口形式和时间预期	依赖清单、对接记录	研发代表	会上确认
关键干系人确认	关键角色到场或有书面确认，确认内容可追溯	签到表、确认消息记录	产品负责人	会上及会后补确认

负责人一栏写具体角色或姓名，检查时点标注“会前”“会上”“会后复核”之一。未通过的检查项不直接打叉了事，而是记录未通过原因、处理方式和跟进人，转入遗留问题台账或阻断项清单。

阻断项与评审完成条件

阻断项指未解决就不能判定评审通过的事项。它们与普通遗留问题的区别在于：阻断项影响需求能否进入排期，遗留问题可以在有条件通过后按期限跟进。

类别	典型情形	处理方式
阻断项	验收标准缺失或不可验证	退回补充，重新评审对应部分
阻断项	关键干系人未确认	补确认后再判定结论
阻断项	重大依赖未澄清	明确对接方与时间前不通过
阻断项	范围与目标冲突	先解决冲突，再确认范围
非阻断项	次要流程描述待补充、文案细节待定	记录为遗留问题，指定负责人和期限

评审完成的判定条件有三条同时满足：结论明确为通过、有条件通过或退回修改；遗留问题均有负责人和期限；评审记录与需求文档已归档到约定位置。三条缺一，评审视为未完成。

评审结论与归档怎么记录

评审结论限定为三类，避免出现“基本通过”这类模糊表述。结论与遗留问题、文档版本一起记录，形成可复核的闭环。

结论类型	适用情形	后续动作
通过	无阻断项，遗留问题不影响排期	进入排期，遗留问题按台账跟进
有条件通过	无阻断项，但存在需限期关闭的遗留问题	明确关闭期限，到期复核后放行
退回修改	存在阻断项	修改后重新提交评审

遗留问题台账建议包含以下字段：问题描述、来源检查项、负责人、期限、状态、关闭证据。状态用“待处理、处理中、已关闭”三档即可，关闭时附上证据位置。

归档要求写明需求文档版本号、评审记录位置和归档责任人。后续复核时点与遗留问题期限挂钩，到期由产品负责人对照台账逐项确认，关闭情况回写到评审记录中。评审结论、遗留问题状态和文档版本需要在团队共用的地方留痕，便于研发、测试和业务方按同一版本协作；在ONES中可将评审记录与需求工作项关联，把结论、遗留问题和版本变更保存在同一处，减少口头结论与文档脱节的情况，具体字段和流程按团队实际配置设置。

常见问题

需求评审会上出现分歧，当场无法达成一致怎么办？

把分歧转为待决问题或遗留问题，记录分歧点、各方意见和期望决策人，不要用“大家没意见”代替确认。若分歧涉及验收标准、关键干系人确认、重大依赖或范围与目标冲突，按阻断项处理，先解决再判定结论；其余分歧可记录为遗留问题，明确负责人和期限后按有条件通过跟进。

需求评审清单和方案原型评审清单可以共用一份吗？

不建议共用。需求评审清单关注需求本身是否讲清楚：背景目标、范围边界、验收标准、依赖与风险、干系人确认。方案原型评审关注交互与视觉方案是否可行，检查项和参与角色不同。两份清单可以共享版本记录和结论归档的格式，但检查内容应分开维护，避免评审会上把需求判断和方案判断混在一起。

小团队需求少，还需要完整的评审清单吗？

可以精简，但阻断项和结论记录建议保留。小团队可把会前准备检查项合并为几项核心核对，例如版本、背景目标、验收标准、待决问题；会上内容检查按需求复杂度取舍。验收标准缺失、关键干系人未确认、重大依赖未澄清这三类阻断项仍应保留，因为它们直接影响后续开发和测试能否顺利推进。结论和遗留问题即使只记在一处共享文档里，也要有负责人和期限。

遗留问题到期未关闭，评审结论还算数吗？

“有条件通过”的结论以遗留问题按期关闭为前提。到期复核时未关闭的，由产品负责人对照台账确认原因：属于客观延期且不影响排期的，更新期限并记录；属于阻断性质的，应把结论调整为退回修改，重新评审对应部分。复核结果回写到评审记录，保持结论与台账状态一致。

评审记录和需求文档版本对不上，怎么处理？

以评审时确认的版本为准，在评审记录中写明需求文档版本号和归档位置。会后需求文档发生变更的，走变更记录并标注是否影响已确认的验收标准、范围或依赖；影响阻断项内容的，需要补充确认或重新评审对应部分。归档责任人负责核对评审记录与文档版本的一致性，避免研发和测试按不同版本推进。