首先對於合同內建設的系統需求進行熟悉和掌握，了解甲方的大致需求，便於調研前的準備工作及切入點。
與甲方確認調研時間：若是甲方一味的推脫比較忙等，則需告知甲方負責人延期調研可能會帶來的負面影響及專案工期的延長，若是還是不行，可建議甲方向其分管領導反饋讓分管領導參與，利用職務安排任務等方式讓其他科室進行配合。
確定時間後，開展需求調研啟動會，讓參與的人員，涉及系統開發人員融入其中，明確自己的職責。
駐場調研，專案經理參與系統調研，把控好需求過程，做好需求對接，需在專案現場調研至少一周的時間，對於調研的成果進行分析梳理，存在疑問繼續找科室確認，與科室對接至少3次調研，至少2次確認，必須進行全面的調研，避免後期引起的需求變更及理解偏差產生的問題。
現場確認無問題後，需提交產品經理和專案經理進行審核，確認無問題後，進行需求內審會議，並明確內審的目的，讓大家知道內審會議有利於後期的系統開發，提高大家的重視度。注重細節，不放過一絲一毫，要讓參與人員內審會議的人都融入其中，了解專案需求是否可行。特別是原型的設計，美觀度直接影響到專案現場的確認，若是原型做的好，甲方還有看下去的必要，若是做的不好，甲方都不願意看，只會說系統好了再給我們看吧，但是就這麼句話則會給我們開發人員帶來很大的工作量。
會後需求人員及專案經理均需要形成會議紀要，然後雙方核實後認無異議，上傳svn。
根據討論的結果更新需求文件及原型，去專案現場與甲方科室對接確認。
與科室確認無異議，則通過。若存在新增問題或變更問題需要梳理，根據反饋問題程度確認是否需要再次進行內審，比如增加某個字段，這類問題可不需要再進行內審了，需求文件及原型更新後，共享svn併發訊息提醒相關人員檢視即可。若是問題比較嚴重，增加某個難以實現的功能，則需要再次進行內審會議。(重複6-8的步驟)
需求調研步驟和方法
第1章前言 目的需求調研是為需要說明書做前期工作，可以說需要說明書說是從需求調研表中得到或抽取而出。需求調研是要了解現實世界中做實際工作的人們真正需要什麼樣的程式的過程，再把這些需求開進細節整理由設計部開發，再由銷售部銷售給使用者。使用者 系統分析人員 第2章前期準備 2.1.確定工具 沒有什麼工具...
需求調研步驟和方法
第1章前言 目的 需求調研是為需要說明書做前期工作，可以說需要說明書說是從需求調研表中得到或抽取而出。需求調研是要了解現實世界中做實際工作的人們真正需要什麼樣的程式的過程，再把這些需求開進細節整理由設計部開發，再由銷售部銷售給使用者。使用者 系統分析人員 回頁首 第2章前期準備 2.1.確定工具 2...
問答系統調研
大型qa系統大多數是基於web資訊檢索的，各級nlp技術比如句法分析,ner,ir ie等都會涉及。還有一種是基於knowledge base的,將自然問句形式化成query，到知識庫裡檢索答案。如果想自己做乙個簡單系統的話可以先選擇乙個特定領域比如醫療qa，到網上抓取資料，用語義網rdf owl構...