分析人員或客戶理解有誤
軟件系統分析人員不可能都是全才，更不可能是行業方面的專家�？蛻舯磉_的需求，不同的分析人員可能有不同的理解。如果分析人員理解錯了，可能會導致以后的開發工作勞而無功。記得一則笑話，有個外星人間諜潛伏到地球刺探情報，它給上司寫了一份報告：“主宰地球的是汽車。它們喝汽油，靠四個輪子滾動前進，嗓門極大，雙眼在夜里能射出強光……有趣的是，車里住著一種叫作‘人’的寄生蟲，這些寄生蟲完全控制了車�！彼苑治鋈藛T知識的專一性也會造成需求分析的誤解和失敗。這時，咨詢監理公司就必須根據實際的項目需求調研計劃，提醒承建方加強業務了解程度和注重溝通技巧。
圖二 第二階段訪談式項目中角色、流程圖
需求分析方法論
根據以往的工程經驗，需求分析工作方法，應該定位在“三個階段”(也稱“三步法”。
第一階段：“訪談式”(Visitation)
這一階段是和具體用戶方的領導層、業務層人員的訪談式溝通，主要目的是從宏觀上把握用戶的具體需求方向和趨勢，了解現有的組織架構、業務流程、硬件環境、軟件環境、現有的運行系統等等具體情況、客觀的信息。建立起良好的溝通渠道和方式。針對具體的職能部門以及各委辦局，最好能指定本次項目的接口人。
實現手段：訪談、調查表格
輸出成果：調查報告、業務流程報告
第二階段：“誘導式”?Inducement?
這一階段是在承建方已經了解了具體用戶方的組織架構、業務流程、硬件環境、軟件環境、現有的運行系統等等具體實際、客觀的信息基礎上，結合現有的硬件、軟件實現方案，做出簡單的用戶流程頁面，同時結合以往的項目經驗對用戶采用誘導式、啟發式的調研方法和手段，和用戶一起探討業務流程設計的合理性、準確性、便易性、習慣性。用戶可以操作簡單演示的DEMO，來感受一下整個業務流程的設計合理性、準確性等等問題，及時地提出改進意見和方法。
實現手段：拜訪(誘導)、原型演示
輸出成果：調研分析報告、原型反饋報告、業務流程報告
第三階段：“確認式”?Afirm?
這一階段是在上述兩個階段成果的基礎上，進行具體的流程細化、數據項的確認階段，這個階段承建方必須提供原型系統和明確的業務流程報告、數據項表，并能清晰地向用戶描述系統的業務流設計目標。用戶方可以通過審查業務流程報告、數據項表以及操作承建方提供的DEMO系統，來提出反饋意見，并對已經可接受的報告、文檔簽字確認。
實現手段：拜訪(回顧、確認)，提交業務流程報告、數據項表;原型演示系統
輸出成果：需求分析報告、數據項、業務流程報告、原型系統反饋意見(后三者可以統一歸入需求分析報告中，提交用戶方、監理方進行確認和存檔)
整體來講，需求分析的三個階段是需求調研中不可忽視一個重要的部分，三個階段或者說三步法的實施和采用，對用戶和承建方都同樣提供了項目成功的保證。當然在系統建設的過程中，特別在采用迭代法的開發模式時，需求分析的工作需一直進行下去，而在后期的需求改進中，工作則基本集中在后兩個階段中。
圖三 第三階段訪確認式項目中角色、流程圖
文章來源于領測軟件測試網 http://www.kjueaiud.com/
