本文介紹了需求管理的必要性，并介紹了控制需求漸變的一些方法。

　　軟件需求是整個(gè)軟件項目的最關(guān)鍵的一個(gè)輸入，和傳統的生產(chǎn)企業(yè)相比較，軟件的需求具有模糊性、不確定性、變化性和主觀(guān)性的特點(diǎn)，他不像生產(chǎn)汽車(chē)、電腦等硬件的需求，是有形的、客觀(guān)的、可描述的、可檢測的，軟件需求是軟件項目最難把握的問(wèn)題，他的復雜性體現在以下方面：

　　需求的描述問(wèn)題

　　筆者曾經(jīng)被緊急委派主管一個(gè)已經(jīng)進(jìn)入了編碼后期階段的項目，該項目已經(jīng)換過(guò)2次項目經(jīng)理了，這是第3次更換項目經(jīng)理，用戶(hù)方的IT部經(jīng)理找筆者抱怨：“我已經(jīng)是第3次來(lái)給你們講補貨申請的處理規則了！”。我只能表示抱歉，因為我無(wú)法找到原來(lái)的需求描述，這是一個(gè)變更的需求，前任的項目經(jīng)理講他只是將當時(shí)與用戶(hù)交流的需求記到2頁(yè)草稿紙上，不幸的是，那2頁(yè)珍貴的手稿現在已經(jīng)找不到了！更不幸的是，該IT部經(jīng)理是在轉述業(yè)務(wù)部門(mén)的需求，當軟件開(kāi)發(fā)完畢后，業(yè)務(wù)部門(mén)講“這不是我們最初給IT部反映的需求，我們說(shuō)的不是這樣的！”。缺少正式的完整的需求文檔浪費了大量的人力物力，但是有了需求文檔又出現了新的問(wèn)題。曾經(jīng)有多個(gè)項目經(jīng)理向我抱怨，在用戶(hù)方進(jìn)行的需求評審會(huì )完全是走形式，因為用戶(hù)根本不去聽(tīng)他讀那上百頁(yè)的需求文檔。不同層次的客戶(hù)（用戶(hù)）關(guān)心的問(wèn)題是不一樣的，想要每個(gè)客戶(hù)都成為需求專(zhuān)家是不現實(shí)的。

　　需求的完備程度問(wèn)題

　　需求如何做到?jīng)]有遺漏？如何準確劃定系統的范圍？這確實(shí)是一個(gè)兩難問(wèn)題，稍微大一點(diǎn)的系統要想窮舉需求幾乎是不可能的，每次開(kāi)需求評審會(huì )時(shí)，總會(huì )冒出新的需求，以至于系統沒(méi)有一個(gè)準確的范圍界定。即使是這樣，系統還是要開(kāi)發(fā)，沒(méi)辦法，系統的范圍還要硬性的劃定一個(gè)，從而建立一個(gè)基線(xiàn)。本文轉自項目管理者聯(lián)盟

　　需求開(kāi)發(fā)的工期問(wèn)題

　　在需求上花費了大量的時(shí)間（而不是人工時(shí)，因為需求階段人多了也沒(méi)有作用），客戶(hù)、軟件公司是否能夠忍受？為了確保需求的正確性，完備性，項目經(jīng)理往往堅持要在需求階段花費大量的時(shí)間，但是客戶(hù)與公司的高層領(lǐng)導卻會(huì )為項目遲遲看不到實(shí)際可運行的軟件擔心不已！他們往往會(huì )逼迫項目組盡快往前推進(jìn)，而項目組的成員往往也會(huì )為系統復雜的善變的需求折騰的筋疲力盡，他們也希望盡快結束此階段。項目管理者聯(lián)盟，項目管理問(wèn)題。

　　需求的細致程度問(wèn)題

　　需求到底描述到多細，才算可以結束了？仁者見(jiàn)仁，智者見(jiàn)智，并沒(méi)有定論，如果時(shí)間允許，要想細總可以細下去的。但是，需求的周期越長(cháng)，可能的變化越多，對設計的限制越嚴格，對需求的共性提取要求越高，所以只要大家（客戶(hù)、用戶(hù)、需求分析人員、設計人員、測試人員）認為描述清楚了，就可以進(jìn)入設計階段了。項目管理者聯(lián)盟文章，深入探討。

　　在軟件開(kāi)發(fā)過(guò)程中如果只有一條真理的話(huà)，那一定是：需求的變化是永恒的，需求不可能是完備的。軟件開(kāi)發(fā)的過(guò)程實(shí)際上是同變化做斗爭的過(guò)程，需求的變更不一定是壞事，也有可能是好事，是商業(yè)機會(huì )，對市場(chǎng)敏感的人可以從需求的變化中發(fā)現市場(chǎng)機會(huì )。

　　需求變化的原因很多，如：

　　一開(kāi)始沒(méi)有識別全，需要增加需求；業(yè)務(wù)發(fā)生了變化，需求必須變化；需求錯誤；需求不清楚；

