先說一個小笑話。有一個生產(chǎn)隊隊長，他對專家說：“現(xiàn)在我們生產(chǎn)隊的地越來越多，牛越來越忙不過來了。我想要這么一種牛，他吃的草和普通牛一樣多，但是干的活是普通牛的十倍?！睂＜艺f：“這種牛是可以造出來的，現(xiàn)在有基因工程?！标犻L說：“好吧，你給這造幾頭這樣的牛?！庇谑菍＜艺业搅松飳嶒炇遥屔飳嶒炇业娜烁阋粋€基因工程，把牛造出來。于是工程浩大，投資無法保證，合作多半是不愉快的收場。
　　現(xiàn)實世界里很多人分析需求的過程就類似于這位專家，他們把注意力放在用戶提出的功能點上，而對用戶的實際需求沒有興趣。有不少軟件公司和程序員，其實都在做類似的基因工程。如果這個專家把注意力放在生產(chǎn)隊長的業(yè)務(wù)需求上，而不是太在乎他提出的功能點，他會說：“我認識一個賣拖拉機的，可以帶你去看看?！?BR>　　軟件的維護為什么這么痛苦，一個很重要的原因在于：需求已經(jīng)被遺忘了。
　　需求是對用戶具有直接商業(yè)價值的活動，而不應(yīng)該牽涉到任何的功能實現(xiàn)方式。實現(xiàn)同一個需求可以使用多個方案，每個方案有自己的功能方式，在某個方案中至關(guān)重要的功能點，也許在另一個方案中根本無關(guān)緊要。
　　瀑布式的開發(fā)過程，首先是由一批懂得用戶業(yè)務(wù)的專家去調(diào)查用戶的需求，分析出這個系統(tǒng)應(yīng)該具有哪些功能，形成一個非常重要的文件——《xxx系統(tǒng)需求規(guī)格說明書》?？蛻粽J可了這個《說明書》，在上面簽字蓋章，加入合同附件，到時候項目驗收就以此為準。這時候，需求就已經(jīng)分解成了一個個功能點，從這時候開始，需求本身就漸漸被人們遺忘。設(shè)計人員圍繞著這些功能點進行工作，考慮用什么樣的技術(shù)手段把功能點制造出來。功能點的制作細節(jié)形成了另外一份重要的文件——《xxx項目設(shè)計規(guī)格說明書》。這個《設(shè)計規(guī)格說明書》交給程序員去進行編碼。
　　這樣的做法在開發(fā)中已經(jīng)形成了很大的問題。
　　首先，面對這樣的《需求規(guī)格說明書》，設(shè)計人員已經(jīng)無法知道最初的需求是什么。假如這個《需求規(guī)格說明書》中的功能點沒有出現(xiàn)互相矛盾的情況，而他們串起來卻和用戶的需求不同，設(shè)計人員沒辦法發(fā)現(xiàn)這樣的情況，編碼人員也無法發(fā)現(xiàn)。假如測試也是根據(jù)這個《需求規(guī)格說明書》來做的，測試人員也發(fā)現(xiàn)不了。直到最后客戶看見這個程序展現(xiàn)在他們面前。需求的分析需要在隨后的過程中不斷得到反饋，傳統(tǒng)的過程不是沒有反饋，而是反饋的時間太長了。
　　其次，由于設(shè)計人員已經(jīng)無法知道基本的需求是什么，也就無法對業(yè)務(wù)進行建模。這樣的需求分析是以開發(fā)人員的需要為核心的，可是結(jié)果恰恰妨礙了開發(fā)人員對需求的理解。如果開發(fā)人員對用戶的業(yè)務(wù)過程不甚了解，他們只有一種選擇：不要試圖去了解需求了，直接按照這些功能點做吧。于是，他們建立的對象模型就不是以需求為核心的，而是以功能、界面為核心的。我見到過很多這樣的系統(tǒng)，開發(fā)者確實有很高的抽象思維水平，程序中設(shè)計了非常巧妙的控制器和界面，可以很方便的進行開發(fā)和變更。唯獨業(yè)務(wù)層的對象非常簡陋，一旦發(fā)生實際業(yè)務(wù)的變更，仍然十分辛苦。
　　更大的困難發(fā)生在維護程序的時候。
　　假設(shè)有一個移動通信公司需要制造一個系統(tǒng)，用來解決手機用戶入網(wǎng)的問題。這個需求有下面幾個要素：
　　1：用戶付錢，得到一個SIM卡和一個號碼，把這個SIM卡裝到手機里就可以通話。
　　2：營業(yè)員收的錢要記錄下來，提供給稽核人員，現(xiàn)金和帳目必須是平的。
　　3：用戶付的話費要劃入他自己的帳戶，可以打印票據(jù)。
　　4：用戶要在入網(wǎng)合同上簽字，然后營業(yè)員把合同歸檔。
　　這幾個要素都是和通信公司的商業(yè)利益直接相關(guān)的，沒有牽涉到任何系統(tǒng)實現(xiàn)方式。如果不考慮通信公司內(nèi)部的業(yè)務(wù)規(guī)范，實現(xiàn)方案可以有幾十種，下面列舉兩種：
　　1：S

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

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