软件方法 | Stay Hungry

将“业务到实现” 涉及的所有流程进行拆解、细化，提供落地标准。并有例子说明，通俗易懂。
自己看了收获很大，改正以前很多不规范的地方，对软件方法有了新的认识。还需要消化吸收，和以前的知识融合一下。

👇一句话来自书中，算是《穷查理宝典》中“保持终生学习”的具体例子，与大家分享：

有的开发人员的“十年工作经验”实际上是“一年工作经验用了十年”，一直在热热闹闹的民工层次徘徊，没有积累和成长。

建模和UML

利润 = 需求 - 设计

“子系统”不是从需求直接映射出来的，需要设计人员的想象力
需求和设计的区别
要拥有全局视角，不能从需求出发进行方案设计。作者拿”人体”系统作为例子，很形象。

人体的功能(能做什么)是走路、跑步、跳跃、举重、投掷、游泳……但是设计人体的结构时，不能从需求直接映射到设计，得到“走路子系统”、“跑步子系统”、“跳跃子系统”……人体的“子系统”是“呼吸子系统”、“消化子系统”、“血液循环子系统”、 “神经子系统”、“内分泌子系统”……“子系统”不是从需求直接映射出来的，需要设计人员的想象力 ——本例子的设计人员就是造物主了。同样，也不能从设计推导出需求:因为人有心肝脾肺肾，所以人的用例是“心管理”、“肝管理”。

建模工作流

业务建模：描述组织内部各系统(人脑系统、电脑系统……)如何协作，使得组织可以为其他组织提供有价值的服务。 如果通过业务建模推导新系统的需求，而不是拍脑袋得出，假的“需求变更”会大大减少。

需求：描述为了解决组织的问题，系统必须具有的表现——功能和性能。严防“做”污染“卖”。需求工作流的结果——需求规约是“卖”和“做”的衔接点。
分析：提炼、封装核心域。
设计：核心域如何映射到选定平台上实现。

建模和敏捷

愿景、业务建模方法，帮助迅速定位最重要的需求;领域分析方法，帮助厘清各种概念的变和不变。
不要让“面向过程”、“敏捷”成为偷懒的庇护所。

业务建模之愿景

什么是愿景

以一个待引入系统为研究对象，其愿景的定义是:在目标组织代表(老大)看来，引进该系统应该给组织带来的改进。（百度百科-愿景 )

定位目标组织和老大

目标组织：待引入系统将改进其流程的组织。它可以是一个机构，也可以是一个人群。
老大：目标组织的代表。

【步骤】定位目标人群和老大

方法:不断追问“谁比谁更像?”、“为什么?”
常见错误：
1. 从功能加上“人群”二字得到目标人群
2. 吃窝边草
3. 虚构老大

【步骤】定位机构范围和老大

（个人理解为垂类领域，如erp、crm等专业系统。因为任何机构都由人组成，但既然称为“机构”，一定专注于某一特定领域，该领域有自己的规则。听上去和“目标人群”又有些一样了。）

方法：最开始机构中的某个涉众(可能不是老大) 提到要做一个什么系统，还提供了一些模糊的目标，建模人员根据这些素材推敲到机构范围，再定位老大，揣摩老大的愿景，再从愿景来判断之前的范围是否要调整。如果范围变化，老大可能也要再做调整……循环往复，逐步逼近。

常见错误：
1. 目标机构的 IT 主管是老大：IT 主管不是老大，因为系统要改进的不是目标机构 IT 部门的流程，而是业务部门的流程。所以，老大应该是业务部门主管或机构负责人，视系统改进波及的范围而定。以看病做类比。患者病情比较严重或者患者不便交流的时候，和医生频繁打交道的可能是患者的家属，但切不可因此把患者家属架上手术台。
2. 机构之上的大领导是老大。
3. 谁出钱谁是老大：还是以看病做类比。患者治病的钱可能是自己出，也可能是家属出，政府出，同房病友捐赠，甚至由医院免单。不管怎样，上手术台的还是患者。
4. 把其他涉众当作老大

【步骤】定位目标机构

系统是为某一类机构服务。那么，除了第 2 种情况中要做的工作之外，还需要插入一步:定位目标机构。（更加精确）定位目标机构的思考方法和定位目标人群的思考方法是一样的。

提炼改进目标

