新產品開發及流程優化中的需求（Requirement），是用單一檔案說明，特定設計、產品或是流程要滿足的目標。此一詞語常用在工程設計（例如系統工程、軟體工程或企業工程）的正式說明中。需求是廣義的概念，可以指必要的（或是想要有的）機能、屬性、能力、特徵、或是系統的品質，而這些特性是對客戶、組織、內部使用者及利害相關者有價值，有效用的。
需求可能有不同的特定性層次。例如需求規格（requirement specification，也可能會簡稱為 requirement spec）是指特定材料、設計、產品或服務需要符合，明確且高度清晣的一個（或多個）需求。

需求可以做為新產品開發時，設計階段的輸入。需求也是驗證及確認階段的重要輸入，每一個測試應該要可以追溯到特定的需求。需求可以看出在特定專案中，需要哪些元件或是功能。若是用迭代式開發或敏捷軟體開發進行開發，系統需求會在設計及實現的過程中，漸進式的增加。若是用瀑布模型進行開發，會在設計以及實現之前就確定需求。



起源

自 1960 年代開始，需求（requirement）一詞已開始使用在軟體工程的群體之中。

依照 IIBA（國際商業分析協會）BABOK（商業分析知識體系）第 2 版，需求是：

1. 利益相關者要解決問題或是達到某一目標，需要有的條件或是能力
2. 為了滿足合約、標準、規格或是其他正式檔案，其解決方案或是其中元件需要符合旳條件或能力
3. 有關 (1) 或 (2) 所述的條件或能力的檔案

此定義是以 IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology 為基礎
。



產品需求及流程需求

需求可以分為以下兩種：


* 產品需求：描述產品或系統的特性。

* 流程需求：描述開發團隊所進行的活動。例如，流程需求可能會列出團隊需依循的方法論，以及團隊需遵守的規定。

產品需求和流程需求可以設計成有緊密的相關性。例如產品需求可以要求自動化，以支援某一流程需求。而流程需求也可以標示為了某產品需求而需進行的活動。例如：在開發成本上的需求（流程需求）是為了達到售價上的需求（產品需求），而產品要可以維護的需求（產品需求）會透過在開發時用特定的開發模式（例如物件導向程式設計）、模式指南，代碼評審，或流程需求檢查來支援（流程需求）



需求種類

需求可以依開發進行的不同階段來分類，其術語也會依開發用的整體模型而定。以下的框架是由 IIBA 在其 BABOK 檔案中所提的內容（也可以參考 FURPS 及需求分析條目）

架構需求
: 系統架構相關的需求可以說明在識別系統架構整合，以及系統行為時，需要完成的內容。

　
: 在軟體工程中，會將此需求稱為架構重要需求，定義為：對軟體架構有可衡量影響的的需求。

業務需求
: 業務需求是對組織目標、目的或需求的高階敘述。一般是指組織希望實現的機會，或是希望解決的問題。會用業務案例來描述。

使用者（利益相關者）需求
: 使用者（利益相關者）需求是中階的描述某個特定利益相關者（或是某個群體）的需求，一般會描述某人需要和特定的解決方案以哪一種形式互動。這會是高階業務需求和詳細解決方案需求之間的媒介，會寫在使用者需求檔案中。

功能需求
: 功能需求一般會列出解決方案需要有的能力、行為或是資訊。例如文字格式化、計算數字、訊號調變等。有時也會稱為是「能力」（capabilities）

服務品質需求
: 服務品質需求屬於非功能性需求，一般會詳細列出解決方案在什麼情形下需維持有效、解決方案需要有的品質、或是其運作時的限制。例如：可靠度（Reliability）、可測試（testability）、可維護（maintainability）、可用性（availability）。這些常稱為「特性」、「限制」，因許多這類詞語的結尾是 ility，也會稱為 ilities。

實施需求
: 實施需求會列出為了讓企業從目前狀態到想要的理想狀態，需要有的能力或是行為，企業到理想狀態後就不需要了。例如招募人員、角色調整、資料由一系統轉換到另一系統等。

