摘要：作者針對當(dāng)前軟件系統(tǒng)建設(shè)中普遍存在的需求變更問題提出了自己的見解，并提出除了從客觀上采取加強(qiáng)培訓(xùn)和代價分析等方法外，更重要的是通過采用合理的分析設(shè)計方法，進(jìn)行可擴(kuò)展性設(shè)計可以有效地降低需求變更引起的風(fēng)險和維護(hù)代價，并給出了可擴(kuò)展性設(shè)計的一個具體例子。軟件系統(tǒng)開發(fā)過程中的需求變更問題作為軟件開發(fā)人員或者軟件系統(tǒng)客戶，相信我們都遭遇過因為需求變更而需要修改系統(tǒng)的情況，一般說來客戶會要求改變界面，改變操作方式，甚至改變業(yè)務(wù)，說，當(dāng)時我是那樣要求的，不過現(xiàn)在我們的業(yè)務(wù)調(diào)整了…這時需要中斷正在進(jìn)行的工作，需要查證以往的資料，需要修正計劃，需要…
　　需求包括業(yè)務(wù)需求、用戶需求和功能需求。業(yè)務(wù)需求（Business Requirement ）反映了組織機(jī)構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，用戶需求（User Requirement ）描述了用戶使用產(chǎn)品必須完成的任務(wù)，功能需求（Functional Requirement ）定義了開發(fā)人員必須實現(xiàn)的軟件功能。在軟件系統(tǒng)開發(fā)過程中，有很多問題都是由于在需求分析階段沒有正確地收集、編寫、協(xié)商、修改產(chǎn)品真實需求而產(chǎn)生的，造成這樣的狀況有幾方面的原因:
    對需求的理解分歧當(dāng)客戶向需求分析人員提出需求的時候往往是通過自然語言來表達(dá)的，這樣的表達(dá)對于真實的需求來說是一種描述（甚至只是某個角度的描述），遠(yuǎn)遠(yuǎn)不能保證這樣的描述可以得到百分之百的正確理解，也許在同客戶交流的第一時刻就埋下了理解分歧的種子，打一個比方說客戶說我要的是大象，身子象一堵墻，耳朵象扇子，四條腿象四根柱子，尾巴象繩子，分析人員想，哦，墻、扇子、柱子、繩子這些我都知道，但是真的畫出來的時候客戶當(dāng)然會跳起來了！這是理解分歧的問題，一般跟分析員的知識、背景，還有客戶表述的標(biāo)準(zhǔn)程度、雙方的交流情況有關(guān)；系統(tǒng)實施時間過長一個大中型系統(tǒng)的建設(shè)可能要延續(xù)一段時間，當(dāng)客戶提出要求之后，他當(dāng)時并不能看到系統(tǒng)的運行情況，當(dāng)雙方認(rèn)為理解大概沒有分歧的時候（事實上還會有個Deadline ），開發(fā)方就開始工作了。當(dāng)客戶拿到差不多可以試用的產(chǎn)品時他可以實際操作，這時候他就會對系統(tǒng)的界面、操作、功能、性能等有一些切身的體會，有可能提出需求變更要求；客戶具體情況不一當(dāng)前客戶的情況不一，有可能客戶行業(yè)的競爭度高，需要隨時作出調(diào)整和反應(yīng)，那么他們自然會經(jīng)常提出需求變更的要求；也有可能客戶所在的行業(yè)操作不規(guī)范，本身存在很多人為因素，這時候開發(fā)方更是需要隨時準(zhǔn)備應(yīng)變；開發(fā)本身要求有可能是來自開發(fā)方自身版本升級或性能改進(jìn)、設(shè)計修正的要求出現(xiàn)需求變更，這時更是無法繞開這個問題的了！所以說就算分析人員和客戶之間不存在理解分歧，客戶對于實際的系統(tǒng)還是會提出一些個人意見，就算沒有個人意見，他們自己的業(yè)務(wù)會變化或環(huán)境發(fā)生變化，這些都是無法避免的，所以不要夢想那么理想的需求分析，當(dāng)你開始一個項目的時候就應(yīng)該意識到，客戶需求變更一定會有的，那么對于這樣的現(xiàn)狀，我們該怎么辦呢？客戶是上帝，難道我們就象以前一樣，跟著客戶的需求不停地修改軟件，到最后工期延長，員工疲憊，成本成倍增長，客戶滿意度降低，原來的設(shè)計也會改變得支離破碎，系統(tǒng)難以維護(hù)？客觀面對需求變更如果需求一定會變化，如果我們不得不面對，如果我們已經(jīng)痛定思痛，想要變革，那么還有什么辦法可以改善我們的現(xiàn)狀答案是有的。加強(qiáng)人員培訓(xùn)從客觀方面可以采取的措施來說，首先，我想不容置疑的是加強(qiáng)對需求分析人員的培訓(xùn)，盡可能增強(qiáng)軟件系統(tǒng)、行業(yè)的背景知識，提高與客戶的溝通能力，增強(qiáng)服務(wù)意識和責(zé)任感，因為將要開發(fā)的系統(tǒng)直接建立在需求分析的基礎(chǔ)上；同時規(guī)范需求分析人員和客戶溝通的方式，以及規(guī)范需求說明的格式，如果可能的話，盡量采取象XP 的UserStory ，或者用戶可以理解的用例圖來對需求進(jìn)行標(biāo)準(zhǔn)、規(guī)范的描述，保證雙方在工具的協(xié)助下對需求達(dá)到共同的認(rèn)識，這一點是老生常談，就不多說。
    確定文檔的有效性（Validity ）順便要提的一句是關(guān)于文檔，需求文檔是相當(dāng)重要的，可是目前存在一種奇怪的現(xiàn)象，本來說必須要有文檔，而且是按照某種特定的格式，當(dāng)然這沒有錯，但接下來，卻沒有人關(guān)心文檔的真正內(nèi)容是否正確，格式是否真的合理，是否實用（而且很多情況下是在幾天時間里趕出來或補(bǔ)上去的），例如我遇到一個例子，需要在原來的需求基礎(chǔ)上進(jìn)行后續(xù)開發(fā)，文檔找到了，完全符合格式的要求，但是我在里面找到的線索是有限的，結(jié)果是自己花幾天的時間查找數(shù)據(jù)表結(jié)構(gòu)、甚至查看數(shù)據(jù)表的內(nèi)容，詢問當(dāng)時的開發(fā)人員，才分析到所要的關(guān)系，這種情況在設(shè)計文檔里也存在，所以同時提一提，希望我們的開發(fā)人員、PM 以及各級領(lǐng)導(dǎo)可以注意文檔的有效性和有用性問題，甚至對文檔的格式進(jìn)行一下合理性檢查。建立代價估算（Cost Estimate ）概念這一點對開發(fā)方和客戶同樣重要，因為如果出現(xiàn)需求變更，不可避免將帶來成本的增加、開發(fā)時間延長等不良后果，這樣的影響是雙方的。這時候需要區(qū)分需求變更的原因，是客戶方必要/不必要的要求，還是由于開發(fā)方的工作失誤，還是雙方都有原因，然后對現(xiàn)實情況進(jìn)行分析，得出雙方實現(xiàn)變更需求的需要的成本，包括時間，人力，資源等等方面，再與客戶商討是否必要進(jìn)行變更和如何在最小代價下實現(xiàn)變更。當(dāng)客戶看到實際的代價估算，他們也會再一次慎重地考慮需求變更問題，也會更容易理解系統(tǒng)建設(shè)中的進(jìn)行狀況，自然開發(fā)方也不用負(fù)擔(dān)所有的需求變更成本，所以進(jìn)行成本分?jǐn)傔€是有其積極意義的。當(dāng)然還有建立需求變更版本控制等等專業(yè)的需求管理，在這里不做專門論述。從軟件分析和設(shè)計著手前面說了面對需求變更的幾種策略，那么從軟件系統(tǒng)分析和設(shè)計的角度來看，通過采用合理的分析設(shè)計方法，進(jìn)行可擴(kuò)展性設(shè)計可以有效地降低需求變更引起的風(fēng)險和維護(hù)代價。
    采用OO 技術(shù)
    采用OO 技術(shù)可以建立易于改變和加強(qiáng)可重用性的軟件系統(tǒng)。
    對于OO 技術(shù)，我想現(xiàn)在已經(jīng)不是什么陌生的概念：