思考度量指标，可以用以下方法（这部分是系统思考方法，需要找几本书看看）：
- 针对形容词来思考符合这个形容词和不符合这个形容词的情况。（常见的一种系统思考方法）
- 从初步设想的解决方案倒推。可以这样思考:如果没有这个解决方案，涉众要付出什么代价?
- 借鉴机构的 KPI。
改进目标描述的是系统给目标组织带来的改进，应该从老大和目标组织的视角来定义。

业务建模之业务用例图

有了愿景，我们知道老大对他所代表的组织的现状的某些指标不满意。接下来就可以研究组织，弄清楚到底是组织的哪些环节造成了这些指标比较差，这就是业务建模(Business Modeling)的主要内容。 “业务建模”这个名字其实起得不好，应该更名为“组织建模”。 出于对过去叫法的尊重，本书依然称为“业务建模”。
开发团队经常发现需求“容易变化”。根源之一是需求的来路不正，没有把系统当作一个零件放在组织中来看，靠拍脑袋得出需求，导致得到的系统需求是错的。系统投入使用后，发现和组织的其他零件格格不入，自然要改。“需求变化剧烈”是一个假象，真正的需求没有变，只不过一开始得到的需求是假的。如果能正确运用业务建模技能，“需求变化”就会消于无形。（这不也是正确的废话，谁能保证建模正确。）
在业务建模工作流，我们从内外两个视角来研究组织。从外部看，组织是一些价值的集合，我们可以用业务用例图表示；从内部看，组织是一些系统的集合，我们可以用业务序列图来表示。

【步骤】识别业务执行者

业务执行者

以某组织为研究对象，在组织之外和组织交互的其他组织(人群或机构)就是该组织的执行者。因为研究对象是一个组织，所以叫业务执行者。

业务工人和业务实体

组织内的人称为业务工人(Business Worker)，例如某商业银行里面的营业员。业务执行者和业务工人的区别是:一个在组织外面，一个在组织里面；一个是组织不可替换的服务对象，一个是组织可以替换的零件。
业务工人是可以被替换的人脑零件，它可能会被其他业务工人替换，但更有可能被业务实体替换。业务实体是组织中的非人智能系统，例如银行的 ATM、点钞机、营业系统。
责任转移的思想对识别待引入系统的需求很有帮助。开发人员说，“我在开发一个新系统”，其实说的就是“我在开发一个新的业务实体，取代现有业务工人或业务实体的一些责任”。这样，探索需求的思路就出来了——我们画好现状的业务序列图，然后寻找改进点改进业务序列图。
业务工人和业务实体不在业务用例图中出现，因为它们不是组织的价值，而是成本。在识别业务执行者时，不需要画业务工人和业务实体。
在接下来画业务用例的实现——业务序列图的时候，将业务工人和业务实体作为类(Class)的一个构造型，放在名为“业务对象”的包里。组织的业务工人和业务实体协作完成业务用例，系统的类协作完成系统用例。

识别业务执行者

（《金字塔原理》《重构》中都有同样观点：在同一抽象层次上描述。）

直觉上观察到的不是组织之间的交互，而是组织派出的系统之间的交互，但是一定要把它理解成组织之间的交互，因为谈论业务执行者时，研究对象是组织，所以外部对应物——业务执行者也应该是组织。

【步骤】识别业务用例

业务用例指业务执行者希望通过和所研究组织交互获得的价值。
业务用例是为业务执行者服务，不是为业务工人服务。这不是什么规范问题，背后有它的道理。
要从业务执行者的角度去看，才能看得清楚组织的本质价值。
组织里发生的一切都是为了给业务执行者提供价值。这样的思路对改进业务流程有非常大的帮助:先归纳出组织对外提供什么价值，再思考如何更好地优化组织内部流程来实现这些价值。

正确理解价值

价值是期望和承诺的平衡点、买卖的平衡点。
业务用例是组织对组织的服务，相对于系统为系统提供的服务(系统用例)来说，所需要的时间是比较长的，不能把用例实现过程中的某个交互片段当成用例。
一个典型的执行者使用系统做了某事，达到了某个结果，然后离开系统去做别的事情，如果离开时他心里认为得到目前的结果已经不算白做，就可以把做某事作为一个系统用例。有一些词汇带有浓浓的“系统”味道，例如新增、查看、录入、查询、修改、配置……带有这些词汇的用例，很可能不是组织提供的价值，而是某系统提供的价值。

边界框问题

