做軟件需求最重要就是分解用例場景，沒有用例就不是需求

軟件工程這類書要學，不過軟件工程軟件需求最關鍵就是用例場景的合理建立，這條，好象沒有什?大學教科書談到，仿佛中國的大學計算機科學系教師統統沒有做 過軟件項目的，完全沒有這個概念。所謂的軟件需求，如果不是變成走不通的?代碼，就是用不上的美工方案，程序員對此除了幹瞪眼是沒?的。。


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

用例，usecase，目前多見于UML下的對面向對象程序中的對象行?的表達；不過，這不是它的源泉；它之所以被看作是這類語言的標准URL描述手段， 是因?面向對象本身就是在虛擬程序中模擬真實世界那樣地工作；而真實世界，就是圍繞著用例展開的。用例的觀念其實也不能算是一個軟件概念，只不過在軟件領 域定義得最?精確而已，今天從每個人的生老病死，婚姻嫁娶，其實都是一個個的用例的描述和實施。用例，顧名思意，就是假如（假設）出現某種情況，采取什? 樣的行動；可能會有什?樣的結果；然後，根據這個結果，再采取什?樣的行動......直到得到希望的某個最終結局。

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

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

不懂軟件需求的需求人員一般會犯如下錯誤：一是把版面美工形式看作需求，其實程序員看程序如同醫生透過X光看一個人，看到的是骨架，至于是美人還是醜八怪 如果能看出來，那個醫生一定是變態的；在開發過程中都強調實現用例功能實現，而不是首先色彩如何花梢漂亮，後者不但不是主要的，也不是次要的，在開發過程 中什?都不是；一開始把精力放在這?當成需求實現是浪費時間浪費金錢。二是把靜態網頁當成需求，特別是當把靜態網頁當成prototype時更經常犯這個 錯誤；常常說："按prototype做出來不就行了？"實際上prototype本身如果不是看不出清楚的用例邏輯，就是可能有幾種用例解釋；何況真正 變成動態程序，與靜態的東西是不一樣的。我在網上看到的美女明星下了台到眼前成了醜八怪，就是這個道理。而且更遭的是，客戶還同時犯第一個錯誤，看著那? 不順眼就改一改版面還一天三變,不知不覺的基本用例就變成了另外一個東西，原來是賓館現在成了蓋?儀館，原來搞錯了因?不知道躺的人不同叫不同的館（死人 還是活人），試問，如何實現？項目開始和後期看到的同一個版面成?不同的故事絕對是經常出現的故事，軟件上稱?需求變遷，這是項目經常延期的最主要原因。


三是需求人員把定制了解成按客戶所有想法迎合靜態頁面，而不是按客戶的業務用例要求建立相應的程序；還要求程序員也這樣做；實際上，如果不能撥亂反正的 話，任何項目到此?止已經是死路一條：那不是軟件，無非是靜態網頁人員出租！需求人員常犯的另一個錯誤仍是不懂用例，就是把用例的使用方式當成了需求；這 種錯誤有時連初級程序員都會犯，最典型就是把一個菜單欄目當成需求，而程序員無法從菜單中看出明顯的簡潔的用例邏輯——這是一個沒有意義的菜單，天曉得? 頭是什?？同樣地，?頭的要幹的東西還一天三變。事實上，同一種邏輯用例可以用到N個欄目，那是"軟件的使用而不是軟件本身"。

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

所以對于需求由于用例的沖突，程序員如果不想不了了之最後責任全部背上身的話，最好就是堅持原則；程序員迎合網頁編寫是沒有意義的，遷就需求也不是沒有意 義的，因?......無法遷就的，越是遷就就越是沒有辦法實現，或者客戶沒有辦法滿意的。軟件其實很簡單的，無非是分析好用例，然後讓計算機一步步實現 而已，用例，是所有軟件實現的前提：不然，軟件到底要幹什?
？好的軟件項目都有一個共同的特點，就是簡單的邏輯，明確用例。最典型的，看google,ebay
http://blog.csdn.net/zwwwxy/archive/2005/06/13/393671.aspx