這篇部落格的作者開篇這樣寫道：幸福的家庭都是一樣的，不幸的家庭卻各有各的不幸；幸福的軟體專案都是一樣的，不幸的軟體專案卻各有各的不幸；或者說，成功的軟體專案都是一樣的，失敗的專案卻各有各的問題。軟體的失敗原因千奇百怪，但說到根本，問題還是出在軟體需求和分析上。
從我們的角度來說，需求來源於使用者的一些“需要”，這些“需要”被分析、確認後形成完整的文件，這些文件又詳細地說明了產品“必須或應當”做什麼。
其實，開發軟體系統最困難的部分就是準確說明開發什麼。最困難的概念性工作是編寫出詳細的需求，包括所有面向使用者、面向機器和其它軟體系統的介面。這項工作一旦做錯，將會給系統帶來極大的損害，並且以後對它修改也極為困難。因此，需求分析就是在需求開發過程中，對所獲取的需求資訊進行分析，及時排除錯誤和彌補不足，確保需求文件正確地反映使用者的真實意圖。
由此可見，需求與分析的正確性與一個軟體專案是否能成功息息相關。我們要充分了解客戶的需求是否可行，如果把開發當做“有條件要上，沒有條件創造條件也要上”的魯莽之事，那麼結果必然是十分悲慘的。
在文中講解的一步步的需求調研中，我對每一步的關鍵點，理解如下：
1、初識：我們對客戶提出的需求進行深入理解以後，應該運用我們專業知識，提出比客戶的原始需求更加合理、可操作的解決方案。這就保證了我們在與客戶的初步交涉中，佔有了一定主動權，更容易調整客戶的預期，使客戶描述軟體的可行性更強。
再者，在與領導商議的會議時，要記住樹立良好的職業威信，進行詳細角色分析，將與會各方代表對號入座，以及從巨集觀上制訂目標與方案。
2、拜訪：經過一番交往，我們將逐漸在客戶中結識一批可以幫助我們的人。而今後一段日子裡，我們將依靠他們去學習和認識業務知識，收集業務需求，為日後的軟體研發提供素材。
3、研討會：業務研討會是重要的，但同時又是靈活的，沒有一個定式，甚至有時都不能稱之為會議。但恰恰它是重要的，為了有效抑制個性化差異並且分模組組織專項研討會。
4、需求研討：它不是一種簡單的你說我記的收集活動，而是在大量業務分析與技術可行性分析基礎上的分析活動。只有建立在這種分析基礎上的軟體研發，才能保證需求的正確與變更的可控。
5、迭代：每開發完一個迭代週期，將開發的成果與客戶反饋。這樣做，是為了讓客戶可以及時地提出我們對需求理解的偏差，或者及時提出對我們設計不滿意的地方，使我們存在的問題得到及時地發現與解決。問題及時的解決，使我們修復問題的代價得以降至最小。
6、需求捕獲：從需求列表到產品需求說明書，這之間要經過一段長長的路，這段路就是我們的分析與設計，而不是簡單的記錄與編寫文件。只有經過這樣的過程，最後得到的才是高質量的需求分析，才能有效地指導軟體研發，避免專案的風險。
7、功能角色分析與用例圖：這就到了軟體開發的UML階段。功能角色分析是對系統巨集觀的、整體的需求分析，它用簡短的圖形繪製出了一個系統的整體輪廓。但僅僅進行功能角色分析是遠遠不夠的，我們還需要在它的基礎上做更加詳盡的分析。
8、業務流程分析：ERP對企業流程改進，清除低效環節，簡化業務瓶頸，整合可用資源，自動化繁重操作。
9、用例說明：由於不同的人對用例的理解不同，格式也不盡相同，但一些基本的元素是一樣的。每次需要升級時，則新增上新的需求，或對以往的需求進行更新。
10、查詢報表分析：一個報表的核心就是展現給客戶的報表格式，以及報表與報表間的各種連結。需求人員在進行需求分析階段，應當準確地與客戶敲定這些格式，並最終在用例說明中體現出來。報表格式是否體現客戶的意圖，報表資料項是否都能在系統中取到，資料間的邏輯關係是否正確，報表格式是否技術可行，都是需求分析人員在前期就必須要分析到位的內容。
11、子用例與擴充套件用例：用例分析中對子用例與擴充套件用例的分析，使我們對系統的設計，從一開始就將公共的、可共享的部分提取出來，使我們在日後的設計與開發中得以很好地複用，提高了系統的內聚並降低了系統的耦合，是一個優秀軟體設計的開始。
12、行動圖和狀態圖。
13、業務領域分析。
14、領域驅動設計：需求人員在開始一個新的管理系統的分析工作時，都有可能面臨著一個全新的業務領域。每認識深入一點兒，就可能會體現到我們的分析設計中，並最終體現在開發的軟體中。我們對領域知識認識越深，軟體就再完善一分。
15、需求列表：需求列表中應當剔除那些客戶對系統設計的內容。
除這些外，軟體需求規格說明書、評審與簽字確認會也是很重要的。
在需求的問題上，這篇部落格給出了幾個例項來講解，我大概學到以下幾點，這或許就是王建民老師讓我們閱讀這篇部落格的關鍵所在。
我們當前軟體需求與分析所要掌握的必要內容：
1、當客戶提出業務變更的時候，一定不能被客戶牽著走，不要覺得客戶說啥就是啥。畢竟在軟體開發上，我們才是專業的，要從業務角度深入的去分析，他為什麼提出變更，提得是否合理，以及我們有沒有更合理的方案滿足這個需求。相信當我們提出更加合理的方案時，客戶必然是樂於接受的，那麼變更也變得可控了。
2、客戶提出的原始需求往往是不考慮技術實現，基於非計算機管理的操作模式提出來的，畢竟人家是非技術的，他們提出的很多需求常常比較理想而不切實際這也情有可原。我們必須要基於技術實現去引導客戶的需求。做需求就應當首先理解現有的管理模式，然後站在資訊化管理的角度去審視他們的管理模式是否合理，最後一步一步地去引導他們按照更加合理的方式去操作與管理。
3、一個軟體專案的需求調研首先必須要進行角色分析，然後對不同的角色分別進行調研。需求調研的初期需要召開專案動員大會，這是十分必要的。真正要完成需求分析，應該分成細化的小會，只討論某個領域的業務需求。
很多問題都不是能一蹴而就完成的，我們必須與專家建立聯絡，反覆溝通後完成。需求分析必須遵從的是一定的科學方法，而不是盲目的大上快上。
4、敏捷開發認為，需求分析階段不可能解決所有的需求問題，因此在設計、開發、測試，直到最終交付客戶，這整個過程都應當不停地用開發的成果與客戶交流，及時獲得反饋。只有這樣才能及時糾正需求理解的偏差，保證專案的成功。
對於一個失敗的專案來說，它們有的是需求的問題，有的是客戶關係的問題，還有設計的問題、技術的問題、時間管理的問題、人員培養的問題。但歸根到底，更多的卻還是需求的問題。需求分析既是人際交往的藝術，還是邏輯分析與嚴密思考的產物。正是我們在需求分析過程存在的巨大隱患，最終導致了那麼多專案的失敗。
要做到好的需求結果，我認為需要，大膽和使用者溝通。不要怕說錯、有不懂業務問題的一定要問使用者，不要怕打擾別人了，再者多寫各類軟體文件不要怕麻煩，多百度一下很多問題能解決，多推敲在使用者需求上能否在擴充套件更有用的東西。