讨论“是不是用例”、“有哪些用例”的时候，必须先说清楚研究对象，否则讨论没有意义。
画用例图时，能加上边界框尽量加上。

识别业务用例的思路和常犯错误

识别业务用例有两条思路：

从业务执行者开始，思考业务执行者和组织交互的目的。
通过观察组织的内部活动，一直问为什么，向外推导出组织外部的某个业务执行者。
第一条路线是主要的，第二条路线用于补漏。

识别业务用例本来应该是很简单的事情，但是，许多程序员出身的需求人员受到了以往工作经历的影响，往往把简单的事情变得复杂，常见错误：

把业务工人的行为当作业务用例。这里反映了建模人员常见的一个问题:分不清问题和问题的解决方案。
业务用例随待引入系统伸缩。一个组织，甚至组织的一条流程都涉及许许多多的系统。在开发不同的系统时，研究业务用例和业务流程，发现得到的结果和开发另一个系统时的研究结果差不多，这是很正常的。建模人员不必因此感到惊慌，更不要因为“业务用例太少”、“业务用例太简单了”不自觉地改变研究对象，把待引入系统的用例搬上来。
把害怕漏掉的扩展路径片段提升为业务用例。 可以使用扩展路径来解决。
管理型业务用例。 从“药师盘点药品”推导出背后的好处，然后画成“管理型业务用例”。它没有特定组织的味道，哪家营利机构不是为了赚钱?另外，也很容易和愿景、涉众利益混在一起，发展下去，就会有“顾客→希望东西更便宜”之类的“用例”。

业务建模之业务序列图

描述业务用例的实现，即业务流程，然后改进它，推导出待引入系统的用例。

序列图和活动图比较

活动图只关注人，序列图把人当作系统：活动图描述业务流程时，建模人员往往只注意人或部门的活动，忽略了非人智能系统的责任。本书选择序列图的原因是把人脑系统和电脑系统平等看待。
活动图表示动作，序列图强迫思考动作背后的目的：使用序列图来做业务建模，“对象协作以完成用例”的思想就可以统一地贯彻业务建模和系统建模的始终。
活动图“灵活”，序列图不“灵活”:灵活是双刃剑。

业务序列图要点

消息代表责任分配而不是数据流动

序列图最重要的要点是消息的含义。A 指向 B 的消息，代表“A 请求 B 做某事”，或者“A 调用 B 做某事的服务”，做某事是 B 的一个责任。

数据流仅仅作为消息的输入输出参数存在。如果不了解这一点，就容易把消息的方向当成数据流动的方向，不但消息名称没写对，还会出现成对的消息。

抽象级别是系统之间的协作

业务建模的研究对象是组织，出现在业务序列图生命线上的对象，其最小颗粒是系统，包括人和非人系统。
几种错误：

表达过细，系统内部的细节也表现出来，这些是在分析、设计阶段表现。
业务序列图内容和业务用例图差不多：建模人员根本不了解组织内部有哪些岗位，各自承担什么责任。
把不具备任何智能的物体放到了业务序列图的生命线上。

可能有的读者纳闷，我怎么记得看过的书里经常有序列图上出现订单、申请单对象?那是分析序列图。我们用对象的思想去构思我们所开发的系统的内部结构和行为，就得到了订单、申请单等假想的有生命的对象。

只画核心域相关的系统

大致的判断标准是：如果是核心域相关的系统，应该出现在业务序列图中，如果不是，可以不出现。
（类似《ddd》中，不同的领域内聚合根、实体、值对象是不一样的。在不同场景，核心域相关的系统也不同）

把时间看作特殊的业务实体

时间和定时器不是一个概念。时间是外系统，定时器是其他系统用来和时间打交道的边界类，如图 4-19 所示。世界上只有一个时间系统，但有无数的定时器。有的建模人员在识别系统用例时说“执行者是定时器”，这样说是错的，执行者是时间。

为业务对象分配合适的责任

【步骤】现状业务序列图

尽力描绘出真实的现状，说起来非常简单，做到却极其困难。为了克服困难，建模人员甚至应当在心里暗暗发誓：如果不尽力去靠近真相，天打雷劈!（😆😆）

错误1:把想象中的改进当成现状

背后的原因很可能是根本没有深入到组织流程中去做观察和访谈，对现状没有认识，只好想像一个改进后的场景来应付。

错误2:把“现状”误解为“纯手工”

简单讲就是只考虑“人”，忽略了“非人系统”。

