繼續根據上一篇的軟體業務價值流圖來學習總結，本篇我們關注價值流圖的最開端也是最基礎的環節：需求管理。

需求 - - 開發模式 - - 變更 - - - 版本控制 - - -  環境管理 - - - 持續部署 - - - 監控反饋

                                   |                                                    |

                                   - - - 持續整合 - - - 自動化測試 - - -

需求管理屬於產品管理領域，是整個持續交付過程的起始點。它的目標是將IT產品的特性和需求以合理的層級結構來劃分，並依託特定系統來承載和維護，確保每一條需求都能夠清晰的指導後續開發過程形成最終的價值，並且整個需求的生命週期有記錄可追溯。清晰良好的需求管理檢視是頻繁迭代的基礎和保障，能夠明確每個迭代的計劃範圍和驗收標準。

首先宣告需求管理中的常用概念：“功能”、“特性” 和 “需求” 。

“功能”  function：是從公眾角度對IT產品進行的通俗描述，可常見於產品宣傳、資料手冊中，不能直接指導研發過程（非技術語言）；

“特性”  feature：是從專業角度對IT產品進行的技術闡述，通常與產品軟體的模組架構相呼應，可形成設計文件指導研發過程；一般可劃分為“特性域”和“特性”兩個層級；特性的結構設計需要對產品的軟體架構有深入的認識和掌握；

“需求”  requirement：是從管理角度對功能/特性的變化進行承載和細化跟蹤；可以視為變更流程的一種，可對應到實際軟體程式碼和測試用例的變更；一般可劃分為“原始需求”、“系統需求”兩類，分別對應“功能”、“特性”的變更（分配需求或story則屬於特性變更的細化子項）；

在將IT產品的功能轉化為合理層級結構的特性和需求後，就可以將這些特性和需求資訊錄入相關係統（Jira或專業的需求管理系統），並與研發的版本控制庫對接，使每一條需求都能和對應的程式碼/用例關聯起來。

然後我們描述一下需求管理的基本流程：

從市場或內部收集對IT產品功能的意見，形成原始需求 ==》產品架構師對原始需求進行評審和解讀，按照特性的維度分解為相應的系統需求並掛靠至對應特性下面 ==》按照敏捷的迭代週期對未完成的系統需求進行計劃制定，並分解為相應的分配需求或story ==》分配需求或story指定相應的開發owner進行開發測試，並完成程式碼和用例的更新 ==》sprint結束時完成本輪版本的驗證，關閉相關分配需求或story，然後關閉對應系統需求並更新對應特性資訊。

有了基本的需求管理框架後，就應考慮具體的開發模式，此處在敏捷理論中已經討論得比較詳細，所以僅摘抄幾點關鍵部分：

sprint需求規劃 ==》特性驅動測試 ==》測試驅動開發 ==》結對程式設計 ==》開發測試融合 ==》 站會+看板 ==》 頻繁迭代

最後提一下變更管理。軟體研發的過程其實就是變更的過程，變更管理可分為 需求變更管理和缺陷變更管理兩類，分別對應特性和bug的管理。 需求變更管理一般與承載特性和需求資訊的系統一體，注重變更請求的稽核和影響領域的跟蹤，保障變更全生命週期可追溯。與變更管理緊密相關的就是版本控制技術，下一篇我們繼續總結版本控制和環境管理部分。