我讀了《我們怎樣做需求分析》這篇部落格，讓我對如何做需求分析有了更多的認識與了解。如果我們想要跟好的做軟體需求分析，那麼我們需要做到初識、拜訪、研討會、需求研討、迭代、需求捕獲、（功能角色分析與用例圖、業務流程說明、用例說明、子用例與擴充套件用例、行**與動態圖、）查詢報表分析、原文分析法、領域區域設計、非功能需求、需求列表、乙個需求列表的例項、快速原型法、需求規格說明書、評審與簽字確認會。
1、初識——需求調研是需求分析最重要的一環，也最集中地體現了需求分析的特點——既是乙份體力活兒，更是乙份技術活兒。它既要求我們具有一種理解能力、設計能力，更要求我們具有一種與人交往、溝通的能力。我們對客戶提出的需求進行深入理解以後，運用我們專業知識，提出比客戶的原始需求更加合理、可操作的解決方案，讓客戶感覺你說的正是他們想要的。我們在進行需求調研的時候，什麼部門的需求就應當跟什麼部門談。同時，縱向又可以劃分為多個層次，如高層領導、中層領導與基層人員，理解這些方面格外重要。
2、拜訪——需求調研不是一蹴而就的事情，是一件持續數月甚至數年的工作
。在這漫長的時間裡，我們需要依靠客戶這個群體的幫助，一步一步掌握真實可靠的業務需求。不僅如此，技術這東西總有不如意甚至實現不了的地方，我們需要客戶的理解與包容，這都需要有良好的客戶關係。
3、研討會——
如何以合適的時間、合適的地點、通過合適的形式與客戶研討業務需求，
是乙個難題。分為
集中式的業務研討形
式、分布式的業務研討形式
。業務研討會是重要的，但同時又是靈活的，沒有乙個定式，甚至有時都不能稱之為會議。專案經理需要根據實際情況，合理地與客戶組織研討會。但不論怎樣組織，必須注意兩點：有效抑制個性化差異、分模組組織專項研討會。
4、需求調研——
應當怎樣與客戶討論業務需求
，首先跟客戶**的不是軟體功能，而是客戶現有的業務知識，用專業的話叫「業務領域分析」。然後
我們才能去分析他們提出的所有原始需求。
5、迭代——
需求分析不是一蹴而就的，是乙個反覆迭代的過程。它將從第一次需求分析開始，一直持續到整個專案生命週期
6、需求捕獲——
7、（功能角色分析與用例圖、業務流程說明、用例說明、子用例與擴充套件用例、行**與動態圖、）uml統一建模
8、調查報表分析——
9、原文分析法——
10、區域
11、12、
13、14、
15、16、
《我們應當怎樣做需求分析》閱讀筆記
通過閱讀 我們應當怎麼做需求分析 一文，我了解了需求分析的基本步驟和一些方法 1 需求調研 如何與客戶交流 建立聯絡 研討業務需求，捕獲需求 2 需求分析 功能角色分析 業務流程分析與業務領域分析，用例分析及用例圖，查詢報表分析，原文分析，非功能需求 3 需求確認 需求列表,需求例項，快速原型法，需...
《我們應該怎樣做需求分析》閱讀筆記
認識 軟體需求分析是貫穿軟體專案從出生到成長或者死亡的，我們必須搞清楚到手的軟體是為了什麼要做什麼做成什麼樣，通過顧客的描述彼此的合作分析需求與業務邏輯，不斷改進從而實現軟體在合理範圍內符合顧客要求。怎麼做 初識 人際交往，不失自我的禮貌尊重，感情上的聯絡促進關係，針對性分析角色需求。拜訪 情感交流...
閱讀部落格 《我們應當怎樣做需求分析？》筆記記錄
這篇部落格的作者開篇這樣寫道 幸福的家庭都是一樣的，不幸的家庭卻各有各的不幸 幸福的軟體專案都是一樣的，不幸的軟體專案卻各有各的不幸 或者說，成功的軟體專案都是一樣的，失敗的專案卻各有各的問題。軟體的失敗原因千奇百怪，但說到根本，問題還是出在軟體需求和分析上。從我們的角度來說，需求 於使用者的一些 ...