错误3:把“现状”误解为“本开发团队未参与之前”

错误4:把“现状”误解为“规范”

建模人员在建模业务流程时，照搬组织制定的规范，没有去观察实际工作中人们是如何做的，或者即使观察到了人们实际没有按照规范做，却依然按照规范建模。如果视而不见，也就丧失了许多有价值的改进机会。

错误5:“我是创新，没有现状!”

错误6:“我做产品，没有现状!

做需求时把产品当项目做”的道理，就不会困惑了。“现状”指目标组织的现状，是具体而且有最佳答案的。

【步骤】改进业务序列图

改进模式1:物流变成信息流

注意观察各种物的流动，并提炼物背后承载的信息。 注意，不要忘了还有人的流动，人可是一个几十公斤的物。
目前各领域在“物流变成信息流”方面留下的改进空间已经不多。随之而来要面对的是信息流转不通畅的问题。

改进模式2：改善信息流转

把各软件系统之间的协调工作改为由一个软件系统来完成，人只需要和单个软件系统打交道，信息的流转就改进了。
人和人的协作中，可能隐藏了信息流转不畅的情况。（能够自动化的不要手动化，能通过程序的不要通过人。）

改进模式3:封装领域逻辑

提炼人脑中封装的领域逻辑，改为封装到软件系统中，用软件系统代替人脑，业务流程就得到了改进。

阿布思考法

假设有充足的资源去解决问题，得到一个完美的方案。（目标要定的高，最理想的情况是什么样）
用手上现有的资源去山寨这个完美方案。

如果有一个方案，花费完美方案 1%的资源，能达到完美方案 20%效果。这个方案已经是目前最好的方案了，因为它是在突破思维限制以后一步步往后退得来的。（是不是最好的存疑，但做事方式要朝着最好的方向努力。）

需求之系统用例图

看看如何从业务序列图映射出系统用例图。
系统用例的定义:系统能够为执行者提供的、涉众可以接受的价值。
和第3章的业务用例相比较，研究对象从组织变成了系统。
要理解好系统用例，重点依然是之前所强调的买卖平衡点、期望和承诺平衡点。

系统执行者要点

系统执行者的定义: 在所研究系统外，与该系统发生功能性交互的其他系统。

系统是能独立对外提供服务的整体

封装了自身的数据和行为，能独立对外提供服务的东西才能称为系统。不了解这一点，建模人员很容易把“添加一些功能”当作“研发新系统”。

系统边界是责任的边界

系统执行者不是所研究系统的一部分，是该系统边界外的另一个系统。这里的系统边界不是物理的边界，而是责任的边界。
涉众根本不在意系统划分成几个组件以及组件之间如何分布和交互。建模人员如果没有学会从涉众视角看问题，只是从自己角度看问题，就会犯这样的错误。
边界越模糊，越需要执行者来帮助理清。

系统执行者和系统有交互

换言之，没有交互就不是系统执行者

系统执行者和重要无关。系统执行者只关注哪个外系统和所研究系统接口。
用例必须在它的路径、步骤和补充约束中考虑这些涉众的利益。

交互是功能性交互

执行者和系统发生的交互是系统的功能需求。

系统执行者可以是人或非人系统

用例技术中“执行者”和“涉众”的概念，把演员和观众分开了。演员(执行者)在台上表演，观众(涉众)在台下看，演员表演什么是由观众的口味决定的，演员可以不是人，但观众肯定是人。
用例使用“执行者”和“涉众”代替了原来的“用户”，这是一个非常大的突破。“用户”这个词混淆了演员和观众的区别。过去经常说“找用户调研需求”，这是错误的。所谓“用户”，就是上台表演的人类演员。找用户调研需求，相当于找演员问剧本应该是什么内容，岂不是很荒谬？剧本应该由编剧向观众调研编写出来，然后由各路演员在台上演绎。
建立“执行者和系统在台上表演，涉众在台下看表演”的概念，在执行者为非人系统时对捕获需求很有帮助。

【步骤】识别系统执行者

从业务序列图映射系统执行者

业务序列图上，和所研究系统有实线相连的对象映射为所研究系统的执行者。

图 5-12 中执行者不再带有斜杠，因为这时候研究对象是系统。有的执行者画在边界框左边，有的则画在右边，是为了方便表达主执行者和辅执行者。

系统用例要点

价值是买卖的平衡点

