前置问题： 利润 = 需求 - 设计。
需求：从卖的视角、具体的实际问题来考虑，将产品当做项目来做一步一步来走。
设计：从做的角度、抽象的问题模型来考虑，将项目当做产品来做尽力做出彩。
综述：设计源于需求而又高于需求。
需求规约（如何考虑）：
组织要解决什么问题 => 业务建模
为了解决组织的问题，待开发的系统应该提供什么功能和性能 => 需求 以上2部分考虑如何提升销售的问题
为了提供功能，系统内部应该有什么核心机制 => 分析
为了提供性能，系统的核心机制如何用选定的技术实现 => 设计 以上2部门考虑如何降低成本的问题
组织 <==> 组织 组织及组织之间是业务建模考虑点
系统 <==> 系统 系统外部和系统之间是需求考虑点
=> 系统的核心域 <= 系统内部的核心域是分析考虑点
<= 系统内部&核心域外部 => 系统核心域基础上的表示、存储、协议、消息等是设计考虑点
0-愿景：确定一个从系统角度出发的非功能描述的范围合理的具体的目标。
关键点：系统角度、非功能性描述、范围切记太大、一定要具体的目标不要说宽泛的废话。
愿景格式如下：
系统：xxxx系统（从系统角度出发，别放大到整个组织）
老大：xx部门总监（老大指会花钱买这个系统的人，或对购买起着关键作用的决定人）
目标（度量指标）：（勿拿组织目标当系统目标太宽泛）
提高xxx人员的工作效率
减少xxx人员的错误率
提高xxx工作的准确性
1-组织建模(业务建模): 记住你开发的系统只是要替换掉组织中的人工成本，所以建模的对象是组织而不是系统。
关键步骤：
1.确定建模组织：（组织的选取需要站在主要利益方和渉利群众的角度考虑，勿草率选取公司这种大范围的组织。对于互联网项目，应该选取项目的目标人群做组织。）画一个圈，把大多数责任可能被（部分/全部）替换的系统（人肉系统/电脑系统...）包在里边。
2.画出组织（业务）用例图和序列图：（从外部看，可以用业务用例图表示组织。从内部看，可以用业务序列图表示组织。）
研究组织的目的：把系统的价值和组织的价值挂上钩，给组织一个购买系统的理由。
1). 业务用例图：
a.确定业务执行者：寻找组织的执行者（业务执行者），在组织之外和组织交互的人。（业务执行者是一个组织或人群，而非系统。）
思考方式：摄像机对准组织边界，谁找组织办事、谁发邮件给组织...等等，谁就有可能是业务执行者。
b.确定业务工人和业务实体：业务工人是位于组织内部（业务执行者在组织外部）的人肉系统，即组织内的工人，而业务实体就是组织内部的非人工的系统。
业务工人和业务实体是组织的成本而非价值，所以其不在业务用例图中出现，而是放在“业务对象”的包里。识别业务执行者时不需要画业务工人和业务实体，在画业务序列图时候加上即可。
c.业务用例和业务流程：把业务流程看作是业务用例的实现，将其组织在业务用例下面。组织里发生的一切都为了给业务执行者提供价值。
识别业务用例：第一条路线，也是主要路线，方法是从业务执行者开始，思考业务执行和组织打交道的目的。思考的焦点是“执行者对组织的期望和组织对执行者的承诺”的平衡点。第二条路是通过观察组织的内部活动，一直问为什么，向外推到组织外部的某个业务执行者。
主要执行者和次要执行者：执行者指向用例，这种执行者为主要执行者；用例指向执行者则为次要执行者。如：“出版社→推广书籍→外部译者”可以这样解读：为了给出版社提供推广书籍的服务，组织靠自己的力量不足以完成，需要找外部译者帮忙。
注意：业务用例是组织为组织服务，在不同的场景中，两个组织的系统形成不同的交互。业务用例是组织的，而不是组织内某个系统的用例。
2). 业务序列图：业务流程有三种描述方式：文本方式、业务活动图方式、业务序列图方式。文本方式生动感欠佳不推荐，业务活动图是主流方式，但推荐的是业务序列图。UML的交互概述图是采用活动图的形式将各个场景的序列图串起来，相当于结合了活动图和序列图的特点。