做軟件項(xiàng)目需求最重要就是分解用例場(chǎng)景，沒(méi)有用例就不是需求。軟件工程這類(lèi)書(shū)要學(xué)，不過(guò)軟件工程軟件項(xiàng)目需求最關(guān)鍵就是用例場(chǎng)景的合理建立，這條，好象沒(méi)有什么大學(xué)教科書(shū)談到，仿佛中國(guó)的大學(xué)計(jì)算機(jī)科學(xué)系教師統(tǒng)統(tǒng)沒(méi)有做過(guò)軟件項(xiàng)目的，完全沒(méi)有這個(gè)概念。所謂的軟件項(xiàng)目需求，如果不是變成走不通的偽代碼，就是用不上的美工方案，程序員對(duì)此除了干瞪眼是沒(méi)輒的。

　　其中最大的原因就是從事網(wǎng)站或者類(lèi)似的軟件項(xiàng)目需求的許多人都不懂真正的軟件項(xiàng)目需求是什么東西，包括我處理過(guò)的SAP/ERP項(xiàng)目這類(lèi)都是同樣的問(wèn)題，盡管那不是網(wǎng)站；他們犯的一般共同的錯(cuò)誤就是把網(wǎng)頁(yè)表現(xiàn)形式（那其實(shí)是美工的工作），以及內(nèi)容的采排看作是需求，完全沒(méi)有一個(gè)用例的觀念。

　　用例，usecase，目前多見(jiàn)于UML下的對(duì)面向?qū)ο蟪绦蛑械膶?duì)象行為的表達(dá)；不過(guò)，這不是它的源泉；它之所以被看作是這類(lèi)語(yǔ)言的標(biāo)準(zhǔn)URL描述手段，是因?yàn)槊嫦驅(qū)ο蟊旧砭褪窃谔摂M程序中模擬真實(shí)世界那樣地工作；而真實(shí)世界，就是圍繞著用例展開(kāi)的。用例的觀念其實(shí)也不能算是一個(gè)軟件概念，只不過(guò)在軟件領(lǐng)域定義得最為精確而已，今天從每個(gè)人的生老病死，婚姻嫁娶，其實(shí)都是一個(gè)個(gè)的用例的描述和實(shí)施。用例，顧名思意，就是假如（假設(shè)）出現(xiàn)某種情況，采取什么樣的行動(dòng)；可能會(huì)有什么樣的結(jié)果；然后，根據(jù)這個(gè)結(jié)果，再采取什么樣的行動(dòng)......直到得到希望的某個(gè)最終結(jié)局。

　　用例也叫場(chǎng)景，軟件，實(shí)際上就是對(duì)場(chǎng)景操作過(guò)程的描述，而不是一堆版面框架網(wǎng)頁(yè)的集成。沒(méi)有用例支持就不叫軟件，更加不叫項(xiàng)目——連垃圾都算不上。很多時(shí)侯我們說(shuō)需求不明確，其實(shí)就是說(shuō)這個(gè)用例不清晰；在電子商務(wù)網(wǎng)站中，除了人員素質(zhì)導(dǎo)致對(duì)基本概念方法不明白外，最可能的導(dǎo)因就是商業(yè)模式不明確，或者不成立。這個(gè)成立與否，實(shí)際上可以從上面的假如如何那般的推導(dǎo)中進(jìn)行初步的可行性推演。所以，程序員實(shí)際上有兩個(gè)層次，一個(gè)是你說(shuō)什么他做什么，但永遠(yuǎn)沒(méi)有結(jié)果的。他卻的確實(shí)現(xiàn)了你（需求人員）提出的所有要求，但這個(gè)項(xiàng)目卻必然是永遠(yuǎn)沒(méi)有結(jié)果的，因?yàn)?，它本身只是把這個(gè)程序員當(dāng)成網(wǎng)頁(yè)編輯用了，項(xiàng)目沒(méi)有基本用例的支持。我想90%的程序員是這類(lèi)程序員，沒(méi)有用例明確定義也就沒(méi)有軟件能力的評(píng)估，因?yàn)檐浖藛T不是美工。另一種程序員則可以從上訴推演中發(fā)現(xiàn)整個(gè)項(xiàng)目本身有沒(méi)有用例，以及用例是否合理（理論上沒(méi)有明顯的邏輯障礙）；雖然程序員一般不應(yīng)該關(guān)心商業(yè)模式是否合理，但實(shí)際上他有這個(gè)能力，常常是第一個(gè)發(fā)現(xiàn)商業(yè)模式的問(wèn)題，假如他也關(guān)心的話。

