需求分析不是壹項壹蹴而就就可以完成的工作，它需要壹個長期的過程，而這個過程是壹個由粗到細的過程，它體現了人類認識事物的客觀規律。在需求分析的初期，我們對需求的認識往往是整體的、宏觀的，隨著分析工作的逐漸深入，壹步步細化。按照這個思路，我們對需求的分析，首先應當從功能角色分析開始。所謂功能角色分析，就是從壹個外部用戶的視角分析整個軟件系統能夠提供的功能，以及這些功能到底是提供給哪些角色使用。
對壹個系統進行功能和角色方面的梳理和分析，可以采用的比較主流的方法之壹就是繪制用例圖。用例圖是UML的4+1視圖中的壹種，準確地說就是那個“+1”。用例圖是貫穿整個面向對象分析/設計（OOA/D）的核心視圖，它描述的是系統到底為用戶提供了哪些功能，以及到底是哪些用戶在使用這些功能，是溝通用戶與技術人員的橋梁。
運用用例視圖對業務需求進行分析、抽象、整理、提煉，進而形成抽象模型的過程稱之為用例建模，而這個模型就是用例模型。 壹般地，在壹個用例圖中通常有三種元素：參與者（Actor）、用例（Use Case）與系統邊界（Boundary）。
上圖是壹個考核系統中壹個子模塊的用例圖。圖中的用例就是這個系統提供給用戶的各項功能。 註意，這裏僅僅是在羅列功能而不表示它們之間諸如流程調用等相互關系，這是壹些初學者常常犯的毛病。
在這個用例圖中，普通用戶執行查詢操作，查詢系統提供的“預警監控單項查詢”、“預警監控匯總查詢”等查詢報表；每日自動觸發器觸發自動考核功能，自動考核功能從“稅收征管系統”這樣壹個外部系統中采集數據。 圖中考核管理員和執法人員代表的是兩個完全不同的角色，但他們在這個圖中體現的是壹些***有的特性，即對這堆報表的查詢，因此被繪制成繼承自普通用戶。繼承是參與者間唯壹的關系，代表繼承者擁有被繼承者所有的功能與權限。除了參與者以外，用例與用例直接也存在著壹些類型的關系，這我們在後面詳細講述。 在繪制用例圖時壹個值得思考的細節是，用例是怎樣通過分析獲得的。這個問題，在壹些客戶對信息化管理比較有經驗的項目中不存在問題，因為在客戶提供給我們的需求文檔中就清晰地劃分出了壹項壹項的功能。這些功能可能會在日後的需求分析工作中有所調整，但它從整體上形成了壹個雛形，成為我們進行用例分析進而形成用例的依據。 但當我們面對的是壹些對信息化管理沒有經驗的客戶，情況就有些不妙了。在這種情況下，通常客戶只能給我們壹些管理目標、基本想法，其它的調研工作就需要我們自己去做了。這時，我給大家的建議是，首先從組織機構上劃分清楚系統涉及哪些部門、哪些科室，然後在這個基礎上劃分出來這些部門這各個科室的人員都扮演哪些不同職能的角色，以及完成哪些業務操作。系統中的壹個功能，在壹般情況下是組織機構中某個（或多個）角色，為該機構某項業務流程完成的某個操作，並且這個操作應當有某個確定的結果（即產出物）。而這個功能就是我們需要提取出來的用例。雖然功能角色分析在整個需求分析過程中可能會隨著認識的深入而不斷調整，但分析過程大體是這樣進行的。 有人說，我們繪制的用例圖拿給客戶看不懂。這樣壹個清晰明了的用例圖，輔之以我們對圖形的描述，客戶怎麽會看不懂呢？關鍵問題在於，我們沒有將用例圖的精髓弄明白，再加上出現壹些常見問題，使得用例圖畫得不倫不類，客戶當然就看不明白了。