調研的過程推薦開發商系統開發人員有專人進行會議記錄，並在每日會議結束後，當場宣佈本次會議的結果，並由參加會議人員進行簽字。第二日複印或發送電子文件給參加會議人員及相關人員。以便做到有據可查，明確過程。
注意：在調研過程的中系統開發人員的變更會對計劃產生重大的影響，不要簡單認爲是人員更換的問題。因爲在調研過程中對業務的理解，不是通過看看文檔就可以達到。3天通過討論達到對需求理解的程序，9天對文檔的學習也不一定能達到。
- 整體調研
對於調研過程中的整體調研，一定要其用戶主管者及用戶全體人員（含用戶IT人員）參加，第一個目的是瞭解用戶的整體需求細節，第二個目的使用戶人員從各自的角度也瞭解到用戶方要做一個什麼樣的系統。
需求提供者如果是一個人，他知道自己要一個什麼樣的系統。但如果是多人，在開發商系統分析人員進行調研前，每人也不過是計劃自己的需求而已，即使有時溝通，一般也是在討論而不是進行結論。使業務需求並不是很明確。整體調研的其中一個目的就是把用戶的多人需求組成一個整體，整體調研過程也是一個用戶人員溝通並整合需求的一個過程。
用戶方多人在進行開發商需求確認前，業務互相有分歧是相當正常的，開發商系統分析人員必須要在需求調研過程，使其達成一致。
一般情況下需明確以下問題:
當前整體業務需求的目的
要求提供的需求功能列表
已經定義的需求規則
將來發展的設想
明確服務器、客戶機的軟、硬件及性能要求（容量、速度、可操作性等）
用戶目前相關的技術人員和業務人員情況
將來最終系統操作人員的技術及業務人員情況
用戶需求的系統及用戶本身或其它系統的接口要求
用戶的其它要求
- 需求完全明確情況
對於整體調研過後就要進行各個具體業務需求的調研，對於具體需求調研如果是用戶提供的現有的文檔，開發商的系統分析人員只是對業務進行了解及進行修改爲系統分析人員及業務人員全可以看懂的需求說明書，那麼這個過程就比較容易。
只要系統分析人員把業務文檔看懂看明白，並且對於一些難理解的業務描述修改爲易懂（有些業務名詞有一定的專業性就要進行額外的說明）、明確進出的單據（數據項）就可以。當然編寫需求說明書具體的細節可以參見其他的衆多的書籍及文件模版了。
- 需求不完全明確情況
如果用戶對於自己的需求在調研開始並沒有完全明確，需要進行引導及細化，那麼這個過程就比較麻煩了。
對於用戶本身需求不明情況下，對於業務要先從基本業務進行細化，對於不明業務或不確定業務在後面進行。對於進出的單據一般在這種情況下用戶當沒有現在的文檔，這個過程只需明確單據的進出的必須數據源就可以，如果做到細節，由用戶在需求調研期確定單證，是不太可能的----只是設計單據的樣式、風格就不是短時間可以完成的。對於報表也只能明確基本報表要求及數據項。一般這種情況使用原型法進行，先做一個簡單的，在簡單的上面再進行完善。
對於用戶本身需求不明情況下的調研要做每日（或2到3天,最多3天爲間隔）的工作（分析進展）記錄，由雙方簽字，因爲調研過程會出現爲用戶要求添加一支新業務，對新業務進行分析後，因某些原因發現不能添加。這個過程的結果是一個0，但爲證明是0這結果可能花了很長的時間。要記錄這個過程，說明調研過程中做了什麼事情，有時有些人可能會說爲什麼這麼長時間纔出這點點東西，到時以便說明原因。
- 關於選取開發模型
有時開發模型的選取不是很容易判斷的，這裏面有時不單是需求及開發的問題，對於開發商有開發週期、開發費用的問題，對於用戶同樣有內部計劃、公司發展計劃等因素進行影響。
一般來說對於應用開發―――爲客戶開發軟件，客戶在開發及測試完畢軟件後就要實際開始使用，那麼就使用瀑布模型。
當然在需求明確的情況下自然也要使用瀑布模型
對於自主開發及客戶需求不明並有較長的設計時間―――可以用演化模型。
而螺旋模型適於適合於大型軟件開發，吸收了"演化"概念，不過有時也用於用戶需求不明的情況下。
當然還有其他開發模型，沒有在本文討論。
名詞定義：
瀑布模型：規定了各項軟件工程活動。包括：制定開發計劃、進行需求分析和說明、軟件設計、程序編碼、測試及維護。
特點：自上而下，相互銜接的固定次序，如瀑布流水、逐級下落。
演化模型：第一次只是試驗開發，其目標只在於探索可行性，弄清軟件需求;第二次則在此基礎上獲得較爲滿意的軟件產品，通常把一次得到的試驗性產品稱"原型"。
特點：減少由於軟件需求不明確而給開發帶來的風險。
螺旋模型：將瀑布模型及演化螺旋模型結合起來，並且加入被兩種模型都忽略了的風險分析，彌補了兩者的不足。
