(3) 标识各个用例。由于已经定义参与者及其目标，这一步便简化了。接下来只要定义符合这些目标的用例即可，这正是开发的主要目的，即设计满足用户需要的系统；
(4)确定用例和用例之间的关系。系统都包含一个或多个用例，当存在多个用例时，通常描述用例之间的关系；
●描述用例规约：
★在用例图中，每个用例只有一个名字，拿用例图当作需求规格文档还远远达不到“明确”的要求，这是因为我们还有一项工作没有做. 那就是详细描述每个用例，即用例规约；
★用例规约主要包含下面内容：
1、前置条件：前置条件指执行用例之前，系统必须所处的状态。
2、事件流：事件流 (Flow of Events) 包含基本事件流和备选事件流、事件流应该表示出所有场景；
3、后置条件：后置条件指用例执行完毕后，系统可能处于的一组状态。
eg：以“易买网“的 “用户登录’ 用例为例：讲解如何详细描述一个用例；
★前置条件：会员在“易买网“首页输入用户名和密码；
★基本事件流，内容如下：
▲会员在易买网首页输入用户名和密码，单击 " 登录“ 按钮时用例开始；
▲会员向系统提交用户名和密码；
▲保存当前用户信息在 "会话 (Session)"中；
★备选事件流，内容如下：
▲在基本事件流步骤 2 中，若会员提交错误用户名或密码，则系统提示用户名密码错误，转至本事件流步骤1；
★后置条件，'会话“ 中保存了已登录用户的信息：
▲前置与后置条件。前置与后置条件表示用例开始和结束会发生什么。即在用例开始时系必须处在什么状态 (前置条件), 或者在用例结束时系统必须处在什么状态 (后置条件)，不管紧随用例之后是哪一个分支或选择，后置条件必须为真；
▲事件流。事件流包含基本事件流和备选事件流；
☉基本事件流描述的是该用例最正常的一种场景，在基本事件流中系统执行一系列活动步骤，响应参与者提出的服务请求；
☉备选事件流负责描述用例执行过程中，异常的或偶尔发生的一些情况；
■从参与者的角度来看，事件流是一系列陈述句，它列出了用例的各个步骤：告诉我们它如何始，使用一个像 “当……时，用例开始” 的描述. 如果用例是为软件做的.那么软件如何知道什么时候用例开始？同样地，用例如何结束？这可以使用如 "用例结束’ 的短语清晰地陈述它。
■事件流包含顺序、分支和循环三种结构。使用分支可以表示选择。当需要重复一个或者一系列步骤时，可以使用循环。要清楚地指出循环在哪里开始和在哪里结束，还要清楚地指出将如何结束，它可能因为已经到达这一系列的终点而结束，或者有些条件导致了循环的结束；
■当详细描述了每一个用例时，我们的需求规格说明书也就完成了。一般在需求规格说明书功性需求的部分，我们会首先放上系统级的用例图，然后对逐个模块进行描述，采用规范的模式详地描述每个用例。
■以上就是我们得到软件需求的方法