軟體工程/規劃/需求管理入門
需求管理是記錄、分析、跟蹤、優先排序和達成共識的過程，然後控制變更並與相關利益相關者進行溝通。它是一個貫穿整個專案的持續過程。需求是指專案成果（產品或服務）應符合的功能或屬性。
需求管理的目的是確保組織記錄、驗證並滿足其客戶和內部或外部利益相關者的需求和期望[1]。需求管理從分析和收集組織目標和約束開始。需求管理還包括支援需求規劃，整合需求和組織以使用它們（需求屬性），以及與其他提供需求的資訊的關係，以及這些資訊的更改。
由此建立的可追溯性用於管理需求，以便根據合規性、完整性、覆蓋範圍和一致性來報告公司和利益相關者利益的實現情況。可追溯性還支援變更管理，作為需求管理的一部分，以瞭解變更對需求或其他相關元素的影響（例如，透過與功能架構的關係對功能的影響），並促進引入這些變更。[2]
需求管理涉及專案團隊成員和利益相關者之間的溝通，以及在專案進行過程中對需求變更的調整[3]。為了防止一類需求壓倒另一類需求，開發團隊成員之間的持續溝通至關重要。例如，在內部應用程式的軟體開發中，業務部門有如此強烈的需求，以至於可能會忽略使用者需求，或者認為在建立用例時，使用者需求正在得到滿足。
需求可追溯性關注的是記錄需求的生命週期。應能夠追溯到每個需求的來源，並應記錄對需求進行的每次更改，以實現可追溯性。即使在已部署和使用的已實現功能之後使用需求也應該是可追溯的[4]。
需求來自不同的來源，例如訂購產品的業務人員、營銷經理和實際使用者。這些人對產品都有不同的需求。使用需求可追溯性，可以將已實現的功能追溯到在需求收集過程中想要它的個人或團隊。例如，這可以在開發過程中用於優先考慮需求，確定需求對特定使用者的價值。它也可以在部署之後使用，當用戶研究表明功能沒有被使用時，用於瞭解為什麼首先需要它。
在開發過程的每個階段，都有關鍵的需求管理活動和方法。為了說明這一點，請考慮一個標準的五階段開發過程，包括調查、可行性、設計、構建和測試以及釋出階段。
在調查階段，從使用者、業務和開發團隊收集前三類需求。在每個領域，都會問類似的問題；目標是什麼，約束是什麼，當前有哪些工具或流程，等等。只有在充分了解這些需求後，才能開發功能需求。
這裡需要提出一個警告：無論團隊多麼努力，在專案開始時都無法完全定義需求。有些需求會發生變化，要麼是因為它們根本沒有被提取出來，要麼是因為內部或外部力量在工作中影響了專案中期。因此，團隊成員必須在開始時就同意，成功的首要條件是思維和操作的靈活性。
調查階段的交付成果是所有團隊成員都批准的需求文件。後來，在開發過程中，這份文件對於防止範圍蔓延或不必要的更改將至關重要。隨著系統的開發，每個新功能都會開啟一個充滿新可能性的世界，因此需求規範將團隊錨定在最初的願景中，並允許對範圍變更進行受控討論。
雖然許多組織仍然只使用文件來管理需求，但其他組織使用軟體工具來管理他們的需求基線。這些工具允許在資料庫中管理需求，並且通常具有自動化可追溯性的功能（例如，透過允許在父需求和子需求之間或在測試用例和需求之間建立電子連結），電子基線建立、版本控制和變更管理。通常，此類工具包含一個匯出功能，允許透過將需求資料匯出到標準文件應用程式來建立規範文件。
在可行性階段，確定需求的成本。對於使用者需求，將當前工作成本與新系統到位後的未來預計成本進行比較。會問諸如此類的問題：“現在資料輸入錯誤給我們造成了多少成本？”或者“由於當前介面操作員錯誤造成的廢品成本是多少？”事實上，對新工具的需求通常是在這些問題引起組織財務人員注意時認識到的。
業務成本將包括“哪個部門擁有此專案的預算？”“新產品在市場上的預期回報率是多少？”“如果我們開發一個新的、更易於使用的系統，在減少培訓和支援成本方面，內部回報率是多少？”
技術成本與軟體開發成本和硬體成本相關。“我們有合適的人員來建立該工具嗎？”“我們需要新的裝置來支援擴充套件的軟體角色嗎？”最後一個問題是一個重要的型別。團隊必須調查最新的自動化工具是否會增加足夠的處理能力，將部分負擔從使用者轉移到系統，以節省人員時間。
這個問題還指出了關於需求管理的一個基本要點。人和工具構成一個系統，這種認識在工具是計算機或計算機上的新應用程式時尤其重要。人類思維擅長並行處理和對資料不足的趨勢進行解釋。CPU 擅長序列處理和精確的數學計算。因此，軟體專案需求管理工作的總體目標是確保要自動化的工作被分配給合適的處理器。例如，“不要讓使用者記住她在介面中的位置。讓介面始終報告使用者在系統中的位置。”或者“不要讓使用者在兩個螢幕上輸入相同的資料。讓系統儲存資料並在需要時填寫第二個螢幕。”
可行性階段的交付成果是專案的預算和時間表。
假設成本被準確地確定，並且獲得的利益足夠大，專案就可以進入設計階段。在設計階段，主要的 需求管理活動是將設計結果與需求文件進行比較，以確保工作保持在範圍內。
再次強調，靈活性是成功的關鍵。以下是一個經典的例子，說明了在專案中期更改範圍實際上效果很好。在 20 世紀 80 年代初，福特汽車設計師預計到本世紀末汽油價格將達到每加侖 3.18 美元。在福特金牛座的設計過程中，汽油價格穩定在每加侖 1.50 美元左右。設計團隊決定，如果汽油價格保持低位，他們可以製造一輛更大、更舒適、更強大的汽車，因此他們重新設計了這款汽車。當新車上市時，金牛座的推出創下了全國銷量紀錄，主要是因為它非常寬敞，駕駛起來很舒適。
然而，在大多數情況下，偏離原始需求的程度不會奏效。因此，需求文件成為幫助團隊做出關於設計更改決策的關鍵工具。
在構建和測試階段，需求管理的主要活動是確保工作和成本保持在時間表和預算內，以及確保正在開發的工具實際上滿足了需求。此階段使用的主要工具是原型構建和迭代測試。對於軟體應用程式，可以在紙上建立使用者介面，並在構建軟體框架時與潛在使用者進行測試。將這些測試的結果記錄在使用者介面設計指南中，並在設計團隊準備開發介面時將其移交給他們。這可以節省他們的時間，並使他們的工作更容易。
需求管理不會隨著產品釋出而結束。從那時起，有關應用程式可接受性的資料將被收集起來，並輸入到下一代或版本的調查階段。因此，該過程將再次開始。
存在用於需求管理的桌面和基於 Web 的工具。基於 Web 的需求工具可以安裝在客戶的資料中心，也可以作為按需需求管理平臺提供，在某些情況下，該平臺完全免費。以前，INCOSE 維護著這些工具的清單，但他們在 2015 年放棄了它。 [5]
系統工程建模語言 SysML 包含一個需求圖，允許開發人員以圖形方式組織、管理和跟蹤需求。
按需需求管理平臺是一個完全託管的需求管理解決方案，其中唯一的系統要求通常是網際網路訪問和標準的 Web 瀏覽器。
該服務通常包括所有特殊的硬體和軟體。其他服務可能包括旨在保護您的資料免遭物理丟失和未經授權使用、24×7 資料可用性以及確保服務隨著您新增使用者、應用程式和額外活動而擴充套件的技術和流程。
一些按需需求管理平臺收取費用，而另一些平臺則免費使用。
- ↑ Stellman, Andrew; Greene, Jennifer (2005). 應用軟體專案管理. O'Reilly Media. ISBN 978-0-596-00948-9.
- ↑ "需求管理". 英國政府商務辦公室. 檢索於 2009-11-10.
- ↑ 專案管理知識體系指南 (第 4 版). 專案管理協會. 2008. ISBN 978-1-933-89051-7.
- ↑ Gotel, O., Finkelstein, A. 需求可追溯性問題分析 第一屆需求工程國際會議論文集，1994 年，第 94-101 頁
- ↑ "需求管理工具調查". 國際系統工程理事會. 存檔於 原始於 2015 年 4 月 19 日. 檢索於 2017 年 6 月 4 日.
{{cite web}}: 檢查日期值：|accessdate=(幫助)
- CMMI 產品團隊 (2006 年 8 月). "用於開發的 CMMI，版本 1.2" (PDF). 技術報告 CMU/SEI-2006-TR-008. 軟體工程研究所. 檢索於 2008-01-22.
{{cite journal}}: 引用期刊需要|journal=(幫助) - Colin Hood，Simon Wiedemann，Stefan Fichtinger，Urte Pautz *需求管理：需求開發與所有其他工程過程之間的介面* Springer，柏林 2007，ISBN 354047689X