需求需求管理成熟度的五個級別

的一樣，我們都不可能一下子就精通，而是按照一種學習的曲線進展，本篇本篇主要介紹一下需求管理成熟度的六個級別。

沒有任何明確的需求被記錄下來，他們假定知道要構建什麼，希望節省需求的時間來做開發，但這勢必會給開發工作帶來混亂，因為需求是一項比較複雜的工程，並不能通過假定就可以明確軟體功能，這樣做很可能會導致所做的產品並不是使用者所需要的。

從混亂的沒有需求級別上公升一步的就是簡單的寫出需求。雖然只是簡單書寫需求，但是相對於沒有需求級別來說已經可以感受到很多好處了：

與客戶有乙個基本的約定。如果寫的好，需求能夠清晰地描述你對客戶需要的理解，他們可以通過閱讀需求來檢查是否與他們想的一致

開發團隊的每個成員通過需求可以很好的支援他們的工作。架構師和設計師可以開始考慮如何架構系統來支援客戶期望，也可以支援測試人員及早開始測試案例的編寫，當然更能支援開發人員理解軟體要求來編寫**

需求可以讓新來的成員更快速的了解系統是什麼

要得到這些好處，我們也需要付出一些成本：

需要有人花時間來寫需求

為了保證需求的及時性，需要不斷地維護需求

需求的目的是為了清晰地與使用者、客戶和其他涉眾（例如開發團隊）等人就問題的解決方案進行溝通。級別二關注需求質量、格式化、安全和儲存，以及版本管理。

可訪問性、安全性和版本管理：當存在很多需求時，我們會經常遇到不知道在**可以找到需要的需求，這時我們就需要有乙個統一管理需求地方

級別三開始對需求進行歸類，它們是功能性需求還是非功能性需求？是業務需求還是系統需求？是特性還是軟體需求？客戶、市場和使用者需求是什麼？區分這些可以幫助我們更好的理解和管理需求。之前級別都是用一些文字類語言來描述，而級別三是一種結構化需求，例如給需求新增一些屬性。

需求本身就是層級的，由業務需求到使用者需求再到系統需求；而需求又與開發和測試有所關聯，通過可跟蹤性管理，我們可以知道在更改乙個需求時，會影響到哪些子需求以及相關的同級需求，還能夠分析出影響哪些開發和測試內容。

就是通過建模來結構化需求，它的目標就是要做成能夠讓業務工程師來開發應用程式。

需求 需求管理成熟度的五個級別