用例之前的许多需求方法学，把需求定义为思考系统“做什么”，用例把需求提升到思考系统“卖什么”的高度。
这种思考是非常艰难的，因为它没有标准答案，只有最佳答案。
要得到这个最佳答案，不能靠拍脑袋，必须揣摩涉众。要得到合适的用例，需要有一颗善于体察他人的心。

价值不等于“可以这样做”

建模人员只能根据目标涉众心中对系统的期望来确定系统应该提供什么样的服务。
举得权限例子没看懂，按照书中所讲的用例，用例岂不是膨胀很多
最常犯的错误是把步骤当作用例。Include 的目的是为了复用在多个用例中重复出现的步骤集合，形状往往是多个用例 Include 一个用例。看到这种一个用例 Include许多个用例的形状，基本上可以判断它犯了把步骤当作用例的错误。

正确的做法是：把右侧的“验密码”和“扣除金额”作为步骤写在用例规约中。

增删改查用例的根源是从设计映射需求

需求工作中，我们所写的每一个字，所画的每一张图都必须对好卖有推动作用，否则还不如不做。
即使再难，也只能从涉众的视角来定义需求，不能贪图方便选择一个自己熟悉的视角应付了事。
老老实实去研究业务流程，做好业务建模，尽量从业务序列图中映射出系统用例

从设计映射需求错误二:“复用”用例

用例是涉众愿意“购买”的、对系统的一种“用法”，只要涉众愿意“购买”，当然是越多越好。
同样的制作材料，变出更多可卖的价值，说明您的设计能力强，制作成本低，何乐而不为?
可惜建模人员经常会犯傻，不自觉地合并用例，相当于告诉涉众说，你真笨，你买我这些功能，其实都是我用同样几个类作为零件灵活组装出来的。干脆，你成本价把我的零件买走，自己去组装吧!
需求的基本要点：需求不考虑“复用”，如果在考虑“复用”，要警惕自己是不是已经转换到了设计视角来思考问题。

图 5-17、图 5-22 和图 5-24 的错误用例图有一个共同点：多个执行者指向同一个用例。已完工的用例图不应该出现这样的形状，如果出现，可以有两种修改方法。
1. 要是我们揣摩系统的这个用例针对这几个执行者来说并无区别，就泛化出抽象的执行者，或者不需要泛化关系，直接用单个更合适的执行者代替;
2. 反之，如果对不同执行者来说有区别，就把该用例分成几个不同的用例。这种往往更常见。

系统用例不存在层次问题

系统用例的研究对象就是某特定系统，不是组织，也不是系统内的组件。如果存在“层次”上的疑惑，背后的原因是研究对象不知不觉改变了。（仍然有前面的疑惑）
用例很多时可以将用例分包，但用例包是从外部对系统用例所做的分包，里面的用例依然是系统的用例，不是用例包或“模块”的用例。

用例的命名是动宾结构

动词前面可以加状语，宾语前面可以加定语，把一句话的主语砍掉，剩下的可以作为用例的名字。
给用例起名时不要使用弱动词。
如果“名词+动词”已经成为行业中的一个术语，也未必要严格的动宾结构。

【步骤】识别系统用例

认真做好业务建模，从业务序列图上映射系统用例，得到的结果自然就会符合上面说的这些要点。

业务序列图中，从外部指向所研究系统的消息，可以映射为该系统的用例。

有的箭头是从执行者指向用例，这样的执行者称为用例的主执行者，有的箭头是从用例指向执行者，这样的执行者称为用例的辅执行者。主执行者主动发起用例的交互，辅执行者在交互的过程中被动参与进来。
辅执行者这个概念是被误用比较多的。最常见的错误是把信息的接收者或者将来可能使用信息的人当成辅执行者。箭头代表的是责任分配。 图 5-35 的意思是:线索部经理使用线索管理系统分配名单的过程中需要外呼人员的帮忙，如果外呼人员睡着了没有响应，用例的目标就受到影响。显然，这不符合事实。
另一种辅执行者的误用刚好反过来，把信息的来源当作辅执行者。如图 5-36，建模人员认为外呼人员要想使用线索管理系统来查看本人当天名单，“依赖于”线索部经理事先分配好名单。这同样是错误的，在用例进行过程中不需要线索部经理的参与。
一般来说，辅执行者是非人智能系统的情况较多，人脑系统作为辅执行者的情况比较少，所以碰到辅执行者是人的时候，要多留心。
主、辅执行者是针对某个用例来说的，一个外系统可以是这个用例的辅执行者，同时也可以是另外一个用例的主执行者。“××是系统的主(辅)执行者”的说法是错误的。

