在IT專案開發的生命週期中，越晚發現在的錯誤，其修復成本就越高。Boehm（1981）的研究發現，要改正在產品付諸應用後所發現的一個需求方面的缺陷比在需求階段改正這個錯誤多出68倍的成本；而越來越多的研究表明，這個錯誤導致的成本提升可能高達200倍。而錯誤對專案另一種重要的不良影響是修復時間，從對大量開發專案情況的研究中發現，在需求開發階段發現的一個錯誤，平均僅需要花30分鐘修復， 但若在系統測試時發現則需要5到17個小時來修復。
所謂需求分析是指通過對問題域的研究，獲得對該領域特性及存在於其中(需要解決)的問題特性的透徹理解並有文檔的說明。需求分析在IT項目中具有十分重要的作用。本文就IT專案中需求分析時應注意的主要問題進行了研究分析。
一、與用戶溝通前應進行充分溝通
通常，與用戶溝通前的準備時間要遠遠大於正式會面溝通的時間。一般情況下，使用者在和你連續交談兩個小時之後，就會失去熱情和耐心，這是大部分人的共同特點。所以充分的準備工作至關重要。
準備工作包括對專案整體環境熟悉的準備工作和對具體業務進行調研前的準備工作。專案整體環境的熟悉工作需要瞭解:專案的背景、專案的目的、專案的利益相關方等資訊，以便對當前專案的鷹缽情況有一定瞭解。
對具體業務調研前的準備工作包括:需求調研問題的準備、需求調研範本的設計、需求調研時間安排等內容。要充分珍視用戶的時間，儘量避免由於準備工作不足而反復約見用戶，給用戶造成效率低下的印象。一旦發生這樣的錯誤，以後可能就會很難約見到用戶。
二、主動積極瞭解客戶業務和相關知識
在電腦技術方面我們可能非常專業，但對於具體的用戶業務可能並不十分清楚。這個專案對使用者是否有説明、某一系統功能是否有用、某一流程處理是否合理，在不瞭解使用者業務的情況下，我們將很難做出判斷。
因此只有在瞭解業務的基礎上，我們才和使用者有共同的溝通語言和業務理解，才能真正理解系統應具有哪些功能。應用領域的知識是無邊無際的，在各種專案的調研過程中，肯定會出現由於需求分析者缺乏某一領域的知識而影響需求分析工作的準確、順利進行。遇到此類問題時，需求分析者應虛心向用戶請教，同時應及時補充應用領域的知識。最好能夠在調研前做好充分的準備。
三、對用戶進行正確分類
組織中的使用者在很多方面存在差異，例如:使用系統的頻度和程度、電腦系統知識、所進行的業務過程以及個人的素質和喜好等。根據使用者的特點，可對用戶進行一定的分類。將用戶分類並歸納各自特點，詳細描述他們的個性特點及任務狀況，將有助於需求的獲取和分析。
不同的問題需要詢問不同的人，對於操作細節的問題，要和實際負責操作的用戶進行溝通，而對於關乎全域的問題，則要和相應的管理層用戶進行溝通。如通過組織架構圖得知倉庫部門有三種角色:倉庫主管、發貨理貨員、系統操作員。
我們發現倉庫主管是對全盤業務相當熟悉的人，他負責協調本部門的全域事務;而發貨理貨員是部門的主要業務執行人;系統操作員則是倉庫管理系統的直接操作者。若我們調研的目的是搞清該部門的整體性流程，我們會很自然地選擇倉庫主管作為訪談的對象。
四、引導用戶，使用戶充分表達自己的想法
在與用戶交談中，如何引導用戶說出他們的需求是非常關鍵的。恰當的提問，會使用戶滔滔不絕，充分發表自己的意見和建議。而不恰當的提問，可能會導致用戶無法回答或敷衍了事地進行回答。提問可分為封閉式提問和開放式提問。
封閉式提問目的明確。如:現在你們的送貨單是手工填寫還是電腦列印?但過多使用封閉式提問，會導致談話枯燥，讓用戶感覺自己好像在接受審問。開放式提問是請對方對某一事物做進一步的解釋，可使談話達到一定的深度和廣度。
如:你認為目前的工作中存在哪些可以改進的地方?開放式提問缺點是容易使談話內容偏離主題。因此在談話過程中，應採用封閉式和開放式提問相結合的方式。以簡單問題開始、從使用者熟悉的內容開始。每次只提一個問題、集中一個重點，寧問勿猜。並儘量避免使用IT相關的一些術語，以便用戶能夠很好地理解我們的表達。
五、確定需求的優先順序別
當客戶的期望很高、開發時間很短且資源有限時，設定需求的相對優先順序將有助於專案管理人員解決衝突、安排階段性交付並做出必要的取捨。建立每個需求的重要性有助於規劃軟體的構造，以最少的費用提供產品的最大功能。
特別是對漸進式的項目，優先順序的設定就顯得更為重要，因為在這些開發中，項目時間安排極為緊迫並且交付日期不可改變，一些低優先順序的需求就需要推遲到後續版本中進行實現或直接取消。
當眾多用戶因期望不同而就某些需求優先順序的設定難以達成一致意見時，需求分析者可指出每一需求所需的費用、難度、技術風險或其他特定的與權衡需求有關的指標，來客觀評價每一需求的優先順序。
六、分析需求可行性
柳傳志曾說:“沒錢賺的事我們不幹;有錢賺但投不起錢的事不幹;有錢賺也投得起錢但沒有可靠的人選，這樣的事也不幹。”
柳傳志為聯想集團的決策確立了上述準則，同時也為可以行性分析指明了重點。可行性分析主要是針對某一需求決定是做還是不做。一般可行性主要考慮兩個方面的因素:技術和人。技術方面主要是分析在給定的時間段內是否可實現所需的功能並滿足產品的品質要求等相關指標。很多時候，用戶的想法在實際實施過程中是不現實的。若一味地求全和盲目遵從用戶的設想，將為專案的後續工作帶來很大的風險。因此應儘量避免在需求分析中包含技術實施上有難度的功能。如在筆者曾經負責的一個專案中，使用者要求新的管理系統應實現和用友、金蝶等管理系統的資料介面，以方便這些系統中的資料導人新的管理系統。
許諾提供與用友、金蝶等系統的資料介面，將為新系統的成功實施帶來很大的風險。因為熟悉這些系統需要時間，開發與它們的介面也需要時間，而且用友、金蝶等這些系統存在多個不同的版本。因此與外部系統介面的可行性定義為: 不可行。
人的方面主要考慮目標使用者是否具有相應的素質和能力。在實際專案中，筆者曾對快速消費品行業經銷商批次管理的可行性進行了分析。首先，批次管理將涉及到所有產品的出入庫操作，並存在一個產品有多個批次的情況，因此批次管理對操作人員的能力和素質要求比較高。
其次，快速消費品行業的特點決定了產品的出入庫操作極為頻繁，因此，操作人員的工作強度比較大。再次，大部分經銷商的倉庫所在地都距離城鎮比較遠，因此工作人員的文化水準普遍不高。在綜合考慮後，將批次管理的可行性定義為低。
對於複雜的項目，還應從經濟方面和環境方面進行考慮。經濟方面主要從投入、收益、短期、長遠利益等方面進行分析。環境方面主要考慮市場環境和政策因素。
七、正確理解需求分析文檔確認
需求分析是一項繁瑣枯燥的工作，需要和使用者不斷的商討、確認和反復。但大部分用戶並不只做這項工作，特別當他被很多其他的事情纏身的時候，而無心在筆者曾負責的經銷商管理系統中，經銷商認為，庫存過高將佔用企業運轉資金，增加企業負擔;
庫存過低則無法滿足客戶訂單，從而導致交貨週期延長，降低企業市場競爭力。由於經銷商對當前可用庫存十分關注，因此可用庫存的優先順序被定義為:高優先順序。仔細考慮或回答你的問題。這很容易使你錯誤地認為使用者已經真正地瞭解並認可了你的分析文檔。
在需求分析文檔上簽字確認，通常被認為是使用者同意需求分析內容的標誌行為。而實際操作中，簽字確認工作並未得到用戶的充分重視。“他們要求我在需求文檔上簽名，於是我就簽了，否則開發人員不開始編碼。”用戶的這種態度將可能給項目帶來潛在的風險，如不斷地進行需求變更等。對於需要使用者確認的需求分析文檔，最好在用戶確認前，就文檔內容對使用者進行一定的講解，以確保用戶完全理解並認可文檔中的內容。若使用者對文檔中的內容存在修改意見，則修改後再與用戶進行確認，直至用戶完全認可文檔中的內容為止。
需求確認將給初步的需求開發工作畫上了雙方都明確的句號，並有助於形成一個持續良好的用戶與需求分析人員的關係，為專案的成功奠定堅實的基礎。通常為對項目有一個整體、準確的理解，需求分析所包含的內容通常大於專案範圍所包含的內容。因此，應讓用戶理解對於某些功能的討論並不意味著即將在系統中實現它。應使用戶明白對需求分析文檔的簽字確認是建立一個需求的基線，進一步的變更可在此基線上通過專案定義的變更過程來進行。
八、應實地瞭解使用者工作流程
實地觀察用戶執行業務任務的過程。瞭解使用者什麼時候獲得什麼資料，並怎樣使用這些資料，業務處理 過程中需要處理哪些單據，需要和哪些角色的使用者發生關聯等。這都將有助於明確產品的功能需求。
經驗證明，與人們面談關於他們如何完成任務時會有許多限制和不準確性，而這是任務觀察可以直接解決的。特別是對於某些組織中普遍接受的規則和方法，使用者認為你也應理所當然知道，而不曾提起時。
近年來，由於人機交互的複雜性驚人地增加，人機交互的觀察和記錄已引起人們的廣泛注意。觀察是一個主觀的領域，很大程度上依賴於需求分析者的經驗。在經銷商管理系統的需求分析中，通過觀察發現:某些客戶要求送貨單中的商品價格為含稅價格，而有些客戶則要求送貨單上的商品價格為不含稅價格;有些商品的稅率為13%，而有的商品稅率為17%;
有些客戶要求送貨單上的金額小數點後保留四位元，有的客戶又要求送貨單上必須提供自己公司的商品編碼等。而這些都是在調研中，使用者不曾提起的內容。