笔记-软件方法-上册-业务建模和需求

这本书其实买了有两年了，还去参加了潘老师的公开课，限于能力，当时上课时领悟有限，最近因为Scanning打印系统做代码重构，要做代码框架设计，想借助于UML，以严谨一些，就翻出了这本书，重新看了一遍。

这本书其实并没涉及到具体软件架构设计要用的UML操作，诚如书名，侧重于需求分析。

以下是一些笔记，比较杂乱:

利润=需求-设计：

这里的意思是，现在已经过了粗放经营的阶段了，企业需要搞清需求（产品好卖）和做好良好设计（降低成本），才能在激烈竞争中赢得优势。对于软件，我们更要注重代码重用带来的效率提高。

基本共识上的沟通：

针对不少开发人员并不喜欢用UML，而是自造草图的情况，书里一针见血地指出是想通过”形式上的丑陋来遮掩内容上的丑陋”。大家对一些基本技能形成共识，可以“大大减少思考中的浪费”。

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

愿景：

缺乏清晰、共享的愿景往往是项目失败的主要原因。（我们公司当前也缺乏愿景）

要避免无用的废话，例如PS可乐的目标客户是“卖给想喝可乐的人”。

系统的愿景应该是“买了这个系统，对组织有什么好处”。

由于编程语言的表达能力越来越强，针对某一段代码画流程图，变得没有必要。业务流程的描述，建议使用序列图。

阿布思考法：

1) 假设有足够的资源去解决问题，得到一个完美的方案。

2) 用手上现有的资源去山寨这个完美方案。

许多伟大的创新，其实就是用廉价的替代方案来山寨过去富豪和高官的生活。

软件工程更接近于经济学，而非计算机科学。

需求是不考虑“复用”的，用同样的材料，变出更多可卖的功能，这是设计能力的体现。

大家可以尝试用“不这样行吗”这个标准去过滤我们的“需求”。