面试官问题

• 在需求评审会议中，你会发现什么问题？

• 在需求评审时，是通过哪几个角度来进行考虑及发现问题的？

考察点

• 是否参加过需求评审

• 在需求评审过程中是否能提出有效的问题

4个角度发现问题

在需求评审的过程中通过以下4个通用的角度来进行问题的发现：

业务场景角度

用户故事方法论

站在用户的角度，考虑用户会遇到的各种情况，从各种情况的需求中去匹配查看是否有对应的场景描述及结果展示。

例子

比如，企业微信添加部门这个功能的需求评审，我们不能只考虑对应的部门可以添加成功，还需要考虑以下几点是否有相关说明：

1、在已有的部门下添加子部门，如何展示，对应层级关系/父子关系是否明确

2、对应修改部门的信息，是否子部门的关联相关信息也进行修改

3、删除部门的时候是否校验包含子部门及成员

4、是否有部门查询功能

业务流程图

根据用户的使用场景画出简单流程图，查看需求中是否对各种场景对应的路径、执行条件及约束关系 有明确、合理的定义。

系统交互角度

穷举系统：穷举系统，找出相关系统

开发和测试人员共同把控，把目前公司已有的系统都考虑一遍，对比当前需求，找出与其功能实现相关的系统服务。

产品只考虑前端交互，对应涉及后端多少个服务系统并不清楚，需要开发和测试人员找出涉及的系统；

例子

产品提出的需求对应只涉及当前A、B两个系统交互进行开发，但是测试时发现由于上下游系统未被考虑进需求，导致无法按需求的期望整体业务流转。

系统边界

每个系统都有自己侧重实现点，产品只考虑该功能页面实现效果，但是对应是哪个开发组进行该功能开发产品不清楚，这就会导致当前需求的划分系统边界问题。

如果系统边界划分不清晰会最后导致整个技术架构混乱，所以，在需求评审时，测试需要提出让技术架构保持一个内聚的结构。

例子

企业微信增加新需求，获取考勤系统中员工的考勤异常记录并发送给该员工。

但是不同的公司会有不同的考勤系统，对应企业微信如果实现该功能则需要兼容市面上所有主流的考勤系统，对应的难度直接增大。

其实这就是对应系统之间的边界没有划分清晰，定制化的业务逻辑不要放在系统中。

企业微信要实现考勤异常记录发送给员工，应该实现一个开放式接口，去规定好考勤异常记录的消息模版，不同公司的考勤系统导出异常数据，填入企业微信规定好的模版内即可。

系统明确对应功能，比如企业微信主要是进行数据的管理及消息传递的动作

侵入性

原有系统有某些数据相关特性约定，由于新业务需求改变了之前的一些数据约定或者需要愿系统做一个范围内的整改，这种情况就需要对该需求对系统原有设计的侵入性进行评估。

如果是非要对数据结构进行更改，则需要在设计的时候尽量与原有模块的数据进行解耦。

改动性

在需求评审的时候，需要对产品提出的需求所带来的改动进行必要性及改动量评估，有些需求由于产品经理不熟悉产品直接提出，但是有时对应产品有些公共通用组件就可以实现该需求。

所以，在产品提出需求时，需要对该需求的必要性进行评估。

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

功能点角度

数据

有关需求中的数据内容，对应的约束是否比较全面，约束的条件是否规定的比较合理。

流程

需求中存在多种分支的逻辑情况时，对应的描述是否全面，是否覆盖了所有分支路径。

比如企业微信添加员工，在添加后是否自动邀请该员工使用企业微信，邀请和不邀请对应的分支逻辑具体是什么。

需求中对应功能存在多种状态时，对应功能的状态流转描述是否完整并且合理。

比如审批流，对应审批中、审批失败、审批驳回、再次审批这些状态的流转是否明确并且合理。

权限

需求对应的功能是否有对应权限描述。

比如审批这个功能，对应是销售权限的人员只能提交审批，经理级别的人员才能进行以及审批等等，对应每个功能的角色权限需要描述清楚。

项目角度

优先级

不是只要产品提出一个需求，就要进行开发上线，需要对该需求进行一个优先级的评估，是否为当前系统所必须；

如果有多个需求并发的话，需要对这些需求进行一个优先级排序。

deadline

需求不只是要排出对应的优先级，还需要对需求进行一个排期，对应开发周期及测试周期，还有最终的该需求的上线日期。

第三方系统对接确认

如果需求涉及到与第三方系统进行交互，则在需求评审时需要产品明确对接流程。

作为一个测试人员在开需求评审会时，大致需要通过以上几个通用角度来进行考虑。