這是大三上學期寫的，具體時間是軟體工程課程的“需求分析”階段結束之後。寫這篇文章的目的是将自己在這個過程的收獲記錄下來，并分享給其他三個團隊成員。剛才重看課程總結，想起還有這篇，就發到部落格上了。
歡迎大家點評，以下是正文：
-
與客戶交流非常重要。沒有明确需求，就會做很多無用功：
你以為使用者是這樣想的，寫出代碼。交給使用者時，使用者說他想要的不是這樣的功能。那你就得改代碼了。如果這個功能牽扯到其他很多功能呢？牽一發而動全身。到時候将會苦不堪言。
- 一定要主動與客戶聯系。你要知道，你做的是真實的項目，跟你的收入有關系。不要害怕與使用者交流，多交流可以減少很多麻煩。
1、交流前
- 仔細研究客戶已給出的需求描述。并記錄在研究時所有的疑問，無論大小。
記住，從多個角度進行分析。尤其要從使用者的角度進行分析。比如教師報課系統，從教務處的角度看，是整合多張表格；而從程式員的角度，是對資料庫添加的操作。要體會他們是如何看待這個問題的。
- 将客戶的需求進行分類，哪些是核心功能，哪些是不太重要的功能。
- 把所提供的功能，用思維導圖畫出來。這樣客戶就能從宏觀上看到所有功能。
- 做出原型，盡可能把所有功能展現出來。這裡就深入較為細節的部分，能在很大程度上解決需求不明确的情況。你了解的使用者需求，和使用者真實的需求，這之間相差有多大，通過原型就能展現出來。
如果可以，做出可以操作的原型，而不是靜靜地躺在紙上。網上有線上的原型制作工具，提供了制作可運作的原型的功能。
2、交流過程
- 帶上思維導圖和原型（紙質原型，能互動的原型也帶上）。
客戶可能無法在一開始就完全了解你跟他都說了什麼，沒有一個總體的概念。這些東西他可以在你進行講解的時候檢視對應的部分，也可以帶回去，好好了解你會做成什麼樣。
- 帶上筆和紙。
僅有思維導圖和原型是不夠的，客戶可能提出新的疑問，而這些疑問并不能通過思維導圖和原型進行解答。如果隻是用語言描述，客戶可能會了解錯你想要表達的意思。因為你在講解的時候，在頭腦中是有成像的，但是使用者在腦中并不能及時生成圖像，也就很難了解。這時候就可以用筆在紙上将你的想法畫出來，這樣更利于使用者了解你的想法。
- 如果項目不涉及機密，一定要提出錄音請求！
這有多重要呢？如果你沒有多少經驗，客戶傳達的很多重要的資訊，一開始你可能沒發現他們的重要性，或者認為你能記住它們，但過後卻忘了。客戶描述需求時，很可能自相沖突；或者描述不清楚，很難了解；或者你剛好在思考他的上幾句話，漏掉了他正在說的重要資訊。而一旦錄音，你可以不用害怕忘記什麼重要資訊，可以更專注于如何引導出使用者需求。
- 較長的描述原型的每一個功能該如何操作。
使用“使用者場景”進行描述：
- 給出一個目的
從軟體打開開始，一步一步展示，直至達到這個目的。
用這樣的方式給客戶展示一遍，能讓客戶較為全面了解你的軟體将做成什麼樣子。
- 要判斷是否能夠完成客戶的每一項需求，要大膽的說“不”。
不能老是讓客戶來決定該怎麼做，有些客戶的要求會讓你在實作功能的時候變得很複雜。你可能認為，客戶說怎麼做就怎麼做，這樣就是完美的了解使用者需求。盡管使用者需求很重要，但是砍掉不合理的需求也很重要，這樣才能實作共赢。
- 描述完你的原型之後，對這次交流進行一個總結。
讓客戶知道你是否都了解了剛才你們交流的内容。這樣客戶會更放心一些，因為他有了一個總體的概念。
- 交流結束，一定要留好聯系方式。讓客戶可以友善聯系到你，而你也可以友善聯系到他。
最好再找客戶要一下郵箱，這樣可以在必要的時候發項目進展給他，讓他可以對項目進行回報。
- 要讓客戶記住你的名字。
不然客戶怎麼稱呼你？
3、交流之後
- 整理在交流時的筆記。
- 聽錄音，補充筆記。
這時候你應該能從錄音中聽到很多你原本沒注意到的地方。
- 整理完之後，修改思維導圖和原型，再配上功能說明文檔，發給使用者。
本文采用知識共享署名 2.5 中國大陸許可協定進行許可。歡迎轉載，演繹或用于商業目的，但是必須保留本文的署名 schaepher（包含連結）。如您有任何疑問或者授權方面的協商，請給我留言。