儀館也是建房子，到底客戶要的是什么房子合適，不搞清楚干下去的程序都是不負(fù)責(zé)任的，或者是冒牌貨。
不懂軟件項目需求的需求人員一般會犯如下錯誤：一是把版面美工形式看作需求，其實程序員看程序如同醫(yī)生透過X光看一個人，看到的是骨架，至于是美人還是丑八怪如果能看出來，那個醫(yī)生一定是變態(tài)的；在開發(fā)過程中都強調(diào)實現(xiàn)用例功能實現(xiàn)，而不是首先色彩如何花梢漂亮，后者不但不是主要的，也不是次要的，在開發(fā)過程中什么都不是；一開始把精力放在這里當(dāng)成需求實現(xiàn)是浪費時間浪費金錢。二是把靜態(tài)網(wǎng)頁當(dāng)成需求，特別是當(dāng)把靜態(tài)網(wǎng)頁當(dāng)成prototype時更經(jīng)常犯這個錯誤；常常說：按prototype做出來不就行了？實際上prototype本身如果不是看不出清楚的用例邏輯，就是可能有幾種用例解釋；何況真正變成動態(tài)程序，與靜態(tài)的東西是不一樣的。我在網(wǎng)上看到的美女明星下了臺到眼前成了丑八怪，就是這個道理。而且更遭的是，客戶還同時犯第一個錯誤，看著那里不順眼就改一改版面還一天三變,不知不覺的基本用例就變成了另外一個東西，原來是賓館現(xiàn)在成了蓋殯儀館，原來搞錯了因為不知道躺的人不同叫不同的館（死人還是活人），試問，如何實現(xiàn)？項目開始和后期看到的同一個版面成為不同的故事絕對是經(jīng)常出現(xiàn)的故事，軟件上稱為需求變遷，這是項目經(jīng)常延期的最主要原因。
三是需求人員把定制了解成按客戶所有想法迎合靜態(tài)頁面，而不是按客戶的業(yè)務(wù)用例要求建立相應(yīng)的程序；還要求程序員也這樣做；實際上，如果不能撥亂反正的話，任何項目到此為止已經(jīng)是死路一條：那不是軟件，無非是靜態(tài)網(wǎng)頁人員出租！需求人員常犯的另一個錯誤仍是不懂用例，就是把用例的使用方式當(dāng)成了需求；這種錯誤有時連初級程序員都會犯，最典型就是把一個菜單欄目當(dāng)成需求，而程序員無法從菜單中看出明顯的簡潔的用例邏輯——這是一個沒有意義的菜單，天曉得里頭是什么？同樣地，里頭的要干的東西還一天三變。事實上，同一種邏輯用例可以用到N個欄目，那是軟件的使用而不是軟件本身。
以上的錯誤常見于網(wǎng)站建設(shè)，所以網(wǎng)站建設(shè)最通常的結(jié)局是不了了之，大概占了50%以上，無論設(shè)入多少錢多少人花多少時間都是如此的；除非有人能夠撥亂反正，讓項目需求走上正道。而在ERP/DRP這類項目中，需求人員一般情況下是業(yè)務(wù)的行家，他們反而很容易理解用例是什么東西，象醫(yī)院收費，絕對不會把精力放在收費界面有沒有脫衣舞女讓收費員提神上，收費這個用例有多少個環(huán)節(jié)是他們理解的。這種項目需求最易犯的錯誤是讓先進(jìn)的計算機工具重復(fù)原始狀態(tài)下的不合理的流程。最典型的笑話就是：手工審批要蓋五個章，用五天時間；現(xiàn)在電算化效率提高了一百倍，所以可以蓋五百個章（電子簽名呢?。?，時間嘛，仍然是五天！在這里，矛盾不是有沒有用例，而是用例是不是合理的，最高效率的。
所以對于需求由于用例的沖突，程序員如果不想不了了之最后責(zé)任全部背上身的話，最好就是堅持原則；程序員迎合網(wǎng)頁編寫是沒有意義的，遷就需求也不是沒有意義的，因為......無法遷就的，越是遷就就越是沒有辦法實現(xiàn)，或者客戶沒有辦法滿意的。軟件其實很簡單的，無非是分析好用例，然后讓計算機一步步實現(xiàn)而已，用例，是所有軟件實現(xiàn)的前提：不然，軟件到底要干什么？好的軟件項目都有一個共同的特點，就是簡單的邏輯，明確用例。