IBM Rational Unified Process(RUP) 提倡通過用例來提取系統中可操作的需求。 1 軟件需求說明書，即 Software Requirements Specification (SRS)，包括軟件的所有需求，其中包括很多相關的文檔。用例就是其中的一個重要部分。 SRS主要包括以下幾部分：
用例模型，包括：
用例圖：可視化的描述系統用戶，和系統為用戶提供的服務。
角色定義：用文字描述系統功能，和系統所需的服務。
用例描述：用文字描述系統提供的主要功能。
軟件補充規格文檔：這個文檔包括了整個系統相關的各種需求，和一些與對系統用戶和用例都不直接相關的隱藏需求。
在RUP方法中，這個需求文檔是后續的分析和設計工作的起點。不同的開發方式，對項目的推動力是不同的，也就會產生不同的文檔。如果軟件發布之后，你還總是在不停的修補缺陷，你很可能根本沒有需求文檔。只能從Bug報告中看出，軟件已經和最開始設計的樣子不一樣了。如果你在維護或者改進一個軟件版本（比如增加一項新功能），你可能有一兩個用例，他們描述了這些新功能和用戶之間如何交互，但是你不會有軟件補充規格文檔，因為這些功能之外的部分并沒有改變。
在這里，用一個虛構的軟件項目"green-field" 作為例子。這是一個面向對象的軟件項目，使用UML來描述系統中的各種概念與關系。讀者需要具有對象和類的基礎知識，熟悉UML 版本1.x 或者2.0中的類圖、順序圖和協作圖。
用例分析活動
下面我們討論一下RUP中的用例分析。如圖1所示，將RUP中結構分析的結果整合起來。
圖1： 結構分析的工作流程(early Elaboration)
顯而易見，嚴格來說的話，軟件開發過程應該側重于企業系統級的架構設計，以及軟件重用。但是基于以下三點原因，在這里我不會長篇大論的講述結構分析：
我的目標不是結構分析設計，而是面向開發人員的更底層的日常工作。
這不是一本專著，沒有那么多篇幅來講述結構分析。
根據我多年在軟件架構和軟件過程方面的咨詢經驗來看，只有很少的軟件開發組織能夠很規范的進行結構分析。如果你正在從事結構分析，你一定曾經經歷過本文中的一些內容。對一個新的，或是一個大型的軟件項目來說，采用結構分析是明智的選擇。但是如果你不太熟悉結構分析，本文的內容將會對你有所裨益。
用例分析的目的：
找出用例中的執行流程、事件的各個類。
通過實現用例，把用例的行為指定到具體的類。
找出類的責任、屬性和他們相互的關系。
規范地確定系統中各用例的職責。
我們也可以認為，用例分析的目標，就是把我們對用例的理解，轉變為與業務一致的形式，實現需求的價值。在用例設計的時候，我們把業務概念抽象成類、對象、關系、組件、接口等等，這些都與目標系統直接對應。
文章來源于領測軟件測試網 http://www.kjueaiud.com/