（1）用戶解決問題或達到目標所需的條件或能力。
（2）系統或系統部件要滿足合同、標準、規範或其它正式規定文檔所需具有的條件或能力。
（3）壹種反映上面(1)或(2)所描述的條件或權能的文檔說明。 實通俗的講，“需求”就是用戶的需要，它包括用戶要解決的問題、達到的目標、以及實現這些目標所需要的條件，它是壹個程序或系統開發工作的說明，表現形式壹般為文檔形式。
需求工程的定義：
需求分析的過程，也叫做需求工程和需求階段，它包括了需求開發和需求管理兩個部分。需求開發是指從情況收集、分析和評價到編寫文檔、評審等壹系列產生需求的活動，分為四個階段：情況獲取、分析、制訂規格說明和評審。這四個階段不壹定是遵循線性順序的，他們的活動是相互獨立和反復的。需求管理是軟件項目開發過程中控制和維持需求約定的活動，它包括：變更控制、版本控制、需求跟蹤、需求狀態跟蹤等工作。
需求開發與管理的壹些方法：
（1）繪制關聯圖：繪制系統關聯圖是用於定義系統與系統外部實體間的界限和接口的簡單模型。
（2）可行性分析：在允許的成本、性能要求下，分析每項需求實施的可行性，提出需求實現相關風險，包括與其它需求的沖突，對外界因素的依賴和技術障礙。
（4）系統原型：當用戶自身對有的需求不十分清楚時，我們可以建立壹個系統原型，用戶通過評價原型更好地理解所要解決的問題。。
（5）圖形分析模型：繪制圖形分析模型是編制軟件需求規格說明重要手段。它們能幫助分析人員理清數據、業務模式、工作流程以及他們之間的關系，找出遺漏、冗余和不壹致的需求。這樣的模型包括數據流圖、實體關系圖、狀態變換圖、對話框圖、對象類及交互作用圖。
（6）數據字典：數據字典是對系統用到的所有數據項和結構的定義，以確保開發人員使用統壹的數據定義。在需求階段，數據字典至少應定義客戶數據項，確保客戶與開發小組是使用壹致的定義和術語。
需求管理的方法主要包括以下壹些方面：
1）確定需求變更控制過程。制定壹個選擇、分析和決策需求變更的過程，所有的需求變更都需遵循此過程。
2）進行需求變更影響分析。評估每項需求變更，以確定它對項目計劃安排和其它需求的影響，明確與變更相關的任務並評估完成這些任務需要的工作量。通過這些分析將有助於需求變更控制部門做出更好的決策。
3）建立需求基準版本和需求控制版本文檔。確定需求基準，這是項目各方對需求達成壹致認識時刻的壹個快照，之後的需求變更遵循變更控制過程即可。每個版本的需求規格說明都必須是獨立說明，以避免將底稿和基準或新舊版本相混淆。
4）維護需求變更的歷史記錄。將需求變更情況寫成文檔，記錄變更日期、原因、負責人、版本號等內容，及時通知到項目開發所涉及的人員。為了盡量減少困惑、沖突、誤傳，應指定專人來負責更新需求。
5）跟蹤每項需求的狀態。可以把每壹項需求的狀態屬性（如已推薦的，已通過的，已實施的，或已驗證的）保存在數據庫中，這樣可以在任何時候得到每個狀態類的需求數量。
6）衡量需求穩定性。可以定期把需求數量和需求變更（添加、修改、刪除）數量進行比較。過多的需求變更"是壹個報警信號"，意味著問題並未真正弄清楚。
4.需求分析評價標準
（1）清晰：目前大多數的需求分析采用的仍然是自然語言，自然語言對需求分析最大的弊病就是它的二義性，所以開發人員需要對需求分析中采用的語言做某些限制。例如盡量采用主語＋動作的簡單表達方式。需求分析中的描述壹定要簡單，千萬不要采用疑問句、修飾這些復雜的表達方式。 除了語言的二義性之外，註意不要使用行話，就是計算機術語。需求分析最重要的是和用戶溝通，可是用戶多半不是計算機的專業人士，如果在需求分析中使用了行話，就會造成用戶理解上的困難。
（2）完整：需求的完整性是非常重要的，如果有遺漏需求，則不得不返工，在軟件開發過程中，最糟糕的事情莫過於在軟件開發接近完成時發現遺漏了壹項需求。但實際情況是，需求的遺漏是常發生的事情，這不僅僅是開發人員的問題，更多發生在用戶那裏。要做到需求的完整性是很艱難的壹件事情，它涉及到需求分析過程的各個方面，貫穿整個過程，從最初的需求計劃制定到最後的需求評審。
（3）壹致：壹致性是指用戶需求必須和業務需求壹致，功能需求必須和用戶需求壹致。在需求過程中，開發人員需要把壹致性關系進行細化，比如用戶需求不能超出預前指定的範圍。嚴格的遵守不同層次間的壹致性關系，就可以保證最後開發出來的軟件系統不會偏離最初的實現目標。
（4）可測試：壹個項目的測試從什麽時候開始呢？有人說是從編碼完成後開始，有人說是編碼的時候同時進行單元測試，編碼完成後進行系統測試，這些結論都不完全正確。實際上，測試是從需求分析過程就開始了，因為需求是測試計劃的輸入和參照。這就要求需求分析是可測試的，只有系統的所有需求都是可以被測試的，才能夠保證軟件始終圍繞著用戶的需要，保證軟件系統是成功的。