做軟體需求最重要就是分解用例情境，沒有用例就不是需求

[ 新浪ViVi ] [ Poco網摘 ] [ 365KEY ] [ 博採 ] [ 億友響享 ] [ 你摘 ] [ YouNote ] [ 天極網摘 ] [ 和訊網摘 ]

軟體工程這類書要學，不過軟體工程軟體需求最關鍵就是用例情境的合理建立，這條，好象沒有什麼大學教科書談到，彷彿中國的大學電腦科學系教師統統沒有做過軟體項目的，完全沒有這個概念。所謂的軟體需求，如果不是變成走不通的虛擬碼，就是用不上的美工方案，程式員對此除了乾瞪眼是沒輒的。。

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

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

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

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

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

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

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

所以對於需求由於用例的衝突，程式員如果不想不了了之最後責任全部背上身的話，最好就是堅持原則；程式員迎合網頁編寫是沒有意義的，遷就需求也不是沒有意義的，因為......無法遷就的，越是遷就就越是沒有辦法實現，或者客戶沒有辦法滿意的。軟體其實很簡單的，無非是分析好用例，然後讓電腦一步步實現而已，用例，是所有軟體實現的前提：不然，軟體到底要幹什麼
？好的軟體項目都有一個共同的特點，就是簡單的邏輯，明確用例。最典型的，看google,ebay