法規需求
: 法規需求是指定義在法律（聯邦法或國家法律、州法、縣市法令、區域性法令）、契約（條款及條件）或政策（公司、部門、或是專案層級的政策）中的需求。



良好需求的特點

有許多不同的研究者提出了良好需求的特點，每個研究者都會強調其特點是特別適用在所探討的領域中。一般而言，良好需求會有以下的特點。

還有許多和需求品質相關的屬性。若需求受到資料完整性規格的約束，則準確性／正確性及有效／有授權也是重要的屬性。追溯性可以確認需求是否滿足系統所需，不多不少。

除了上述的屬性外，有些研究者會加上外部可觀察性（Externally Observable），也就是此需求所描述的特徵需要是外界可以觀察到，或是客戶可以感受到的。有些人認為說明內部架構、設計、實現或測試決策之類的需求可能要列為系統的限制，而且需明確的列在需求檔案的限制章節。反對此作法的人認為，此觀點有兩處有問題。第一，此觀點沒有識別到，客戶體驗可能是被一些客戶感受不到的需求所支援。例如，一個顯示位址編碼資訊的功能可能是被第三方商業夥伴的介面需求所支援。使用者感受不到此一介面，但可以感受到從此一介面產生資訊的呈現。第二，限制會讓設計的選擇性變小，而需求是定義設計的特徵。若繼續考慮剛剛的例子，選擇網頁介面的需求和為了要和單一登入架構相容，在設計選項上的限制是不同的。

驗證

需求應該有驗證的方式。最常見的方式是測試，若無法測試，需要有其他的驗證方式（例如分析、展示、檢測，或是設計評審等方式）。

有些需求有特殊性，無法完整驗證。例如像系統不能有特定性質，或是一定要有特性性質。這類需求若要測試，其測試量會是無限多的。這類的需求需要改寫為可以驗證的需求，上述的所有需求都要是可以驗證的。

無法在軟體層級上驗證的非功能需求，需要保留作為客戶期望的檔案。不過這類需求可以追溯到流程需求，可以判定是否有特別的方式可以滿足此一需求。例如有一個非機能需求是軟體不得有後門，此一需求可以用使用結對編程來開發軟體的流程需求來取代。其他的非功能需求也可以追溯到其他的系統元素，可以在系統層級進行驗證。例如系統可靠度可以用系統層級的分析來驗證。飛航軟體以及其複雜的安全需求必需遵守 DO-178B 開發流程進行。

有些活動會讓系統需求或是軟體需求出現變化。需求工程中會包括專案的可行性研究或概念分析階段、需求取得（蒐集、理解、審核並及銜接利益相關者的需求）以及需求分析、確認需求的一致性及完整性、將需求轉換為規格檔案、再確認所列需求的正確性。

需求常會有模糊不清、不完整以及不一致的問題。有些技術可以處理這類的問題，例如嚴謹的軟體檢測。模糊不清、不完整以及不一致的問題若在需求階段就可以處理，所花的成本會遠低於比產品開發階段才處理的成本。需求分析致力要處理這類的問題。

需求是否過於模糊，或是太過詳細，其中有些工程上的取捨，取捨標準如下

1. 是否會花很長時間才能完成，有時當產品完成時，已經過了時機，沒有價值了
2. 限制了實現時可選擇的空間
3. 製作的成本太高

敏捷軟體開發視為是一種克服上述問題的方式，在較高的階層上訂定需求的基準，以及時或 「最後責任時刻」的基礎上說明細節。



需求的檔案化

需求一般會寫作檔案，做為不同的利益相關者溝通的媒介。因此不論對於一般使用者或是開發人員，需求都要是可以輕鬆理解的。有一種常見將需求檔案化的作法，是列出系統應該做的事。例如 「承包商需要在 X 月 X 日前交付產品」。其他檔案化的方式有用例及使用者故事。



