一、
初識我們對客戶提出的需求進行深入理解以後，運用我們專業知識，提出比客戶的原始需求更加合理、可操作的解決方案，讓客戶感覺你說的正是他們想要的。
劃分清楚角色，弄清楚每個角色的需求提出者與決策者，就是為了在今後的需求調研中找對正確的人，使今後的調研工作事半功倍
1）樹立良好的職業威信；2）進行詳細角色分析，將與會各方代表對號入座；3）從巨集觀上制訂目標與方案。隨後的工作，就是與各方**建立聯絡，逐一拜訪他們，將需求調研工作一步一步進行下去。
拜訪做事先培養感情，感情培養起來才好慢慢做事
研討會業務研討會是重要的，但同時又是靈活的，沒有乙個定式，甚至有時都不能稱之為會議。專案經理需要根據實際情況，合理地與客戶組織研討會。但不論怎樣組織，必須注意兩點：有效抑制個性化差異、分模組組織專項研討會
需求研討
認識客戶的業務領域之後，我們才能去分析他們提出的所有原始需求。
迭代需求捕獲
從客戶嘴中說出來的需求，只是整個軟體需求中的冰山一角，還有兩類需求需要我們自己去挖掘：客戶嘴中沒有說出來的需求，和客戶壓根兒就沒有想到的需求。在深入理解業務領域與需求的基礎上，通過分析提前發現這些需求。
功能角色分析和用例圖
不同型別的軟體專案其分析方法可能存在差異，但一般來說，資訊化管理類軟體專案通常從這幾個方面著手分析：功能角色分析、業務流程分析與業務領域分析。
用例圖中通常有三種元素：參與者（actor）、用例（use case）與系統邊界（boundary）。
業務流程分析(細化需求)
分析哪些是系統之內的，哪些是系統之外的。
用例說明
當我們進行業務流程分析時，繪製行**、狀態圖，以及編寫用例說明
查詢報表分析
根據需要設計自己的格式
子用例和擴充套件用例
用例分析中對子用例與擴充套件用例的分析，使我們對系統的設計，從一開始就將公共的、可共享的部分提取出來，使我們在日後的設計與開發中得以很好地復用，提高了系統的內聚並降低了系統的耦合，是乙個優秀軟體設計的開始。
行**和狀態圖
業務領域分析
對需求分析中涉及到的業務實體，以及它們相互之間關聯關係的分析。
原文分析法
對用例說明中事件流部分的文字描述，提取其中的名詞。
系統之內的事物轉化到領域模型中，可能會變成兩種東西：實體與實體中的屬性。
名詞的多義性。
用例說明中的動詞分析，是為了定義各個實體之間的各種行為。原文分析方法，給了我們乙個簡單可行、易於操作的方法，讓我們準確而高效地完成業務領域分析。
領域驅動設計
非功能需求
非功能需求更加靠近的是技術，是設計，是實現，是架構師關注的內容，是需求人員最不擅長的方面
那麼哪些是非功能需求呢？我們可以簡單歸納為「urps+」，即可用性（usability）、可靠性（reliability）、效能（performance）、可支援性（supportability）以及其它（+）。而這5部分我們可以進一步細化。
需求列表
我們的專案需要對需求的跟蹤
需求列表，又稱之為需求跟蹤表，是最原始的、使用者對業務需求的描述。它不摻雜任何需求分析人員對業務需求的分析與設計，而是以簡短扼要的語句，以業務人員的口吻表述的，今後要開發的這個系統應當提供給他們的各項功能。
快速原型法
我們就應當在需求分析階段拿出實物，用實物與使用者確認需求
需求規格說明書
本著實事求是、切實可行的態度，去描述使用者的業務需求。那些不可行的需求被摒棄，或者換成更加可行的解決方案。
評審與簽字確認會
需求評審會的主要目的就是確認需求，以便以此開始我們的設計開發工作。從理論上說，需求評審會應當由使用者代表，與專案經理、需求分析員、系統架構師、設計人員、測試人員、qa經理，還有公司相關領導參加。但實際上，讓如此多不同角色的人聚集在一起開會是不現實的。因此，我們可以將需求評審會分為內部評審會與外部評審會兩部分來開比較現實。
部落格閱讀筆記
1 rest框架 2 天地不仁，以萬物為芻狗 聖人不仁，以百姓為芻狗 3 進入看圖說話時代，如漫畫版的 水滸 等 4 錢多為啥看不見？關於減稅的建議 5 在公司政治中生存 6 從美食家到點菜家 7 無建議不批評 客觀描述清楚問題的事實 分清問題的輕重緩急 考慮解決問題的條件與條件獲得途徑 提出解決問...
部落格閱讀筆記
初識 我們對客戶提出的需求進行深入理解以後，運用我們 專業知識，提出 比客戶的原始需求更加合理 可操作的解決方案，讓客戶感覺你說的正是他們想要的。劃分清楚角色，弄清楚每個角色的需求提出者與決策者，就是為了在今後的需求調研中找對正確的人，使今後的調研工作事半功倍 1 樹立良好的職業威信 2 進行詳細角...
部落格閱讀筆記
1.初識客戶，2.拜訪，3.研討會，4.需求調研，5.迭代，6.需求捕獲，7.需求分析 1.首先要求我們具有一種與人交往 溝通的能力 劃分清楚角色。能夠準確，恰當的和不同的人進行溝通 並從他們的話語中能夠知道他們身處不同地位所考慮的不同問題 不同的部門，由於業務的不同，對軟體的需求自然是不同的，因此...