👉目录

1 这些话你熟悉吗

2 找准战场——业务建模

3 制定方略——需求

4 小结

5 尾巴

去年写的《业务系统是怎么逐步变成“万人嫌”的》只是回顾了系统是怎么一步步变坏，然而最难的部分怎么防止变坏却没有写出来，因为这涉及到流程规范、团队文化、组织管理等方方面面，我的认识有限确实无法全面总结，不过我可以站在一名普通研发的角度，选取“做有价值的需求”这一个点来继续聊聊。

《Google 软件工程》中有一句话：“代码是负债，而不是资产”。这里实际上有一个限定，在软件工程领域，代码的构建是要花费时间和人力成本的，代码本身没有价值，真正有价值的是代码所要解决的产品问题，这才是给用户和公司带来价值的东西。同样，读过 UMLChina《软件方法》的同学应该还记得里面有一个公式：利润=需求-设计，需求致力于解决提升销售的问题，设计致力于解决降低成本的问题，而我们的目标就是用更少的代码（成本）完成更多的需求（价值），提高组织的收益。

减少负债的手段很多，今天我们也并不是来讨论编码的艺术，我们的时间、精力有限，每天产出代码也是有限的，那如何让我们的代码所解决的产品问题最大化就显得至关重要，用我们的武功去最大化获得战功。假如需求是错的，那么哪怕为这个需求写一行代码都是浪费！

读到这里相信你也明白了，其实讲“做有价值的需求”就是讲如何做好四大工作流中业务建模和需求。以下内容是 UMLChina 相关课程结合刷脸就餐案例撰写，如有错误欢迎指正。

01

这些话你熟悉吗

这些口头禅我们经常听到并习以为常，可是仔细想想是这样吗？

“你这需求怎么又变了”：需求是解决实际问题的，但是仔细一想发现解决的问题还在那里从未变过，需求是药，要解决的实际问题是病，病情没有变化却要换药，只能说之前的药开错了。

“我们人力有限，只做最高优先级的需求”：哪些需求优先级最高呢，依据是什么？听用户的、产品的、还是领导的，如果他们意见相左听谁的？

“你这需求不合理”：为什么不合理，因为我“感觉”这样不合理吗？开的药合不合理是有医理可依的，肯定不是靠我觉得不行或者看药的颜色好不好看来决定。

“你这过度设计了”：首先说明过度设计是指需求是正确的，但是系统内部实现得过于精妙了，大多数时候我们所说的过度设计指的是需求蔓延，即花了很多精力去做了很多用不上的功能。你说过度设计了，那凭什么说这些功能用不上呢？

这样的话我们平时可以听到很多，乍一听觉得非常有道理，可以仔细一琢磨发现根本经不起推敲，都是靠假设、靠感觉。接下来我们一起来看病开药，用一个实际案例来看下治病的药方到底是怎么根据医理一步步推导出来的。

02

找准战场——业务建模

某一天你参加完孩子的家长会，结束后到学校餐厅亲身感受下孩子在学校吃得怎么样，由于是就餐高峰期，餐厅窗口排了长长的队伍，队伍缓慢移动，你无聊地盯着窗口处阿姨打菜、输入菜品、学生刷卡，发现这个过程大多数学生并不会提前准备好卡，而是刷卡时才会现场从口袋、书包找卡，甚至会因为忘记带卡或者刷卡时发现余额不足又到处找同学借，让队伍前进更加缓慢。

忽然你灵机一动：现在新兴的刷脸支付又快又安全，自己何不将刷脸技术引入校园，提升就餐效率，天赐商机，说干就干。

2.1 确定目标——愿景

凛冬创业，再也不是“站在风口上猪都会飞”，花的都是自己实打实的钱，那就一定要先想清楚愿景：目标组织代表（老大）在引进系统之后最希望带来的改进是什么。这是开发系统的出发点，下面对愿景的每个词进行解释：

2.1.1 谁来买——目标组织和老大

目标组织：系统擅长改进指标和组织当前最需要改进指标匹配程度最高的组织。这里的组织它可以是一个具体的机构、也可以一类人群，特别需要注意这个“最”字，系统可以改进的指标很多，不同组织需要改进的指标也各不相同，匹配程度最高的才是目标组织。举个常见的例子：微信文件助手（假设是一个系统）可以提升不同终端之间的文件传输效率，但是有的人用来传输文件、有的人用来发消息当备忘录，按照上面的原则，微信文件助手的目标组织是有频繁在不同终端之间传输文件的这类人，而不是用来当备忘录的这类人。

