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