可能會導致用戶無法回答或敷衍了事地進行回答。提問可分為封閉式提問和開放式提問。
封閉式提問目的明確。如:現(xiàn)在你們的送貨單是手工填寫還是電腦打印?但過多使用封閉式提問，會導致談話枯燥，讓用戶感覺自己好像在接受審問。開放式提問是請對方對某一事物做進一步的解釋，可使談話達到一定的深度和廣度。
如:你認為目前的工作中存在哪些可以改進的地方?開放式提問缺點是容易使談話內(nèi)容偏離主題。因此在談話過程中，應采用封閉式和開放式提問相結合的方式。以簡單問題開始、從用戶熟悉的內(nèi)容開始。每次只提一個問題、集中一個重點，寧問勿猜。并盡量避免使用IT相關的一些術語，以便用戶能夠很好地理解我們的表達。
五、應實地了解用戶工作流程
實地觀察用戶執(zhí)行業(yè)務任務的過程。了解用戶什么時候獲得什么數(shù)據(jù)，并怎樣使用這些數(shù)據(jù)，業(yè)務處理 過程中需要處理哪些單據(jù)，需要和哪些角色的用戶發(fā)生關聯(lián)等。這都將有助于明確產(chǎn)品的功能需求。
經(jīng)驗證明，與人們面談關于他們?nèi)绾瓮瓿扇蝿諘r會有許多限制和不準確性，而這是任務觀察可以直接解決的。特別是對于某些組織中普遍接受的規(guī)則和方法，用戶認為你也應理所當然知道，而不曾提起時。
近年來，由于人機交互的復雜性驚人地增加，人機交互的觀察和記錄已引起人們的廣泛注意。觀察是一個主觀的領域，很大程度上依賴于需求分析者的經(jīng)驗。在經(jīng)銷商管理系統(tǒng)的需求分析中，通過觀察發(fā)現(xiàn):某些客戶要求送貨單中的商品價格為含稅價格，而有些客戶則要求送貨單上的商品價格為不含稅價格;有些商品的稅率為13%，而有的商品稅率為17%;
有些客戶要求送貨單上的金額小數(shù)點后保留四位，有的客戶又要求送貨單上必須提供自己公司的商品編碼等。而這些都是在調研中，用戶不曾提起的內(nèi)容。
六、確定需求的優(yōu)先級別
當客戶的期望很高、開發(fā)時間很短且資源有限時，設定需求的相對優(yōu)先級將有助于項目管理人員解決沖突、安排階段性交付并做出必要的取舍。建立每個需求的重要性有助于規(guī)劃軟件的構造，以最少的費用提供產(chǎn)品的最大功能。
特別是對漸進式的項目，優(yōu)先級的設定就顯得更為重要，因為在這些開發(fā)中，項目時間安排極為緊迫并且交付日期不可改變，一些低優(yōu)先級的需求就需要推遲到后續(xù)版本中進行實現(xiàn)或直接取消。
當眾多用戶因期望不同而就某些需求優(yōu)先級的設定難以達成一致意見時，需求分析者可指出每一需求所需的費用、難度、技術風險或其他特定的與權衡需求有關的指標，來客觀評價每一需求的優(yōu)先級。
七、分析需求可行性
柳傳志曾說:“沒錢賺的事我們不干;有錢賺但投不起錢的事不干;有錢賺也投得起錢但沒有可靠的人選，這樣的事也不干。”
柳傳志為聯(lián)想集團的決策確立了上述準則，同時也為可以行性分析指明了重點?？尚行苑治鲋饕轻槍δ骋恍枨鬀Q定是做還是不做。一般可行性主要考慮兩個方面的因素:技術和人。技術方面主要是分析在給定的時間段內(nèi)是否可實現(xiàn)所需的功能并滿足產(chǎn)品的質量要求等相關指標。很多時候，用戶的想法在實際實施過程中是不現(xiàn)實的。若一味地求全和盲目遵從用戶的設想，將為項目的后續(xù)工作帶來很大的風險。因此應盡量避免在需求分析中包含技術實施上有難度的功能。如在筆者曾經(jīng)負責的一個項目中，用戶要求新的管理系統(tǒng)應實現(xiàn)和用友、金蝶等管理系統(tǒng)的數(shù)據(jù)接口，以方便這些系統(tǒng)中的數(shù)據(jù)導人新的管理系統(tǒng)。
許諾提供與用友、金蝶等系統(tǒng)的數(shù)據(jù)接口，將為新系統(tǒng)的成功實施帶來很大的風險。因為熟悉這