老大：系统的目标组织中担任负责人的人脑系统实例，是一个具体的个人，系统最优先照顾其利益的那个人，如果做的系统他不满意那其它人满意也没用。

定位目标组织和老大可以分为三种情况：

情况	改进范围	定位老大步骤	示例
针对特定人群的非定制系统	某个人群	定位目标人群->定位老大	针对中产单身青年的XXX交友系统，老大为想脱单的某29岁的上市公司员工张三
针对某特定机构的定制系统	某特定机构	定位机构范围->定位老大	XXX学校教务系统，老大为XXX学校教务处处长李处长
针对某类机构的非定制系统	某类机构	定位机构范围->定位目标机构->定位老大	针对实行学分制大学的教务系统，老大为已经实行学分制多年的XXX大学教务处处长李处长

针对特定人群的非定制系统：改进的是“某个人群”，例如微信、企业微信、QQ 虽然都是聊天软件，但是针对的人群并不相同，因为不同人的喜好各异，一款 APP 不可能全部满足。即使国家反诈 APP 全民推荐，但是我相信在开发这款软件前，也是调研分析全国诈骗案例，得到被诈骗最多的群体，例如子女不在身边的老人群体作为目标组织。
针对某特定机构的定制系统：这个就不多做解释了，例如一般大公司都会结合公司特点定制自己的 OA 系统。
针对某类机构的非定制系统：如果你仔细观察的话，可以发现很多餐厅扫码点餐用的都是同一个系统。

定位目标组织

定位目标组织并不是一步到位，相反还很艰难，需要多次调整、逐步逼近，需要先定一个范围再来定位到具体组织。上文已经提到没有一个系统可以满足所有用户的需求，同样刷脸就餐系统不可能满足所有的餐厅，例如某幼儿园餐厅是包月制，就餐时直接配送到固定餐位，那就根本用不到收银系统；例如某公司餐厅提前小程序付款预约，那就没有用餐高峰期排队付款问题。

经过初步的思考，刷脸就餐系统是针对某类机构的非定制系统，确定自己创业项目当下是服务于校园餐厅，但是校园餐厅也有很多种分类，具体服务于哪类校园餐厅（定位机构范围）、选择研究的目标机构是哪所学校、老大是谁？

我们可以结合类图通过不断的追问“谁比谁更像，为什么”得到，我们画出学校餐厅的类图如下，然后针对每个属性以及所关联类的属性值展开比较，找出最像的属性值集合。

现在开始不断针对类图上的属性开始追问，例如：

问“学校等级是什么“，答”初等/中等教育”，问“为什么”，答“学前教育大多数学校饭菜配送到座位，那根本就不用收银系统，而高等教育的学生都有手机，基本都可以方便的使用手机扫码支付，效率比使用饭卡也快很多，而初等、中等学校学生没有手机，基本上都是用饭卡支付"；

问“学校所在城市是什么类别”，答“中等城市”，问“为什么”，答“一线城市学校大多数已经引进了已经较为先进就餐系统，建制镇学校目前一般规模不大，就餐队伍拥堵不严重，通过调研发现中小城市的学校改进意愿最高。”

通过不断追问，我们得到刷脸就餐系统改善是“位于中小等城市的、初等/中等教育的、寄宿学校的刷卡支付餐厅”这类机构，然后继续追问，慢慢缩小范围，最终定位到一个具体的餐厅，例如“A 市第一小学餐厅”。

定位到的目标组织一定是具体的、（能力所及）最像的，绝不是“需要引入刷脸就餐系统的餐厅”这样正确而无用的废话，也绝不能偷懒随便找身边的一个组织去研究。你也许会问，战场搞那么清楚干啥，我全都要不行吗，答案是不行。因为你不可能资源充足到可以随便挥霍，即使李云龙喊“没有助攻，全他娘的主攻，现在我们的兵力是八比一，这种富裕仗我八辈子也没打过，这会咱们敞开了当回地主“，也是把战场聚焦到了平安县城，而且八辈子才遇到这么一次。

这时候一定要专注于目标组织，不要有“只关注目标组织 A 市第一小学餐厅的需求，那其他学校餐厅的需求是不是就漏掉了“这种担心，目标组织都没服务好去想其它组织干什么，需求是做不完的，只要愿意可以找到无穷无尽的需求。

