【本篇爲《如何有效實現軟件的需求管理》第五篇，（第一篇，第二篇，第三篇，第四篇，第五篇，第六篇，第七篇，第八篇）】
好了，上面把需求處理過程的四個階段簡單介紹了一下，後面結合我們公司流程時還是會提到，不過接下來的話，畢竟是要講需求的管理，所以還是先講講這個“管理”的一些知識。
一個軟件或者硬件必然是有N多的功能組合而成的，而一般情況下每個功能其實都是來源於一個需求的，當然一個需求可能也會有很多個功能來實現的。所以對於需求的管理，我們不是在管理一個需求，而是在管理一堆需求，需求管理好了，這個產品纔有可能做得好。
所以對於需求的管理，我們必然需要有很多嚴格的要求：
1. 需求管理必須流程化：
什麼意思呢？因爲需求的管理涉及了需求從被獲取到分析到設計最後去實現這樣子一連串的過程，每個過程其實都是缺一不可的（雖然在敏捷中可能過程的概念被弱化，但是事實上最基本的管理還是有的），而且過程之間是有必然的聯繫，比如我不可能獲取了需求就去設計開發了，最後卻發現做出來的東西不是客戶需要的，這是因爲你繞過的分析的階段。
所以需求的管理對於過程的流程化很重視，需求需要嚴格按照流程來處理，每個過程最好由不同的人的來處理，並且過程之間轉換時，需要有審覈程序。
2. 需求管理必須有審覈：
其實第一條裏也提到了審覈，審覈這個程序也是非常重要的，因爲需求涉及到的這麼多過程都是需要人處理的，人處理的好壞會直接影響到這個需求的實現，獲取得不對，分析得不好，設計得不佳，開發得不行，只要有一點做得不好，都會導致這個產品失敗，所以我們需要審覈，一般情況下每一個過程都需要一次審覈，審覈失敗就重新來過，有些公司甚至有幾重審覈機制。
3. 需求管理必須歡迎變更：
“沒有不變的需求，世上的軟件都改動過3次以上，唯一一個只改動過兩次的軟件的擁有者已經死了，死在去修改需求的路上。”
現代軟件開發中，變更已經是不可缺少的一個因素了，即使你初期軟件設計得再好，總是或多或少在後期會有些需要變更的地方，增加或者減少或者改變功能點都是有可能的，所以我們必須歡迎變更，不然的話，客戶會說，你的產品太差勁，連做些修改的都不行。
雖然我們必須歡迎變更，但是我們還是需要對變更做嚴肅的處理，做軟件的人都知道，如果對於已經在開發功能做變更，會增加很多難度，不光成本上，時間上，更重要的是在質量上；如果是對於已經開發完的功能做變更，潛在問題可能更多。所以我們需要一套嚴格的機制來確保質量。
4. 需求管理必須有版本控制：
版本控制的好處是可以隨時知道以前怎麼改的，對於需求管理而言，這個是極其重要的，因爲設計啊開發啊這種工作，經常在不停地修改數據，你經常會發現我今天改錯，我想把幾天之前的數據回滾回來，或者我不知道現在這個設計有沒有問題，我想和幾天之前的數據做個比對，這些都是需要版本控制的。
查看各種版本的數據與比較各個版本的數據，這是版本控制必須具備的，很多情況下版本控制還需要具備基線（Baseline）的功能，以比較產品最初設計與最終實現的變化。
5. 需求管理必須有可跟蹤性：
所謂的可跟蹤性，說得簡單點就是這個需求自始至終所有的過程我都能跟蹤到和記錄下來，這樣的目的，
第一， 是爲了能完全管理到整個需求過程，如果整個過程中，每件事情我如果都能跟蹤到，從理論上就會保證我能Control這個需求的發展過程，我就能知道這個需求誰在做，在做什麼，什麼時候能完成，已經修改了多少次了，誰負責審覈的。。。。。。
第二， 以後很多時候，我們需要去查找以前的一些數據，這個可跟蹤性就比較重要了，比如說，這個需求完成代碼後發現嚴重與客戶的要求不符，這樣子的話，我就需要知道當初誰來負責需求獲取的，誰負責分析的，誰負責審覈的。
第三， 跟蹤和記錄下儘可能多的數據，可以使得報表能採用儘可能真實的數據，從而能真實展現現在、分析過去和預測未來。
（未完待續）