　　需求的變化問(wèn)題是每個(gè)開(kāi)發(fā)人員、每個(gè)項目經(jīng)理都遇到的問(wèn)題，也是最頭痛的問(wèn)題，一旦發(fā)生了需求變化，你不得不來(lái)修改你的設計、重寫(xiě)你的代碼、修改你的測試用例、調整你的項目計劃等等，需求的變化好比是萬(wàn)惡之源，為項目的正常的進(jìn)展帶來(lái)不盡的麻煩，怎么辦？管理它！使需求在受控的狀態(tài)下發(fā)生變化，而不是隨意變化，需求管理就是要按照標準的流程來(lái)控制需求的變化。

　　本文轉自項目管理者聯(lián)盟難題隨之而來(lái)，需求中的變化一般不是突發(fā)的革命性的變化，最常見(jiàn)的是“項目需求的漸變”（Project Scope Creep）問(wèn)題，這種漸變很可能是客戶(hù)與開(kāi)發(fā)方都沒(méi)有意識到的，當達到一定層度時(shí)，雙方才驀然回首，發(fā)現已經(jīng)物是人非，換了一番天地。

　　控制需求漸變需要注意以下幾點(diǎn)：

　�。�1）需求一定要與投入有顯示的聯(lián)系，否則如果需求變更的成本由開(kāi)發(fā)方來(lái)承擔，則項目需求的變更就成為必然了。人們常說(shuō)世上沒(méi)有免費的午餐，同樣也不應該有免費的需求變更。但是，接受需求變更目前卻是軟件開(kāi)發(fā)商不得不咽下的苦果。所以，在項目的開(kāi)始無(wú)論是開(kāi)發(fā)方還是出資方都要明確這一條：需求變，軟件開(kāi)發(fā)的投入也要變。

　�。�2）需求的變更要經(jīng)過(guò)出資者的認可，需求的變更引起投入的變化，所以要通過(guò)出資者的認可，這樣才會(huì )對需求的變更有成本的概念，能夠慎重地對待需求的變更。筆者曾經(jīng)經(jīng)歷過(guò)一個(gè)項目，為了避免項目的風(fēng)險，我們請了用戶(hù)代表全程參與了開(kāi)發(fā)過(guò)程，結果此用戶(hù)代表在開(kāi)發(fā)過(guò)程提出了大量？小“的需求變更，當開(kāi)發(fā)人員按此需求變更修改了軟件時(shí)，在項目進(jìn)入現場(chǎng)實(shí)施階段時(shí)，卻有大量的這些變更需要改回去，問(wèn)題就是出在我們的項目組成員視該用戶(hù)代表的需求為圣旨，卻忽略了需求是否經(jīng)過(guò)了客戶(hù)方真正有決策權的人員的認可。

　�。�3）小的需求變更也要經(jīng)過(guò)正規的需求管理流程，否則會(huì )積少成多。在實(shí)踐中，人們往往不愿意為小的需求變更去執行正規的需求管理過(guò)程，認為降低了開(kāi)發(fā)效率，浪費了時(shí)間。正式由于這種觀(guān)念才使需求的漸變不可控，最終導致項目的失敗。

　�。�4）精確的需求與范圍定義并不會(huì )阻止需求的變更。并非對需求定義的越細，越能避免需求的漸變，這是2個(gè)層面的問(wèn)題。太細的需求定義對需求漸變沒(méi)有任何效果。因為需求的變化是永恒的，并非由于需求寫(xiě)細了，它就不會(huì )變化了。

　　注意溝通的技巧。實(shí)際情況是用戶(hù)、開(kāi)發(fā)者都認識了到了上面的幾點(diǎn)問(wèn)題，但是由于需求的變更可能來(lái)自客戶(hù)方、也可能來(lái)自開(kāi)發(fā)方，作為客戶(hù)他們可能不愿意為需求的變更付出更多的投資，開(kāi)發(fā)方有可能是主動(dòng)的變更了需求，他們的目的可能是使軟件做的更“精致”，于是作為需求管理者、項目經(jīng)理需要采用各種溝通技巧來(lái)使項目的各方各得其所。

　　軟件需求的復用問(wèn)題

　　筆者曾經(jīng)遇到過(guò)一位領(lǐng)域專(zhuān)家，他在有20多年的領(lǐng)域工程經(jīng)驗，積累了大量的領(lǐng)域需求，可是在其每進(jìn)行一次產(chǎn)品開(kāi)發(fā)時(shí)，他總是感到他所理解的需求無(wú)法為與他配合的分析人員、設計人員所接受。當我們一起來(lái)討論這個(gè)問(wèn)題的時(shí)候，共同的一個(gè)觀(guān)點(diǎn)就是：沒(méi)有對需求進(jìn)行有效的管理，已經(jīng)形成的需求文檔沒(méi)有很好的復用。所以需求管理一個(gè)很重要的目標應是提高軟件需求的復用率。  項目管理者聯(lián)盟文章，深入探討。

　　基于上述的問(wèn)題，必須對需求進(jìn)行管理，使需求能夠真正成為軟件工程和管理的基線(xiàn)，使軟件計劃、活動(dòng)和工作產(chǎn)品同軟件需求保持一致，使需求可以復用。