今天閱讀了建民老師課件上提供的關於如何做需求分析的博文，下面把這篇博文的
一些重點總結一下。
需求分析既是乙份體力活兒，更是乙份技術活兒，它既是人際交往的藝術，又是邏輯分析與嚴密思考的產物。
作者給我們提出了幾個例子
第乙個故事講的是發生在東軟的事情，由於對客戶的需求了解不夠透徹最終導致了
整個這個專案組的所有成員都離開了東軟，這就是不了解客戶的需求。
深入地去理解客戶的業務，進而想到客戶的心坎兒上去，最後做出來的東西必然是客戶滿意的。
當客戶提出業務變更的時候，我們一定不能被客戶牽著走，客戶說啥就是啥。我們要從業務角度深入的去分析，
他為什麼提出變更，提得合不合理，我有沒有更合理的方案滿足這個需求。
當我們提出更加合理的方案時，客戶是樂於接受的，變更也變得可控了。
第二個故事告訴我們做需求就應當首先理解現有的管理模式，然後站在資訊化管理的角度去審視他們的管理模式是否合理，
最後一步一步地去引導他們按照更加合理的方式去操作與管理。
客戶提出的要求是根據他們心中的理想但是他們並不是技術人員，所以他們沒有考慮到需求分析必須實事求是的、基於技術可以實現的角度去考慮。
需求分析不是一蹴而就的，它應當貫穿整個開發周期，不斷的分析確認的過程。
本學期軟體需求與分析應該掌握需求調研、需求分析、需求確認，需求調研是需求分析最重要的一環，也最集中地體現了需求分析的特點——既是乙份體力活兒，
更是乙份技術活兒。它既要求我們具有一種理解能力、設計能力，更要求我們具有一種與人交往、溝通的能力。
我們對客戶提出的需求進行深入理解以後，運用我們專業知識，提出比客戶的原始需求更加合理、可操作的解決方案，讓客戶感覺你說的正是他們想要的。
業務研討會是重要的，但同時又是靈活的，沒有乙個定式，甚至有時都不能稱之為會議。專案經理需要根據實際情況，合理地與客戶組織研討會。但不論怎樣組織，必須注意兩點：有效抑制個性化差異、分模組組織專項研討會。
需求分析不是一種簡單的你說我記的收集活動，而是在大量業務分析與技術可行性分析基礎上的分析活動。只有建立在這種分析基礎上的軟體研發，才能保證需求的正確與變更的可控。
需求分析就是按照這樣的過程，每次多理解一些，再多理解一些，更多理解一些，逐漸深入的過程。每深入一步，我們的軟體就更接近客戶的滿意。
企業資訊化管理實質就是一次改革，是企業摒棄手工操作，向資訊化建設邁進的一次改革。既然是改革，就必須要改變過去不合理的管理流程，向更加合理和高效的管理流程邁進。因此，我們的需求捕獲最初是源於企業現有的操作流程，但當我們深入理解了客戶現有的操作流程以後，應當有意識地發現那些不合理的部分，並最終提出更加合理、更適於資訊化管理的流程。如果需求人員能上到這樣乙個高度，我們的需求分析就進入了乙個更加嶄新的層面。
需求分析：功能角色分析與用例圖、業務流程分析、用例說明、查詢報表分析、子用例與擴充套件用例、行**與狀態圖、業務領域分析、原文分析法、領域驅動設計、
非功能需求。
需求確認：需求列表、乙個需求列表的例項、快速原型法、需求規格說明書、評審與簽字確認會。
閱讀筆記（1） 軟體需求與分析需要掌握哪些重要內容
閱讀部落格 我們應當怎樣做需求分析 中幾個典型案例，結合網上查閱的資料得出一些心得總結 軟體需求分析，就是把軟體計畫期間建立的軟體可行性分析求精和細化，分析各種可能的解法，並且分配給各個軟體元素。是軟體定義階段中的最後一步，是確定系統必須完成哪些工作，也就是對目標系統提出完整 準確 清晰 具體的要求...
《軟體需求與分析》
在我看來，軟體需求與分析，說的就是我們這些程式設計人員要理解客戶的需求，分析客戶想要的究竟是什麼，來做出使客戶滿意的作品。專案經理在和客戶溝通的時候要清晰地理解客戶的需求，這將為後續的軟體設計打下良好的 基礎。需求調研 需求調研是需求分析最重要的一環，也最集中地體現了需求分析的特點 既是乙份體力活兒...
軟體需求與分析 問題賬戶需求分析
案例 某大銀行的一位銀行卡辦公室的收賬經理liz遇到了乙個問題。她每週都收到乙份過期未付款的賬戶名單。這份報告已經從兩年前的250個賬戶增加到現在的1250個賬戶。為了確定那些嚴重拖欠債務的賬戶，liz需要通讀這份報告。嚴重拖欠債務的賬戶由幾個不同的規則確定，每個規則都要求liz檢查客戶的一項或幾項...