最近經常都開電腦，搜索“需求”。因爲在寫一個需求分析書，我就是不明白，到底什麼是需求。網上很多的理論文檔，看的頭大。結果今天恰巧就看了一個寫的很好的。
最啓發我的部分是作者講的關於需求和功能的描述，我想我以前都沒有弄明白過。
那個打電話的例子最講的明白。希望我的朋友們能看到。
今天老大在晨會上給我們談了談需求，獲益匪淺，記錄於此：
關於需求：
1、什麼是需求？——理解需求和功能的區別
我們舉個例子，比如用手機打電話。首先，你需要開機，然後，手機通過無線電信號連接到基站，然後，打開手機通訊簿，找到小朱的電話號碼，接着，撥號、通話，通話完畢，掛斷。
在這裏，打電話是一個需求。給小朱打電話是一個需求的實例（需求的實例，有時也稱爲應用場景，可以拿來做系統測試用例，但是不能只開發專門給小朱打電話的手機！）。對於手機軟件而言，必須提供：開機、聯網、通訊簿、撥號、掛斷這幾項功能，才能滿足打電話這一個需求。
我們在做軟件的時候，常常會碰到：我已經做完了所有的功能了呀，爲什麼用戶還是不滿意呢？這就是將功能和需求混淆了。如果手機分別提供開機、聯網、通訊簿、撥號、掛斷這幾項功能，而不通過打電話這個需求將這些功能有機的聯繫起來，你說消費者還會買這款“具備了所有功能”的手機嗎？
2、需求是需要分析的
需求來自我們的用戶。但，用戶說的不一定是他想要的，他想要的未必都說了出來（也許是他不能、不會），所以，需求需要分析。
有時候路上碰到熟人，說：“小朱，有空吧？我請你吃飯去！”我其實有點餓了，但是習慣性的客氣幾句：“啊，不啦不啦，謝謝、謝謝，改天改天！”這叫做“口不應心”。這種場合當然是處於客氣，但是，對於軟件用戶，由於不是計算機專業的原因，的確不能說出他想要的來。
比如現在天氣熱了，用戶對你說，“小朱啊，幫我買只冰激凌來！”如果我不假思索，跑去買了一隻給他，他肯定說：“哎呀，我要的是巧克力味道的，你買的是牛奶的！”無語～～～只能跑去自掏腰包買一個牛奶的。如果是軟件系統，那麼就意味着加班趕工重做。。。
好了，第二次，另外一個用戶要買冰激凌，我這次學聰明瞭，先問：“您是要牛奶的，還是巧克力的？”他說，“巧克力的。”，我繼續問：“那麼是什麼牌子的，準備買多少錢的？”“伊犁的，2塊錢的那種。”好的，拿錢去買。
心想，這次應該沒有問題了吧？買了給他，一嘗，他說了，“哎呀，不對，還是牛奶的比較好！”暈倒～～～
到底要怎麼樣呢？
第三次，又有人要冰激凌，我決定這樣：“您爲什麼要冰激凌？”，用戶說：“因爲我口渴。”我分析了一下，在夏天口渴的話，冰激凌並不是解渴的，相反，甜膩膩的冰激凌吃了會更渴；什麼東西解渴呢？冰凍的綠茶是很解渴的，於是，我說：“您口渴的話，我建議還是喝綠茶比較好。冰凍的綠茶更加解渴。”如果用戶是理性的，他肯定會同意。於是我買來綠茶，口渴解決，項目圓滿完成！
如果用戶不理性呢？最好的做法是不要讓這些人成爲你的用戶。如果碰到了，解決的辦法也很多，但通常都要付出代價。比如，同時提供小份的冰激凌和綠茶的試用裝給他，他一試就知道要什麼了。但是，我們卻要付出製作小份試用裝的代價。對於軟件系統，這個代價有時候是很昂貴的。
所以，請不要將《需求規格說明書》作爲《用戶要求記錄單》來用，應該先運用你的專業知識來分析一下。
3、需求是會變的
通過分析、溝通，終於確定了一份需求文檔，簽了字，值得慶祝！但是，先別大意，因爲需求肯定會變的。
需求會變是一個現實，就像太陽每天東昇西落一樣。隨着工作開展的深入和對於系統的熟悉，用戶原來的想法肯定會和剛開始看一份抽象的方案不一樣。既然不會不變，我們只能想辦法來應變！（殘酷啊，現實！逼得我們進化！）
通常有2個手段：
（1）積極的溝通。及時瞭解變化，並進行變更控制管理。
（2）在系統的架構設計上，爲變化做準備。面向對象也好、面向服務也好、三層也好、四層也好，我們爲什麼把代碼分開層次，爲什麼提供那麼多抽象的接口？都是爲了應對變化，爲了我們在這個需求像雲彩一樣變化的環境中能夠適應。
所以，在癡迷的學習這些架構、設計模式的時候，別忘記是爲什麼要學習他們。
4、保持溝通渠道的暢通
說了上面一大堆，有一個前提還沒有講，就是和用戶的溝通渠道。（當然同樣重要的是公司內部的機制和溝通渠道，不過這不在本次的議題中，以後有機會再談。）
即使和用戶爭吵也比不相往來要好。需求是需要溝通來了解、來確認、來變化的。溝通，未必能夠做好需求（原因多方面，比如用戶對系統並不關心。。。）；但是不溝通，項目就失去了成功的機會。
無論無何，留住這個溝通的渠道，也許突然有一天用戶對你說：“哎呀，你辛苦啦，上次提的那個功能不做算啦！”：）