一 需求
1．定义系统：初步定义系统中应该包括哪些内容，以及不包括哪些内容。
目标－确定系统的范围
活动：
1）捕获通用词汇：确立项目中要使用的通用术语和概念。
输入工件：前景文档
输出工件：词汇表
通用术语指的是那些在描述系统行为过程中经常会出现的词汇。
2）找出参与者和用例：定义系统的边界
综述：识别出参与者和用例，将结果记录在用例模型中。对于不能与特定用例相关
联的需求内容记录在补充规约中。
输出工件：用例模型、补充规约
步骤：
（1）找出参与者
参与者是在系统外部与系统交互的某人或者某系统。找出参与者有助于定义系
统的边界。它们代表系统的外部环境。
（2）找出用例
用例是一个完整的事件流描述，为特定的参与者提供一个有价值的结果。
找出用例的最好办法就是研究每一个参与者针对系统的要求。系统之所以存在
的意义就在于为那些与其交互的参与者提供他们需要的服务。
以下的一系列问题有助于找出用例：
· 针对每一个参与者，系统将参与完成哪些任务
· 参与者是否需要获知系统内部所发生的特定情况。
· 参与者是否需要将外部变化通知系统
· 找出的用例是否能够提供前景中所描述的全部特性。
· 在系统中必须要修改和建立什么信息。哪些参与者需要参与到相应的变更
活动中。
· 什么用例会支持系统的管理和维护工作。
注：现在不用描述用例的细节内容。现在的主要任务是定义这些用例的目的。
（3）收集补充需求
有些需求并不能分配给特定的用例，这些需求是针对整个系统的。将这些
需求记录在补充规约当中。
（4）描述参与者和用例的交互
它们之间的关系被表述为关联关系。
（5）对用例和参与者打包
用例模型的目的是开发团队与系统涉众之间的一个合约。因而将该模型的
复杂度控制在最低限度是非常重要的。如果参与者和用例的个数过多，可以将
它们放到用例模型的不同包当中。
3）排序用例
活动：对已识别出的用例进行排序
输入工件：用例模型、前景文档
输出工件：用例优先级列表。
步骤：
（1） 排序用例
（2） 更新软件架构文档
2．精化系统定义
活动：
1） 细化用例
综述：针对先前找出的用例，描述相应的事件流内容。不针对特定用例的需求内容被记录在补充规约中。在当前的迭代中，针对每个用例展开细化用例的活动。
这个活动的起点事在找出参与者和用例活动中得到的用例的描述，而后逐步细化相关内容，直到所有涉众都认可用例的内容已经能够表达他们的需求。
在细化用例的时候，我们要说明以下信息：
·名称
·简要描述：用例的目标和用途
·事件流：针对系统行为的文字描述。其内容表述为参与者和系统之间的交互。
·特殊需求：针对那些不在事件流中的需求内容的文字描述。就是针对用例的非功
能需求。
·前置条件：为了执行特定用例，系统所应具备的状态
·后置条件：用例执行结束时，系统可能处于的状态列表。
注：将用例的详细文字描述放在用例规约文档中。
步骤：
（1）细化用例的事件流内容
（2）描述用例的特殊需求
（3）描述用例的前置条件
（4）描述用例的后置条件
2） 结构化用例模型
综述：消除用例之间的冗余，使得用例模型更加简明。