在做專案時，經常會碰到這樣的事情：客戶向我們反映在和你們的工程師談論需求時，他們總是滿口答應沒問題。可是，當他們做好以後，拿過來一看，根本就不是這麼回事。而開發人員也在訴苦：使用者什麼都不懂，而且他們的需求老是變動，時間又這麼緊,你讓我們怎麼辦？
我覺得如果開發人員在做需求分析時，需要注意下面幾點：
一、掌握相關的行業知識，會前做好充分準備
通常會面前的問題列表準備時間要遠遠多於會面的時間。通常客戶在連續和你交談2個小時之後，就會失去熱情和耐心，這是大部分人的共同特點。所以充分的準備工作很重要。如果你去客戶那捕獲需求，通常客戶會說，我需要做乙個什麼樣的系統，然後我可以用它來做這個，那個，還有那個……，然後就不知道該說什麼了。這 時，你一定要拿出事先準備的問題列表，針對每個大的功能的每乙個功能點進行提問，乙個都不能放過。對非功能的需求也同樣不能放過，如客戶需要的系統至少連 續執行多少小時不出問題，系統在若干數量的訪問者訪問時的響應時間範圍等。如果你在會面前沒有對客戶提供的資料，**等進行全面研究，對客戶需求就不可能調查全面，你可能需要反覆去約見他，這樣你會給客戶留下工作效率低的印象，他對你會逐漸的感到厭煩，對你未來的工作表現會失去信心。
在和客戶溝通之前，最好了解一下相關的行業知識。有乙個專案管理人員說：行業知識可有可無，作為需求人員，最重要的是和客戶溝通。最好把客戶講的東西都記下來。然後，由專案組決定後，再把意見反饋給使用者。這種溝通方式，既不能有效的發現問題，也容易延誤專案時間。
二、重在溝通
溝通的方式可以是訪談和調研、會議、**、電子郵件、小組討論、模擬演示等不同形式。我的意見是最好是與客戶面對面的溝通。金庸武俠**中的高手過招，都是面帶微笑，不露聲色，比拼的是內力。面對面的溝通，就是比拼內力。所以，一定要把準備工作都做好了。
溝通其實也是在相互妥協。對使用者合理的要求，要盡量滿足。使用者的一些不合理的要求，要想辦法避免。要委婉地提醒使用者，如果這樣做，可能要增加專案時間，或者對執行環境有更高的要求等等。溝通一定要有記錄，對於交流的結果還可以進行分類，便於後續的分析活動。如果是比較正式的溝通，還需要將會議記錄以郵件的形式發給雙方相關主要人員確認，抄送會議中的其他相關人員。
溝通中須注意下面幾個問題：
1、讓客戶開啟話匣子
對客戶進行提問，引導客戶說出他們的需求，是非常關鍵的，這裡面的學問也是很大的。有一些人通常會問這樣的問題：「你們的工作流程是什麼樣的?」，這種問題是非常經典的無效問題。當你向客戶提出問題的時候，你可以先進行換位思考，如果有人問你這個問題你該怎麼回答呢?是不是很好回答呢?如果連你也覺得這個問題並不好回答時，就需要考慮換個問法了。通常人們在談論自己很熟悉的東西時，都會有說不完的話，對於客戶自己每天做的工作，他為什麼沒辦法對你談呢?問恰當的問題，問能讓客戶開啟話匣子的問題，你就勝利了。這時你會面前的準備工作就顯得尤為重要了，你要針對他們要做的軟體的功能，一部分一部分的問，不能著急，要深入，並細緻，對於他們如何處理這些事情的操 作習慣等都要重視，因為要改變他們的習慣，讓他們適應你的軟體的一種新的操作方法通常是會降低客戶滿意度的，甚至他們會要求你進行修改。對於你對某些功能的猜想和假設，也一定要問客戶，是不是根本就不需要，客戶有時會礙於情面不好意思說出你的想法是沒有必要的或是錯誤的，這時你一定要足夠敏感，並勇於否定自己，這樣會減少不必要的開發工作，也會給客戶留下你很尊重事實的良好印象。
2、搞清能正確回答問題的人
不同的問題需要問不同的人，需求中有很多是細小的操作級別的問題，也有很多是關乎全域性的問題，這就要求一定要搞清楚什麼問題去問什麼人。很多捕獲需求的人員抱怨說，「客戶答不上這些問題，他們自己都不知道要怎麼做」，如果你碰到了這種事情，就要反省一下，你問對人了嗎?客戶中有一些是大幹部，有些是中層管理人員，還有操作人員。對於操作細節上的問題，一定要去問那些負責操作的人員，他們會更清楚每個步驟需要怎麼去操作，如果你去問大幹部這些問題，你通常會被搪塞，或者以工作太忙，還有其他得事等原因被打發掉。對於關乎全域性的問題，操作級別的人員給出的答案通常是不權威的，即便他們回答了你，你也一定要去大幹部那裡確認一下，再開始開發工作，否則你會後悔的。
3、千萬不要浪費客戶的時間
和客戶面談時特別要注意一點，就是千萬不能浪費客戶的時間，讓他覺得非常無聊，這是捕獲需求最大的忌諱。一旦你犯了這樣的錯誤，你再想約見他就難了，他很可能不願意再和你會面了。尤其是企業中的領導，他們通常是日理萬機，因此要格外珍惜會面的時間。這也是很多作需求的人員常常抱怨的問題，「客戶經常沒時間見我，我有什麼辦法」，如果你遇到了這類問題，你一定要反省一下自己，是不是曾經犯過這樣的錯誤，下次一定不要再犯了。
三、深究細節
不要等到專案做好後，才讓客戶發現問題。客戶所能提供給你的只是他們想到的功能需求，很多問題並不在他們考慮的範圍之內，如果作為專案承擔方沒有去做分析，簡單的按照功能要求去設計、規劃，最終出來的系統是很難完全符合客戶的業務流程的，這時，在客戶看來當然需要更改，但這種更改卻被我們看成了需求的更改。既然是需求的更改，那麼就需要增加專案 成本(資源)或延長專案時間。我看過一篇文章,說要要想專案成功，就得和使用者建立親密的夥伴關係。可是，這種以需求的更改為理由讓使用者從口袋裡掏錢,親兄 弟也不幹阿。所以，需求分析不僅僅是拿到客戶的需求，更重要的是還需進行分析，了解細節，並就細節跟客戶諮詢，獲取最詳細的資料。需求是最重要的工作，也是最麻煩的。 客戶是不懂需求的，他們的腦海裡面沒有這個概念， 他們只希望你做出能用的系統 ，用著順手就好。
四、充分利用需求確認會議
需求確認會議通常由全體涉眾(利益相關人)參加，這可是個確認需求的難得的機會，大家能聚在一起，這樣的機會其實很難得，所以一定要珍惜。在這種會議上，一定要先針對全域性性的問題(與大家都相關的問題)進行交流，千萬不要針對部分人感興趣的問題討論個沒完沒了，那樣的話，不感興趣的人會走 開的，那樣你再想徵求與他們相關問題的意見時就找不到人了。對於只跟個別部門或人員有關係的問題你可以單獨找時間根他們討論。
五、發揮原型的效力
了解需求後及時做出demo讓客戶確認，確認後要簽字。這一點非常重要，很多時候我們了解了需求就悶頭開發，等開發完畢後，卻不是客戶想要的東西，造成巨大浪費；簽字是為了讓客戶認真對待這個demo。demo能用就好，不要過多追求。程式設計師往往追求完美，想一下子把工作做到位；而最有效率的方法是盡快看到結果 然後再慢慢完善。在專案初期需求會經常改變，這樣的目的也是避免把過多時間耗在無用的需求上。demo對於提高客戶對軟體的認知程度有很好的效果，他能使客戶對軟體有乙個直觀的認識，面對原型，他們可以更好地提出他們的想法和意見，尤其對那些對軟體缺乏認識的客戶。對原型的修改，再確認，最後得到穩定的原型，這些工作會讓需求更穩定，減少很多實施工作中的反覆修改工作或者返工。
六、注意挖掘不能拿到臺面上講的非功能性潛在需求
我們在軟體開發驗收過程中得到很多的經驗教訓，最常見的問題是在開發過程中沒有抓住客戶的關鍵負責人或重要領導的意圖，沒有了解客戶看重的是什麼。而等到 開發團隊提出要驗收的時候，客戶又總是覺得這也不滿意那也不滿意，總之是不願意驗收
需求採集 使用者訪談的注意點
1 避免一組固定的問題 固定的問題會讓被訪者產生被審問的感覺，我們應該準備好問題清單，但清單只起乙個引導作用，並不用照著讀。2 首先關注目標，任務其次 比使用者行為更重要的是行為背後的原因，多問問使用者為什麼這麼做。3 避免讓使用者成為設計師 聽使用者說，但不要照著做，使用者的解決方案通常短淺，片面...
痛點以及需求分析
在大學生活中會遇到很多痛點，以下和結伴小夥伴李秦總結出的幾個痛點 1.宿舍樓平台 首先之所以會想到這個痛點，來自於從大一開始，a3女生宿舍樓的熱水就是壞的，反應了很多遍，到今年才修好。如果平時有什麼東西損壞的話，我們可以通過這 個平台和阿 姨們交流 更加方便。平時輪到哪個宿舍值班，也可以通過平台公告...
需求分析的介面需求 需求分析
本篇不是為業務分析人員寫的，不會細緻講解需求分析的方方面面，業務分析師可以看徐鋒的 軟體需求最佳實踐 或者王海鵬翻譯的 掌握需求過程 本篇立足於架構師視角，講解需求分析過程中應了解的過程和方法，以及需要特別關注的點。開發者拿到的往往是乙個個的方案，方案來自於需求，那麼開發者拿到的需求是怎麼來的？乙個...