#### 軟件需求的層次 >軟件需求通常包括了 3 個不同的層次——業務需求、用戶需求和系統需求。此外，每個系統還有諸多各種非功能性的相關需求。 1. 業務需求（ Business requirement ） 表示組織或客戶高層次的目標。業務需求通常來自項目投資人、購買產品的客戶、實際用戶的管理者、市場營銷部門或產品策劃部門。業務需求描述了組織為什么要開發一個系統，即組織希望達到的目標。使用前景和范圍（ vision and scope ）文檔來記錄業務需求，這份文檔有時也被稱作項目輪廓圖或市場需求（ project charter 或 market requirement ）文檔。 2. 用戶需求（ user requirement ） 描述的是用戶的目標，或用戶要求系統必須能完成的任務。用例、場景描述和事件——響應表等都是用來表達用戶需求的有效途徑。也就是說用戶需求描述了`用戶能使用系統來做些什么`。 3. 系統需求（ system requirement ） 用于描述包含多個子系統的產品（即系統）的頂級需求。系統可以只包含軟件系統，也可以既包含軟件又包含硬件子系統。人也可以是系統的一部分，因此某些系統功能可能要由人來承擔。 4. 功能需求（ functional requirement ） 規定開發人員必須在產品中實現的軟件功能，用戶利用這些功能來完成任務，滿足業務需求。功能需求有時也被稱作行為需求（ behavioral requirement ），因為習慣上總是用“應該”對其進行描述：“系統應該發送電子郵件來通知用戶已接受其預定”。`功能需求實際上描述的是開發人員需要實現什么`。 #### 業務規則 業務規則（business rule） 包括企業方針、政府條例、工業標準、會計準則和計算方法等。業務規劃本身并非軟件需求，因為它們不屬于任何特定軟件系統的范圍。然而，業務規則常常會限制誰能夠執行某些特定用例，或者規定系統為符合相關規則必須實現某些特定功能。有時，功能中特定的質量屬性（通過功能實現）也源于業務規則。所以，對某些功能需求進行追溯時，會發現其來源正是一條特定的業務規則。 #### 功能需求 功能需求（ functional requirement ） 記錄在軟件需求規格說明（ SRS ）中。 SRS 完整地描述了軟件系統的預期特性。 SRS 我們一般把它當作文檔，其實， SRS 還可以是包含需求信息的數據庫或電子表格；或者是存儲在商業需求管理工具中的信息；而對于小型項目，甚至可能是一疊索引卡片。開發、測試、質量保證、項目管理和其他相關的項目功能都要用到 SRS 。 #### 非功能需求 　　除了功能需求外， SRS 中還包含非功能需求，包括`性能指標`和對`質量屬性`的描述。 　　 質量屬性（ quality attribute ） 對產品的功能描述作了補充，它從不同方面描述了產品的各種特性。這些特性包括可用性、可移植性、完整性、效率和健壯性，它們對用戶或開發人員都很重要。其他的非功能需求包括系統與外部世界的外部界面，以及對設計與實現的約束。 　　約束（ constraint ） 限制了開發人員設計和構建系統時的選擇范圍。 　　產品特性（product feature）。所謂特性（ feature ） ，是指一組邏輯上相關的功能需求，它們為用戶提供某項功能，使業務目標得以滿足。對商業軟件而言，特性則是一組能被客戶識別，并幫助他決定是否購買的需求，也就是產品說明書中用著重號標明的部分。客戶希望得到的產品特性和用戶的任務相關的需求不完全是一回事。一項特性可以包括多個用例，每個用例又要求實現多項功能需求，以便用戶能夠執行某項任務。 　　還有一項稱為可用性（ usability ）的質量屬性，它規定了業務需求中“有效”（ efficiently ）一詞的含義。 　　管理人員或市場營銷人員負責定義軟件的業務需求，以提高公司的運營效率（對信息系統而言）或產品的市場競爭力（對商業軟件而言）。所有的用戶需求都必須符合業務需求。需求分析員從用戶需求中推導出產品應具備哪些對用戶有幫助的功能。開發人員則根據功能需求和非功能需求設計解決方案，在約束條件的限制范圍內實現必需的功能，并達到規定的質量和性能指標。 #### 需求變更（requirement change） 　　當一項新的特性、用例或功能需求被提出時，需求分析員必須思考一個問題：“它在范圍之內嗎？”。如果答案是肯定的，則該需求屬于需求規格說明，反之則不屬于。但答案也許是“不在，但應該在”，這時必須由業務需求的負責人或投資管理人來決定：是否擴大項目范圍以容納新的需求。因為這是一個可能會影響項目進度和項目預算的商業決策。