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

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

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

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

• 利润=需求-设计：

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

• 基本共识上的沟通：

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

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

• 愿景：

缺少清晰、共享的愿景每每是项目失败的主要缘由。（咱们公司当前也缺少愿景）

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

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

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

• 阿布思考法：

1. 假设有足够的资源去解决问题，获得一个完美的方案。
2. 用手上现有的资源去山寨这个完美方案。

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

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

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

你们能够尝试用“不这样行吗”这个标准去过滤咱们的“需求”。