软件方法

核心工作流

1. 业务建模（组织建模）：描述组织内部各个系统如何协作，使得组织可以为其他的组织提供有价值的服务，新系统只不过是组织为了对外提供更好的服务，对自己的内部重新设计而购买的一个零件。
2. 需求：聚焦于待开发系统的边界，消息描述系统要卖的出去必须具有的表现-功能和性能。
3. 分析：提炼系统内需要封装到核心领域机制。
4. 设计：将核心领域知识和非核心领域知识结合，最终实现系统。

寻找老大

1. 老大是买方。
2. 系统改善哪个组织的流程，老大就是该组织的负责人。
3. 系统好坏的度量指标在他的大脑里吗。
4. 如果国王之给你几分钟时间把正在做的系统卖出去，而且只有一次推销的机会，如果失败了就会被枪毙。您会向谁推销？推销的时候说什么话保住自己的性命可能性做大？这个答案就是老大和愿景。
5. 愿景是改善组织的指标，而不是做某事，要达到这个目标，需要各个岗位分别使用XXX，XXXX等功能。
6. 愿景不是问系统有什么功能，而是回答买了这个系统，对组织有什么好处。
7. 愿景是老大针对系统的目标
8. 用例使用“执行者Actor”和涉众代替了原来的用户，这是一个非常大的突破；
9. 计算机系统不只是简单的把纸里的东西往电脑里般；

业务建模之业务用例图

1. 业务建模的目的是从组织的角度来定位系统应该提供的价值，所以说“业务建模”应该更名为“组织建模”。
2. 业务执行者：BusinessActor。首先来寻找组织的执行者，也就是业务执行者，业务执行者的定义是：在组织之外和组织交互的人群或组织。（组织：某商业银行； 业务执行者：储户（存钱）、企业（贷款）、人民银行（监督））
3. 业务工人（Business Worker）：组织内的人肉系统，业务执行者和业务工人的区别就是，一个在组织内部，一个在组织里面，一个是组织不可替换的，一个是组织可以替换的。
4. 业务工人可能被新的业务工人替换，但更多的是可能被新的业务实体（BusinessEntity）替换，业务实体就是组织中的非人系统。
5. 开发人员说，“我在开发一个新系统”，其实是说“我在开发一个新的业务实体”，取代现有的业务工人或业务实体的一些责任。

探索需求的思路就出来了：

• 画好现状的业务序列图
• 把待开发的系统作为一个新的业务实体空降到列图中
• 寻找改进点，取得该业务实体的责任
• 直接映射到待开发系统的系统用例

业务工人和业务实体不再业务用例图中出现，因为他们不是组织的价值，而是成本。在识别业务执行者时，不需要画业务工人和业务实体，在接下来画业务用例的实现-业务序列图的时候加上就可以。

1. 业务工人和业务实体协作完成业务用例，系统类协作完成系统用例。
2. 业务执行者是一个组织（或人群），而不是系统。因为研究对象是组织，和它对应的概念也应该是组织。
3. 业务用例指业务执行者希望通过和组织交互达到，而且组织能提供的价值。
4. 业务用例是为业务执行者服务，不是为业务工人服务。或者说，因为无用例表达组织的本质价值。
5. 改进业务流程的思路：先归纳出组织对外提供什么价值，再思考如何更好地优化组织内部流程来实现这些价值。

总结

1. 业务用例是组织的、而不是组织内某个系统的用例。
2. 组织的用例不会因为某个人肉系统或者电脑系统的存在或消失而改变。所以，“这个系统的业务用例是什么”这样的说法是错误的，业务用例图，研究对象都是组织。
3. 为什么要研究组织的用例呢？因为我们想要把系统的价值和组织的价值挂上钩，给组织一个购买系统的理由。也就是说，业务用例不是思考系统提供什么“功能”，而是思考组织购买了这个系统，对组织本来就是有哪些“功能”会带来一点点帮助。

需求之系统用例图

1. 系统执行者的定义：在所研究系统外，与该系统发生功能性交互的其他系统。
2. 系统用例的定义：系统能够为执行者提供的、涉众可以接受的价值。
3. 用例之前的许多需求方法学，把需求定义为思考系统“做”什么，用例把需求提升到思考系统“卖什么”的高度。
4. 做需求的目的不是为了安慰自己或走过场，而是让产品更加好卖。不以这个为出发点的需求工作是没有意义的。
5. 老老实实去研究业务流程，做好业务建模，尽量从业务序列图中映射出系统用例，这样得到的系统用例是不会骗人的。新增、修改、删除、查询、管理、改变状态这样的词语是数据库里面的“鸟语”，不是领域里面的“人话”。业务流程中不会有人说，小张你等一下，我要到系统哪里去做一下发票管理，只会说，我去开一张发票，我去作废一张发票，我去开一张红字发票。。。