定位老大

老大满足如下三个条件：1）是一个具体的人；2）目标组织的实际负责人；3）有责任和权利决定目标组织的改进方向。这里非常容易犯错，比如很可能定位出“A 市第一小学王校长”、“餐饮系统开发团队的张总”、“A 市第一小学餐厅管理人员”，我们来分析下为什么不对。

说“A 市第一小学王校长”理由是校长权力最大：一旦这样的话那我们就不用思考了，切记“不要把遥远的大领导当做老大”，校长确实是学校最高负责人，但是他更可能是提纲挈领地提要求，并不关心具体某一项该如何落实。

说“餐饮系统开发团队的张总”理由是他是我的老大：对，他是你的老大，不是系统的老大，我们可以使用“爆炸法”验证，假如你身上绑了炸弹命令你在几分钟内把刷脸就餐系统卖出去，而且只能找一个人来推销，而他购买的原因必须是你的系统打动了他，而不是因为亲情友情等原因买你的系统，你应该找谁（即老大），说什么话（即愿景）。这么思考一下子就明朗了，你肯定不会找自己的领导张总推销系统，那张总是谁，很可能是给你绑炸弹的人。

说“A 市第一小学餐厅管理人员”的理由是他是餐厅管理人员，就是管理餐厅的：这里犯了两个错，一是管理人员不是一个具体的人，二是学校餐厅可能压根就没有管理人员，“切不可臆想出来一个负责人来当老大”，因为很可能该学校的餐厅归后勤管理处管理，那老大就是是“A 市第一小学餐厅后勤管理处李处长”。

2.1.2 凭啥买——提炼改进目标

改进的认知来自于比较（竞争），老大觉得这个系统好、那个系统不好是通过对比得到，因此我们一定要有竞争的意识。例如不用刷脸就餐系统会怎么样：学生吃饭需要花费更多的时间，影响学生午休；学生容易丢饭卡、忘记充值导致吃不了饭影响学生健康等等。

改进目标是“系统改善组织行为的指标（例如提升就餐效率）”，不是“系统能做某事（例如某人喜欢看刷脸支付成功的动画，就专门买一个刷脸设备来刷脸看动画解压）”，也不是“系统行为的指标（XXX接口耗时2秒内）”，要得到这个指标并不容易，因为人心复杂。举个例子：最近《庆余年》第二季很火，里面考生发现郭尚书主导的考场翻新的工程是有问题的，拆下来的旧石板和木材，竟然比新换上去的更好，这里有改进吗？

有！系统的改进是是无关法律、道德的，而是纯粹的从老大的角度来看，老大觉得改进才是改进。从考生角度来看没有改进，还变差了，从郭尚书角度来看就是天大的改进，改进指标为：礼部库房新增资产30%。但是这个改进指标郭尚书肯定不会自己说，需要做事的人仔细揣摩，从那些“假、大、空”的话中揣摩出老大真正想要的。

这里如果问“A 市第一小学餐厅后勤管理处李处长”的目标是什么，那他很可能说“解决就餐效率低”这样正确而无用的话，那我们怎么得到想要的呢，可以通过鱼骨图（因为没有支持鱼骨图的软件，下图画的不严谨）来分析，不断的问为什么，得到答案后来判断这个问题是我们系统能解决的，不能解决就继续问为什么。

改进的目标一定是系统带来的，提升就餐效率这个目标太大了，实际上刷脸就餐带来的改进更准确的说是“提升就餐支付效率”。当然这还不够，上面已经提到改进的的认知来自于比较，既然有比较就要有度量指标，不能是我感觉、我觉得。比如“提升就餐支付效率”，那么提升了多少，怎么度量？这些老大不会告诉我们，我们也要警惕快、好等模糊的形容词，而是给出实实在在的指标，这个指标可以通过几种常见的方法揣摩，比如：

比较法：更快，为什么更快，因为原来需要5分钟，现在3分钟了（指标）；
具体化：排队时间长，具体多长，居然等了1个小时（指标）；
倒推法：如果没有这个系统，达到相同的效果老大要付出什么代价，比如要花费100万元（指标）建设一个新的食堂增加窗口。

所以我们需要将“提升就餐支付效率”度量出来，得到改进指标为“平均每人就餐支付时间从5分钟缩短至3分钟”。