　　可惜大部分用戶需求人員不明白這個(gè)道理，反而可能會(huì)以為程序員是在推卸責(zé)任，或者是刁難需求；也正因?yàn)檫@個(gè)原因，需求人員和實(shí)現(xiàn)人員的沖突在項(xiàng)目中屢見(jiàn)不鮮，倒不是個(gè)人矛盾的沖突，而是由于雙方?jīng)]能有一個(gè)基本的立足點(diǎn)。我見(jiàn)過(guò)這樣的項(xiàng)目，需求人員建一個(gè)大型網(wǎng)站的需求就是一大籮的每個(gè)網(wǎng)頁(yè)的非常詳細(xì)的描述，到每個(gè)字每個(gè)連接......直至每個(gè)網(wǎng)頁(yè)出現(xiàn)的次序，項(xiàng)目經(jīng)理說(shuō)一個(gè)笑話：萬(wàn)一他摔一跤，這籮子?xùn)|西鬼才能再撿回原來(lái)的模樣。的確，負(fù)責(zé)需求的客戶方副老總和一幫企業(yè)需求編輯辛苦做了兩個(gè)月，但其實(shí)這不是需求，而是使用這個(gè)項(xiàng)目軟件的具體編輯排版的安排；根本不是程序員要看的東西。程序員需要的是使用這個(gè)網(wǎng)站時(shí)需要有那幾種用例邏輯，然后抽象出其中的對(duì)象，根據(jù)對(duì)象建立存儲(chǔ)方式（象數(shù)據(jù)庫(kù)存儲(chǔ)結(jié)構(gòu)）和內(nèi)容采摘方式。那大籮東東，實(shí)際上什么用處也沒(méi)有的。開(kāi)發(fā)軟件如同建房子，旁觀者可能問(wèn)一句：建房子啊就拍手說(shuō)明白了，但對(duì)于開(kāi)發(fā)員來(lái)說(shuō)，如果得不到準(zhǔn)確的房子細(xì)到磚磚瓦瓦的準(zhǔn)確設(shè)計(jì)（需求定義）；要知道建小平房和建金茂大夏都是建房子，建賓館還是建殯儀館也是建房子，到底客戶要的是什么房子合適，不搞清楚干下去的程序都是不負(fù)責(zé)任的，或者是冒牌貨。

　　不懂軟件項(xiàng)目需求的需求人員一般會(huì)犯如下錯(cuò)誤：

    一是把版面美工形式看作需求，其實(shí)程序員看程序如同醫(yī)生透過(guò)X光看一個(gè)人，看到的是骨架，至于是美人還是丑八怪如果能看出來(lái)，那個(gè)醫(yī)生一定是變態(tài)的；

    在開(kāi)發(fā)過(guò)程中都強(qiáng)調(diào)實(shí)現(xiàn)用例功能實(shí)現(xiàn)，而不是首先色彩如何花梢漂亮，后者不但不是主要的，也不是次要的，在開(kāi)發(fā)過(guò)程中什么都不是；一開(kāi)始把精力放在這里當(dāng)成需求實(shí)現(xiàn)是浪費(fèi)時(shí)間浪費(fèi)金錢(qián)。

    二是把靜態(tài)網(wǎng)頁(yè)當(dāng)成需求，特別是當(dāng)把靜態(tài)網(wǎng)頁(yè)當(dāng)成prototype時(shí)更經(jīng)常犯這個(gè)錯(cuò)誤；

    常常說(shuō)：按prototype做出來(lái)不就行了？實(shí)際上prototype本身如果不是看不出清楚的用例邏輯，就是可能有幾種用例解釋?zhuān)缓螞r真正變成動(dòng)態(tài)程序，與靜態(tài)的東西是不一樣的。我在網(wǎng)上看到的美女明星下了臺(tái)到眼前成了丑八怪，就是這個(gè)道理。而且更遭的是，客戶還同時(shí)犯第一個(gè)錯(cuò)誤，看著那里不順眼就改一改版面還一天三變,不知不覺(jué)的基本用例就變成了另外一個(gè)東西，原來(lái)是賓館現(xiàn)在成了蓋殯儀館，原來(lái)搞錯(cuò)了因?yàn)椴恢捞傻娜瞬煌胁煌酿^（死人還是活人），試問(wèn)，如何實(shí)現(xiàn)？項(xiàng)目開(kāi)始和后期看到的同一個(gè)版面成為不同的故事絕對(duì)是經(jīng)常出現(xiàn)的故事，軟件上稱(chēng)為需求變遷，這是項(xiàng)目經(jīng)常延期的最主要原因。

