通过与用户的访谈，确认待开发系统“要做什么”，从企业角度研究

项目的范围：找出目前已存在的系统，~是否提供了相关的集成接口。

必要的业务流程：初期应该捕捉“必要的”业务流程，避免对细节的研究。

项目成功关键因素：了解利益相关方对整体项目成功与否最关切的问题是什么，并且评估问题和项目成败的风险是否相关。

上述四个重点，一开始就决定了项目是否会成功，如果项目开始就落入细节性的讨论，反而容易造成项目的失败。

与客户（领域专家）沟通，进行需求的收集和分析，标准文书表达，形成需求规格说明书，交由设计人员进行后续的系统设计工作。

UML的用户例图是用于需要收集和表达的有力工具，但非易事，可能是零散的、没有系统性的。

因此在分析用户例前，可先对企业级的业务流程进行规划和设计，抓住企业的本质工作流，为后续进行详细的需求收集和用例分析做好准备。

可以通过“企业级的用例”来完善工作流程规划与设计，不过，大部分领域专家对“用例”的接受度较差，因此可用另一个工具进行企业的建模，即Eriksson和Penker所提出的一个活动图的构造型，称为“Eriksson-Penker业务扩展模型”

1）业务流程规划--Eriksson-Penker业务扩展模型

Eriksson-Penker业务扩展模型是一种“目标导向”的流程分析方式，主要是将与业务流程相关的重要人、事、物以及这个业务流程所要实现的目标做一个链接，描述了企业重要的人、事、物与流程的关系。

在项目开始队阶段，需求分析人员可以通过“Eriksson-Penker业务扩展模型”找出要开发系统的重要性，利用“目标导向 ”方式，对业务流程进行适当的切割。

前一阶段的主要产物是用例图，后续的设计与开发都将以用例驱动，系统设计阶段的主要工作，便是实现用户例。

实现用例的目的在于保证系统的设计可以满足用户的功能性需求，在实现用例过程种，应该利用Jacobson所分类的三种分析类

在项目立项之后，需求分析师与医院的领域专家通过面对面的访谈，整理出了医院实际上的住院出院流程，并绘制成活动图。

需要分析师基于企业的业务流程图，与领域专家通过进一步沟通，进行需求的收集，最终绘制出用例图。当然下图中没有包含用例叙述。

在得到用例图之后，便进入实现用例的阶段，可以通过上一节所介绍的有三种分类找到问题领域工勤上的重要概念，从而得到领域模型，然后通过类图来表达。

比如针对上一节用例图中的“登记出院记录”用例，通过分析可以得到一个控制对象（登记出院记录BPO）和多个实体对象（病床、病人、医生、护士、病症等），并绘制成如下的类图。

通常领域模型中会包含很多的类，必须对这些类进行分类，放置在不同的命名空间中，利用命名空间之间的关系图，来限制住不同分类对象之间的访问，这就是“包图”的使用场景。

“包图”是一个高阶的视图，由于所有的类都必须属于某一个包，因此当包之间的关系被限定时，该包内部所有的类，都会受到包图中设置的影响。

比如最基本的分类就是按照上面所说的三种分析类，对上面的领域模型，按照这种方式进行分类，便可绘制出如下包图

参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。

用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。用例是参与者想要系统做的事情。

系统边界是用来表示正在建模系统的边界，系统边界在画图中用方框来表示。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。

箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。