提炼改进目标结束了吗？没有，大多数项目的愿景并不是一个改进指标，还可能有多个。“我们的领导要求我们又快又好的完成开发任务”可是“快”了很可能就影响“好”，怎么办呢？要对目标排序，找出老大最关心的目标。如果所做的系统是国民应用，出一点问题都会给人民带来极大的不便，那很明显“好”排在“快”前面。

至此我们可以得到刷脸就餐系统的愿景如下：

   
    目标组织：A市第一小学餐厅
老大：A市第一小学餐厅后勤管理处李处长
目标（度量指标）：平均每人就餐支付时间从5分钟缩短至3分钟

2.1.3 目标会变吗

当然会，否则企业岂不是止步不前，当攻克可一个战场就会选择下一个战场，比如经过几年努力，几乎所有的学校都用了你的刷脸就餐系统，那下一步很可能进军企业餐厅战场，这时候老大、目标组织、愿景全都变了。上面所有的结论都是在某一个时间点找到的最值得的改进。即使还在原来的战场，改进后现状就变了，下一步自然也是基于新的现状寻找最值得的改进点，最起码改进指标会发生变化。

2.2 战场分析——业务用例

有了愿景也就知道老大对他所在组织现状的某些指标不满，接下来我们就要研究目标组织，搞清楚到底是组织的哪些环节造成了这些指标较差。业务建模的目的就是为了得到待引进软件系统的需求。

系统是组织的一个个零件，为了让组织更好的对外提供价值，需要对里面的系统不断升级，然而怎么升级？升级什么？一步到位还是逐步升级？这要一步步推导。开发团队经常发现需求容易变化，根源之一就是需求的来路不正，没有把系统当成零件放在组织中看，导致系统需求是错的。需求上线后发现和组织的其他零件格格不入，真正的需求从来没变，只不过一开始需求就是假的，那么实现该需求的代码也就全部都是“垃圾”了。

2.2.1 从外向内看

研究目标组织可以从内外两个视角来研究组织，首先从外部看，组织是价值的集合。即一个组织为另一个组织提供一些价值。

业务执行者：为谁提供价值。虽然这个名字看起来是一个人，但实际上业务执行者是一个组织（一群人或者一个机构）。当我们以一个观察者的身份去分析组织时很容易看不到全貌，我们观察到的是：小明去学校餐厅找食堂阿姨买饭，阿姨给小明提供服务（价值），但无论是小明还是食堂阿姨都是（人脑）系统，并不是业务执行者和目标组织，我们需要站在庐山之外看庐山。小明的背后是该学校的学生群体，而阿姨背后是学校食堂。

用例是期望和承诺的平衡点。比如你观察学生除了吃饭还会在非营业时间去食堂学习，然而“提供学习场所”并不是一个用例，因为这不是餐厅所承诺的，而只是学生单方便的一厢情愿。所以一定要注意权衡目标组织的承诺和学生的期望。下面是就餐的业务用例：

如何确定就餐这个用例找的是对的呢，除了检查上面提到的这些点，还有就是思考业务用例是否代表组织的本质价值。这个价值很难变化，并且和你是否做这个系统没有什么关系，从古至今餐厅（餐馆）就是吃饭的地方，银行（钱庄）是存取钱的地方，他们的本质价值没有变化，变得是业务流程，也就是通过不断替换组织内部的零件（人脑系统和信息系统）持续改进，让业务流程更高效。

特别注意，我经常见到“害怕忘记、自找麻烦”的案例，比如：观察A市第一小学餐厅后勤管理处李处长定时查看收银系统账单，就觉得有这么一个业务用例，但是发现找不到业务执行者，因为这里犯了一个错误，找用例一定是站在组织的角度观察，李处长（业务工人）和收银系统都是组织的零件，是组织内部自己的交互，怎么能说是系统用例呢？也可能会反驳到，现在不写出来后面忘记了怎么办，难道收银系统不用做账单功能吗？不要害怕，因为只要按照既定流程是可以推导出来的，例如我们观察到财务处要求定时审核餐厅的收支，这是因为两个组织目前无法通过智能系统直接交互才需要人来查看抄录，你直接从一个坏的现状映射出一个业务用例那肯定是不对的，一定要分清楚问题和问题的解决方案。

2.2.2 从内向外看

作为一个程序员，我们接触最多的就是系统，什么目标组织、老大、业务执行者我们大多数情况接触不到，谈上面的内容似乎很“虚”，迫不及待的想研究系统，很遗憾这里的从内向外看还是研究组织，只是终于出现即将要开发的系统了。

