需求分析不是壹蹴而就的，它應該貫穿整個開發周期，不斷地分析和確認過程。這是敏捷開發提倡的需求反饋。敏捷開發認為，在需求分析階段不可能解決所有的需求，所以從設計、開發、測試到最終交付給客戶的整個過程都要不斷地用開發的結果與客戶溝通，並及時得到反饋。只有這樣，才能及時糾正需求理解的偏差，保證項目的成功。
二、應該如何做需求調研？
1.初次相識。
在深入了解客戶提出的需求後，利用我們的專業知識，提出比客戶原有需求更合理、更具可操作性的解決方案，讓客戶覺得妳說的正是他們想要的。如果妳能做到這壹點，客戶不僅會欣然接受妳的提議，還會覺得妳很專業，妳在客戶心目中的形象也會在無形中得到提升，這樣妳就有更多的機會提出有利於發展的可行方案，降低發展的風險。這無疑會形成良性循環，但要做到這壹點並不容易。毫無疑問，與客戶接觸初期的表現起著極其關鍵的作用。
(1)高層領導關心的是宏觀目標，我們要和高層領導談軟件R&D目標、宏觀統計報表、決策支持功能。
(2)中層領導關心的是具體的收益，即軟件給各部門的信息管理帶來的收益。因此，中層領導是各種業務流程和功能模塊的需求決策者。他們關心的是功能的定義，業務流程的銜接，查詢報表的設計，但是對於壹些具體的操作，壹些具體業務流程的細節，他們並不是很關心。
(3)基層人員是每壹個業務流程的操作者，是未來軟件的真正使用者。他們是真正了解妳要開發的軟件的業務需求的領域專家，是妳需求調研的重點對象。而基層人員往往受限於自己的視野，可能只知道非常狹窄的工作範圍。所以，我們需要努力找到真正的業務廣泛、經驗豐富、有壹定大局觀的專家。此外，他們是未來軟件的真正用戶，他們的參與將使他們成為未來軟件實施的忠實支持者，這對其他運營商大有裨益。他們關心的是每個操作的細節。
俗話說萬事開頭難。如果妳在項目開始時總是感到困惑，這裏有三條建議給妳:
1)樹立良好的職業威信；
2)進行詳細的角色分析，並據此帶各方代表參加會議；
3)從宏觀角度制定目標和計劃。接下來的工作就是和各方代碼建立聯系，逐壹拜訪，壹步壹步的進行需求調研。
拜訪。
需求調研不是壹朝壹夕的事情，而是壹項持續數月甚至數年的工作(如果項目有後期維護的話)。在這漫長的時間裏，我們需要依靠客戶的幫助，壹步步掌握真實可靠的業務需求。不僅如此，技術總是不盡如人意，甚至無法實現。我們需要客戶的理解和包容，這就需要良好的客戶關系。盡管如此，我們不能總是期望所有的客戶都與我們合作，不可避免地會有人阻礙許多項目的發展。
3.研討會。
(1)由於業務人員自身的限制，不可能完全掌握所有業務領域的細節，熟悉的部分和不熟悉的部分總是存在的。
分。劃分業務組可以讓業務人員在自己最熟悉的業務範圍內參與討論，可以有效提高業務討論的質量；
(2)集中商務討論形式和分散商務討論形式；
(3)有效約束個體差異，分模塊組織專題研討。
4.商務討論
在需求分析過程中，客戶最大的問題是不能提出正確的需求，這表現在幾種形式上:
(1)因為不了解軟件，客戶也無法提出要求，也不知道軟件最終會是什麽樣子。這類客戶在需求討論過程中，目前只能描述手工管理的方式，不知道計算機會如何管理。
(2)可以提出壹些業務需求，但是當軟件制作到妳面前時，需求就會發生變化。這類客戶，能熟練使用電腦，對信息管理很清楚。他們提出的業務需求整體上應該是不可分割的。但由於沒有實物，軟件中的壹些具體操作並沒有完全想好。
(3)能夠非常詳細地提出業務需求，甚至有時會提出要做什麽。這類客戶參與過很多軟件信息化建設，有的甚至是軟件開發的半專業人士。但是他們提出的業務需求太具體了，甚至怎麽實現都有說，但有時候這些並不是最好的設計方案，可能在技術上很難實現，有些甚至過於理想化而無法實現。
解決方案:
業務領域分析:客戶現有的業務流程是什麽，有哪些操作？客戶的業務中有哪些東西和術語，如何定義，它們之間的關系是什麽？客戶每次操作的目的是什麽，為什麽要做，做出來的人工報表說明了什麽？
問題？
(1)我們在做需求分析的時候，不要僅僅停留在軟件本身，還要拓寬視野，延伸到與這個業務相關的那些領域。
(2)客戶提出的所有原始需求中，與業務實現相關的都是無效需求，只能作為我們的參考。
(3)還有壹些需求在技術上很難或不可能實現。我們應該耐心地說服和引導我們的客戶，並為他們提出壹個更合理的方案。
(4)需求分析不是簡單的收集活動，而是基於大量業務分析和技術可行性分析的分析活動。只有基於這種分析的軟件研發，才能保證需求的正確性和變更的可控性。
5.循環
在第壹個需求分析階段，我們需要和客戶反復討論壹段時間，而這個過程往往是這樣壹個循環往復的過程:需求捕捉->；需求整合->；需求驗證->；需求捕獲...
(1)需求捕捉:是我們與客戶召開研討會討論需求的活動，客戶可能會描述他們的業務流程，然後我們在紙上畫出簡單的流程草圖並及時記錄下來；在描述業務的同時，客戶可能會反復提及壹些業務術語，詳細詢問這些術語的含義以及與其他術語的關系，並用類圖或對象圖畫出簡單的草圖；客戶在描述業務的同時，還會提出軟件希望在未來實現的功能，比如能夠顯示報表，導出文件，以需求清單的形式記錄下來。壹個功能在需求列表中會有多個需求，每個需求要能在20個字以內用1和2句話描述清楚。需求清單是客戶提出的最原始的需求。它不摻雜任何分析和設計，是我們每個功能必須實現的內容。
(2)需求整理:是需求分析人員在需求研討會結束後，對討論內容進行分析整理的過程。首先，需求分析師要通過用例模型劃分整個系統的功能模塊和各個模塊的業務流程。用例模型分析是壹個由粗到細的過程，這樣的過程也是壹個符合人類認識世界的思維習慣的過程。首先要為整個系統畫壹個用例圖，設計壹個用例場景，依次分析這些用例，比如用例描述、流程分析、角色分析等等。當然，在分析整體用例的同時，還要進行整體的角色分析，畫出角色分析圖，進行流程分析，畫出流程分析圖(可以是傳統的流程圖，UML中的動作圖，甚至是簡單的原理圖等。)，然後在整體用例圖的基礎上依次為每個用例畫出用例圖。在每個用例圖中，多個用例會被劃分得更加詳細，用例描述、流程分析、角色分析等分析工作會依次進行。不斷地改進這個和那個，直到我們認為需求已經被清楚地描述了。
(3)領域模型:是對用戶業務領域中相關事物、相互關系和相互行為的描述，以對象圖和類圖的形式表示。需求者對領域模型的分析，對業務理解的深度，對未來軟件的設計，對軟件的功能擴展、升級和進化都有至關重要的作用。
(4)需求驗證:需求驗證應貫穿整個R&D周期，在不同時期表現出不同的形式。首先，在需求分析階段，需求驗證表現為對需求理解是否正確的信息反饋。需求分析師和客戶再次坐在壹起，逐壹描述我們對需求的安排和理解，而客戶則不時糾正壹些問題或者更深入的描述。我們認真記錄，回來整理，等待下壹次驗證。在需求分析的後期，我們還可以做壹些簡單的原型來更形象的描述我們對需求的理解，這樣會讓我們和客戶的溝通更加順暢。在隨後的設計和開發階段，我
科學家應該以叠代開發的形式來做。每次叠代後，將開發結果反饋給客戶。這樣壹來，客戶就可以及時提出我們對需求理解的偏差，或者提出我們設計不滿意的地方，這樣我們存在的問題就可以及時發現並解決。問題的及時解決可以將修復問題的成本降到最低。
6.需求捕捉
深入分析後會發現，客戶說出的需求只是整個軟件需求中的冰山壹角，有兩類需求需要我們自己去發掘:客戶沒說出的需求和客戶沒想到的需求。
(1)客戶的隱性需求是什麽？不是客戶故意顯擺自己的官，不想說，而是他們業務領域已經約定好的商業規則，被他們認為理所當然，根本不用說。但是作為剛剛涉足這個領域的需求人員，他們並不了解這些規則。如果采用被動的方式，只記錄客戶陳述的需求，無疑會失去這部分需求，這也是為什麽直到項目的後期才開發軟件並將交付，客戶卻說不是我想要的軟件，並提出壹大堆更改需求的理由。要求我們在需求分析的全過程中不斷學習業務知識。我在需求面試的初期，往往不是和客戶談需求，而是先和客戶談業務。妳是怎麽操作的？有哪些流程？誰來完成這些操作？妳為什麽這麽做？註意，在所有這些問題中，最後壹個是最重要的。客戶業務領域的所有操作和流程都有其自身的意義，體現了其內在的原因和作用。多問為什麽可以幫助我們深入了解這些領域。站在客戶的角度思考，然後深刻理解客戶為什麽提出業務需求。
(2)另壹種是客戶不曾想到的需求:在需求分析階段，雖然客戶不曾想到，但需求分析師是軟件研發領域的專業人士，他們應該在深入了解業務領域和需求的基礎上，通過分析提前發現這些需求。作為需求分析師，他們應該站在客戶的角度思考，我們的軟件應該設計成什麽樣子，每個需求的真實意圖是什麽。在此基礎上，運用專業知識進行整理、分析和設計。前面我提到過，客戶描述的原始需求寫在需求清單中，經過需求分析師的整理、分析和設計，通過用例分析和領域建模，最終形成產品需求規格說明書(或產品規格說明書)。先在壹些非正式的場合單獨和客戶交談，產生第壹手的信息，最後把這些需求放到更正式的場合，比如各部門參加的，有用戶代表參加的業務研討會