摘要：作者針對當前軟件系統(tǒng)建設中普遍存在的需求變更問題提出了自己的見解，并提出除了從客觀上采取加強培訓和代價分析等方法外，更重要的是通過采用合理的分析設計方法，進行可擴展性設計可以有效地降低需求變更引起的風險和維護代價，并給出了可擴展性設計的一個具體例子。軟件系統(tǒng)開發(fā)過程中的需求變更問題作為軟件開發(fā)人員或者軟件系統(tǒng)客戶，相信我們都遭遇過因為需求變更而需要修改系統(tǒng)的情況，一般說來客戶會要求改變界面，改變操作方式，甚至改變業(yè)務，說，當時我是那樣要求的，不過現在我們的業(yè)務調整了…這時需要中斷正在進行的工作，需要查證以往的資料，需要修正計劃，需要…

　　需求包括業(yè)務需求、用戶需求和功能需求。業(yè)務需求（Business Requirement ）反映了組織機構或客戶對系統(tǒng)、產品高層次的目標要求，用戶需求（User Requirement ）描述了用戶使用產品必須完成的任務，功能需求（Functional Requirement ）定義了開發(fā)人員必須實現的軟件功能。在軟件系統(tǒng)開發(fā)過程中，有很多問題都是由于在需求分析階段沒有正確地收集、編寫、協(xié)商、修改產品真實需求而產生的，造成這樣的狀況有幾方面的原因:

對需求的理解分歧當客戶向需求分析人員提出需求的時候往往是通過自然語言來表達的，這樣的表達對于真實的需求來說是一種描述（甚至只是某個角度的描述），遠遠不能保證這樣的描述可以得到百分之百的正確理解，也許在同客戶交流的第一時刻就埋下了理解分歧的種子，打一個比方說客戶說我要的是大象，身子象一堵墻，耳朵象扇子，四條腿象四根柱子，尾巴象繩子，分析人員想，哦，墻、扇子、柱子、繩子這些我都知道，但是真的畫出來的時候客戶當然會跳起來了！這是理解分歧的問題，一般跟分析員的知識、背景，還有客戶表述的標準程度、雙方的交流情況有關；系統(tǒng)實施時間過長一個大中型系統(tǒng)的建設可能要延續(xù)一段時間，當客戶提出要求之后，他當時并不能看到系統(tǒng)的運行情況，當雙方認為理解大概沒有分歧的時候（事實上還會有個Deadline ），開發(fā)方就開始工作了。當客戶拿到差不多可以試用的產品時他可以實際操作，這時候他就會對系統(tǒng)的界面、操作、功能、性能等有一些切身的體會，有可能提出需求變更要求；客戶具體情況不一當前客戶的情況不一，有可能客戶行業(yè)的競爭度高，需要隨時作出調整和反應，那么他們自然會經常提出需求變更的要求；也有可能客戶所在的行業(yè)操作不規(guī)范，本身存在很多人為因素，這時候開發(fā)方更是需要隨時準備應變；開發(fā)本身要求有可能是來自開發(fā)方自身版本升級或性能改進、設計修正的要求出現需求變更，這時更是無法繞開這個問題的了！所以說就算分析人員和客戶之間不存在理解分歧，客戶對于實際的系統(tǒng)還是會提出一些個人意見，就算沒有個人意見，他們自己的業(yè)務會變化或環(huán)境發(fā)生變化，這些都是無法避免的，所以不要夢想那么理想的需求分析，當你開始一個項目的時候就應該意識到，客戶需求變更一定會有的，那么對于這樣的現狀，我們該怎么辦呢？客戶是上帝，難道我們就象以前一樣，跟著客戶的需求不停地修改軟件，到最后工期延長，員工疲憊，成本成倍增長，客戶滿意度降低，原來的設計也會改變得支離破碎，系統(tǒng)難以維護？客觀面對需求變更如果需求一定會變化，如果我們不得不面對，如果我們已經痛定思痛，想要變革，那么還有什么辦法可以改善我們的現狀答案是有的。加強人員培訓從客觀方面可以采取的措施來說，首先，我想不容置疑的是加強對需求分析人員的培訓，盡可能增強軟件系統(tǒng)、行業(yè)的背景知識，提高與客戶的溝通能力，增強服務意識和責任感，因為將要開發(fā)的系統(tǒng)直接建立在需求分析的基礎上；同時規(guī)范需求分析

    項目經理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://m.opto-elec.com.cn/pmqhd/index.html