这本书其实买了有两年了，还去参加了潘老师的公开课，限于能力，当时上课时领悟有限，最近因为Scanning打印系统做代码重构，要做代码框架设计，想借助于UML，以严谨一些，就翻出了这本书，重新看了一遍。
这本书其实并没涉及到具体软件架构设计要用的UML操作，诚如书名，侧重于需求分析。
以下是一些笔记，比较杂乱:
- 利润=需求-设计：
这里的意思是，现在已经过了粗放经营的阶段了，企业需要搞清需求（产品好卖）和做好良好设计（降低成本），才能在激烈竞争中赢得优势。对于软件，我们更要注重代码重用带来的效率提高。
- 基本共识上的沟通：
针对不少开发人员并不喜欢用UML，而是自造草图的情况，书里一针见血地指出是想通过”形式上的丑陋来遮掩内容上的丑陋”。大家对一些基本技能形成共识，可以“大大减少思考中的浪费”。
和涉众的交流内容应该聚焦涉众利益，而不是需求。
- 愿景：
缺乏清晰、共享的愿景往往是项目失败的主要原因。（我们公司当前也缺乏愿景）
要避免无用的废话，例如PS可乐的目标客户是“卖给想喝可乐的人”。
系统的愿景应该是“买了这个系统，对组织有什么好处”。
由于编程语言的表达能力越来越强，针对某一段代码画流程图，变得没有必要。业务流程的描述，建议使用序列图。
- 阿布思考法：
- 假设有足够的资源去解决问题，得到一个完美的方案。
- 用手上现有的资源去山寨这个完美方案。
许多伟大的创新，其实就是用廉价的替代方案来山寨过去富豪和高官的生活。
软件工程更接近于经济学，而非计算机科学。
需求是不考虑“复用”的，用同样的材料，变出更多可卖的功能，这是设计能力的体现。
大家可以尝试用“不这样行吗”这个标准去过滤我们的“需求”。