《软件方法-业务建模和需求》

第一章

利润=需求-设计

在软件开发中，需求工作致力于解决“产品好卖”的问题，设计工作致力于解决“降低成本”的问题，二者不能相互取代。

实际上，客户的需求从来没有变过，知识我们一开始就没有揣摩出来！

随着一段时间的联系，团队的情况有所好转，软件版本的发布周期有了改善，被良好封装的代码形成了系统的稳定中间态，系统也更加强壮。虽然还有部分人没能很好掌握，我想着其中最主要的原因还是在于技术思维的转变。

自己团队的难处与众不同，奇特的困难降临在他们身上，偏偏别人得以幸免。很多团队都高估了自己团队的“个性”，而低估了“个性”！

另外要说的是，要用发展的眼光看问题，不能搞“原教旨主义”。某种思想或方法起源于某人，不意味着某人最初对该思想或方法的认识永远是最正确的。

廉价的“大牛”、“大仙”，“大神”式的称呼。

从需求直接映射设计，会导致功能分解，得到重复代码。如果从设计出发来定义需求，会到一大堆假的需求。

业务建模：描述组织内部各系统（人肉系统、机械系统、电脑系统……）如何协作，使得组织可以为其他组织提供有价值的服务。
需求：聚焦待开发系统的边界，详细描述系统要卖得出去必须具有的表现-功能和性能。
分析：提炼系统内需要封装的核心领域机制。
设计：将核心域知识和非核心域知识结合，最终实现系统。说”代码就是设计“指的是这里说的”设计“。代码确实是设计，但代码不是分析，不是需求，不是业务建模。
不同工作流产生的工件之间的区别不在于形式，而在于内容，也就是思考的边界。

不能把”迭代“作为偷懒的庇护所。

刚入行的开放人员体会到建模的重要性，是正常的。就像下象棋，初学者面对单车对马双士、单马对单车等已经有共识的局面还需要思考良久，最终还拿不下来甚至输掉比赛。这时中局和布局的书在他看来多半是枯燥无味的，还不如把一本实用残局汇编看熟了，学到一些奇技淫巧，也能在菜市场赢几盘棋。不过，要迈向职业棋手的境界，参加更残酷的竞争，就体会到中和布局的重要了。

UML模型不是用来和涉众沟通的。和涉众进行交流的是模型的各种视图。

软件的需求规约相当于电影剧本。电影剧本并不是由观众直接提供的，而是有编剧根据不同观众的口味编出来的。同样，软件需求不是由涉众直接提供的，而是有需求工程师综合不同涉众的利益编造出来的。涉众没有资格、也没有责任提供需求。

团队实施过程改进容易流于形式，根源往往在于技能的不足。

多半会发现其实他所说”敏捷过程“就是没有过程。

第二章

如果开发人员的思维停留在”可以工作的软件“而不是追求”可以卖的软件“，他甚至会纳闷为什么要写这个东西。

这里说的”买“是广义的”买“，不仅是付出金钱，也可以是付出声誉、官职、时间等。我没有付钱给Google，但确实是在花我最宝贵的”时间“来使用它的服务。

愿景实际上就是系统最重要涉众的利益。

越是用户，往往在涉众排位越靠后。整天操作电脑搞得手僵脖子硬的”用户“，有几个是职位高的呢？真正威高权重的涉众，虽然偶尔也会上台表演当Actor，但更多时候是坐在台下看戏。开发人员过多关注”用户“，话在重要的前排涉众身上的时间往往就不够了。

涉众利益是团队可以积累的财富

第三章

业务建模的目的是从组织的角度来定位系统应该提供的价值，所以说”业务建模“这个名字其实起得不好，应该更名为”组织建模“。处于对过去叫法的尊重，本书依然称为”业务建模“。