　　1 封裝（Encapsulation ）可以把問題影響的范圍縮小，外部的變化要求對系統(tǒng)的影響可以限定到某個類層次或某些類層次中，從而改變系統(tǒng)的一部分相對簡單；
　　2 繼承（Inheritance ）可以使改變基于原有技術(shù)基礎(chǔ)，很大程度上減少重復(fù)開發(fā)工作；
　　3 多態(tài)（Polymorphism ）的應(yīng)用可以使開發(fā)和設(shè)計人員在相對統(tǒng)一的接口下更改系統(tǒng)的實現(xiàn)細(xì)節(jié)，從而改變系統(tǒng)的行為；
　　4 而且由于對OO 的類體系結(jié)構(gòu)業(yè)界有非常清楚明晰的描述方式，就是目前規(guī)范的描述語言-UML ，非常易于被開發(fā)組的理解并達(dá)成共識，促進(jìn)開發(fā)組成員之間的合作以及加強(qiáng)軟件開發(fā)工作的可延續(xù)性；可見本身即是一種增強(qiáng)軟件可維護(hù)性、健壯性以及保持設(shè)計穩(wěn)定性的一種分析和設(shè)計方法，本身可以在一定程度上快速對需求變更進(jìn)行反應(yīng)，并可相對減少需求變更需要的成本。（OO 的意義在于分析和設(shè)計軟件系統(tǒng)的思考方式，以及建立對象庫以后的軟件重用將給軟件系統(tǒng)的開發(fā)帶來質(zhì)的改變，但是在建立OO 開發(fā)體系之前的過程，一定會是一段荊棘遍布的路，需要付出加倍的努力以及達(dá)成思想的轉(zhuǎn)變。這里還有一個誤區(qū)需要澄清的是很多人以為用了C++，PB ，VB ，DELPHI 就是面向?qū)ο蟮拈_發(fā)了，其實只是用了一些面向?qū)ο蟮墓ぞ撸亲永锶匀皇墙Y(jié)構(gòu)化的分析和設(shè)計方法，套上一層OOP 的外殼而已。）可擴(kuò)展性設(shè)計（Extensible-Design ）
　　其次，從我們可以控制的軟件設(shè)計來說，怎樣進(jìn)行合適的設(shè)計才能最大程度減少需求變更帶來的代價？
　　許有人說，我的設(shè)計極為靈活，我已經(jīng)預(yù)計了客戶可能提出的要求，并設(shè)計幾種應(yīng)對的方式，到時候客戶提出來，呵呵，我已經(jīng)解決了。這樣的想法不錯，至少比僵硬的設(shè)計強(qiáng)，但是誰可以保證設(shè)計者可以預(yù)知以后的需求變化？而同時為了達(dá)到這種靈活（萬能/多能？）的設(shè)計，設(shè)計將變得復(fù)雜，而且可能那些多余的設(shè)計從來不會被用到？復(fù)雜的設(shè)計將增加實現(xiàn)的難度和提高成本，并有可能帶來潛在的Bug ，使得系統(tǒng)難以維護(hù)。
設(shè)計的思想應(yīng)該有一些小小的轉(zhuǎn)變，那就是，設(shè)計確實要靈活，但是要體現(xiàn)在可擴(kuò)展性上面，也就是說，設(shè)計可以簡單，但是一定要易于轉(zhuǎn)變，需要給出便于改變的接口，這一點很重要。
結(jié)論
　　可見，在面對需求變更時，除了客觀上可以通過人員培訓(xùn)、代價分析等管理方式進(jìn)行有效的需求管理外，從分析和設(shè)計的角度可以通過采用合理的分析和設(shè)計方法，還有改變我們設(shè)計的意識，可以做到對需求變更的靈活應(yīng)對，至少可以在一定程度上降低維護(hù)代價和提高用戶滿意度。軟件需求的管理和控制是非常專業(yè)的學(xué)問，作者在這里結(jié)合自己的實踐提出一些粗淺的認(rèn)識，只是想起到一個拋磚引玉的作用，希望大家可以一起來面對和想辦法解決我們在系統(tǒng)開發(fā)過程中的實際問題，我想那樣才是我真正想達(dá)到的目的。