20211012社保查询需求评审总结
业务背景
住建局进行购房资格审批时，需要查看申购人近一年和近两年的社保缴纳情况。
本次需求要实现两个功能：单户查询、批量查询。
合作方已经提供了查询近一年、近两年社保的接口。
需要实现的功能看似很简单，但是经过大家的热烈讨论、思想碰撞，激发出很多需求人员想不到的点。
我觉得这次需求评审会议很有价值，对与需求人员，可以查缺补漏，对于测试人员，可以学习怎么更好地参与到需求评审当中。
受到启发的一些点
-
开发实现时需要考虑外网、内网等网络问题
我们做的是政府项目，涉及住建局、社保局，这两个机构的网络并不是在同一个局域网内，那数据在其中的交互就可能出现不稳定的情况。
据说，智能柜台视频连线不稳定，就是因为内外网的网络不稳定。 -
是否有批量接口
在讨论的过程中，我们发现对方提供的都是单户查询接口。
那批量查询的时候就需要一个一个进行调用，这样速度是会很慢的。 -
接口要关注正常、异常返回
评审单户查询时，我提出如果单户查询出现异常，如查询没有数据，怎么提示，需求没有说明。
需求人员看对方提供的接口，只有正常返回的约定说明，那就要向对方了解清楚异常返回的情形。 -
需要考虑并发
原始需求提出批量查询是每次限制查询500个申请人，架构师提出那并发不能只是考虑500，你要去了解是有多少个审批人员使用，如果5个审批人员同时使用，那么并发就不是500。 -
打印功能最好做成所见即所得
需求人员提出，局方有提出一种实现方案：社保证明查看时不展示签章，因为不大美观，只展示申购人的社保购买记录，打印社保证明的时候，再加上签章。
架构师提出建议：打印功能最好做成所见即所得，不然做起来很麻烦。 -
查询、盖章接口的调用顺序
查询后，还需要调用另外一个系统进行盖章，盖章后查询结果才是有效的。
批量查询的时候，是每查询成功一个就发送一次盖章接口，还是全部查询成功后再统一进行盖章。 -
批量导入异常场景考虑
需求没考虑到导入文件有很多异常情况。
如给了模板，用户没有规范填写模板时，导入文件时怎么处理
多次导入是覆盖导入吗 -
批量查询异常场景考虑
如查询100条，成功查询了80条，查询失败20条，怎么处理？是全部从头查询一般，还是保留已经成功查询的数据，只查询失败的数据
异常有很多情形：
1）因为查询过程经过一系统的链路，查询链路有问题，造成异常
2）查询是调用了别人提供的接口，封装的接口有问题，造成异常
3）到数据库，数据库返回异常
4）查询的数据，数据库不存在 -
批量导入文件的设计
因为是查询最近一年和最近两年的社保缴纳记录
可以分成两个表格
也可以是一个表格 -
导入数据的展示
一个开发提出不使用分页，直接使用滚动条
在下方展示本次导入数据的总数量 -
敏感信息的保护
需求评审过程中提到了敏感信息保护问题，提出这些信息应该是不能直接保存到本地
查询应该与业务绑定，比如查询的时候需要提供办理流水号
在查询记录中加上操作员的信息，不能只使用操作员的姓名进行区分，需要使用唯一的id进行区分，因为姓名是有相同的 -
注意交互是否符合用户习惯
需求讲解当中，提到，在输入信息后，点击左上方的按钮
这样进行查询。
这个交互不符合使用习惯，我在看原型图的时候就比较困惑，一般我们输入信息后，查询按钮都是放在下面，我们填写信息是从上往下，填完信息的注意点自然是在下方，这时要去左上角找按钮，非常不友好。 -
查询失败的处理
评审过程中，提出了几种针对批量查询失败的处理方式
1）增加一个单户查询按钮，对于查询失败的数据，用户可以直接点击按钮再次进行查询；增加勾选框，可以勾选多个查询失败的数据发起再查询
2）做两个页签，一个是查询成功的数据，一个是查询失败的数据，可以一键对查询失败的数据再发起查询
3）针对查询失败的数据，可以直接导出成文件，然后再直接导入进行查询
显示出本次导入多少条数据，成功查询多少条数据 -
关注批量查询结果列表的排序
局方是否要求按导入表格的顺序进行排序
是否需要增加筛选条件，方便进行筛选
看似简单的功能，你会发现其实并不简单。
