系統開發初期最重要的一個前導工作即在於紀錄及蒐集需求(Requirement)。

所謂的需求即是使用者與系統(System)之間的一種契約(contract)，它是一組特定的功能、規格、特徵或原則，而系統必須提供以達成為使用者服務的目的。

所以需求也就構成了軟體專案開發的範圍(scope)。需求的紀錄獲取，往往就是在軟體開發時的一項重要的前導活動(Activity)。

在以往的作法，需求分析師(Requirement Analyst)是利用非標準化的需求列表(Requirement List)來記錄使用者的需求。分析師個別來訪談使用者的需求並依此而紀錄所做成的需求列表。

這種作法，看似鉅細靡遺，卻存在著很多的衝突。例如，使用者經常干涉到實作細節，甚至，連畫面的編排都有意見，所以，分析師可能就會紀錄著這麼一段話：「某甲希望某某欄位擺在那個畫面位置上，並且可以用 【TAB】鍵來循序切換欄位位置」。又，也有可能分析師訪談的兩位使用者，其實都是希望系統作同一件事，但因描述到不同的實作作法(干涉到系統內部)，而使得分析師必須分兩件事來記錄。諸如此類，使得分析師所記錄下來的需求列表長達數十甚至上百頁，而要從其中繁雜的內容釐清來開發系統，談何容易！

總之，要能最有效率地來正確地捕捉需求，需要能避免下述的問題：

• 衝突(conflicts)。
• 冗長多餘(redundancy)。
• 實作上的細節(implement detail)。
• 盡量能對共通性的事物抽象而得以對大多數的使用者感覺有意義。
• 能區隔功能性(functional)與非功能性(nonfunctional)的需求。

說明：什麼是功能性與非功能性需求？

• 功能性需求(Functional Requirements)：
  所謂的功能性需求即是使用者需要系統能為他做什麼。這往往是顯而易見的，因為，使用者可以清楚的看到系統為他服務並會有回應。
  例如在一個訂購系統中，功能性需求有：
  • 系統接受顧客的訂購，並且會通知倉管該產品庫存量是否充足。
  • 系統會對前一日的訂購在當夜會產生統計報表。
• 非功能性需求(Nonfunctional Requirements)：
  非功能性的需求往往是使用者所感受不到系統有直接提供服務並有回應，往往非功能性的需求是總體(global)的、模糊(fuzzy)的一些因素而導致系統整體的良好運作。例如：
  系統要能處理超過1千人以上線上訂購書籍的效能(performance) ； 系統為了要能應付日增的交易處理，所以必須要能具備延展性(scalability)。

利用使用案例來紀錄及捕捉系統的功能性需求，可以避免及降低上述所列問題的產生。

使用案例，是從使用者的角度(View)來看待與應用系統之間的互動，又不致干涉到系統實作(how-to)的內部，所專注的僅是在於與系統溝通時的“進(Request)”與“出(Response)”，也就是從使用者的角度來看時，應用系統是一個黑箱(Black-box)。

應用系統接收到使用者傳送進來的訊息(Message)，經過內部的處理再將結果傳回給使用者，而使用者不需也不必瞭解系統內部實作的細節。
也就是說，使用者只在乎系統在完成他的期望(Goal)的過程期間，只需瞭解系統“做什麼(What to do)”而不需要知道系統“如何做(How to do)”。

在需求獲取階段(requirement gathering)及分析階段期間，分析師要能捕捉(capture)到使用者對系統的期待或想法，也就是要能取得使用者的需求是相當重要的。

早期使用傳統的需求列表方式，發現太多的繆誤發生(同樣一件事不同的使用者對系統有不同的觀點)、作過多的假設、冗長的文件列表…等，並且很有可能其內容會誤導開發團隊過早陷入實作細節，而造成 “分析癱瘓 (analysis paralysis) ”。

參考 Benjamin L.Kovitz 對於“需求”一詞的定義：
“Requirements are the effects that the computer is to exert in the problem, by virtue of the computer’s programming.”。
而使用案例，便是一種極佳的工具，可以容易正確地來捕捉到 User 的需求，又不致陷入於實作的細節內。

Martin Fowler 在 “UML Distilled” 一書中，便提到：
“我幾乎無法想像沒有使用案例時會是一個怎樣的情況。使用案例對獲得需求、規劃、和控制循環式(iterative)的專案來說已經是一個基本的工具了。”

Martin Fowler 同時也提到：
“尋找使用案例和建立領域概念模型(domain conceptual model) 是兩件事。”
“使用案例代表系統的外部觀點。因此，不要期待 use case 跟系統內部的物件類別(class)之間會有太多的相關性。”

基本上，使用案例與物件導向並沒有直接關聯，但會是導入物件導向技術重要的需求捕捉關鍵技術。可以說，使用案例是以物件導向思維的專案開發模式的最佳前導工具。