作者在第一段說“需求分析既是一份體力活兒，更是一份技術活兒，它是人際交往的藝術，又是邏輯分析與嚴密思考的產物。”然後作者講述了幾個故事來說明了需求分析。他的第一個故事講了東軟的一個項目過程中客戶不停地修改需求，最後以致於項目組的員工都離開了東軟，究其原因是他們只聽到了客戶表面上的需求說辭，沒有去站在用戶的角度理解客戶心裏真正想要的是什麽。正確的做法應是在用戶更改需求時我們去提出更加合理的方案去滿足用戶的需求。第二個故事是說在作者的一個早期項目中，客戶向他們提出了許多非常理想的但是技術上難以實現的需求，最後作者想盡方法去實現但最後還是失敗了。而面對這樣的用戶需求時，我們應該去在現有的技術的基礎之上引導客戶的需求，摒棄過去的手工管理模式，換成現有的信息管理模式。第三個故事是講作者參與的一個集團信息化建設的項目。該項目中的客戶有很多角色，不同的角色有不同的需求，但是作者在做需求分析時沒有認真分析所有的角色需求，所以在項目上線後，系統根本用不了。一個軟件項目的需求調研應該必須進行角色分析，然後面對不同角色分別調研。然後分別與領域內的專家溝通一個領域一個領域的做業務需求。第四個故事是講在項目的後期講項目交給客戶看時客戶提出了許多需改，然後趕時間修改項目，但項目上線後發現了許多BUG。這個故事告訴我們需求分析不是一開始就做好然後再不用管它的，而是貫穿整個項目。所以我們在項目開發時應在發布之前不停地將項目交給客戶與客戶溝通，然後根據客戶的滿意度繼續做需求分析。

很多需求分許的工作是從需求調研開始的，然後作者給我們介紹了幾種需求調研的方法：初始，拜訪，研討會，需求研討，叠代，需求捕獲。在與客戶初識時，我們應該在客戶提出需求後提出更加專業，更加合理可操作性的解決方案，真正理解客戶內心想要的東西。而不是討好客戶，唯唯諾諾，讓客戶提出非常理想卻不能實現的需求。除此之外，當我們面對許多角色時，我們應該向不同的部門尋求不同的需求。與高層討論宏觀的目標，與中層討論功能的定義，業務流轉的銜接，查詢報表的設計等，與基層的領域內專家討論軟件的細節。在與客戶認識後應該經常拜訪客戶，與客戶建立良好的關系。在隨後的客戶交流中去得到對軟件的幫助。當軟件存在個性化的問題時，通常會集聚不同的業務需求的客戶分成若幹個業務組，在客戶最熟悉的領域內討論需求。當客戶不能集聚在一起時，就需要我們開需求研討會。

在捕獲需求後，我們需要做需求分析。作者給我們介紹了幾種需求分析方法：功能角色分析與用例圖，業務流程分析，用例說明，查詢報表分析，子用例與擴展用例，行動圖與狀態圖，業務領域分析，原文分析法，領域驅動設計，非功能需求。大部分都在我們上學期的UML建模語言課上都學習過。

當我們捕獲到需求後，為了我們得到的需求與客戶心中的需求相同，所以我們需要向客戶再確認一次，這就是需求確認。作者給我們介紹了幾種需求確認的方法：需求列表，一個需求列表的實例，快速原型法，需求規格說明書，評審與簽字確認會。需求列表不摻雜我們對業務需求的任何分析與設計和客戶對系統設計的內容。項目過程中每一次升級維護都不斷增添和修改需求求列表。而需求列表是經過初次與評審人員的業務討論以後而得出。有了需求列表，需求分析後，每項都檢查是否滿足用戶需求。快速原型法就是在需求分析階段拿出實物，用實物與客戶確認需求。需求規格說明書的重要作用是摒棄不可行的需求或者換成更加可行的解決方案。當做出需求列表與需求規格說明書後，最後一項就是需求評審會。

最後，我通過閱讀這篇文章，整理出了學習軟件需求的知識點。

《我們應當怎樣做需求分析》閱讀筆記