需求分析与用例

一、需求分析与用例：

需求：就是系统必须提供的能力和必须遵从的条件，包括：功能需求和非功能的需求（性能要求）。

需求分析：重要手段是确定和编写用例。

用例：是文本形式的情节描述，用于需求的发现和记录。用例会影响后续的OOA/D工作。

参与者（Actor）：某些具有行为的事物，可以是人（由角色标识）、计算机系统或组织，例如收银员。

场景（Scenario）：是参与者和系统（我们要开发的系统）之间的一系列特定的活动和交互。包括主成功场景和交替场景（主成功场景表示正常功能….；交替场景是如果….）

二、用例的目的与形式：

用例编写的形式：

需求分析早期使用，通常用于主场景（如“管理员向系统提交用户名和密码。系统进行认证。系统向管理员显示功能登录信息”）

三、用例编写的格式：

四、如何发现用例：

1选择系统边界

2确定主要参与者

3确定每个主要参与者的目标

4定义满足用户目标的用例，根据其目标对用例命名

在真实项目中发现用例，遵循如下思维习惯：调研需求时最先弄清楚有多少部门，多少岗位（参与者），然后找到每一个岗位的业务代表，问

他们类似的问题：你平时都做什么？（参与者目标）这件事是谁交办的？

做完了你需要通知或传达给认证吗？做这件事情你都需要填写些什

么表格吗？

五、用例关联及一些术语

用例彼此之间可能具有联系，比如：处理信用卡支付用例可倾向于为处理销售、处理租金等常见用例的一部分。

（1）关联

在用例图中，用例和执行者之间的关系用一条连接二者带箭头的连线表示，

如图所示，该连线称为关联。它表示了一个执行者和一个用例之间的关系。

在用例图中，关联关系只用在执行者和用例之间，用例和用例之间不会存在关联关系。关联关系采用的是单箭头的连线，表示在该关联中执行者是主动的，是执行者启动的用例。如下图所示。

）包含2（．

包含是指一个用例作为另一个用例必需的部分被使用，包含关系是依赖关系的一种。包含关系用一条连接二者带箭头的虚线表示，并在虚线的上面标注《include》，箭头方向由基本用例指向包含用例，如下图所示。

包含的使用场合：如果多个用例有大量一致的功能，可以将这个功能分解到一个用例中，

其他用例和这个用例建立包含关系。一个用例功能太多，可以使用包含关系建立若干小用例。

（3）扩展扩展是指一个用例扩充了另一个用例的功能，但这个扩充功能不是必需的，扩展关系也是依赖关系的一种。扩展关系用一条连接二者带箭头》，箭头方向由扩展用的虚线表示，但在虚线的上面标注的是《extend 例指向基本用例，如下图所

示。．

扩展关系和包含关系的区别。包含用例是一个完整的用例，它可以独立的存在，也可以单独被执行

者所调用。扩展用例并不是一个完整的用例，它只是由部分扩展功能组成的，它

不能独立的存在，必须依赖于基本用例。

）泛化（4用例间的泛化关系是指一个概念较为抽象的用例可以被一般化为一

个或多个概念更为具体的用例。其中概念较为抽象的用例被称为父用例，概念更为具体的用例称为子用例。子用例是父用例的特殊形式，子用例从父用例处继承属性和行为，还可以添加、覆盖或改变继承的行

为。．

?