軟件需求包括3個不同的層次――業務需求、用戶需求和功能需求。除此之外，每個系統還有各種非功能需求。
業務需求（Business requirement）表示組織或客戶高層次的目標。 業務需求通常來自項目投資人、購買產品的客戶、實際用戶的管理者、市場營銷部門或產品策劃部門。業務需求描述了組織為什麽要開發一個系統，即組織希望達到 的目標。使用前景和範圍（vision and scope）文檔來記錄業務需求，這份文檔有時也被稱作項目輪廓圖或市場需求（project charter 或 market requirement）文檔。
用戶需求（user requirement）描述的是用戶的目標，或用戶要求系統必須能完成的任務

業務規則包括企業方針、政府條例、工業標準、會計準則和計算方法等。 業務規劃本身並非軟件需求，因為它們不屬於任何特定軟件系統的範圍。然而，業務規則常常會限制誰能夠執行某些特定用例，或者規定系統為符合相關規則必須實 現某些特定功能。有時，功能中特定的質量屬性（通過功能實現）也源於業務規則。所以，對某些功能需求進行追溯時，會發現其來源正是一條特定的業務規則。
功 能需求記錄在軟件需求規格說明（SRS）中。SRS完整地描述了軟件系統的預期特性。SRS我們一般把它當作文檔，其實，SRS還可以是包含需求信息的數 據庫或電子表格；或者是存儲在商業需求管理工具中的信息；而對於小型項目，甚至可能是一疊索引卡片。開發、測試、質量保證、項目管理和其他相關的項目功能 都要用到 SRS。
除了功能需求外，SRS中還包含非功能需求，包括性能指標和對質量屬性的描述。

質量屬性（quality attribute）對產品的功能描述作了補充，它從不同方面描述了產品的各種特性。這些特性包括可用性、可移植性、完整性、效率和健壯性，它們對用戶或開發人員都很重要。其他的非功能需求包括系統與外部世界的外部界面，以及對設計與實現的約束。
約束（constraint）限制了開發人員設計和構建系統時的選擇範圍。
產 品特性。所謂特性（feature），是指一組邏輯上相關的功能需求，它們為用戶提供某項功能，使業務目標得以滿足。對商業軟件而言，特性則是一組能被客 戶識別，並幫助他決定是否購買的需求，也就是產品說明書中用著重號標明的部分。客戶希望得到的產品特性和用戶的任務相關的需求不完全是一回事。一項特性可 以包括多個用例，每個用例又要求實現多項功能需求，以便用戶能夠執行某項任務。
還有一項稱為可用性（usability）的質量屬性，它規定了業務需求中“有效”（efficiently）一詞的含義。
管 理人員或市場營銷人員負責定義軟件的業務需求，以提高公司的運營效率（對信息系統而言）或產品的市場競爭力（對商業軟件而言）。所有的用戶需求都必須符合 業務需求。需求分析員從用戶需求中推導出產品應具備哪些對用戶有幫助的功能。開發人員則根據功能需求和非功能需求設計解決方案，在約束條件的限制範圍內實 現必需的功能，並達到規定的質量和性能指標。
當 一項新的特性、用例或功能需求被提出時，需求分析員必須思考一個問題：“它在範圍內嗎？”。如果答案是肯定的，則該需求屬於需求規格說明，反之則不屬於。 但答案也許是“不在，但應該在”，這時必須由業務需求的負責人或投資管理人來決定：是否擴大項目範圍以容納新的需求。這是一個可能影響項目進度和預算的商 業決策。
不屬於需求的內容
需 求規格說明中不包括（除已知約束外的）設計和實現的細節、項目的計劃信息，以及測試信息（Leffingwell 和 Widrig 2000）。把這些內容與需求分開，就可以把需求活動的註意力集中到了解開發小組需要開發的產品特性上。項目中通常還包括其他類型的需求，如開發環境需 求，進度或預算限制，幫助新用戶跟上進度的培訓需求，或者發布產品使其轉入支持環境的需求。這些都屬於項目需求而不是產品需求，因此不屬於軟件需求的討論 範圍。

舉例如下：

業務需求一般是我由我們 軟件開發人員來搜集的，是企業自身在顧問等引導下自己所作的工作。我們只是去從他們那裏直接的拿來就可以了。比如為了配合企業生產改造，為了加強庫存管 理，為了建立企業電子化運行平臺，這些都是業務需求。這些東西的建模還是留給咨詢顧問吧，我們沒有拿那份企業流程重組的錢，也就不用費這個力氣。
用戶需求是用戶為實現其業務需求而提出的基於實際情況的具體目標。比如我的系統要可以查看庫存中的零件數量，我需要可以由計算機給出投料方案，計算工資總額。
功能需求就是要去解決這些具體的用戶需求所產生的解決方案。這個就是我們平常說的需求說明。要得到這個就需要對用戶需求作具體的分析，提出具體的實施方法。

業務需求、用戶需求和功能需求