在需求评审，测试需要关注的四类问题

参加需求评审时，我们一般通过业务场景、系统交互、功能点、项目，以上四个维度来进行问题的提出。

第一、业务场景中的用户故事方法论

通过业务场景中的用户故事方法论，即站在用户的角度去考虑用户会遇到的各种情况(包括当前场景分析下用户当前痛点/需求，和结合场景前后文预期用户需求/行为)，以及每一种情况是否有对应的场景描述及其结果展示；根据用户的使用场景是否有流程图展示各种场景对应的路径、执行的条件、约束的关系等是否有明确合理的定义。

第二、穷举系统

穷举系统，需要开发和测试人员共同把控，把已有的系统跟当前的需求进行对比，找出与需求实现相关的系统服务。在穷举系统中也需要考虑系统边界，如果系统边界划分不清晰会导致整个技术架构混乱。

第三、对系统的侵入性进行评估

系统原有数据有相关特性约定，由于新需求改变了数据的约束关系，导致系统要做数据结构范围内的整改，这种情况则需要对系统原有设计的侵入性进行评估；如果是非要对数据结构进行更改，则需要在设计的时候，尽量与原有模块的数据进行解耦。

第四，对需求的改动量及其必要性进行评估

比如有些需求，产品可能会认为只是实现一个小的功能点按钮，未考虑到技术实现会涉及到服务端多个模块，导致对该需求改动量评估过低。

第五、需求的流程

需求中存在多分支逻辑时，需要考虑各个分支描述是否全面、是否覆盖了所有分支路径。比如企业微信添加员工，在添加后是否自动邀请员工使用企业微信，邀请和不邀请对应的分支逻辑具体是什么；需求中对应功能存在多种状态时，对应功能的状态流转描述是否完整、是否合理；需求中的功能是否有权限描述。

第六、需求的优先级

对所提需求进行一个优先级的评估，是否为当前系统所必须。

第七、第三方系统对接确认

如果需求涉及到第三方系统，在评审时需要明确对接流程。

以上就是在需求评审会议时提出问题的几种方式。