现状业务序列图

系统就是组织的一个零件，组织通过更换或者添加零件（我们的系统）优化业务流程，那必然要先描述出真实的现状，接下来在此基础上改进才能得到最符合现状的改进方案，在凭空想象的现状上改进那必然是假需求，因此这里最重要的就是“如实、如实、还是如实”，现实的各种客观或主观原因都在给我们“如实”描述制造阻碍：

最常见到的就是太自负，觉的自己系统是前所未有的创新，就拿刷脸就餐来说吧，是新东西吗，不是的，而且古代的刷脸就餐比现在体验还好，想一下这个场景“小二记账”，“好嘞，西门大官人您慢走”，这可不就是刷脸就餐吗？

还容易犯的错误是太主观，以为有规范了大家都会按照规范来实践，比如学校餐厅是按照固定价格套餐售卖，可是有的学生想多加一个鸡蛋、有的学生不吃鸡腿要求去掉，这都会导致价格不再固定；再比如觉得现状是纯手工，以为计算总价是阿姨在系统点选菜品后然后计算，实际上每个菜盘都有NFC标签，放在收银台已经自己识别计算价格了。

当然更多的情况是不经意间的骗自己，或因为汇报、或因为宣传要求经常整理材料，对比自己公司参与前后提效多少，但是注意现状是当前这个时间点的现状，不是自己公司参与之前的现状。

我们就把自己当做一个录像机，录下整个业务流程，一般我们选择序列图来描述组织内系统之间的协同：

改进业务序列图

有了现状就有了问题，有了问题那如何改进呢。从上面图我们可以看到付款慢的主要原因就是学生准备好一张余额充足的饭卡的过程慢，我们可以从如下三种改进模式入手思考：

物流变成信息流：这里就不多解释，系统之间运输物品大概率不如传递信息成本低，比如短信替代信件；
改善信息流转：软件系统越来越多，各个系统之间沟通不畅，我举一个生活中的例子：每年老家亲戚都会给我寄一箱樱桃，在果农处购买樱桃，然后去快递点填单寄送，今年亲戚告诉我现在方便多了，只需要在果农处填一下手机号地址，剩下的果农全部给处理好，这就是典型的改善信息流转。
封装领域逻辑：将人脑中的领域逻辑封装到软件系统中，很多安卓手机当收到短信验证码时会自动提取并填写到当前页面。

这里我们思考下，学生付款慢根本原因就是准备卡的这个过程，为什么要准备卡？因为要使用卡运输学生卡号，这个账号信息能否不用卡而使用声光电运输，于是我们想到刷脸就是使用光传递学生身份信息（卡号），于是就得到下面这张图。

如果改进都这么简单就可以得到，那钱也太好赚了，学生余额不足要去借卡浪费时间，即使换了刷脸就餐系统还不是喊一个人来帮刷脸，能否更好的改进？这里介绍一下阿布思考法：首先假设有充足的资源去解决问题，然后用手上现有的资源去山寨这个完美的方案。

第一步，假设世界首富就餐时支付时会遇到余额不足吗，几乎不可能，因为即使储蓄卡里没有钱也可以从他那张高额度的黑金信用卡扣；第二步，我们能否为每个账号山寨这样一张信用卡，评估处每个学生每天吃饭最多花多少钱，然后当 XX 支付账户余额不足时就可以从这张信用卡扣款。

当然改进序列图不仅就这一个，刷脸能够识别到用户的前提是提前录入人脸并签约绑定一个微信账号，余额不足时垫资了自然而然就有追缴，这里就不一一画出了。需要注意的是改进方案是经过权衡的，一定是和愿景一致的。

03

制定方略——需求

现在将研究粒度进一步缩小至系统。系统是封装了自身数据和行为，能够独立对外提供服务的东西，其边界是责任的边界，如果搞不清楚系统的边界，很容易得到很多数据几乎相同的“假系统”，这会让我们的分析、思考变得更麻烦，因此明确系统边界至关重要。其实从老大角度看，你到底是零件升级还是新增零件并不关心，他要的是改进，真的没必要强行拆那么多系统。

3.1 找高地——系统用例

