1．定义系统：初步定义系统中应该包括哪些内容，以及不包括哪些内容。

目标－确定系统的范围

活动：

       1）捕获通用词汇：确立项目中要使用的通用术语和概念。

              输入工件：前景文档

              输出工件：词汇表

              通用术语指的是那些在描述系统行为过程中经常会出现的词汇。

       2）找出参与者和用例：定义系统的边界

              综述：识别出参与者和用例，将结果记录在用例模型中。对于不能与特定用例相关

联的需求内容记录在补充规约中。

输出工件：用例模型、补充规约

        步骤：

（1）找出参与者

       参与者是在系统外部与系统交互的某人或者某系统。找出参与者有助于定义系

统的边界。它们代表系统的外部环境。

              （2）找出用例

                         用例是一个完整的事件流描述，为特定的参与者提供一个有价值的结果。

找出用例的最好办法就是研究每一个参与者针对系统的要求。系统之所以存在

的意义就在于为那些与其交互的参与者提供他们需要的服务。

                     以下的一系列问题有助于找出用例：

                  · 针对每一个参与者，系统将参与完成哪些任务

            · 参与者是否需要获知系统内部所发生的特定情况。

            · 参与者是否需要将外部变化通知系统

            · 找出的用例是否能够提供前景中所描述的全部特性。

            · 在系统中必须要修改和建立什么信息。哪些参与者需要参与到相应的变更

活动中。

            · 什么用例会支持系统的管理和维护工作。

注：现在不用描述用例的细节内容。现在的主要任务是定义这些用例的目的。

        （3）收集补充需求

                            有些需求并不能分配给特定的用例，这些需求是针对整个系统的。将这些

需求记录在补充规约当中。

        （4）描述参与者和用例的交互

                            它们之间的关系被表述为关联关系。

              （5）对用例和参与者打包

                            用例模型的目的是开发团队与系统涉众之间的一个合约。因而将该模型的

复杂度控制在最低限度是非常重要的。如果参与者和用例的个数过多，可以将

它们放到用例模型的不同包当中。

       3）排序用例

              活动：对已识别出的用例进行排序

              输入工件：用例模型、前景文档

              输出工件：用例优先级列表。

              步骤：

（1）       排序用例

（2）       更新软件架构文档

2．精化系统定义

       活动：

1）  细化用例

综述：针对先前找出的用例，描述相应的事件流内容。不针对特定用例的需求内容被记录在补充规约中。在当前的迭代中，针对每个用例展开细化用例的活动。

       这个活动的起点事在找出参与者和用例活动中得到的用例的描述，而后逐步细化相关内容，直到所有涉众都认可用例的内容已经能够表达他们的需求。

       在细化用例的时候，我们要说明以下信息：

    ·名称

    ·简要描述：用例的目标和用途

    ·事件流：针对系统行为的文字描述。其内容表述为参与者和系统之间的交互。

    ·特殊需求：针对那些不在事件流中的需求内容的文字描述。就是针对用例的非功

能需求。

·前置条件：为了执行特定用例，系统所应具备的状态

·后置条件：用例执行结束时，系统可能处于的状态列表。

注：将用例的详细文字描述放在用例规约文档中。

    步骤：

    （1）细化用例的事件流内容

    （2）描述用例的特殊需求

    （3）描述用例的前置条件

    （4）描述用例的后置条件

2）  结构化用例模型

综述：消除用例之间的冗余，使得用例模型更加简明。