在需求评审的过程中通过以下4个通用的角度来进行问题的发现：
一.业务场景角度
用户故事方法论
站在用户的角度，考虑用户会遇到的各种情况，从各种情况的需求中去匹配查看是否有对应的场景描述及结果展示。
业务流程图
根据用户的使用场景画出简单流程图，查看需求中是否对各种场景对应的路径、执行条件及约束关系 有明确、合理的定义。
二、系统交互角度
穷举系统
穷举系统，找出相关系统，把目前公司已有的系统都考虑一遍，对比当前需求，找出与其功能实现相关的系统服务。
产品只考虑前端交互，对应涉及后端多少个服务系统并不清楚，需要开发和测试人员找出涉及的系统；
系统边界
每个系统都有自己侧重实现点，产品只考虑该功能页面实现效果，但是对应是哪个开发组进行该功能开发产品不清楚，这就会导致当前需求的划分系统边界问题。
如果系统边界划分不清晰会最后导致整个技术架构混乱，所以，在需求评审时，测试需要提出让技术架构保持一个内聚的结构。
例子
企业微信增加新需求，获取考勤系统中员工的考勤异常记录并发送给该员工。
但是不同的公司会有不同的考勤系统，对应企业微信如果实现该功能则需要兼容市面上所有主流的考勤系统，对应的难度直接增大。
其实这就是对应系统之间的边界没有划分清晰，定制化的业务逻辑不要放在系统中。
企业微信要实现考勤异常记录发送给员工，应该实现一个开放式接口，去规定好考勤异常记录的消息模版，不同公司的考勤系统导出异常数据，填入企业微信规定好的模版内即可。
系统明确对应功能，比如企业微信主要是进行数据的管理及消息传递的动作
侵入性
原有系统有某些数据相关特性约定，由于新业务需求改变了之前的一些数据约定或者需要原系统做一个范围内的整改，这种情况就需要对该需求对系统原有设计的侵入性进行评估。
如果是非要对数据结构进行更改，则需要在设计的时候尽量与原有模块的数据进行解耦。
改动性
在需求评审的时候，需要对产品提出的需求所带来的改动进行必要性及改动量评估，有些需求由于产品经理不熟悉产品直接提出，但是有时对应产品有些公共通用组件就可以实现该需求。
所以，在产品提出需求时，需要对该需求的必要性进行评估。
有些需求，产品认为只是实现一个小的功能点按钮之类的，未考虑到技术实现会涉及到服务端多个模块，导致对该需求改动量评估过低的现象。
三、功能点角度
数据
有关需求中的数据内容，对应的约束是否比较全面，约束的条件是否规定的比较合理。
流程
需求中存在多种分支的逻辑情况时，对应的描述是否全面，是否覆盖了所有分支路径。
权限
需求对应的功能是否有对应权限描述。
比如审批，地区数据只能本地区人员可见，和上级可见，其他地区不可见。
四、项目角度
优先级
不是只要产品提出一个需求，就要进行开发上线，需要对该需求进行一个优先级的评估，是否为当前系统所必须；
如果有多个需求并发的话，需要对这些需求进行一个优先级排序。
deadline
需求不只是要排出对应的优先级，还需要对需求进行一个排期，对应开发周期及测试周期，还有最终的该需求的上线日期。
第三方系统对接确认
如果需求涉及到与第三方系统进行交互，则在需求评审时需要产品明确对接流程。
作为一个测试人员在开需求评审会时，大致需要通过以上几个通用角度来进行考虑。