我們將圍繞著“需求變更”這個主題展開討論，希望對各位開發能有所幫助。讓我們先來看一個需求變更的典型案例：
Steven剛出任項目經理，并承接了一個中型軟件項目。公司再三叮嚀他一定要尊重客戶，充分滿足客戶需求。項目開始比較順利，但進入到后期，客戶頻繁的需求變更帶來很多額外工作。Steven動員大家加班，保持了項目的正常進度，客戶相當滿意。
但需求變更卻越來越多。為了節省時間，客戶的業務人員不再向Steven申請變更，而是直接找程序員商量。程序員疲于應付，往往直接改程序而不做任何記錄，很多相關文檔也忘記修改。很快Steven就發現：需求、設計和代碼無法保持一致，甚至沒有人能說清楚現在系統“到底改成什么樣了”。版本管理也出現了混亂，很多人違反配置管理規定，直接在測試環境中修改和編譯程序。但在進度壓力下，他也只能佯裝不知此事。但因頻繁出現“改好的錯誤又重新出現”的問題，客戶已經明確表示“失去了耐心”。
而這還只是噩夢的開始。一個程序員未經許可擅自修改了核心模塊，造成系統運行異常緩慢，大量應用程序超時退出。雖然最終花費了整整3天的時間解決了這個問題，但客戶卻投訴了，表示“無法容忍這種低下的項目管理水平”。更糟糕的是，因為擔心系統中還隱含著其他類似的錯誤，客戶高層對項目的質量也疑慮重重。
隨后發生的事情讓Steven更加為難：客戶的兩個負責人對界面風格的看法不一致，并為此發生了激烈爭執。Steven知道如果發表意見可能會得罪其中一方，于是保持了沉默。最終客戶決定調整所有界面， Steven只好立刻動員大家抓緊時間修改�？珊髞懋斅犝f因修改界面而造成了項目一周的延誤后，客戶方原來發生爭執的兩人這次卻非常一致，同時氣憤地質問Steven：“為什么你不早點告訴我們要延期！早知這樣才不會讓你改呢！”Steven很無耐，疑惑自己到底錯在哪里了。
段落導航：
為了方便大家的閱讀，我們將本期內容進行了合理的分類，您可以使用下面的鏈接瀏覽您感興趣的主題�！ �
- 對軟件需求和需求變更的理解
- 需求變更的原因
- 需求變更的代價
- 減少需求變更
- 如何控制需求變更
- 需求變更的管理
- 實施需求變更管理需要遵循以下六大原則
- 應對之道
|
對軟件需求和需求變更的理解
軟件需求是整個軟件項目的最關鍵的一個輸入，和傳統的生產企業相比較，軟件的需求具有模糊性、不確定性、變化性和主觀性的特點，它不像生產汽車、電腦等硬件的需求，是有形的、客觀的、可描述的、可檢測的。軟件需求是軟件項目最難把握的問題，同時又是關系項目成敗的關鍵因素，因此對于需求分析和需求變更的處理十分重要。
|
| 需求變更的原因
需求包括業務需求、用戶需求和功能需求。業務需求（Business Requirement ）反映了組織機構或客戶對系統、產品高層次的目標要求，用戶需求（User Requirement ）描述了用戶使用產品必須完成的任務，功能需求（Functional Requirement ）定義了開發人員必須實現的軟件功能。 會導致需求變更的原因會有很多，如老板臨時改變想法、項目預算增加或減少、客戶對功能的需求改變等。在IT項目中，變更可能來自方案服務商、客戶或產品供應商等，也可能來源于項目組內部。在軟件系統開發過程中，有很多問題都是由于在需求分析階段沒有正確地收集、編寫、協商、修改產品真實需求而產生的，造成這樣的狀況有以下幾方面的基本原因:  （1）對需求的理解分歧 當客戶向需求分析人員提出需求的時候往往是通過自己的想法用自然語言來表達的，這樣的表達結果對于真實的需求來說是一種描述（甚至只是某個角度的描述），遠遠不能保證這樣的描述可以得到百分之百的正確理解，也許在同客戶交流的第一時刻就埋下了理解分歧的種子，打一個比方說客戶說我要的是大象，身子象一堵墻，耳朵象扇子，四條腿象四根柱子，尾巴象繩子，分析人員想，哦，墻、扇子、柱子、繩子這些我都知道，但是真的畫出來的時候客戶當然會跳起來了！這是理解分歧的問題，一般跟分析員的知識、背景，還有客戶表述的標準程度、雙方的交流情況有關。 （2）系統實施時間過長一個大中型系統的建設可能要延續一段時間，當客戶提出要求之后，他當時并不能看到系統的運行情況，當雙方認為理解大概沒有分歧的時候（事實上還會有個Deadline ），開發方就開始工作了。當客戶拿到差不多可以試用的產品時他可以實際操作，這時候他就會對系統的界面、操作、功能、性能等有一些切身的體會，有可能提出需求變更要求。 （3）用戶業務需求改變當前客戶的運營情況不確定，有可能客戶行業的競爭度高，需要隨時作出調整和反應，那么他們自然會經常提出需求變更的要求；也有可能客戶所在的行業操作不規范，本身存在很多人為因素，這時候開發方更是需要隨時準備應變。 （4）系統正常升級有可能是來自開發方自身版本升級或性能改進、設計修正的要求出現需求變更，這時更是無法繞開這個問題的了！ 所以說就算分析人員和客戶之間不存在理解分歧，客戶對于實際的系統還是會提出一些個人意見，就算沒有個人意見，他們自己的業務會變化或環境發生變化，這些都是無法避免的，所以不要夢想那么理想的需求分析，當你開始一個項目的時候就應該意識到，客戶需求變更一定會有的，那么對于這樣的現狀，我們該怎么辦呢？客戶是上帝，難道我們就象以前一樣，跟著客戶的需求不停地修改軟件，到最后工期延長，員工疲憊，成本成倍增長，客戶滿意度降低，原來的設計也會改變得支離破碎，系統難以維護？ |
| 需求變更的代價
一般來講，需求的變更通常意味著需求的增加，需求的減少相對很少，而且處理需求減少方面的問題也比較容易。當客戶提出新需求的時候，項目開發人員應該分析這些新需求對項目現階段帶來的風險，得出雙方實現變更需求的需要的成本，包括時間、人力、資源等等方面。 變更都是有代價的，應該評估一下變更的代價和對項目的影響，在評估代價并且與客戶討論的過程中，要讓客戶了解變更的后果，變更之后面臨最大的問題就是項目延期，讓客戶一起做判斷：“我可以修改，但您能接受后果嗎？”�，F在會出現三種可能：客戶接受延期這一后果，開發人員按客戶要求做出相應修改，讓客戶知道為此需要付出延期的代價；如果客戶認為代價太大，那開發人員就不必修改了，可以記錄下需求，待到下一版本再做修改；客戶不接受變更的代價，導致項目夭折。 如果客戶不知道你為變更付出的代價，對你的辛苦便難以體會，以致沒完沒了的提出新的變更。  |
文章來源于領測軟件測試網 http://www.kjueaiud.com/
