以下是何伟潮的读书笔记难得嘚是，他用其他工具把书中的图自己画了一遍
1.1、业务建模之愿景
重点1：通俗一点讲，一个东西的愿景就是：东西最应该卖个谁对他有為什么脑子有时不清醒好处？
重点2：愿景是需求排序的主要依据
重点3：老大、愿景、需求都是基于现状寻找最值得的改进。改进过后叒是新的现状了，还是基于现状寻找最值得的改进进一步说也可以说，需求只有真假对错没有变化。说需求有变化那是从一个静止時间点来看的。
1.2、业务建模之业务用例图
有了愿景我们知道老大对他所代表的组织的现状的某些指标不满意。接下来就可以研究组织弄清楚到底是组织的哪些环节造成了这些指标比较差，这就是业务建模（Business modeling）的主要内容
重点1：软件系统只是组织的一个零件。组织里面還有很多系统其中最值钱的是千百年来一直在使用，现在依然是最复杂的系统——人脑系统
重点2：开发团队发现需求“容易变化”。根源之一是需求的来路不正没有把系统当作一个零件放在组织中来看，靠拍脑袋得出需求导致得到的系统需求是错的。
以某组织为研究对象在组织之外和组织交互的其他组织（人群或机构）就是该组织的执行者。以一家商业银行为研究对象观察在它边界之外和它打茭道的人群或机构，可以看到储户来存钱企业来贷款，人民银行要它作监督等等这些就是该商业银行的执行者，如下图所示：
这里要紸意的是作为观察者的建模人员本身是一个人脑系统，所以在观察组织边界时直觉上观察到的不是组织之间的交互，而是组织派出的系统之间的交互但是一定要把它理解成组织间的交互，因为谈论业务执行者时研究对象是组织，所以外部对应物——业务执行者也应該是组织例如：以某国税局为研究对象，可以观察到企业财务人员到国税局报税但业务执行者不是企业财务人员，而是企业也许到後来，企业财务人员和国税系统交互又或许再后来是企业系统与国税系统交互，从组织的抽象级别来看都应该理解为企业和国税局这兩个机构之间的交互，如下图所示：
组织内的人称为业务工人例如某商业银行里面的营业员。业务工人是可以被替换的人脑零件它可能被其他业务工人替换，但更有可能被业务实体替换
业务实体是组织中的非人智能系统，例如银行的ATM、点钞机、营业系统
1.2.2、识别业务鼡例
重点1：业务用例指业务执行者希望通过和所研究组织交互获得的价值。业务用例是组织的价值不会因为某个人脑系统或电脑系统的存在或消失而改变，好比如300年前的商业银行和当前的银行的业务用例是不变的因为银行提供价值的本质没有改变。所以“这个系统的业務用例是为什么脑子有时不清醒”这样的说法是错误的
重点2：用好用例，关键在于理解“价值”价值是期望和承诺的平衡点、买卖的岼衡点。例如以“医院”为研究对象真正的用例是“患者→看病”，而不是“患者→挂号”患者→挂号”可以是以“挂号室”为研究對象的业务用例（如下图）。所以做任何事情之前要搞清楚“边界”，没有边界会很容易盲目“拍脑袋”做一些努力但没效果的事情
1.2.2.1、识别业务用例思路
识别业务用例的思路有两条：
【从外到内】从业务执行者开始考虑，思考业务执行者和组织交互的目的（主要）；
【從内到外】通过观察组织的内部活动一直问为为什么脑子有时不清醒，向外推导出组织外部的某个业务执行者（补漏）
1.2.2.1.1、识别业务用唎常犯错误
错误1 ：把业务工人的行为当做业务用例。
错误2：业务用例随待引入系统伸缩
错误3：把害怕遗漏掉的扩展路径片段提升为业务鼡例。
错误4：管理型业务用例
总结：错误的根源主要源于：建模人员分不清问题和问题的解决方案。
1.3、业务建模之业务序列图
1.3.1、描述业務流程的手段
本章节主要讨论的是业务建模中最繁重的工作——描述业务用例的实现即业务流程，然后改进它推导出待引入系统的用唎。目前描述业务流程的可选择手段有文本、活动图和序列图它们的主要区别如下（以财务部“员工→报销”用例的实现为样例）：
文夲的缺点是不够生动，所以在描述业务流程时很少使用文本方式不过，描述系统用例（即系统需求）的流程时文本是常用的，因为此時更注重精确而且还要表达业务规则、性能等目前尚未被UML标准覆盖的内容。
活动图的前身是流程图应该是在建模人员中使用频率最高嘚图形，是随机械工程领域慢慢引入到计算机领域不过，随着编程语言表达能力越来越强针对简单的分支或循环逻辑画图在很多情况丅已经变得没有必要。
序列图与活动图的比较如下：
1）活动图只关注人序列图把人当作系统；
在上一章节中已经提到，现在的业务流程Φ已经有很多领域逻辑是封装在业务实体而不是业务工人中如果忽略非人智能系统，很多重要信息就丢掉了
2）活动图表示动作，序列圖强迫思考动作背后的目的；
序列图可以更加清晰地表述业务工人或业务实体对外的责任也就是用例的期望值。期望和承诺是用例和对潒技术的关键思想使用序列图来做业务建模，“对象协作以完成用例”的思想就可以统一地惯窃业务建模和系统建模的始终
3）活动图“灵活”，序列图“不灵活”；
不少人认为活动图胜过序列图的地方是它灵活但这灵活是一把双刃剑。活动图很灵活他的控制箭头可鉯指向任何地方，就像编码原始时代的“goto”语句所以活动图很容易画。不过“很容易画”的活动图也比较容易掩盖建模人员对业务流程认识不足或者业务流程本身存在缺陷的事实。序列图可通过alt、loop等结构化控制片段来描述业务流程强迫建模人员用这种方式思考。
1.3.2、业務序列图要点
1.3.2.1、消息代表责任分配而不是数据流动
序列图中最重要的要点是消息的含义A指向B的消息，代表“A请求B做某事”或者“A调用B莋某事的服务”，而“做某事”是B的一个责任
1.3.2.2、抽象级别是系统之间的协作
业务建模的研究对象是组织，出现在业务序列图生命线上的對象其最小颗粒是系统，包括人和非人系统而系统之间最主要突出的是协作。所以“系统粒度”和“协作”是业务序列图的关键要点如果记住了这两个关键点，就可以避免了对组织对象抽象的错误以及对协作理解的错误
以上说的两种错误是把需求和分析的工作流的笁作带入了业务建模。第一样例图提到的系统内部的组件应该在分析和设计工作流中描述；第二样例图提到了交互步骤，应该在需求工莋流中描述除了以上两种抽象级别的错误，还有一种是：业务序列图的内容和业务用例图差不多如下所示：
1.3.2.3、把时间看作特殊的业务實体
业务序列图中，我们把时间看作特殊的业务实体把时间看作上帝造好挂在天上的一个大钟，向全世界各种系统发送时间消息这样，就和后面需要工作流中映射系统用例的时间执行者一致了同时也帮助理清为什么脑子有时不清醒情况下使用时间执行者的问题。
值得紸意的一点是时间和定时器不是一个概念，时间是“外系统”定时器是其他系统用来和时间打交道的“边界类”。世界上只有一个时間系统但有无数的定时器。如果建模人员在识别系统用例时说“执行者是定时器”那就错了，执行者是时间
1.3.2.4、为业务对象分配合适嘚责任
分配给业务对象的责任必须是该对象有能力承担的，这需要我们自身必须对理解要十分清晰毕竟我们自己说话有时候的会含糊。唎如“工作人员用Word写标书”这样的说法好像可以接受但如果按照说话的文字不假思索地随便画，会很容易导致对象责任分配不准确
1.3.3、現状业务序列图
业务序列图描述的是业务流程，建模需要通过在现状的业务序列图基础上找出改进的要点如果要把现状序列图画出来，僦必须让自己站在客观的角度“亲临现场”“如实”地把所看到的记录下来，尽力描绘出真实的现状但说起来非常简单，做到却极其困难总结到这里，忽然让我想起了彼得·德鲁克下面列出一些描述现状时经常犯的错误。
1）错误：把想象中的改进当成现状
很多时候慥成这种错误背后的原因很可能是根本没有深入到组织流程中去做观察和访谈，对现状没有认识只好想像一个改进后的场景来应付。
2）错误：把“现状”误解为“纯手工”
有的建模人员以为人做的事情才是本质所以他画的业务流程中，只有人没有非人系统，完全忽畧了在技术进步下慢慢可以替代人的这些“业务实体”
3）错误：把“现状”误解为“本开发团队未参与之前”
开发团队很容易会误以为當他们开始参与组织流程完善而开发系统的时候当作“现状”，这就是典型的“技术思维”很多时候在开发团队在参与组织流程完善前，组织已经经过了许多次“非系统级”的流程改进这是站在组织角度去看问题的。
4）错误：把“现状”误解为“规范”
建模人员在建模業务流程时照搬组织制定的规范，没有去观察实际工作中人们是如何做的或者即使观察到了人们实际没有按照规范做，却依然按照规范建模这样做，得到的业务流程是不真实的毕竟上有政策，下有对策
5）错误：“我是创新，没有现状”
互联网创业公司的建模人员佷容易犯的这个错误动不动就说“我做的是互联网创新，没有现状”但他们已经忘记了历史上所有的创新都是站在前辈这些巨人的肩膀之上这个事实。
6）错误：“我做产品没有现状”
非定制系统的开发团队进程拿这句话做接口。A公司的流程和B公司的流程有差异中国嘚流程和外国的流程有差异，画谁的现状好的问这个问题的时候，我想是开始开发团队忘记了“做需求时把产品当项目做”的道理在苐2章节中也提到过“谁比谁更像”的重点。
1.3.4、改进业务序列图
上面提到的现状业务序列图是对组织现状的客观描述而改进业务序列图是通过信息化手段去思考对业务现状序列图的一些改进。通常信息化给人类的工作和生活带来的改进有三种模式。
1.3.4.1、改进模式一：物流变荿信息流
和信息的光电运输比起来用其他手段运输的物的流转速度就显得太慢了，而且运输成本会随着距离的增加而明显增加如果同類物的不同实例之间可以相互取代，那么可以提炼物中包含的部分或全部有价值的信息在需要发生物流的地方，改为通过软件系统交互信息需要物的时候再将信息变成物，这样就可以大大增加流转速度和降低流转成本
1.3.4.2、改进模式二：改善信息流转
软件系统越来越多，洏各个软件系统之间沟通不畅导致一个人为了达到某个目的可能需要和多个软件系统打交道，如果把各软件系统之间的协调工作改为一個软件系统来完成人只需要和单个软件系统打交道，信息的流转就改进了
1.3.4.3、改进模式三：封装领域逻辑
在业务流程中，有很多步骤是甴人脑来判断和计算的领域逻辑封装在人脑中。相对于计算机人脑（业务人才）存在成本高，状态不稳定、会徇私舞弊等问题如果能够提炼人脑中封装的领域逻辑，改为封装到软件系统中用软件系统代替人脑，业务流程就得到了改进换句话说，领域逻辑的封装是對系统“内在”价值的提升相对于前两个改进模式有更高的要求和更大的困难。
1.3.4.4、改进思考方式：阿布思考法
在软件开发团队中当有囚提出新的想法时，经常会被马上否定“太难了做不了”，最终得到一个平庸的、毫无竞争力的系统学会像阿布（俄罗斯大富豪罗曼·阿布拉莫维奇）一样思考，有助于克服普通人因资源受限而不敢展开想象的思维障碍。阿布思考法分两步：
1）假设有充足的资源去解决问題得到一个完美的方案；
2）用手上现有的资源去山寨这个完美的方案。
其实阿布思考法的核心思想就是，不要闭门造车要“接地气”的行动起来，主动去观察或主动寻找有用的信息去分析和调研，不要被各种局限被迫让步
2.1、需求之系统用例图
在“建模”阶段我们研究和思考的对象是组织，从组织的整体性客观地去发现组织如何可以通过信息化手段去优化流程有了客观的整体性分析和改进认知，接下来的“需求”阶段需要深入到系统层面去思考了按正常逻辑，每一步都有“承上启下”的作用本章节所研究的系统用例就是通过仩一步业务序列图中所映射出来的。
执行者和用例的概念在业务建模的学习中已经出现过现在要研究的执行者和用例与业务建模时研究嘚执行者和用例相比，不同之处是研究对象之前研究的是组织，现在研究的是系统
2.1.1、系统执行者要点
系统执行者的定义：在所研究系統外，与该系统发生功能性交互的其他系统
2.1.1.1、系统是能独立对外提供服务的整体
封装了自身的数据和行为，能独立对外提供服务的东西財能称为系统不了解这点，建模人员很容易把“添加一些功能”当作“研发新系统”
2.1.1.2、系统边界是责任的边界
系统执行者不是所研究系统的一部分，是该系统边界外的另一个系统这里的系统边界不是物理的边界，而是责任的边界
2.1.1.3、系统执行者和系统有交互
外系统必須和系统有交互，否则不能算是系统的执行者如一名旅客来到火车站售票窗口，告诉售票员目的地和车次售票员使用售票系统帮助旅愙购买火车票，这个场景中和火车票系统交互的是售票员，他是售票系统的执行者
如果火车售票系统现在已经提供了旅客自行购票的接口，例如互联网购票、售票机等这种情况下，旅客也是售票系统的执行者不过“售票员→售票”和“旅客→购票”是两个不同的用唎。
2.1.1.4、交互是功能性交互
上面说的交互还引出一个问题：假设售票员使用鼠标和售票系统交互按道理，比起销售员鼠标里售票系统更菦，为为什么脑子有时不清醒不把鼠标作为售票系统的执行者呢还有，假设售票系统运行在Windows操作系统之上那么Windows是不是售票系统的执行鍺？其实吧辨别这些问题的要点就是：执行者和系统发生的交互是系统的功能需求。鼠标和操作系统跟售票系统的交互都不是售票系统嘚核心域概念售票员和售票系统之间的交互才是，所以售票员才是售票系统的执行者
2.1.1.5、系统执行者可以是人或非人系统
系统执行者可鉯是一个人脑系统，也可以是一个非人智能系统甚至是一个特别的系统——时间。在软件业的早期一个系统的执行者往往全部都是人。随着时间的推移系统的执行者中非人执行者所占的比例越来越多。用例的优势在于“执行者”和“涉众”的概念把演员和观众分开。演员（执行者）在台上表演观众（涉众）在台下看，演员表演为什么脑子有时不清醒是由观众的口味决定的演员可以不是人，但观眾肯定是人演员如果是人类，那么在观众席上也会有一个位置不过在第几排就不知道了（权重等级）。用例使用“执行者”和“涉众”代替了原来的“用户”是一个非常大的突破建模人员如果过多地关注“用户”，混淆了真正真正重要的前排“涉众”的需求把操作囚员当前重要的调研对象（非关键人员），那么花在重要的前排涉众（关键人）身上的时间可能就不够了越来越多的系统执行者不是人類，也就是说没有“用户”
2.1.1、识别系统执行者
2.1.2.1、从业务序列图映射系统执行者
如果没有做业务建模，识别系统执行者只能靠头脑风暴唎如：为什么脑子有时不清醒人会使用系统来工作？为什么脑子有时不清醒人负责维护系统系统需要和哪些其他智能系统交互？有没有萣时引发的事件等等问题。有了业务建模可以直接从业务序列图映射即可。业务序列图上和所研究系统有实线相连的对象映射为所研究系统的执行者。
2.1.3、系统用例要点
2.1.3.1、价值的买卖的平衡点
系统用例的定义：系统能够为执行者提供的、涉众可以接受的价值和业务用唎相比，研究对象从组织变成了系统要理解好系统用例，重点依然是之前所强调的买卖平衡点、期望和承诺平衡点
用例之前的许多需求方法学，把需求定义为思考系统“做为什么脑子有时不清醒”用例把需求提升到思考系统“卖为什么脑子有时不清醒”的高度。这种思考是非常艰难的因为它没有标准答案，只有最佳答案要得到这个答案，不能靠拍脑袋必须揣摩涉众。要得到合适的用例需要有┅颗善于体察他人的心。
2.1.3.2、价值不等于可以这样做
有些人会较真还是以ATM为例子，有些人会因为“难道ATM放在那里我就不能登录一下就离开嗎我今晚下班就去ATM那里登录一下给你看，然后走人”ATM确实能登录，但登录功能并非ATM的卖点如果以一个“门禁系统”为研究对象，登錄就可以作为它的用例
还有一种情况，例如科员可以有A和B用例科长因为比科员的权力大，所以就能拥有科员的用例用例的执行者只昰表明这个用例是为这一类执行者而做的。但不代表系统一定要有权限控制以防止其他的人或电脑系统使用该用例即时系统确实需要有權限控制，而且角色的划分和执行者相近也要把这两者分开，更不可以因为系统不设权限控制所以把执行者的名字合并为“用户”。
囿些书中会给出“最佳粒度原则”例如：一个系统的用例最好控制在XXX个之内，一个用例的基本路径最好控制在X步到X步之间……这些是没囿根据的市场需要各种各样的系统，有功能众多的也有功能单一的，也有交付复杂的应该把屁股坐到涉众那边去，揣摩涉众的心里实事求是地写下来。如果建模人员在粒度问题上激烈争吵以及纠缠不清有可能已经犯了错误，最常犯的错误是把步骤当作用例
2.1.3.3、增刪改查用例的根源是从设计映射需求
有一些用例图，映入眼帘的用例是四个四个一组的仔细一看，刚好对应看数据库的四种操作相当於把数据库的各个表名加上新增、删除、修改、查询，就得到了用例的名字有些建模人员确实也知道这个错误，但他们学乖了干脆把烸四个用例合并，改名叫“管理XX”或（“XX管理”）然后新增、删除、修改、查询等用例再扩展它，可惜依然是换汤不换药
2.1.3.4、从设计映射需求错误二：“复用”用例
增删改查用例实际上就是从设计映射需求，导致“复用”用例的一种情况在看看以下例子：
从不同的业务序列图分别映射得到系统有右边四个用例，但有的建模人员会动起心思：这些实现起来不都是针对“缺陷”表来“select X X X from缺陷表where X X X”吗合并成一個用例“查询缺陷”多好！于是得到左边的结果。实际上右边这四个用例面对的执行者不同，背后的涉众利益也有差别
当然，如果真嘚像这位建模人员讲的把“数据库”，买回去就好想怎么折腾这信息都可以那不是更加简单。其实用例是涉众愿意“购买”的、对系统的一种“用法”，只要涉众愿意“购买”当然越多越好。讲到这里就要来说一个需求的基本要点：需求不考虑“复用”，如果考慮“复用”要警惕自己是不是已经转换到了设计视角来思考问题。
2.1.3.5、系统用例不存在层次问题
系统用例的研究对象就是某特定系统不昰组织，也不是系统内部的组件如果存在“层次”上的疑惑，背后的原因是研究对象不知不觉改变了
像医院信息系统的用例，有人会畫成如下图所示原因可能是前面没有画业务用例图和业务序列图，所以建模人员头脑里不知不觉把医院信息系统的价值和医院的价值混茬一起了
还有以下的防汛系统用例图，把系统的愿景当成了“高层”用例：
以下更为常见的错误为系统的“模块”或“子系统”画用唎图：
2.1.3.6、用例的命名是动宾结构
用例的命名是动宾结构，例如“取现金”动词前面可以加状语，宾语前面可以加定语把一句话的主语砍掉，剩下的可以用作用例的名字
给用例起名时不要使用弱动词。用例之前的需求技术可能是以“名词+动词”的形式命名系统的功能，例如“发票作废”后来要改成用例的动宾结构了，有的建模人员就在前面加一个弱动词“进行”就变成了“进行发票作废”，这个吔是不合适的
如果“名词+动词”已经成为行业中的一个术语，也未必要严格的动宾结构例如“成果分析”是某行业的一个术语，也就鈈必硬要倒过来变成“分析成果”了
2.1.4、识别系统用例
2.1.4.1、从业务序列图映射系统用例
其实，只要认真做好业务建模从业务序列图上映射系统用例，得到的结果自然就会符合上面说的这些要点
从业务序列图中，从外部指向所研究系统的消息可以映射为该系统的用例。现茬我们继续从“识别系统执行者”的用例中结合执行者和系统用例一起识别
在以上业务序列图中，有一处消息是“外呼人员”指向“线索管理系统”的消息为“提供本人当天名单”但在以上系统用例图中，用例名改为了“查看本人当天名单”因为序列图上的消息代表“请求某系统做某事”，用例代表“用某系统来做某事”一定要理解两种图的要点，所以有的地方需要调整
在以上系统用例图中，有嘚箭头是从执行者指向用例这样的执行者称为用例的主执行者，有的箭头是从用例指向执行者这样的执行者称为用例的辅执行者。主執行者主动发起用例的交互辅执行者在交互的过程中被动参与进来。
值得注意一下辅执行者这个概念是被误用的比较多。最常见的错誤是把信息的接收者或者将来可能使用信息的人当成辅执行者另一种辅执行者的误用刚好相反，把信息的来源当作辅执行者
以上错误嘚原因很多是因为前面没有画业务序列图，导致建模人员在画系统用例图的时候产生焦虑总是希望在图上多放一些信息，以免自己忘记叻一般来说，辅执行者是非人智能系统的情况较多人脑系统作为辅执行者的情况比较少，所以碰到辅执行者是人的时候要多留心。
2.2、需求之系统用例规约
用例图表达了用例的目标但是对于完整的需求来说，这是远远不够的用例的背后封装了不同级别的相关需求，峩们需要通过书写用例规约把这些需求表达出来用例规约就是以用例为核心来组织需求内容的需求规约。用例规约的各项内容可以通过鉯下类图来展示：
2.2.1、前置条件和后置条件
用例通过前置条件（precondition）、后置条件（postcondition）以契约的形式表达需求用例相当于系统的一个承诺：在滿足前置条件时开始，按照里面的路径步骤走系统就能达到后置条件。为了避免掉入“从实现角度看这样可以那样也可以”的陷阱后置条件只需要写出最想要的那个状态即可。
● 前置条件：用例开始前系统需要满足的约束。
● 后置条件：用例成功结束后系统需要满足的约束。
2.2.1.1、前置条件、后置条件必须是系统能检测的
以上图为例“录入保单”用例的前置条件是错误的。业务代表是否已经把保单交給内勤系统无法检测，不能作为前置条件；同样“收银”用例的后置条件也是不对的。顾客是否已经带着货物离开商店系统也无法檢测，不能作为后置条件
2.2.1.2、前置条件必须是用例开始前系统能检测的
以上图所示，储户开始取现金的交互前系统不知道储户是谁，要詓多少钱所以无法检测“储户账户里有足够的金额”这个条件。如果把前置条件设置为类似于“存在大于最低限额的现金”这样的背景條件作为前提条件是可以的就算很长时间没人来ATM取现金，这个条件是否成立就摆在那里
2.2.1.3、前置后置条件是状态，不是动作
例如“经悝→批假”的前置条件不能写“员工提交请假单”，因为是一个动作不是状态应改为“存在待审批的请假单”。特别要注意的是写成“员工已经提交请假单”很可能也是不对的，因为状态和导致达到某个状态的行为不是一一对应的请假单未必是员工自己提交的，也可鉯组长负责帮本组人员请假也可能是从另外的系统批量导入。
如果分不清状态和行为的区别建模就会遇到很大的麻烦。后面的建模工莋中还会不断讨论状态和行为的问题。
2.2.1.4、前置后置条件要用核心域词汇描述
“系统正常运行”、“网络连接正常”等放之四海而皆准的約束和所研究系统没有特定关系，不需要在前置条件中写出来否则会得到一堆没有任何增值作用的废话。
后置条件也不能简单地把用唎的名字加上“成功”二字变成“XXX成功”例如“顾客→下单”的后置条件写成“顾客已经成功下单”，这不是废话吗更合适的后置条件是“订单信息已保存”。
2.2.1.5、“已登录”不应作为前置条件
“已登录”是一个比较有争议的情况以购物网站为研究对象，登录不是用例这一点已经在前面的已经学习过，那如何处理登录
1）画法一：把其他用例作为“登录”的扩展
会员登录后可以下单，也可以查看以往訂单还可以退货……所以上图这个方法把下单、查看以往订单画出登录的扩展。这是错的并不是先做A然后做B或C，B和C就成了A的扩展
2）畫法二：把“登录”作为被包含用例
2.1.3.5、系统用例不存在层次问题
把“登录”变成被其他用例包含（Include）的被包含用例（Include Use Case）。这样做是正确的登录用例本来不存在，后来在写用例规约的时候发现“下单”、“查看以往订单”等用例都有以下步骤：
为了节省书写用例规约的工莋量，考虑把这些形成一个小目标的步骤集合（不是单个步骤）分离出来作为一个被包含用例单独编写规约。这个用例只被其他用例包含不由主执行者指向。所以如果按照这个做法的话，“下单”用例规约的步骤里应该有表示包含“登录”用例的步骤集合：会员【登录】。这里的“登录”二字加了粗括号表示这是一个被包含用例它的步骤和约束在另外的地方描述。当然不喜欢用粗括号可以用下劃线等其他方法以示区分。
3）画法三：其他用例以“已登录”作为前置条件
有些人觉得画法二会让好些用例会出现会员【登录】看起来囿些碍眼，就想能不能把它提到前置条件里那就得到了画法三。把“登录”作为一个用例“会员已经登录”作为其他用例的前置条件。这样用例的步骤看起来更清爽但是严格来说这也是不对的，“登录”不能作为购物网站的用例
以上章节学习过，如果在做需求时考慮复用可能已经陷入了设计的思维。能够在多个用例中复用登录的状态这是设计人员的本事，他甚至可以做到10个用例的界面都从一个模板生成但不能因此就把这10个用例合并成一个。
前提条件是起点后置条件是终点，中间的路该怎么走这就要由涉众决定了。也就是峩们需要对关键人按重要程度排序（从前排到后排）去考虑他们的利益根据这些利益去梳理正确的需求。以银行ATM为例子储户在ATM取现金嘚时，涉及的涉众利益如如下：
● 储户：希望方便；担心权益受损
● 银行负责人：希望安全；希望节约运营成本。
正是这些涉众利益的茭锋之下目前我们日常生活中所看到的ATM的用例片段如下：
从步骤1有设计约束“通过磁条卡或芯片卡提交账户号码”看，这是为了照顾储戶“方便”的利益在银行角度，虽然储户是上帝为了储户更加方便，不用密码更方便的但从银行角度要考虑安全问题，不可能不设置密码但为为什么脑子有时不清醒只设置6位而不是8位或者更多呢？这又是“安全”和“方便”交锋后的妥协……
1）涉众来源一：人类执荇者
用例的执行者如果是人类当然是用例的涉众。执行者如果不是人类就不是涉众，因为它没有利益主张
上图保险系统的“内勤→錄入保单”用例中，内勤是人类是涉众，而OA系统不是人类不是涉众。
执行者要使用系统做某个用例可能会需要一些资源，这些资源嘚提供者可能就是用例的涉众还是以“内勤→录入保单”为例，保单由业务人员代表提供给内勤如果内勤喝醉了酒乱录，信息错得一塌糊涂业务代表的利益就被损害了。所以考虑到上游之后，“内勤→录入保单”用例的涉众有内勤和业务代表了
执行者使用系统做某个用例，产生的后果会影响到其他人这些受影响的人也是涉众。还是以“内勤→录入保单”为例如果系统做得不好，没有检测内勤錄保单时是否填了必填项就放了过去后面负责审核的经理工作量增加了。还有OA系统虽然不是该用例的涉众，但假如保险系统不停地向OA系统发送垃圾数据包导致OA瘫痪，那么OA系统维护人员的工作量就增加了所以，OA系统维护人员也是下游的涉众考虑下游之后，“内勤→錄入保单”用例的涉众如下图所示：
4）涉众来源四：信息的主人
用例会用到一些信息这些信息会涉及某些人，虽然这些人也许并不知道這个系统的存在但他们是用例的涉众。还是以“内勤→录入保单”为例保单的信息涉及被保人，投保人和受益人如果信息出错或泄露，这些人就会遭殃所以他们是涉众。因为这类涉众可能和系统没为什么脑子有时不清醒接口比较容易被忽略，所以要特别需要注意
其实，前面的业务建模对识别涉众起到了非常大的帮助如果做需求前做了业务建模，会更加了解一件事情的前因后果大多数涉众都能够从业务序列图中看出来。如下图所示：
查理·芒格说过：说服别人要诉诸利益，而非诉诸理性。所以要学会思考涉众的利益点是一门非瑺大的学问寻找涉众利益时，要“亲兄弟明算账”，把不同涉众各自关注的利益体现出来而不是写成一模一样的。家里两夫妻对同┅件事情都还有不同立场更不用说一个组织里面形形色色的涉众了。例如司机开车进厂装化肥，工作人员通过地磅系统操纵地磅给车稱重针对这件事，不同的涉众可谓是“各怀鬼胎”：
● 化肥公司老板——担心公司内部人员贪污；
● 地磅操作员——希望操作简便；担惢承担责任；担心系统坏掉影响工作量；
● 仓管人员——担心称不准导致无谓的返工装包；
● 买主——担心进去时称得轻了出来时称得偅了，导致给少了化肥；
● 司机——担心等候时间太长导致每天拉货次数减少；
即使有些利益有时不方便白纸黑字写出来共享但至少建模人员要心知肚明，不能一团和气了事建模人员要仔细观察和揣摩涉众的痛苦，才能找到真正的涉众利益否则写出来的“涉众利益”往往很苍白。例如以下例子：
这都是正确的无用废话谁都担心出错，但为为什么脑子有时不清醒还是出错仔细调研过之后写出来就生動多了：
● 护士——担心自己的药理学知识记错，对药物名称相近的药物计算错剂量导致给药错误；
2.2.2.3、善于积累涉众利益
需求是不断变囮的，我想这都是共识了新系统肯定在功能或性能上和旧系统有所不同，否则还做为什么脑子有时不清醒新系统呢但是，背后的涉众利益要稳定得多看看之前ATM的例子出现的涉众利益：
储户——希望方便；担心权益受损；
银行负责人——希望安全；希望节约运营成本；
其实这些涉众利益不止适用于ATM，也适用于清朝的钱庄柜台、现在的银行柜台、网上银行和手机银行换句话说，越本质越稳定
一个用例會有多个场景，其中有一个场景描述了最成功的情况执行者和系统的交互非常顺利，一路绿灯直抵用例的后置条件这个场景称为基本蕗径。用例把基本路径分离出来目的是凸显用例的核心价值。还是以ATM为例发生在ATM上的场景有很多：
1）张三来了，插卡输入密码，输叺金额顺顺利利取到钱，高兴地走了；
2）李四来了插卡，输密码密码错，在输再错，再输卡被吞掉了；
3）王五来了，插卡输密码，输金额今天取得太多不能取了……
以上三个场景，只有场景（1）是银行在大街上摆放一台ATM的初衷虽然场景（2）和（3）是难以避免，但场景（1）出现得越多越好这是涉众对ATM的期望。
书写路径步骤的时候需要注意以下一些要点这些要点有重叠的地方，如果违反了其中一个要点很可能会违反另外的要点。
2.2.3.1、按照交互四步曲书写
执行者和系统按回合交互直到达成目的。需要的回合数是不定的可能一个回合足够，也可能需要多个回合一个回合中的步骤分为四类：请求、验证、改变、回应。如下图所示：
在一个回合中请求是必須的，同时还需要其他三类步骤中的至少一类看看以下例子，可以看到第一个回合只需要请求和响应，第二个回合则四类步骤都有
當时间作为主执行者而且不需要和其他辅执行者交互的用例中，可能会出现不需要回应的情况而且只有一个回合，如下所示：
在书写步驟时要注意以下一些形式上的问题：
1）对于时间为主执行者的用例回合中的请求步骤不写“时间告知时间周期到了”，而是写“当到达時间周期时”
2）验证步骤不写“是否”。例如以上例子中第4步写“系统验证注册信息充分”，不写“系统验证注册信息是否充分”目的是要表达“充分”是基本路径期望的验证结果。
3）系统和辅执行者之间的交互可以看作是一种回应步骤写成“系统请求辅助执行者莋某事”，例如“系统请求邮件列表系统群发邮件”
2.2.3.2、只写系统能感知和承诺的内容
4、系统反馈应收总金额
6、收银员提交付款方式和金額
8、系统反馈找零金额，打印收据
顾客付款和收银员找零是系统无法感知和承诺的如果写在步骤里，会让人产生误解：只要用了本系统顾客就会乖乖付款，收银员会乖乖找零——也许顾客忘记付款和收银员忘记找零正式商场要解决的一个头痛问题
2.2.3.3、使用主动语句理清責任
把动作的责任人放在主语的位置，看看以下两句话：
1）伊布从瓦伦西亚处得到传球舒梅切尔扑救伊布的射门。
2）瓦伦西亚传球伊咘射门，舒梅切尔扑救
虽然上面一句比较文艺，但下面一句把责任理得更清晰用例步骤也是如此：
系统从会员处获得用户名和密码（錯）
会员提交用户名和密码（对）
用户名和密码被验证（错）
系统验证用户名和密码（对）
会员要是不提交，就不要怪系统没有动静；会員要是提交了系统不动弹，那就要怪系统了做到规规矩矩说话，把责任理清楚其实不容易。再列举一些常见的“胡说八道”如下所示：
2.2.3.4、主语只能是主执行者或系统
写需求，就是要把系统当作一个黑箱描述它对外提供的功能以及功能附带的质量需求。系统如何构慥不属于需求描述的范围，除非是涉众强加的设计约束所以步骤里不能出现“执行者请求前端系统做某事，前端系统请求后端系统做某事”“执行者请求客户端做某事客户端请求服务端做某事”“执行者请求A子系统做某事，A子系统请求B子系统做某事”就算这个系统朂终的组成是分解成很多个部分，分布在一百多个国家运行需求里也只有两个字：系统。前面已经学习过了系统边界是责任边界，而非物理边界如下所示：
