1.什么是用例
*用例是一系列完成一个特定目标的“功能”的组合。把用例解释为某个参与者要做的一件事可能更为合适。
*用例特征：一、用例是相对独立的，这意味着它不需要与其他用例交互而独自完成参与者的目的；二、用例的执行结果对参与者来说是可观测和有意义的；三、用例必须由一个参与者发起，不存在没有参与者的用例；四、用例必然是以动宾短语形式出现的。例如“喝水”是一个用例，“计算”、“统计”不是。
*用例的核心：以参与者为中心而不是以计算机为中心，从参与者角度描述他要做的日常工作。
*用例的首要目标：要弄清楚有多少参与者？每个参与者做什么？业务流程分析则是后续工作。
2.用例的类型与粒度
*用例类型：Rose默认的有business usecase, business usecase realization和usecase realization三种，不指定就是普通的usecase，需求分析中的各个阶段要描述和分析的目标不同，需要使用不同的用例类型。
*需求分析阶段：1.业务建模阶段，目标是通过用例模型的建立来描述用户需求，需求规格说明书通常在这个阶段产生，这个阶段通常使用业务用例和业务用例实现两种类型；用例分析阶段，是系统分析员采用OO方法来分析业务用例的过程，这个阶段又称概念模型阶段。这个阶段通常使用无类型的用例，业务架构通常在这个阶段产生；3.系统建模阶段，是将用户的业务需求转化为计算机实现的过程，这个阶段通常使用无类型的用例和用例实现，系统范围、项目计划、系统架构在这个阶段产生。
*business usecase是用来描述用户的原始需求的，描述必须采用纯业务语言，而不能出现计算机术语。
*business usecase realization是达到需求可追溯要求的一个连接点，是用户在其业务场景中如何做这件事的载体。
*用例分析阶段的用例主要是从业务模拟的概念上，从OO的视角来分解、组合业务用例，粗略建立一个业务架构。
*系统建模阶段的用例主要是从计算机视角描述需求，规定开发范围，作为项目计划的依据，为系统设计做准备。
*用例的粒度：业务建模阶段，粒度以每个用例能够说明一件完整的事情（完整的业务流程）为宜，这有助于明确需求范围。如：取钱，借书；用例分析阶段，粒度以能描述一个完整的事件流（完整业务中的一个步骤）为宜。这个阶段需要采用OO方法，归纳、抽象业务用例中的概念模型；系统建模阶段，粒度以能描述操作者与计算机的一次完整交互为宜
3.涉众分析
*业务模型需要完成的工作：发现和定义涉众；划定业务边界；获取用例；绘制用例场景图；绘制业务实体模型（领域模型）；编制词汇表。
*涉众：涉众是与要建设的业务系统相关的一切人和事。
*用户：指预期的系统使用者。涉众包含了用户。在建模过程中，概念模型的建立和系统模型的建立都只从用户开始分析，其他涉众体现在文档中即可。
4.业务建模的一般步骤和方法
*商业系统无论多复杂，其本质无非是人，事，物，规则。人是一切的中心，人做事，做事产生物，规则限制人事物。人驱动系统，事体现过程，物记录结果，规则则是控制。弄明白了这些之间的关系，商业建模也就基本完成了。
*建模第一步：从涉众中找出用户，并定义这些用户之间的关系。在Rose中应该使用business actor类型
*建模第二步：找出每个用户要做的事，即业务用例，在Rose中应使用business usecase 类型。建议为每个business actor绘制一个业务用例图，这能很好的体现以人为中心的分析模式。
*建模第三步：利用业务场景图帮助分析业务流程，在Rose中最好使用活动图。在绘制过程中使用第一步中定义的用户名作为泳道名，使用第二步中定义的业务用例名作为活动名来绘制，这样可以检查前两步是否正确。
*建模第四步：绘制用例场景图。用例场景图只针对一个用例绘制该用例的执行过程，还是使用活动图绘制。
*建模第五步：从第三步或第四部绘制的活动图中找到每一步活动将使用到的或产生的结果。这是找到物的过程，找到后应当建立这些物之间的关系。在Rose中这称为业务实体模型。
*建模第六步：在上述过程中，随时补充词汇表Glossary。
*建模第七步：根据涉众期望审视建立好的模型，确定业务范围，决定哪些业务用例在系统建设范围内。有两种情况的用例不在建设范围：一是该业务用例是被调用的一方，那么应该把它改为boundary类型，意味着将来他是一个外部接口；二是该业务用例主动调用系统内业务用例，那么应该将它改为business actor类型，它不是人，而通常是一个外部系统进程。
*上述步骤并非一次性完成的，每个步骤都可能导致对上个步骤的调增，即使建模已经完成，当遇到变化或发现新问题时，上述步骤应当从头到尾再执行一次。
6.用例实现、用例场景和领域模型
*通过上述七步，可以得到用户、业务用例和业务场景模型，这三项成果形成了基本的需求框架，圈定了业务范围，但其所包括的内容还是比较粗的，接下来要对业务用例进行场景分析。
*用例场景分析要用到三种视图，业务用例实现视图、业务用例场景、业务实体模型，每个业务用例还应当写一份用例文档，也称用例规约。若有非功能性需求，例如性能要求，吞吐量等，还应当写一份补充用例规约。
*针对每个业务用例实现，应当对用例的实现过程进行场景模拟，这个模拟应当将计算机包括进来，从人机交互的视角来模拟业务场景，这是概念模型的一种，这个图应该用活动图。
*用例场景可以帮助系统分析员发现和定义业务实体。
*分析用例场景中出现的名词，我们会得到一个个业务实体。在需求阶段，系统分析员不要去考虑什么抽象，什么模式，那是系统建模的事情。
7.用例规约的编写——业务规则和实体描述
*业务规则类型：一是全局规则。这种规则一般与所有用例都相关，而不是与特定用例相关。这类规则建议写到补充规约中。这类规则是系统具备的特性，所以应该由系统实现；二是交互规则。这种规则产生于用例场景中。这类规则一般写到用例规约中；三是内禀规则。是指业务实体本身具备的规则，并且不因为外部的交互而变化的规则。这类规则一般写到领域模型文档中。这类规则应该根据面向对象的封装原则，在实体类中实现。
*全局规则很难从用户处调研得来，通常要由有经验的系统分析员、架构师等从业务特点、应用环境等总结而来；交互规则从用例场景而来，场景中的每一个交互可能都隐含者规则，交互规则最主要的来源是业务提出者和业务管理者，而不是业务执行者；内禀规则要对每个业务实体的属性罗列，并找出它们的规则。最主要的来源是业务执行者。
*业务实体的属性：这个阶段的属性应该用业务术语而不是计算机术语描述。调研范围是之前获得的领域模型中的每一个实体。属性来源是客户的各类实际表单，以及客户的各种要求。
*业务实体中的属性是业务角度的描述。系统分析不是做设计，不要有任何关于设计或实现方法的想法。