在軟件工程的歷史中，很長時間里人們一直認為需求分析是整個軟件工程中最簡單的一個步驟，但在過去十年中越來越多的人認識到它是整個過程中最為關鍵的一個過程。假如在需求分析時分析者們未能正確地認識到客戶的需求的話，那么最后的軟件實際上不可能達到客戶的要求，或者導致需求的頻繁變更，而軟件無法在規定的時間里完工。
在需求分析階段，要對經過可行性分析所確定的系統目標和功能作進一步的詳細論述，確定系統“做什么？”的問題，最終建立起目標系統的邏輯模型。
首先是獲得當前系統的物理模型。物理模型是對當前系統的真實寫照，可能是一個由人工操作的過程，也可能是一個已有的但需要改進的計算機系統。首先是要對現行系統進行分析、理解，了解它的組織情況、數據流向、輸入輸出，資源利用情況等，在分析的基礎上畫出它的物理模型。然后抽象出當前系統的邏輯模型。
邏輯模型是在物理模型基礎上，去掉一些次要的因素，建立起反映系統本質的邏輯模型。接下來建立目標系統的邏輯模型。通過分析目標系統與當前系統在邏輯上的區別，建立符合用戶需求的目標系統的邏輯模型。最后補充目標系統的邏輯模型。對目標系統進行補充完善 ,將一些次要的因素補充進去，例如出錯處理等。
UML（The Unified Modeling Language，即統一建模語言）是一種編制系統藍圖的標準化語言，可以對復雜的系統建立可視化的系統模型，目前已經被工業標準化組織OMG（Object Management Group）接受，一經推出便得到許多著名的計算機廠商如Microsoft、HP、IBM、Oracle等的支持，也在逐步開始應用到需求分析過程中。
在使用UML建立當前系統邏輯模型過程中，初學者通常會遇到一些問題：
1.什么時候真正需要業務模型？什么時候用例模型獨立存在？
2.在進行精確的業務建模時能用哪些UML圖形？如何知道是否用順序圖或者交互圖？
3.業務模型如何涉及到其他模型（如領域模型，用例模型等等）呢？如何有機地組織這些模型？
本文將通過圖書館管理系統這個簡單而典型的實例來進行一次UML需求分析實踐之旅。
許多讀者對圖書館圖書管理工作比較熟悉，主要是圍繞讀者、圖書和工作人員的借還書展開工作。我們先看看圖書館工作人員和部分讀者的需求。
讀者來圖書館借書，可能先查詢書庫的圖書記錄。查詢可以按書名、作者、圖書編號、關鍵字查詢。查詢有兩種結果，如果查到則記下書號，交給工作人員，然后等候辦理借書手續。如果該書已經被全部借出，則可做借書登記，等待有書時被通知。如果圖書館沒有該書的記錄，則做缺書登記。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
