《软件方法》讲的是用UML语言来辅助我们进行软件的从0到1的过程。这个过程的结果并不是最终运行在电脑屏幕上的那个界面，而是一堆图纸，可视化的图纸。
是的，确实是图纸。建筑行业有设计和施工图纸，电工行业有设计和实施图纸，城市规划有图纸··· ···任何你看得到的工程都有图纸，你要写的软件居然没有。
“图纸在我脑子里呢”，我也曾经说过。直到看到这本书。
这本书的直接受众应该有两类人：
1.程序员
这类人一般的工作思路就是提功能的人说要做什么，嗯嗯哦哦之后，迫不及待的打开编辑器开始写代码，调试，然后发现做完的东西，总是被告知要修改，没玩没了的改。
2.项目管理者
这类我们称之为“IT包工头”，他们既要跟客户聊需求，转头还要跟程序员转述。作为一个中间人，两边都要沟通，现实是两边都没沟通好。用户说的不就是这样的么？怎么做出来的东西就是不对呢！面对需求和变更，他们是最无奈的，因为他们面对的并不只是程序，而是公司的成本和效益。
我甚至推荐产品经理也来看看这本书，因为一个产品到底要满足谁的需求，提供什么样的功能是一开始就要想清楚的事情。精益思想的逐步迭代改进是没错，但是也要求你在产品之初，能想明白你产品到底能带来什么样实实在在的客户价值。
很庆幸能在工作的第8个年能看到这本书，更荣幸的是，和自己的团队在一起用了7个课时一起讨论学习，一起做作业。最让人兴奋的，是每一次在进行项目讨论的时候，我们都开始用《软件方法》中学到的知识，用新的方法在做我们每天都该去的的事情：内部沟通更加有条理了；需求变更更加谨慎了，和客户的沟通更加有效率了··· ···
读完潘老师的这本大作，我的总体印象是：
概念不清，用词不当，东拉西扯，逻辑错乱。
全书中那些令人啼笑皆非的荒唐错误结论和缺陷主要有：
- 设计约束是需求，但既不是功能需求，也不是非功能需求（潘老师不懂最简单的二元逻辑？）；
- 全书对于“涉众”（Stakeholder）这个基本术语的理解几乎通篇是错误的，而且前后矛盾；
- UML 模型不是用来和涉众沟通的！（很难相信这是一位 UML 首席专家的言论）；
- 涉众没有资格、也没有责任提供需求；
- 把 Actor 译成“执行者”，导致许多违反中文常识的语病，如：人民银行是商业银行的执行者，患者是医院的执行者；
- 系统 Actor 和重要无关，和重要有关的概念是涉众；
- 观众（涉众）在台下看，Actor 在台上表演（其实呢，台上的演员也是涉众）；
- 需求或用例的“粒度”、“层次”这些概念其实并不存在，对开发人员的误导相当严重；
- 设计就是代码，所以设计工作流不推荐画 UML 图；
- 界面组件不是需求。人有眼睛不是需求；
- 只用两三章介绍了 UML 的用例图和业务序列图，未强调业务活动图，也未详细介绍 UML 需求分析中常用到的其他图形，如系统序列图、活动图、状态图等（内容单薄、片面）；
- 第 2 章所谓的“愿景”，只是区区几个“老大”或涉众的目标，名曰“度量指标”，却连一个数量也没有说明，实质内容与愿景文档差距甚远；
- 作为需求分析的名著，从第 3 章到第 6 章的重点章节只介绍了以用例为主的动态建模，未详细介绍需求分析的另一半——静态建模（如领域建模、概念建模）；
1-组织建模(业务建模): 记住你开发的系统只是要替换掉组织中的人工成本，所以建模的对象是组织而不是系统。
关键步骤：
1.确定建模组织：（组织的选取需要站在主要利益方和渉利群众的角度考虑，勿草率选取公司这种大范围的组织。对于互联网项目，应该选取项目的目标人群做组织。）画一个圈，把大多数责任可能被（部分/全部）替换的系统（人肉系统/电脑系统...）包在里边。
2.画出组织（业务）用例图和序列图：（从外部看，可以用业务用例图表示组织。从内部看，可以用业务序列图表示组织。）
研究组织的目的：把系统的价值和组织的价值挂上钩，给组织一个购买系统的理由。
1). 业务用例图：
a.确定业务执行者：寻找组织的执行者（业务执行者），在组织之外和组织交互的人。（业务执行者是一个组织或人群，而非系统。）
思考方式：摄像机对准组织边界，谁找组织办事、谁发邮件给组织...等等，谁就有可能是业务执行者。
b.确定业务工人和业务实体：业务工人是位于组织内部（业务执行者在组织外部）的人肉系统，即组织内的工人，而业务实体就是组织内部的非人工的系统。
业务工人和业务实体是组织的成本而非价值，所以其不在业务用例图中出现，而是放在“业务对象”的包里。识别业务执行者时不需要画业务工人和业务实体，在画业务序列图时候加上即可。
c.业务用例和业务流程：把业务流程看作是业务用例的实现，将其组织在业务用例下面。组织里发生的一切都为了给业务执行者提供价值。
识别业务用例：第一条路线，也是主要路线，方法是从业务执行者开始，思考业务执行和组织打交道的目的。思考的焦点是“执行者对组织的期望和组织对执行者的承诺”的平衡点。第二条路是通过观察组织的内部活动，一直问为什么，向外推到组织外部的某个业务执行者。
主要执行者和次要执行者：执行者指向用例，这种执行者为主要执行者；用例指向执行者则为次要执行者。如：“出版社→推广书籍→外部译者”可以这样解读：为了给出版社提供推广书籍的服务，组织靠自己的力量不足以完成，需要找外部译者帮忙。
注意：业务用例是组织为组织服务，在不同的场景中，两个组织的系统形成不同的交互。业务用例是组织的，而不是组织内某个系统的用例。
2). 业务序列图：业务流程有三种描述方式：文本方式、业务活动图方式、业务序列图方式。文本方式生动感欠佳不推荐，业务活动图是主流方式，但推荐的是业务序列图。UML的交互概述图是采用活动图的形式将各个场景的序列图串起来，相当于结合了活动图和序列图的特点。