需求之系统用例规约

用例规约就是以用例为核心来组织需求内容的需求规约。有了用例规约，可以不需要另外写其他格式的需求规约。

前置条件和后置条件

用例通过前置条件(precondition)、后置条件(postcondition)以契约的形式表达需求。用例相当于系统的一个承诺：在满足前置条件时开始，按照里面的路径步骤走，系统就能到达后置条件。

前置条件：用例开始前，系统需要满足的约束。
后置条件：用例成功结束后，系统需要满足的约束。

前置条件、后置条件必须是系统能检测的。

前置条件必须是用例开始前系统能检测到的。

前置后置条件是状态，不是动作。

例如，“经理→批假”的前置条件不能写“员工提交请假单”，因为是一个动作不是状态，应改为 “存在待审批的请假单”。特别要注意的是，写成“员工已经提交请假单”很可能也是不对的，因为状态和导致达到某个状态的行为不是一一对应的，请假单未必是员工自己提交，也可以组长负责帮本组人员请假，也可能是从另外的系统批量导入。

前置后置条件要用核心域词汇描述。

不要写“XX成功”、“XX正常运行”，要体现领域知识，如“订单信息已保存”。

“已登录”不应作为前置条件。

例子讲得好

涉众利益

涉众利益即针对某件事情，某类人担心什么和希望什么。

前置条件是起点，后置条件是终点，中间的路该怎么走?这就要由涉众利益决定了。如果只考虑目标而没有考虑到涉众利益，正确的需求是出不来的。
认识到需求由涉众利益的冲突和平衡来决定，我们的需求过程就会充满“人”的味道，
为了寻找用例的涉众，可以用“醉酒法”思考。假设台上的演员“喝醉”(“喝醉”加了引号是因为在台上的未必是人)了在台上表演，谁看到这个场面会担心自己的直接利益受到侵害?担心的人就是这个用例的涉众。

涉众利益来源

人类执行者：用例的执行者如果是人类，当然是用例的涉众。执行者如果不是人类，就不是涉众，因为它没有利益主张。
上游
下游
信息的主人

业务建模对于识别涉众非常有帮助。如果我们在需求之前做了业务建模，会更了解一件事情的前因后果，大多数涉众都能够从业务序列图中看出来。

寻找涉众利益

要“亲兄弟，明算账”，把不同涉众各自关注的利益体现出来，而不是写成一模一样。
避免正确的废话，要具体。

善于积累涉众利益

很多需求中的两难，都是因为信息不足导致的。
如果我们能善于积累涉众利益，把目标组织内部各种人的小算盘搞得一清二楚，对方稍微说句话，我们就已经知道他心里的小九九，而且还知道他的要求对谁有利，对谁有害，从而可以自如应对。

基本路径

“观众已经一排排坐好，接下来就要让演员们上台演戏了。把演戏的场景描述出来，就得到了用例的路径和步骤。”

一个用例会有多个场景，其中有一个场景描述了最成功的情况，执行者和系统的交互非常顺利，一路绿灯直抵用例的后置条件。这个场景称为基本路径。
用例把基本路径分离出来先写.

书写路径步骤的时候需要注意以下一些要点:

按照交互四步曲书写

在一个回合中，请求是必须的，同时还需要其他三类步骤中的至少一类.
对于时间为主执行者的用例，回合中的请求步骤不写“时间告知时间周期到了”，而是写“当到达时间周期时”。
验证步骤不写“是否”。例如图 6-18 中，第 4 步写“系统验证注册信息充分”，不写“系统验证注册信息是否充分”，目的是要表达“充分”是基本路径期望的验证结果
系统和辅执行者之间的交互可以看作是一种回应步骤，写成“系统请求辅执行者做某事”，例如“系统请求邮件列表系统群发邮件”。

只写系统能感知和承诺的内容

使用主动语句理清责任

把动作的责任人放在主语的位置。
规规矩矩说话，把责任理清楚。

错误示例	评价
会员进入系统	像黑客帝国一样脑门插插头进去？
会员打开系统	用手撕开？
系统自动计算订单价格	系统当然是自动的
会员提交订单信息给系统	“给系统”冗余