系统用例是系统能够为执行者提供的、涉众可以接受的价值，思考方式和上文中的业务用例一样，只是研究对象从组织换成了系统。如果做了业务建模，事实上系统用例也就有了，直接从业务序列图映射即可，所有指向研究系统的消息就是系统用例，消息的发送方就是执行者，而所研究系统发消息指向的就是辅助执行者。

如果从业务序列图映射得到系统用例大多数情况下没有啥疑问，但是有时候并没有做业务建模，系统用例是靠头脑风暴整理出来的，那很有可能会出现一些有疑惑的点，比如测试人员可以直接点击某个按钮扣款，而不是服务商收银系统触发，那扣款的用例执行者是不是还有测试人员？需要注意的是“价值不等于可以这样做，用例执行者只是表明这个用例是为谁而做”，可口可乐是为青少年而做，但并不影响老年人也喝。

无论是业务用例还是系统用例，始终要把握一点：用例是买卖平衡点，是执行者期望和组织/系统承诺的平衡点。同样是查询订单，很可能财务是查询来对账、家长是来看学生有没有乱花钱，他们的目的根本不同。很多人会不自觉的合并用例为查询订单，这就是思维没有转换：需求不考虑复用，你能用一个界面、一个接口实现更多可以卖的价值说明你厉害，为啥非要补上一句“这其实就一个东西，你不用付两份钱”。

3.2 定路线——用例规约

目标有了，下一步就是将这些需求表达出来，作为一名研发经常吐槽说“需求不够详细”，可是详细的需求是什么样子？

描述系统的方式有很多，用例规约就是以用例为核心来组织需求内容和需求规约，这样的好处就是更容易让我们知道为什么要做这个需求，让质量需求和设计约束指向更精确，接下里我们以扣款为例来看下用例规约怎么写。

3.2.1 前置条件和后置条件

前置条件是状态不是动作，而且是系统可以检测到的。比如“商户收银系统发起扣款”（是动作）、“学生已经拿走菜品”（系统无法检测）这些都不是前置条件，写出的前置、后置条件要有增值作用，比如“系统正常运行”等等这种适用于任何系统的约束也是没有任何意义的。

在早期我学习软件方法认为是系统执行用例前要做的校验的规则，后来意识到这个是错误的，其实前置条件是背景条件，系统在什么条件下可以被外部使用，和用不用没关系，而是系统能不能用的问题，用例就是：在满足前置条件时开始，按照里面的用例步骤走，系统就能达到后置条件。

扣款的前置条件为：存在已经签约的学生账户。不满足这个条件，扣款就一定不会成功，扣款用例根本无法执行；后置条件可以写为：扣款凭证已经关联一笔支付订单。

3.2.2 涉众利益

涉众至关重要，前置条件是起点，后置条件是终点，这个是确定的，但是从起点到终点的路径有千万条，哪一条才是最正确的呢，这就需要考虑涉众利益，不断权衡各方利益才能得出正确的需求。

涉众利益就是针对某件事情，某类人担心和希望什么。人心是复杂，他们的担心和期望大多数是冲突的，而我们就是要把这些冲突找出来，不断权衡、取舍，找出都能接受的路径。以扣款中的垫资这件事为例，我们来分析下不同人的心理：

学校餐厅老板心想：我可不关心你排队长不长，我只关心你换了刷脸系统后别影响我生意，我原来卖1000份饭，收1000份钱，现在不能卖1000份饭，收900份钱，我不管钱是谁付，但是我1000份饭就要收1000份钱。

刷脸系统提供商老板心想：我给你垫资是为了卖我的系统赚钱，但是可不是无限垫付，万一用户不还怎么办，我还赚什么钱。

学生家长：不就是忘记充值了吗，但孩子是祖国的花朵，怎么能因为没钱就不给吃饭呢，就不能欠着吗，我还差你钱不成。

你看，每个人都有不同的小九九，需求中的两难都是因为信息不足，我们知道了不同涉众的想法也就好做决定了，家长心疼孩子，没钱时候希望不耽误孩子吃饭，家长也不会故意欠钱；餐厅想卖多少饭收多少钱，他最希望实时收款，稍晚一下收到钱也能接受；刷脸系统提供商老板只能接受拿出一部分钱让没及时充值的学生可以吃饭以推销自己的系统。权衡各方利益和可以做的妥协，我们可以做出决策：每人每天做多垫3笔，单笔不超过30元，每个学校要有最大垫资限额。这样既帮助余额不足的学生解决燃眉之急，垫资总额也可控，皆大欢喜。

