做軟件項目需求最重要就是分解用例場景，沒有用例就不是需求。軟件工程這類書要學，不過軟件工程軟件項目需求最關鍵就是用例場景的合理建立，這條，好象沒有什么大學教科書談到，仿佛中國的大學計算機科學系教師統(tǒng)統(tǒng)沒有做過軟件項目的，完全沒有這個概念。所謂的軟件項目需求，如果不是變成走不通的偽代碼，就是用不上的美工方案，程序員對此除了干瞪眼是沒輒的。
    其中最大的原因就是從事網站或者類似的軟件項目需求的許多人都不懂真正的軟件項目需求是什么東西，包括我處理過的SAP/ERP項目這類都是同樣的問題，盡管那不是網站;他們犯的一般共同的錯誤就是把網頁表現(xiàn)形式(那其實是美工的工作)，以及內容的采排看作是需求，完全沒有一個用例的觀念。
    用例，usecase，目前多見于UML下的對面向對象程序中的對象行為的表達;不過，這不是它的源泉;它之所以被看作是這類語言的標準URL描述手段，是因為面向對象本身就是在虛擬程序中模擬真實世界那樣地工作;而真實世界，就是圍繞著用例展開的。用例的觀念其實也不能算是一個軟件概念，只不過在軟件領域定義得最為精確而已，今天從每個人的生老病死，婚姻嫁娶，其實都是一個個的用例的描述和實施。用例，顧名思意，就是假如(假設)出現(xiàn)某種情況，采取什么樣的行動;可能會有什么樣的結果;然后，根據(jù)這個結果，再采取什么樣的行動……直到得到希望的某個最終結局。
    用例也叫場景，軟件，實際上就是對場景操作過程的描述，而不是一堆版面框架網頁的集成。沒有用例支持就不叫軟件，更加不叫項目——連垃圾都算不上。很多時侯我們說需求不明確，其實就是說這個用例不清晰;在電子商務網站中，除了人員素質導致對基本概念方法不明白外，最可能的導因就是商業(yè)模式不明確，或者不成立。這個成立與否，實際上可以從上面的假如如何那般的推導中進行初步的可行性推演。所以，程序員實際上有兩個層次，一個是你說什么他做什么，但永遠沒有結果的。他卻的確實現(xiàn)了你(需求人員)提出的所有要求，但這個項目卻必然是永遠沒有結果的，因為，它本身只是把這個程序員當成網頁編輯用了，項目沒有基本用例的支持。我想90%的程序員是這類程序員，沒有用例明確定義也就沒有軟件能力的評估，因為軟件人員不是美工。另一種程序員則可以從上訴推演中發(fā)現(xiàn)整個項目本身有沒有用例，以及用例是否合理(理論上沒有明顯的邏輯障礙);雖然程序員一般不應該關心商業(yè)模式是否合理，但實際上他有這個能力，常常是第一個發(fā)現(xiàn)商業(yè)模式的問題，假如他也關心的話。
    可惜大部分用戶需求人員不明白這個道理，反而可能會以為程序員是在推卸責任，或者是刁難需求;也正因為這個原因，需求人員和實現(xiàn)人員的沖突在項目中屢見不鮮，倒不是個人矛盾的沖突，而是由于雙方沒能有一個基本的立足點。我見過這樣的項目，需求人員建一個大型網站的需求就是一大籮的每個網頁的非常詳細的描述，到每個字每個連接……直至每個網頁出現(xiàn)的次序，項目經理說一個笑話：萬一他摔一跤，這籮子東西鬼才能再撿回原來的模樣。的確，負責需求的客戶方副老總和一幫企業(yè)需求編輯辛苦做了兩個月，但其實這不是需求，而是使用這個項目軟件的具體編輯排版的安排;根本不是程序員要看的東西。程序員需要的是使用這個網站時需要有那幾種用例邏輯，然后抽象出其中的對象，根據(jù)對象建立存儲方式(象數(shù)據(jù)庫存儲結構)和內容采摘方式。那大籮東東，實際上什么用處也沒有的。開發(fā)軟件如同建房子，旁觀者可能問一句：建房子啊就拍手說明白了，但對于開發(fā)員來說，如果得不到準確的房子細到磚磚瓦瓦的準確設計(需求定義);要知道建小平房和建金茂大夏都是建房子，建賓館還是建殯儀館也是建房子，到底客戶要的是什么

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

    http://www.vanceur.cn/pmqhd/index.html