需求的變更

需求常會因為時間而變化。只要定義並且核准了需求，要再更改需要經過變更控制。有許多專案的需求會在系統完成前就變更。部份原因是因為電腦軟體的複雜性，另外，客戶在看到實體之前，不一定知道他們真正的需求。這些有關需求的特徵，也衍生了需求管理的研究以及實務。



問題

多重標準

有關對於需求的觀點，以及要如何管理，有許多不同的觀點。此一產業主要的二個領導組織是 IEEE 及 IIBA。雙方對於需求都有定義，兩者相近，但仍有些差異。

有關軟體需求是否有必要，以及其效果的爭議

許多成功的專案其實沒有什麼需求，或是在需求上沒有共識，有些證據指出指定需求反向會降低創造力以及設計的效能。需求會讓設計者過度受限在提供的資訊中，因此會影響創意及設計。有些研究指出：在沒有明顯實際需求的情形下，軟體需求是種將設計決策誤以為是因為需求而產生的錯覺。

而大部份的敏捷軟體開發方法論質疑事先嚴謹描述軟體需求的必要性，敏捷軟體開發者認為需求是一個會變動的目標。例如，極限編程會用使用者故事（索引卡上的簡單摘要，說明系統在某一層面下要作的事），用非正式的文字來描述需求，認為開發者有責任直接問客戶，澄清相關的疑問。敏捷軟體方法論試圖用一連串的自動驗收測試來捕捉需求。

需求蔓延

隨著時間，需求也會有範圍蔓延，日漸增加的情形。在需求管理中允許需求的更動，但若沒有適當的追蹤或是相關前置步驟（業務目標以及客戶需求）沒有受到額外的管控，考慮其成本以及潛在專案失敗旳風險，需求變更就很可能會出現，而且很容易出現。常常需求的變化比開發者所可以產出的速度還快，因此專案產出的成果最後無法符合新的需求。

多重需求分類法

有關需求的分類，會視使用的框架不同，有不同的分類法（例如 IEEE、IIBA 或美國國防部的作法）。在不同的場合中，使用語言及流程的不同，可能會造成誤解，並且偏離理想流程。

流程的破壞

人所進行的流程會受到人為管理缺陷所影響，可能因為便宜行事、慾望或是其他政治因素而讓流程異常，甚至完全偏離程式，和敎科書上所描述的標準流程完全不同。以下是一些流程腐化的例子。


* 沒有嚴格的遵守流程，因此流程不受尊重：若流程中出現太多的例外或是變更（原因可能因為進行流程的組織其獨立性或權力不足，或是紀錄上的可靠性及透明度不足），可能會造成整個流程被忽視。

* 新參與者希望改變舊流程：新參與者的自然傾向會想要變更原有的工作，展示其權力或是表明其價值，例如新的 CEO 會想要改變前任 CEO 的計劃，例如商業目標、一些已經在開發的專案（例如軟體解決方案）等，因此他們開始加入新的內容，使專案重新訂定基準。

* 在規則以外的作為：參與者不想只做專案管理定義上，依使用者需求或是依優先順序排序的事，而插入一些特定單位提出，設計細節的調整，或是一些接近特定使用者需求的特徵調整，實質上，這些需求有最高的優先順序。

* 太晚參與：在開發前的需求獲取階段中，參與者作的太少或是沒有效果。這可能是因為認為就算沒有實際的參與，還是可以得到相同的好處。或是其習慣是在測試階段或是下一次改版再插入其需求，或是其習慣作法是等工作完成後再批評其成果。



相關條目


* 商業需求

* 軟體需求

* 需求工程

* 需求分析

* 需求取得

* 需求管理

* 需求優先順序

* 需求可追蹤性

* 規格化

* Shall 和 will

* MoSCoW 法則：排定優先順序的技術

* 使用者故事

* 用例



參考資料



外部連結


* _Discovering System Requirements_ （頁面存檔備份，存於網際網路檔案館）