需求 (產品開發)
新產品開發及流程優化中的需求（Requirement），是用單一檔案說明，特定設計、產品或是流程要滿足的目標。此一詞語常用在工程設計（例如系統工程、軟件工程或企業工程）的正式說明中。需求是廣義的概念，可以指必要的（或是想要有的）機能、屬性、能力、特徵、或是系統的質素，而這些特性是對客戶、組織、內部用戶及利害相關者有價值，有效用的。 需求可能有不同的特定性層次。例如需求規格（requirement specification，也可能會簡稱為requirement spec）是指特定材料、設計、產品或服務需要符合，明確且高度清晣的一個（或多個）需求[1]。
需求可以做為新產品開發時，設計階段的輸入。需求也是驗證及確認階段的重要輸入，每一個測試應該要可以追溯到特定的需求。需求可以看出在特定專案中，需要哪些元件或是功能。若是用迭代式開發或敏捷軟件開發進行開發，系統需求會在設計及實現的過程中，漸進式的增加。若是用瀑布模型進行開發，會在設計以及實現之前就確定需求。
起源
[編輯]自1960年代開始，需求（requirement）一詞已開始使用在軟件工程的群體之中[2]。
依照IIBA（國際商業分析協會）BABOK（商業分析知識體系）第2版[3]，需求是：
- 利益相關者要解決問題或是達到某一目標，需要有的條件或是能力
- 為了滿足合約、標準、規格或是其他正式檔案，其解決方案或是其中元件需要符合旳條件或能力
- 有關(1)或(2)所述的條件或能力的檔案
此定義是以IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology為基礎 [4]。
產品需求及流程需求
[編輯]需求可以分為以下兩種：
- 產品需求：描述產品或系統的特性。
- 流程需求：描述開發團隊所進行的活動。例如，流程需求可能會列出團隊需依循的方法論，以及團隊需遵守的規定。
產品需求和流程需求可以設計成有緊密的相關性。例如產品需求可以要求自動化，以支援某一流程需求。而流程需求也可以標示為了某產品需求而需進行的活動。例如：在開發成本上的需求（流程需求）是為了達到售價上的需求（產品需求），而產品要可以維護的需求（產品需求）會透過在開發時用特定的開發模式（例如物件導向程式設計）、模式指南，代碼評審，或流程需求檢查來支援（流程需求）
需求種類
[編輯]需求可以依開發進行的不同階段來分類，其術語也會依開發用的整體模型而定。以下的框架是由IIBA在其BABOK檔案中所提的內容[5]（也可以參考FURPS及需求分析條目）
- 用戶（利益相關者）需求
- 用戶（利益相關者）需求是中階的描述某個特定利益相關者（或是某個群體）的需求，一般會描述某人需要和特定的解決方案以哪一種形式互動。這會是高階業務需求和詳細解決方案需求之間的媒介，會寫在用戶需求檔案中。
- 功能需求
- 功能需求一般會列出解決方案需要有的能力、行為或是資訊。例如文字格式化、計算數字、訊號調變等。有時也會稱為是「能力」（capabilities）
- 服務質素需求
- 服務質素需求屬於非功能性需求，一般會詳細列出解決方案在什麼情形下需維持有效、解決方案需要有的質素、或是其運作時的限制[7]。例如：可靠度（Reliability）、可測試（testability）、可維護（maintainability）、可用性（availability）。這些常稱為「特性」、「限制」，因許多這類詞語的結尾是ility，也會稱為ilities。
- 實施需求
- 實施需求會列出為了讓企業從目前狀態到想要的理想狀態，需要有的能力或是行為，企業到理想狀態後就不需要了。例如招募人員、角色調整、資料由一系統轉換到另一系統等。
良好需求的特點
[編輯]有許多不同的研究者提出了良好需求的特點，每個研究者都會強調其特點是特別適用在所探討的領域中。一般而言，良好需求會有以下的特點[8] [9]。
| 特點 | 說明 |
|---|---|
| 單一性（內聚性） | 需求只敘述一件事，不多不少。 |
| 完整性 | 完整的敘述需求，沒有遺漏的資訊 |
| 一致性 | 需求不會和其他的需求衝突，和權威的外部檔案完全一致 |
| 原子性 | 需求的原子性是指其中沒有連接詞。例如「郵遞區號需要符合美國郵遞區號及加拿大郵遞區號」，應該寫成二個獨立的需求：「郵遞區號需要符合美國郵遞區號」以及「郵遞區號需要符合加拿大郵遞區號」。 |
| 可追蹤性 | 需求需符合所有利益相關者以及權威檔案的商業需要 |
| 即時 | 需求需隨着時間更新，沒有過時的資訊 |
| 無歧義 | 需求需要精準描述，不使用行話、首字母縮略字（若要使用，需在需求檔案中提到），也不要使用深奧的言語。需求需要是客觀的事實，不是主觀的意見。需求只能有一種解釋。要避免含糊的主語、形容詞、介詞、動詞和詞語。要避免負面敘述，也不要有複合敘述。 |
| 標示重要性 | 有些需求是由利益相關者所定義的必需特徵，若沒有這些特徵，產品會有大幅（甚至致命）的缺陷。有些需求則是在時間或預算允許下，希望可以加入的特徵。需求需要標示其重要性。 |
| 可驗證 | 需求的實現需要可用以下的基本方式確認：檢查、展示、（配合裝置）測試、或是（用確認過的模型或是模擬）分析 |
還有許多和需求質素相關的屬性。若需求受到數據完整性規格的約束，則準確性／正確性及有效／有授權也是重要的屬性。追溯性可以確認需求是否滿足系統所需，不多不少。
除了上述的屬性外，有些研究者會加上外部可觀察性（Externally Observable），也就是此需求所描述的特徵需要是外界可以觀察到，或是客戶可以感受到的。有些人認為說明內部架構、設計、實現或測試決策之類的需求可能要列為系統的限制，而且需明確的列在需求檔案的限制章節。反對此作法的人認為，此觀點有兩處有問題。第一，此觀點沒有識別到，客戶體驗可能是被一些客戶感受不到的需求所支援。例如，一個顯示地址編碼資訊的功能可能是被第三方商業夥伴的介面需求所支援。用戶感受不到此一介面，但可以感受到從此一介面產生資訊的呈現。第二，限制會讓設計的選擇性變小，而需求是定義設計的特徵。若繼續考慮剛剛的例子，選擇網頁介面的需求和為了要和單一登入架構相容，在設計選項上的限制是不同的。
驗證
[編輯]需求應該有驗證的方式。最常見的方式是測試，若無法測試，需要有其他的驗證方式（例如分析、展示、檢測，或是設計評審等方式）。
有些需求有特殊性，無法完整驗證。例如像系統不能有特定性質，或是一定要有特性性質。這類需求若要測試，其測試量會是無限多的。這類的需求需要改寫為可以驗證的需求，上述的所有需求都要是可以驗證的。
無法在軟件層級上驗證的非功能需求，需要保留作為客戶期望的檔案。不過這類需求可以追溯到流程需求，可以判定是否有特別的方式可以滿足此一需求。例如有一個非機能需求是軟件不得有後門，此一需求可以用使用結對編程來開發軟件的流程需求來取代。其他的非功能需求也可以追溯到其他的系統元素，可以在系統層級進行驗證。例如系統可靠度可以用系統層級的分析來驗證。飛航軟件以及其複雜的安全需求必需遵守DO-178B開發流程進行。
有些活動會讓系統需求或是軟件需求出現變化。需求工程中會包括專案的可行性研究或概念分析階段、需求取得（蒐集、理解、審核並及銜接利益相關者的需求）以及需求分析[10]、確認需求的一致性及完整性、將需求轉換為規格檔案、再確認所列需求的正確性[11][12]。
需求常會有模糊不清、不完整以及不一致的問題。有些技術可以處理這類的問題，例如嚴謹的軟件檢測。模糊不清、不完整以及不一致的問題若在需求階段就可以處理，所花的成本會遠低於比產品開發階段才處理的成本。需求分析致力要處理這類的問題。
需求是否過於模糊，或是太過詳細，其中有些工程上的取捨，取捨標準如下
- 是否會花很長時間才能完成，有時當產品完成時，已經過了時機，沒有價值了
- 限制了實現時可選擇的空間
- 製作的成本太高
敏捷軟件開發視為是一種克服上述問題的方式，在較高的階層上訂定需求的基準，以及時或 「最後責任時刻」的基礎上說明細節。
需求的檔案化
[編輯]需求一般會寫作檔案，做為不同的利益相關者溝通的媒介。因此不論對於一般用戶或是開發人員，需求都要是可以輕鬆理解的。有一種常見將需求檔案化的作法，是列出系統應該做的事。例如 「承包商需要在X月X日前交付產品」。其他檔案化的方式有用例及用戶故事。
需求的變更
[編輯]需求常會因為時間而變化。只要定義並且核准了需求，要再更改需要經過變更控制。有許多專案的需求會在系統完成前就變更。部份原因是因為電腦軟件的複雜性，另外，客戶在看到實體之前，不一定知道他們真正的需求。這些有關需求的特徵，也衍生了需求管理的研究以及實務。
問題
[編輯]多重標準
[編輯]有關對於需求的觀點，以及要如何管理，有許多不同的觀點。此一產業主要的二個領導組織是IEEE及IIBA。雙方對於需求都有定義，兩者相近，但仍有些差異。
有關軟件需求是否有必要，以及其效果的爭議
[編輯]許多成功的專案其實沒有什麼需求，或是在需求上沒有共識[13]，有些證據指出指定需求反向會降低創造力以及設計的效能[14]。需求會讓設計者過度受限在提供的資訊中，因此會影響創意及設計[15][16][17]。有些研究指出：在沒有明顯實際需求的情形下，軟件需求是種將設計決策誤以為是因為需求而產生的錯覺[18]。
而大部份的敏捷軟件開發方法論質疑事先嚴謹描述軟件需求的必要性，敏捷軟件開發者認為需求是一個會變動的目標。例如，極限編程會用用戶故事（索引卡上的簡單摘要，說明系統在某一層面下要作的事），用非正式的文字來描述需求，認為開發者有責任直接問客戶，澄清相關的疑問。敏捷軟件方法論試圖用一連串的自動驗收測試來捕捉需求。
需求蔓延
[編輯]隨着時間，需求也會有範圍蔓延，日漸增加的情形。在需求管理中允許需求的更動，但若沒有適當的追蹤或是相關前置步驟（業務目標以及客戶需求）沒有受到額外的管控，考慮其成本以及潛在專案失敗旳風險，需求變更就很可能會出現，而且很容易出現。常常需求的變化比開發者所可以產出的速度還快，因此專案產出的成果最後無法符合新的需求。
多重需求分類法
[編輯]有關需求的分類，會視使用的框架不同，有不同的分類法（例如IEEE、IIBA或美國國防部的作法）。在不同的場合中，使用語言及流程的不同，可能會造成誤解，並且偏離理想流程。
流程的破壞
[編輯]人所進行的流程會受到人為管理缺陷所影響，可能因為便宜行事、慾望或是其他政治因素而讓流程異常，甚至完全偏離程式，和敎科書上所描述的標準流程完全不同。以下是一些流程腐化的例子。
- 沒有嚴格的遵守流程，因此流程不受尊重：若流程中出現太多的例外或是變更（原因可能因為進行流程的組織其獨立性或權力不足，或是紀錄上的可靠性及透明度不足），可能會造成整個流程被忽視。
- 新參與者希望改變舊流程：新參與者的自然傾向會想要變更原有的工作，展示其權力或是表明其價值，例如新的CEO會想要改變前任CEO的計劃，例如商業目標、一些已經在開發的專案（例如軟件解決方案）等，因此他們開始加入新的內容，使專案重新訂定基準。
- 在規則以外的作為：參與者不想只做專案管理定義上，依用戶需求或是依優先順序排序的事，而插入一些特定單位提出，設計細節的調整，或是一些接近特定用戶需求的特徵調整，實質上，這些需求有最高的優先順序。
- 太晚參與：在開發前的需求獲取階段中，參與者作的太少或是沒有效果。這可能是因為認為就算沒有實際的參與，還是可以得到相同的好處。或是其習慣是在測試階段或是下一次改版再插入其需求，或是其習慣作法是等工作完成後再批評其成果。
相關條目
[編輯]參考資料
[編輯]- ^ Form and Style of Standards, ASTM Blue Book (PDF). 美國材料和試驗協會. 2012 [5 January 2013]. （原始內容 (PDF)存檔於2015-11-06）.
- ^ Boehm, Barry. A view of 20th and 21st century software engineering. ICSE '06 Proceedings of the 28th international conference on Software engineering. University of Southern California, University Park Campus, Los Angeles, CA: Association for Computing Machinery, ACM New York, NY, USA: 12–29. 2006 [January 2, 2013]. ISBN 1-59593-375-1.
- ^ 1.3 Key Concepts - IIBA | International Institute of Business Analysis. www.iiba.org. [2016-09-25]. （原始內容存檔於2017-07-24）.
- ^ IEEE SA - 610.12-1990 - IEEE Standard Glossary of Software Engineering Terminology. [2020-12-16]. （原始內容存檔於2018-06-15）.
- ^ Iiba; Analysis, International Institute of Business. A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 2.0. 2009 [2022-07-29]. ISBN 978-0-9811292-1-1. （原始內容存檔於2021-05-20）.
- ^ Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar. Characterizing Architecturally Significant Requirements. IEEE Software. 2013, 30 (2): 38–45. S2CID 17399565. doi:10.1109/MS.2012.174. hdl:10344/3061
.
- ^ Ralph, P., and Wand, Y. A Proposal for a Formal Definition of the Design Concept. In, Lyytinen, K., Loucopoulos, P., Mylopoulos, J., and Robinson, W., (eds.), Design Requirements Engineering: A Ten-Year Perspective: Springer-Verlag, 2009, pp. 103-136
- ^ Davis, Alan M. Software Requirements: Objects, Functions, and States, Second Edition. Prentice Hall. 1993. ISBN 978-0-13-805763-3.
- ^ IEEE Computer Society. IEEE Recommended Practice for Software Requirements Specifications. Institute of Electrical and Electronics Engineers, Inc. 1998. ISBN 978-0-7381-0332-7.
- ^ Stellman, Andrew; Greene, Jennifer. Applied Software Project Management. O'Reilly Media. 2005: 98. ISBN 978-0-596-00948-9. （原始內容存檔於2015-02-09）.
- ^ Wiegers, Karl E. Software Requirements, Second Edition. Microsoft Press. 2003. ISBN 978-0-7356-1879-4.
- ^ Young, Ralph R. Effective Requirements Practices. Addison-Wesley. 2001. ISBN 978-0-201-70912-4.
- ^ Checkland, Peter. Systems Thinking, Systems Practice. Chichester: Wiley. 1999.
- ^ Ralph, Paul; Mohanani, Rahul. Is Requirements Engineering Inherently Counterproductive?. Proceedings of the 5th International Workshop on the Twin Peaks of Requirements and Architecture. Florence, Italy: IEEE: 20–23. May 2015.
- ^ Jansson, D.; Smith, S. Design fixation. Design Studies. 1991, 12 (1): 3–11. doi:10.1016/0142-694X(91)90003-F.
- ^ Purcell, A.; Gero, J. Design and other types of fixation. Design Studies. 1996, 17 (4): 363–383. doi:10.1016/S0142-694X(96)00023-3.
- ^ Mohanani, Rahul; Ralph, Paul; Shreeve, Ben. Requirements Fixation. Proceedings of the International Conference on Software Engineering. Hyderabad, India: IEEE: 895–906. May 2014.
- ^ Ralph, Paul. The Illusion of Requirements in Software Development. Requirements Engineering. 2012, 18 (3): 293–296. S2CID 11499083. arXiv:1304.0116 . doi:10.1007/s00766-012-0161-4.
