需求分析方法之——逐字逐句审读法(下)(C系架构设计法)
需求分析的一个重要方法——逐字逐句审读法。
接着上一篇来
接着来看第二句话,“采购人员判断是否下架“,很明显就是由采购人员来审核,因为供应商前面已经提交了预约下架的申请,那么采购人员要来判断、来审核。
这个时候我们就会去思考,采购人员是所有的采购人员吗?因为采购方这边,采购人员可能会很多,采购人员是个角色,但是所有的采购人员都具有这个判断是否下架的权限吗?你看,这就是一个问题。
如果你有一定的业务经验,你就会知道,供应商和采购人员之间,在很多场景里面,采购人员和供应商都是有一定联系的。因为采购人员,他不能负责所有的采购,可能也是分类别的,比方说,有些采购人员只负责办公用品的采购,有些采购人员负责生产资料的采购,这都是不一样的。同样,供应商供货也是千差万别的,所以这个地方,从实际的业务角度来讲,不太可能是任意一个采购人员都能够判断这个供应商的下架申请。
所以你看,这个地方就会延伸出来,采购人员和供应商之间有一个关系。实际的业务中,这些供应商是怎么入驻到这个平台来的呢?是采购人员去邀约过来的。也就是说,供应商里面就有一个邀请人是谁,那么邀请进来过后,这些供应商的维护,也是由这个采购人员去做,所以这个地方,采购人员判断是否下架的功能,就是管理这个供应商的,或者说维护这个供应商的采购人员。
你看,经过我们的深入思考,文档当中并没有写,但是我们会发现这些问题。当然,发现的问题,不一定真的是这样,这个时候,我们就需要去跟需求调研人员确认,如果需求调研人员也确认不了,记录下来再次跟用户去确认。
接着来,如果采购人员不同意,则拒绝下架。意思就是说,供应商预约下架,告诉采购方说这个东西15天过后就会断货,结果采购人员判断完过后,说不行,不允许下架,可能有些人会说,这个会有问题吧。如果供应商是真的没有货,你拒绝下架,后续的业务怎么办?你看,在这整个文档里头,你看不到后续业务。
如果说你拒绝下架申请,很有可能,是认为供应商有货,只是说货现在比较紧俏,他不想再这么大量的供应给采购方。这个时候,你拒绝他的下架申请。但是应该会有后续的业务处理,不是说你不下架,供应商后续就一定要有货供给你,万一真的供应商后面没有货供给你,这个业务该怎么办,你看,这个文档就看不到这些东西了。
总之,这个地方能看出来,采购人员这边有一个功能,就是判断是否下架,就是审核下架申请。审核过后,就会有两个结果,一个是同意一个是不同意,对不对?不同意就拒绝下架。如果同意,在产品真正下架的开始时间,注意刚才是预约下架,并不是马上就下架了。
他是预约的一个时间,比方说15天,这个产品下架时间开始的时候,刚才说了,要有一个定时任务,执行预约下降的功能,你这边审核完成过后,他就会进入到定时任务里头,到了时间点过后,就会把这个产品标记为下架。
接着来,“采购人员则解除与该供应商的供应关系”。这个也是有问题的,这个供应商供应很多的商品,可能我只有一个产品,跟你申请预约下架,结果你跟我的整个供应关系都断掉了,这肯定不合适。所以说这个地方,很有可能是理解偏差,或者是写的就错了,这个地方即使要解除供应关系,也是解除这一个产品的供应关系,对吧。所以,这个地方肯定还会有一个功能,可以叫做解除这个产品的供应关系。
从审核的业务来看,就两个出口,一个是不同意,不同意就没后文了,但实际上咱们是要去追问的,不同意,然后怎么办?另外呢,就是同意,那么什么时候执行下架,就是执行这个解除商品的供应关系,最后才是下架生效。
大家看一下,这就是读这几句文档,我们能够得到的,这就挖掘出了五个功能,当然其他的功能咱们就没有读那么细,你还可以用其他的角色,来审视这个需求描述的功能,比方说有角色可能需要查看已经解除的这个供应关系的数据;或者说已经同意的这个预约下架单等等的,这就又可能会引伸出其他的功能。
上面描述的这个过程,就是逐字逐句审读法的基本做法,通过细读需求文档,去发现具体的功能点,发现里面的业务流程。当然,这里的需求文档就这么几句话,比较简短,没有复杂的业务流程,就是一个申请,一个审核,然后同意不同意,结束。我们就发现了这么多功能,后续该怎么办呢?我们是不是就得一个功能一个功能去研究了,对于审核,咱们就得细化进去,到底怎么细化?方法是什么?咱们后面再来详细的讲。后面会有一个专门讲功能点分析的,也会有专门讲这个业务流程分析的地方。
为了大家更好的交流架构设计的思想和知识,大家可以加sishuok,拉你进架构设计群,一起共同学习,共同进步。