很多时候我们把自己在开发的系统看的太重了，感觉没有我们开发的系统，组织就玩不转了。其实，我们那牛哄哄的系统也只是组织的一个零件，和组织厕所里的马桶没有本质区别。组织里面还有很多系统，其中最值钱的事千百年来一直在使用，现在依然是最复杂的系统-人肉系统，它是由”父母公司“开发，”老师公司“不断升级，组织以每月每人几千上万的租金租用。

首先来寻找组织的执行者，也就是业务执行者（Business Actor）。业务执行者的定义是：在组织之外和组织交互的人群或组织。

业务执行者和业务工人的区别是，一个在组织外面，一个在组织里面，一个是组织不可替换的，一个是组织可以替换的零件。业务实体就是组织中的非人系统，例如银行的取款机、点钞机、营业系统。 

业务用例代表组织的本质价值，很难变化，改变的事业务用例的实现。

业务用例应该是患者对医院的期望和医院对患者的承诺的平衡点。

第四章

业务用例的实现：业务流程。

描述业务流程的手段：文本（不够生动）、活动图、序列图（1、活动图只关注人，序列图把人当系统。2、活动图表示动作，序列图强迫思考动作背后的目的。3、活动图更”灵活“，序列图更不”灵活“）

业务建模研究的焦点是组织，所以业务序列图上对象的最小单位是人肉或非人系统。

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

有一种误解是：认为人做的事情就是本质，电脑做的不是。

业务流程改进的视角

一：物流变成信息流。二：改善信息流转。三：封装领域逻辑。

目前面向大众的互联网（及移动互联网）系统如QQ、Facebook、Twitter，完成的大多是改进一、改进二，系统内部封装的逻辑不复杂。这样的场面很常见：稍有新意的互联网系统刚面世，很快就出现几十，几百个功能几乎一模一样的模仿者，这些模仿者中有的甚至是几个大学生凑一凑就开发出来的。谁成谁败，决胜点根本不是系统本身的功能，而是谁能早点多点拿到投资来购买内容和大作宣传，风险投资人也声称“投资是投的人不是投的产品本身”。

第五章

于业务建模时研究的执行者和用例相比，不同之处是研究对象，之前是研究组织，现在研究系统。

系统执行者要点：

1系统外 2交互 3功能性交互 4系统

系统用例的定义：系统能够为执行者提供的、涉众可以接受的价值。仍然需要平衡系统的承诺也执行者的诉求达到一个平衡点。

用例之前的许多需求方法学，把需求定义为思考系统“做”什么，用例把需求提升到思考系统“卖什么”的高度。这种思考是非常艰难的，因为它没有标准答案，只有最佳答案。

对于这种用于支撑的管理基本数据的用例，才用“管理XX”来打扫战场。

第六章

用例图只是表达了用例的目标，这时远远不够的。用例背后封装了不同级别的相关需求，我们需要通过书写用例规约把这些需求表达出来。用例规约就是以用例方式组织的需求规约。

用例相当于系统的一个承诺：在满足前置条件时开始，按照里面的路径步骤走，系统就能到达后置条件。

前置条件和后置条件

一、前置条件和后置条件必须是系统能够检测的

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

三、前置后置条件是约束，不是动作。

四、前置后置条件要有系统的味道。

五、关于登陆

把“登陆”用例变成被其他用用例包含的被包含用例。这样做是可以的。“”

第七章

从涉纵处获取需求素材的工作叫做需求启发。

需求不是蘑菇。开发人员要能够像猎人一样，用锐利的眼睛发现隐藏在丛林中的猎物；想侦探一样，用缜密的思维判断出伪装成好人的凶手。

curse of knowledge

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

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

软件行业不再像过去的年代一样是香饽饽，优秀人才越来越往“甲方”聚集。

应对手段是埋藏一些不可能错误的“钉子”，如果被调查者敷衍回答，很可能就会答错，从而可以判断这份答卷是无效的。

访谈：

涉众：要找名副其实的涉众   需求工程师

好奇心：

探索力：《六顶思考冒》、《严肃的创造力》

沟通力：《人性的弱点》

表达力：《金字塔原理》