3.2.3 用例步骤

每个用例有多个回合，回合的步骤分为四类：请求、验证、改变、回应，每个回合必须包含请求和其余三类中的一类。写用例步骤注意一些点这里就不做详细的介绍了，可以去《软件方法》相关章节查看，只说一下拓展路径。

所有的步骤都可能要发生意外，其中某些意外是系统要负责处理的，处理意外的路径就是扩展路径，其中验证类步骤一定会出现扩展，否则就不用验证，反正失败了也处理不了，当扩展路径过于复杂时候我们为了便于管理，可以把这些路径当成一个拓展用例，拓展用例并不是从业务序列图推导而来的，它也不能独立给执行者提供价值，其好处是为了我们便于管理用例。

3.2.4 补充约束

补充约束包含字段列表、业务规则、质量需求、设计约束。字段列表是为了描述步骤中某个概念的细节，比如返回扣款信息包含什么？这个字段列表写到涉众有共识就可以了，有些信息不用进一步说明，比如班级信息大家都知道是几年级几班，就不用再去费时间写了。

业务规则是需求一种，是从涉众视角来看不这样不行的规则。例如学生信息要使用MySQL存储，这不是业务规则，涉众才不关心你用什么数据库呢。比如“每个用户最多垫资3笔”这个涉众关注，可以作为业务规则。

质量需求就是系统在正确做事的基础上，还要满足一些指标，这些指标就是质量需求，比如可用性、性能等等，不做赘述。

最后一点就是设计约束了，设计约束一样要从涉众的视角来看，比如扣款要用 XX 支付，因为学校可能申请到了 XX 支付免费率资格。“使用C++语言开发”就不是设计约束，因为涉众并不关心。

经过以上分析，我们得到扣款系统用例规约如下：

   
    前置条件：
       存在已经完成签约的学生账户
后置条件：
       扣款凭证已经关联一笔扣款成功的支付订单
涉众利益：
       家长--担心由于忘记充值，账户内余额不足而导致孩子无法吃饭
       餐厅老板--担心卖出饭但是没有收到对应的款项
       系统提供商老板--担心出现大量垫资未还的欠款，产生坏账造成资金损失
基本路径：
       1. 服务商收银系统提交消费信息
       2. 系统提示学生刷脸
       3. 系统验证刷脸学生账号签约状态
       4. 系统请求 XX 支付扣款
       5. 系统保存扣款结果
       6. 系统返回扣款单信息
扩展路径：
       3a. 学生账号未签约：
             3a1. 系统通知家长签约
       4a. 扣款账户余额不足：
             4a1. 系统校验垫资条件
                     4a1a. 不满足垫资条件
                     4a1a1. 转到5
             4a2. 系统请求 XX 支付扣款
             4a3. 系统通知家长还款
字段列表：
       1. 消费信息=消费金额+商户订单号
       2. 扣款单信息=扣款金额+是否垫资+支付订单号
业务规则：
       1. 单学生账户最多同时存在3笔欠款
       2. 垫资只针对消费金额小于30元的订单
       3. 每个学校有垫资上限，垫资上限=学生数*3*30*10%
质量需求：
       1. 扣款从收到请求到结束在5秒内完成
设计约束：
       1. 收款系统使用 XX 支付

至此，再补充一些设计稿等用于和研发沟通的素材，就可以将需求提给研发，让研发开始实现了。

04

小结

我们可以发现我们做的任何一个需求都是可以一步一步推导出来的，并不是我觉得、我认为、拍脑袋得出来的。“任何需求都是不这样不行，而不是这样也行”。我们做业务建模和需求这两个工作流一定要跳出来，不要从研发角度看问题，采用团灭法，假设研发团队都被杀死了，系统是路上捡到的，从组织角度去看问题，才能得到正确的需求。现在再来看这些话相信你就再也不迷糊了。

“你这需求怎么又变了”：1）需求没变，只是需求人员认识变了，之前的需求是错的；2）需求确实变了，因为战场已经攻占，愿景都变了需求自然而然也变了；

“我们人力有限，只做最高优先级的需求”：按照愿景排序，排在最前面的那个需求就是优先级最高的需求；

“你这需求不合理”：对于愿景中的改进指标没有帮助或者帮助很小，或者没有权衡涉众利益；

“你这过度设计了”：在当前时间点，这些功能对愿景中的改进指标没有帮助或者帮助很小。