由于做正確的事遠比正確的做事重要，一個軟件項目從立項開始，為確定項目的邊界，首先就是要搞清楚軟件需求，所有的工作都是圍繞著需求而展開，只有搞清楚了需求才能使項目不迷失方向。但是甲方不同層次的用戶對需求的關注點是不一樣的，越是高層的用戶，越是關注系統解決所能解決問題和痛點，在理解用戶高層次需求的時候，更應該以問題驅動，搞清楚用戶面臨的實際問題？然后在分析過程中再去思考怎么用技術手段解決他們面臨的問題。對于團隊內部，項目管理人員，需求分析人員，軟件開發人員，測試人員對需求的理解層次也有差異的，為了提高溝通效率，需采取不同的語言將需求進行不同層級的抽象。
對于開發者而言，所有軟件功能的開發都應該一一征求用戶的意見，分清楚哪些是業務需求、哪些是用戶需求、哪些是功能性需求和非功能性需求，對整個軟件的開發有著重大的指導意義；只有當開發人員對整體需求有了明確的目標后，才可以按部就班快速有效地進行功能項開發，以避免系統開發偏離需求。
按照一般的分類方法，需求有以下分類方法：
1、業務需求（Business requirement）：這個也許是項目最原始，最高級的需要。項目中大部分的操作或過程都要圍繞解決業務需求而展開。業務需求表示組織或客戶高層次的目標。業務需求通常來自項目投資人、購買產品的客戶、實際用戶的管理者、市場營銷部門或產品策劃部門。業務需求描述了組織為什么要開發一個系統，即組織希望達到的目標。使用前景和范圍（ vision and scope ）文檔來記錄業務需求，這份文檔有時也被稱作項目輪廓圖或市場需求（ project charter 或 market requirement ）文檔。
2、用戶需求（user requirement）：用戶需求描述的是用戶能使用系統來做些什么或用戶要求系統必須能完成的任務。通常用用例、場景描述和事件――響應表來進行表達。
3.干系人需求（Stakeholder requirement）：項目的干系人既可能是公司內部也可能來自甲方單位的人員，公司內部高層管理者可能為了項目的遠期愿景提出一些額外的需求，對現有需求做一些補充，這些都需要統一考慮。
4、解決方案需求（resolution requirement）：一般我會叫它為“系統需求”或“技術需求”。它是為了滿足業務需求和干系人需求，我們提供的產品、服務或成果必須具備的特性、功能和特征。解決方案可以分解為功能需求和非功能需求：
功能需求（functional requirement）：是關于產品能開展的行為。比如流程，數據，以及與產品的互動。功能需求規定開發人員必須在產品中實現的軟件功能，用戶利用這些功能來完成任務，滿足業務需求。功能需求有時也被稱作行為需求（ behavioral requirement ），因為習慣上總是用“應該”對其進行描述：“系統應該發送電子郵件來通知用戶已接受其預定”。功能需求描述是開發人員需要實現什么。
功能需求通常記錄在軟件需求規格說明（SRS）中。在軟件需求規格說明書（SRS）中說明的功能需求充分描述了軟件系統所應具有的外部行為。軟件需求規格說明在開發、測試、質量保證、項目管理以及相關項目功能中都起了重要的作用。對一個大型系統來說，軟件功能需求也許只是系統需求的一個子集，因為另外一些可能屬于子系統（或軟件部件）。
非功能需求（non-functional requirement）：是對功能需求的補充，是產品正常運行所需的環境條件或質量，從不同方面描述了產品的各種特性。比如移植性、完整性、效率，健壯性，安全性、性能、可擴張性、服務水平等。系統與外部世界的外部界面，以及對設計與實現的約束。
約束（constraint）：限制了開發人員設計和構建系統時的選擇范圍，如局限于軟件工程學科。
一個具體的例子：
業務需求：“用戶能有效地糾正文檔中的拼寫錯誤”，該產品的包裝盒封面上可能會標明這是個滿足業務需求的拼寫檢查器。
用戶需求：可能是“找出文檔中的拼寫錯誤并通過一個提供的替換項列表來供選擇替換拼錯的詞”。同時，該拼寫檢查器還有許多功能需求，如找到并高亮度提示錯詞的操作；顯示提供替換詞的對話框以及實現整個文檔范圍的替換。
功能需求：可能包括以下幾個部分，錯誤定義，錯誤查找，錯誤發現，錯誤高亮，錯誤列表顯示，錯誤替換等。
