封装性是面向对象设计的重要思想之一。而实现封装的前提之一，就是要对需求进行整理的基础上加以功能划分，使具有强烈相关性的功能划分在一起，只有少量接口与外界交互。用例分析，从一开始就对原始需求进行了功能划分，将相关功能划分到一起，将共有功能提取出来，标志出功能间的依赖与非依赖关系（包含表示的是一种依赖关系，而扩展表示的是一种非依赖关系）。这是一种OOA/D，它为日后的OO设计提供了强有力地支持。而这些都是需求规格说明书所不具有，或者不完全具体的功能。
2、参与者
现在再来说说参与者。参与者给大家最直观的认识就是操作系统的那些人，但更准确的说应当是操作系统的那些角色。用例模型要求我们描述清楚系统中的每一个场景的每一步操作，操作者是谁。同时，我们关注的这个操作者并不是某个具体的人，而是一群有着相同职责的人，即角色。用例模型中对参与者的分析，为我们之后在开发过程中，进行功能、角色、用户的划分提供了依据。
用例模型中的参与者，除了表示操作系统的人，还表示处于系统边界之外，与系统边界内的用例有关联的其它系统。因此，只有定义好一个系统的边界，才能定义哪些是这个系统内的用例，哪些是这个系统内外的参与者。用例模型对本系统与其它系统相互关联的分析，为我们日后开发过程中，为其它系统提供接口，或与其它系统进行接口，提供了依据。
参与者之间的关系只有一种——继承关系，表示功能职责上的继承。譬如，通常软件系统中都有“普通操作者”，代表的是进入系统的所有用户都应当具有的功能。而软件系统又有很多“特殊职能者”，他们除了具有普通操作者的功能外，还有自己独特的功能。在这里，“特殊职能者”是对“普通操作者”的继承，继承了“普通操作者”的所有功能。然而，“特殊职能者”又有“普通操作者”不具备的，自己独特的功能。
参与者与用例之间是一种关联关系，即实线表示。通常，参与者与用例之间的关系不用定义导航关系（即画出箭头），但部分UML的书籍也定义了这种导航关系。如果参与者要使用用例，则箭头从参与者指向用例；如果参与者要接受用例提供的数据或查询结果，则箭头从用例指向参与者。
用例分析将参与者放到了一个十分显著的位置，同时还关注的参与者的期望（即“涉众利益”，在后面详细描述），这也是需求规格说明书所不具有的。
3、系统边界
系统边界是一个软件系统需要处理的整个问题空间的范围。一个软件系统不可能处理所有问题，我们必须得给它定义这个问题空间的范围。哪些是我们这个软件可以处理的，哪些则是我们这个软件不能处理的，也就是项目管理中所说的项目范围。与需求规格说明书相比，用例分析通过图形的方式，更加明确地定义出了项目范围，以及与其它系统之间的关系，使其更加清楚明了。
相关链接：