主语只能是主执行者或系统

写需求，就是要把系统当作一个黑箱，描述它对外提供的功能以及功能附带的质量需求。
系统如何构造，不属于需求描述的范围，除非是涉众强加的设计约束。
系统边界是责任边界，而非物理边界。

使用核心域术语描述

不要涉及界面细节

不要涉及交互细节

用例的步骤应该把焦点放在系统必须接收什么输入、系统必须输出什么信息以及系统必须做什么处理这三个重点上，加上字段列表、业务规则、可用性需求等约束，足以表达各种需求。

需求是“不这样不行”

需求是“不这样不行”，而不是“这样也行”。
在需求里大量描述设计，相当于医生没有能力去定位患者得的什么病，干脆拍脑袋开药，然后用正楷把药的说明书抄一遍，抄到自己都感动了，以为这样就可以治好患者了。

扩展路径

基本路径上的每个步骤都有可能发生意外，其中某些意外是系统要负责处理的，处理意外的路径就是扩展路径。

和辅执行者交互的步骤很有可能会出现扩展。在系统请求辅执行者做某事时，如果辅执行者出现故障，系统无法得到想要的结果，很有可能会导致系统行为的变化。
主要由 ”验证“和“辅助系统”产生，如果不是这两种，要特别小心是不是需求

能感知和要处理的意外才是扩展。

设计技能不足导致的错误不是扩展。

不引起交互行为变化的选择不是扩展。

界面跳转不是扩展。

在书写用例规约时，应该把具体的界面看作不存在，把其他用例也看作不存在，专注于典型执行者为了达到本用例目标必须要和系统发生的交互以及不可避免要处理的意外和分支。

补充约束

字段列表

字段列表不同于数据模型。
字段列表不等于数据字典

业务规则

只要涉众能理解，行业上适用的任何方式(例如数学、物理公式)都可以用来表达业务规则。

质量需求

可用性

可用性需求是对人类执行者和系统之间交互质量的度量。

性能

可靠性

可支持性

设计约束

设计约束是在实现系统时必须要遵守的一些约束，包括界面样式、报表格式、平台、语言等。
设计约束既不是功能需求，也不是质量需求。
设计约束是需求的一种，也一样要从涉众的视角来描述。

需求启发

需求模型的质量依赖于需求的素材。从涉众处获取需求素材的工作叫做需求启发。

需求启发要点

需求的一个启发障碍是知识的诅咒(Curse of Knowledge)，意思是：一旦知道某个东西，就很难想像不知道它会是什么样子。
需求启发的另一个障碍是做和定义的不同。涉众会做一件事情，不代表他能够把这件事定义出来教给其他人。

和涉众交流的形式应该采用视图，而不是模型。

和涉众交流的内容应该聚焦涉众利益，而不是需求。

涉众没有资格提供需求。
系统的需求是平衡各种涉众利益得到的，不由单一涉众决定
涉众没有责任提供需求。

需求启发手段

研究资料

研究资料往往是需求启发的第一步，目的是为了获取核心域的初步知识，为下一步的启发工作做知识准备。

问卷调查

访谈

涉众

选择的涉众代表必须名副其实，不要把“代表”等同于“主管”。例如，要访谈车间的操作工，那就要选真正的操作工，不能用车间主任来做代表。

需求人员

需求人员的态度要让涉众觉得自己被尊重。

问题

问题的内容聚焦于业务流程和涉众利益，而非直接的系统需求。
问题的形式和新闻记者提问一样:5W+1H。谁(Who)、什么(What)、什么时候(When)、什么地点(Where)、为什么(Why)、怎么进行(How)。
提问的时候尽量采用领域词汇，不要采用涉及软件实现的专业术语。
问问题的时候，可以跟随涉众的阐述，不断问为什么，深入探索背后的真正需求。

环境

尽可能在涉众的工作环境里访谈。涉众在自己的工作环境中会想起许多工作中的喜怒哀乐.
有人嫌在涉众的工作环境里访谈经常会被打断，但那也是一种真实的工作状态。

观察

观察就是需求人员跟在涉众旁边观察他的工作，甚至亲身去体验涉众的工作。这是最直接的需求启发技术，也最费时间。

研究竞争对手

需求人员的素质培养

一名优秀需求人员所需要的素质归纳成一所房屋的样子。房屋以好奇心为根基，有探索力、沟通力、表达力三根柱子，以热情作为屋顶。