敏捷需求分析 | 回归业务本质：从单据出发分析系统业务

作者：熊节 《重构》译者

老邓同学在王大锤老师的群里说：“我发现一开始搞用户故事的，最容易就是按界面来。然后一旦一个复杂的界面，就手忙脚乱。”我发现这确实是个很常见的问题。从什么脉络去梳理需求，怎么把需求变成一个个前台的界面、后台的服务，再怎么把功能拆解成用户故事交给开发，很多人对这个梳理和拆解的过程是懵的。

其实我一直认为，这个问题是有标准答案的。徐昊很多年前就写过一篇文章讲这事，所以每次有人问需求怎么分析我就直接甩链接:

徐昊：运用四色建模法进行领域分析

然而多甩几次链接我发现，似乎很多人看不懂徐昊这个文章，还得再细讲一下才能明白这到底是怎么回事。这个建模法的关键不在于“四色”，而在于它是从头到尾一根绳拉通的，沿着这个建模法能从需求一直推导到代码。理解这个过程以后，才能明白需求的分析、需求的传递是如何以一种有套路的、不全凭直觉的方式进行。

我用在线编程考试的“科举”系统来做这个讲解。我们的学员上科举系统来的目标都非常单纯：我要拿到那张证书，为了那张证书，你叫我干啥我就干啥。

当然学员很希望给钱就发证，但是我肯定不能这么败自己名声，所以这张证书不能随便发的，并且发完证我也得有一个可追溯的记录，说明我这张证不是随便发的，而是学员正经考出来的，任何时候要查都能查得到。所以为了得到这张证书，学员得拿出一个考试记录来兑换。

那么学员怎么能混到这张考试记录呢？当然就是他得参加考试——也就是“获得考试记录的过程”。在考试的过程中他要提交代码，得到提交记录。如果提交记录显示这次提交被后台判卷的考官（甭管是人还是机器人）标记为“通过”，那么学员就会得到一张通过的考试记录；如果这次提交记录没通过，只要考试时间还没用完，学员还可以继续提交。

那么学员要如何开始“获得考试记录的过程”（即“考试”）呢？他得用一张考试券去换。每张考试券最多只能换一个考试记录。考试券是管理员提前按人头分发给学员的，学员要凭个人信息领取。

就讲到这里好了。学员现在应该很容易明白，他需要凭个人信息换一张考试券，把考试券换成考试记录（其中要包含至少一次通过的提交记录），再把考试记录换成证书，他的目标就达成了。

而我作为科举系统的拥有者，未来如果有人来置疑我，说潘石屹这张证书是假的，我可以一步步给他追溯回去：这张证书对应着这次考试记录，这次考试记录里的这次提交记录是通过的（在提交记录里可以看到当时提交的代码和考官判卷的结果），这次考试记录是基于这张考试券考出来的，这张考试券对应的学员个人信息是潘石屹本人的。

（你说这个潘石屹不是地产大亨潘石屹？我从来也没说是呀。）

就这么个业务流程。你说学员关心界面上怎么操作吗？他不关心。他只关心学员信息给对了（证明真的是他拿了这个证）、考试券拿到了（证明他真的交了考试费）、考试记录完整了（证明他真的参加了考试提交了代码）、最后证书发出来了（乌拉~）。学员不关心操作，只关心通过操作能得到的单据。至于这中间怎么操作，都说了嘛，我费都交了，你叫我怎么操作我就怎么操作。

说得极端点，你叫他用cURL在命令行操作，他也能完成这个流程，拿到所有的单据，最后拿到证书。

这个东西，叫做科举系统的业务。大多数企业信息系统处理的业务都是同样的道理。业务的本质是单据，怎么把单据凑齐全了，业务就能通，在业务能通的基础上再考虑更便捷的操作，这系统就基本上对了。

为什么我前面说这个建模法是一根绳拉通从需求直达代码呢？因为用这个方法分析出来的业务可以直接用RESTful API的形式来表达。单据就是资源，单据的变化就是资源的状态变迁。我们给上面出现的单据分别起好英文名字，

• 学员信息 => Student
• 考试券 => Ticket
• 考试记录 => Exam
• 证书 => Certification

然后你就能直接用一组RESTful API来描述上面的业务流程，完全一一对应，连脑子都不用转，

• POST /students
• POST /tickets
• POST /exams
• POST /certifications

当然这里面会稍微有点细节，比如说考试券是要给到具体某个学员的，那么是不是还得把学员信息先读出来看一下？开始考试的时候是不是还得把题目（Quiz）拿出来看看？类似的想法跟着捋一下，很快你就能得到一个大概齐的完成这个业务所需的API列表，

• POST /students
• GET /certifications/1
• POST /tickets
  • GET /students/1
• POST /exams
  • GET /students/1
  • GET /quizes/1
  • POST /commits
• POST /certifications
  • GET /students/1
  • GET /exams/1
• GET /certifications/1

大概就这意思。当然我这拍脑袋弄出来的列表肯定有错漏，但是没关系啊，这东西设计得对不对超级容易验证，分分钟就可以做一套API原型出来，用cURL跑一遍看看就知道流程通不通了。

所以上面说的这是系统的业务。把业务捋清楚以后，界面上的操作就很容易条分缕析。当然对于现在的前端过度设计的趋势我又有很多想法，实际上有了RESTful API以后怎么把API转化成Web界面的行为，这同样有一根绳拉通的方法。这个我就留着下次有空再接着写吧。