人是會死的，需求是會變的。相信大家都經歷了很多需求變更的痛苦，專案被拖延，成本高漲，十有七八是需求管理沒有做好導致的。有哪一些需求管理方面的常見問題呢，這裡列舉一下：
1.因為專案進度趕等原因，在很多需求還沒有明確情況下，便開始開發的工作。
2.開始客戶只能提出模糊的需求，客戶喜歡先讓你做個東西給他看，然後他才可能逐漸提出真正的需求，而需求調研人員，對此沒有什麼好的處理辦法。
3.客戶以種種原因不籤需求，專案組在不籤需求的情況下，便開始開發工作。
4.客戶不承認之前提出來的需求，專案組又不能得失客戶，專案成員苦不堪言。
5.需求經常變化，無法控制。
6.設計、程式碼與需求不對應，特別是需求變更時，不知道應該修改哪部分，也不知道會有哪些影響。
......
這方面的問題可真是“罄竹難書”了，需求管理這個PA提供了能解決以上大部分問題的最佳實踐。
RM(Requirements Management)只有一個Specific Goals:Manage Requirements
Requirements are managed and inconsistencies with project plans and work products are identified.
中文大意是：
管理需求並且識別出需求與專案計劃、工作產品不一致的地方。
這句話有兩層意思：
1.需求要被管理，被管理的意思又有兩層：一是需求要被確認，二是要控制需求變更
2.需求要用來指導下游的工作產品，如：計劃、設計、測試等
下面簡單介紹一下這個Specific Goals下的5個Specific Practice：
第一個SP是：理解需求。
開發者應該理解客戶的需求，如果這點做不到，後面的工作是沒有意義的。所以，那種在沒有理解需求的情況下，就倉促開發的做法是不合適的。
當然，如果想通過做原型來獲取需求不在此列，另外，大家也千萬不要誤解，在沒有完全理解需求前一定不能開展開發工作，如果部分需求已經掌握，有部分需求還沒有掌握，那也是可以先開展已掌握部分需求的設計、編碼工作的，這時需要考慮沒有確定部分的需求對這些工作可能帶來的影響。
這個SP的英文原文是：Develop an understanding with the requirements providers on the meaning of the requirements.
第二個SP是：確認需求，就是要和客戶簽署需求。
我想大家都非常理解這點的重要性，但大家可能會說，說得容易，客戶就是不籤，咋辦？客戶不籤需求，主要是兩方面的原因：
1)客戶不確定需求。
2)客戶擔心簽了需求後，他就不好變了。
對於原因一，解決辦法就是大家需要把SP1理解需求做好，如何把需求理解做好，更詳細的內容可以參考3級的需求開發(RD)，這裡先不詳細解說。
對於原因二，要消除客戶的顧慮，首先簽署需求不是單方面的約束，其實也是對開發方的約束，就是說我們要承諾做出這樣的一個東西，如果做不出來，客戶可以追究我們的責任，另外一個方面，要跟客戶說清楚，需求是可以變的，現在簽署只是標誌著當前的一個工作里程碑，當前簽訂的需求，是我們後續工作的一個基準。
大家可能又會問如果只能確定一部分需求，客戶還是不願意籤，咋辦？那就先簽確定部分的需求唄！
這個SP的英文原文是：Obtain commitment to the requirements from the project participants.
第三個SP是：管理需求變更。
需求不是不可以變，只不過需要管理。客戶今天說改這，明天改那，後天又不算數，咋辦？怎樣才算管理需求變更呢？
1.要充分理解客戶提出來的需求變更，深究其原因，不能客戶一說變就變，超過一半的客戶變更要求，其實都是不合理的，或者是有其它更好的替代辦法的。
2.客戶提出來的變更要求，要書面記錄，並讓客戶確認，和客戶討論需求變更過程來往的郵件要儲存好，和客戶面談、聊電話後，要發郵件總結當此會談達成的要點共識，總之就是要有書面記錄。
3.客戶提出來的需求變更，要分析所有的影響，包括增加多少的工作量，需要修改或者增加哪些設計文件程式碼等，可能會引發什麼風險等。所有這些要列出清單，反饋給客戶，讓客戶確認。
4.如果需求變更導致專案成本和進度變化太大，超出可承受範圍，則需要高層領匯出面，和客戶協商調整費用。
這個SP的英文原文是：Manage changes to the requirements as they evolve during the project.
第四個SP是：維護需求的雙向跟蹤。
需求是用來指導後續工作的，所以需求與計劃、設計、編碼、測試等後續工作都需要維護好對應的關係，這個工作與第三個SP是關係密切的，如果這個關係沒有維護好，那麼SP1.3也不可能做好。
這樣是不是雙向跟蹤就能做好呢？不是，雙向跟蹤的意思不是由A能找到B，由B又能找到A就叫雙向跟蹤。雙向跟蹤是隻縱向和橫向跟蹤，前面提到的只是縱向跟蹤，縱向跟蹤的意思是上下游工作產品之間的跟蹤關係。而橫向跟蹤指的是需求與需求之間的關係、設計與設計之前的關係、程式碼與程式碼之間的關係等。其中一個需求變化了，有可能影響另外一些需求，其中一個設計變了也可能影響另外一些設計。
所以，這個雙向跟蹤網路，將會是一個很強的網路，任何一點發生變化，能找出全部受牽連的地方。
這個SP的英文原文是：Maintain bidirectional traceability among the requirements and the project plans and work products.
第五個SP是：識別出需求與下游工作產品不一致的地方。
這裡有兩層意思：
1.需求變更時，利用雙向跟蹤表找出需要修改的地方，並用跟蹤表來發現不一致的地方並調整。
2.編寫或者修改計劃、設計、程式碼、測試計劃、測試用例等需求下游工作產品的時候，要注意要與需求保持一致。
這個SP的英文原文是：Identify inconsistencies between the project plans and work products and the requirements.
請看下一文……
作者：張傳波
創新工場創業課堂（敏捷課程）講師
軟體研發管理資深顧問
CMMI首席專家
《火球——UML大戰需求分析》作者