　　三是需求人員把定制了解成按客戶所有想法迎合靜態(tài)頁(yè)面，而不是按客戶的業(yè)務(wù)用例要求建立相應(yīng)的程序；還要求程序員也這樣做；

    實(shí)際上，如果不能撥亂反正的話，任何項(xiàng)目到此為止已經(jīng)是死路一條：那不是軟件，無(wú)非是靜態(tài)網(wǎng)頁(yè)人員出租！需求人員常犯的另一個(gè)錯(cuò)誤仍是不懂用例，就是把用例的使用方式當(dāng)成了需求；這種錯(cuò)誤有時(shí)連初級(jí)程序員都會(huì)犯，最典型就是把一個(gè)菜單欄目當(dāng)成需求，而程序員無(wú)法從菜單中看出明顯的簡(jiǎn)潔的用例邏輯——這是一個(gè)沒(méi)有意義的菜單，天曉得里頭是什么？同樣地，里頭的要干的東西還一天三變。事實(shí)上，同一種邏輯用例可以用到N個(gè)欄目，那是軟件的使用而不是軟件本身。

　　以上的錯(cuò)誤常見(jiàn)于網(wǎng)站建設(shè)，所以網(wǎng)站建設(shè)最通常的結(jié)局是不了了之，大概占了50%以上，無(wú)論設(shè)入多少錢(qián)多少人花多少時(shí)間都是如此的；除非有人能夠撥亂反正，讓項(xiàng)目需求走上正道。而在ERP/DRP這類(lèi)項(xiàng)目中，需求人員一般情況下是業(yè)務(wù)的行家，他們反而很容易理解用例是什么東西，象醫(yī)院收費(fèi)，絕對(duì)不會(huì)把精力放在收費(fèi)界面有沒(méi)有脫衣舞女讓收費(fèi)員提神上，收費(fèi)這個(gè)用例有多少個(gè)環(huán)節(jié)是他們理解的。這種項(xiàng)目需求最易犯的錯(cuò)誤是讓先進(jìn)的計(jì)算機(jī)工具重復(fù)原始狀態(tài)下的不合理的流程。最典型的笑話就是：手工審批要蓋五個(gè)章，用五天時(shí)間；現(xiàn)在電算化效率提高了一百倍，所以可以蓋五百個(gè)章（電子簽名呢！），時(shí)間嘛，仍然是五天！在這里，矛盾不是有沒(méi)有用例，而是用例是不是合理的，最高效率的。

　　所以對(duì)于需求由于用例的沖突，程序員如果不想不了了之最后責(zé)任全部背上身的話，最好就是堅(jiān)持原則；程序員迎合網(wǎng)頁(yè)編寫(xiě)是沒(méi)有意義的，遷就需求也不是沒(méi)有意義的，因?yàn)?.....無(wú)法遷就的，越是遷就就越是沒(méi)有辦法實(shí)現(xiàn)，或者客戶沒(méi)有辦法滿意的。軟件其實(shí)很簡(jiǎn)單的，無(wú)非是分析好用例，然后讓計(jì)算機(jī)一步步實(shí)現(xiàn)而已，用例，是所有軟件實(shí)現(xiàn)的前提：不然，軟件到底要干什么？好的軟件項(xiàng)目都有一個(gè)共同的特點(diǎn)，就是簡(jiǎn)單的邏輯，明確用例。