一 需求
1．定義系統：初步定義系統中應該包括哪些內容，以及不包括哪些內容。
目標－確定系統的范圍
活動：
1）捕獲通用詞匯：確立項目中要使用的通用術語和概念。
輸入工件：前景文檔
輸出工件：詞匯表
通用術語指的是那些在描述系統行為過程中經常會出現的詞匯。
2）找出參與者和用例：定義系統的邊界
綜述：識別出參與者和用例，將結果記錄在用例模型中。對于不能與特定用例相關
聯的需求內容記錄在補充規約中。
輸出工件：用例模型、補充規約
步驟：
（1）找出參與者
參與者是在系統外部與系統交互的某人或者某系統。找出參與者有助于定義系
統的邊界。它們代表系統的外部環境。
（2）找出用例
用例是一個完整的事件流描述，為特定的參與者提供一個有價值的結果。
找出用例的最好辦法就是研究每一個參與者針對系統的要求。系統之所以存在
的意義就在于為那些與其交互的參與者提供他們需要的服務。
以下的一系列問題有助于找出用例：
· 針對每一個參與者，系統將參與完成哪些任務
· 參與者是否需要獲知系統內部所發生的特定情況。
· 參與者是否需要將外部變化通知系統
· 找出的用例是否能夠提供前景中所描述的全部特性。
· 在系統中必須要修改和建立什么信息。哪些參與者需要參與到相應的變更
活動中。
· 什么用例會支持系統的管理和維護工作。
注：現在不用描述用例的細節內容。現在的主要任務是定義這些用例的目的。
（3）收集補充需求
有些需求并不能分配給特定的用例，這些需求是針對整個系統的。將這些
需求記錄在補充規約當中。
（4）描述參與者和用例的交互
它們之間的關系被表述為關聯關系。
（5）對用例和參與者打包
用例模型的目的是開發團隊與系統涉眾之間的一個合約。因而將該模型的
復雜度控制在最低限度是非常重要的。如果參與者和用例的個數過多，可以將
它們放到用例模型的不同包當中。
3）排序用例
活動：對已識別出的用例進行排序
輸入工件：用例模型、前景文檔
輸出工件：用例優先級列表。
步驟：
（1） 排序用例
（2） 更新軟件架構文檔
2．精化系統定義
活動：
1） 細化用例
綜述：針對先前找出的用例，描述相應的事件流內容。不針對特定用例的需求內容被記錄在補充規約中。在當前的迭代中，針對每個用例展開細化用例的活動。
這個活動的起點事在找出參與者和用例活動中得到的用例的描述，而后逐步細化相關內容，直到所有涉眾都認可用例的內容已經能夠表達他們的需求。
在細化用例的時候，我們要說明以下信息：
·名稱
·簡要描述：用例的目標和用途
·事件流：針對系統行為的文字描述。其內容表述為參與者和系統之間的交互。
·特殊需求：針對那些不在事件流中的需求內容的文字描述。就是針對用例的非功
能需求。
·前置條件：為了執行特定用例，系統所應具備的狀態
·后置條件：用例執行結束時，系統可能處于的狀態列表。
注：將用例的詳細文字描述放在用例規約文檔中。
步驟：
（1）細化用例的事件流內容
（2）描述用例的特殊需求
（3）描述用例的前置條件
（4）描述用例的后置條件
2） 結構化用例模型
綜述：消除用例之間的冗余，使得用例模型更加簡明。