專案需求分析是乙個專案的開端，也是專案建設的基石。在以往建設失敗的專案中，80％是由於需求分析的不明確而造成的。因此乙個專案成功的關鍵因素之一，就是對需求分析的把握程度。
在原則上，需求階段監理應尊重承建方的專案管理和專案分析能力；在具體的任務開展上，以不深入、不干擾承建方的自主權為主，除非在專案合作過程中發現承建方的專案管理以及專案分析能力存在很大的差距和不足。
為了保證專案的成功，監理方必須加強專案管理和專案分析工作，在具體的操作上可以堅持吸收、同化、貫徹的方法和手段。
其中，需求分析是乙個專案的開端，也是專案建設的基石。在以往建設失敗的專案中，80％是由於需求分析的不明確而造成的。因此乙個專案成功的關鍵因素之一，就是對需求分析的把握程度。而專案的整體風險往往表現在需求分析不明確、業務流程不合理，使用者不習慣或不願意去用承建方的軟體。作為第三方的監理公司，必須提醒承建方、客戶方重視需求分析的重要性，採用必要的手段和方法來進行需求調研，同時監理方也應深入具體的需求調研中去。只有這樣才能切切實實地把握使用者的需求和方向，才能在將來的功能界定、開發範圍上有發言權。
如何進行需求分析
需求分析不象偵探推理那樣需從蛛絲馬跡著手，而是應該先了解巨集觀的問題，再了解細節的問題。
乙個應用軟體系統（記為s）的涉及面可能很廣，可以按不同的問題域（記為d）分類，每個問題域對應於乙個軟體子系統。
s=問題域di由若干個問題（記為p）組成，每個問題對應於子系統中的乙個軟構件。
di=問題pj有若干個行為（或功能，記為f），每個行為對應於軟構件中的實現介面。
pj=重點監控需求分析
由於專案的特殊性和行業覆蓋的廣闊性，以及需求分析的高風險性，軟體需求分析的重要性是不言而喻的，同時需求分析又的的確確難做。其原因基本是由於以下情況造成的。
客戶說不清楚需求
有些客戶對需求只有朦朧的感覺，當然說不清楚具體的需求。例如全國各地的很多部門、機構、單位在進行應用系統以及網路建設時，客戶方的辦公人員大多不清楚計算機網路有什麼用，更缺乏it系統建設方面的專家和知識。此時，使用者就會要求軟體系統分析人員替他們設想需求。工程的需求存在一定的主觀性，為專案未來建設埋下了潛在的風險。
需求自身經常變動
根據以往的歷史經驗，隨著客戶方對資訊化建設的認識和自己業務水平的提高，他們會在不同的階段和時期對專案的需求提出新的要求和需求變更。事實上，歷史上沒有乙個軟體的需求改動少於三次的！所以必須接受「需求會變動」這個事實，在進行需求分析時要懂得防患於未然，盡可能地分析清楚哪些是穩定的需求，哪些是易變的需求，以便在進行系統設計時，將軟體的核心建築在穩定的需求上，同時留出變更空間。諮詢監理方在需求分析的功能界定上擔任乙個中間、公平、公正的角色，所以也必須積極參與到需求分析的準備中來，以便協助客戶方和承建方來界定「做什麼」、「不做什麼」的系統功能界限。
分析人員或客戶理解有誤
軟體系統分析人員不可能都是全才，更不可能是行業方面的專家。客戶表達的需求，不同的分析人員可能有不同的理解。如果分析人員理解錯了，可能會導致以後的開發工作勞而無功。記得一則笑話，有個外星人間諜潛伏到地球刺探情報，它給上司寫了乙份報告：「主宰地球的是汽車。它們喝汽油，靠四個輪子滾動前進，嗓門極大，雙眼在夜裡能射出強光……有趣的是，車裡住著一種叫作『人』的寄生蟲，這些寄生蟲完全控制了車。」所以分析人員知識的專一性也會造成需求分析的誤解和失敗。這時，諮詢監理公司就必須根據實際的專案需求調研計畫，提醒承建方加強業務了解程度和注重溝通技巧。
需求分析方**
根據以往的工程經驗，需求分析工作方法，應該定位在「三個階段」（也稱「三步法」）。
第一階段：「訪談式」（visitation）
這一階段是和具體使用者方的領導層、業務層人員的訪談式溝通，主要目的是從巨集觀上把握使用者的具體需求方向和趨勢，了解現有的組織架構、業務流程、硬體環境、軟體環境、現有的執行系統等等具體情況、客觀的資訊。建立起良好的溝通渠道和方式。針對具體的職能部門以及各委辦局，最好能指定本次專案的介面人。
實現手段：訪談、調查**
輸出成果：調查報告、業務流程報告
第二階段：「誘導式」（inducement）
這一階段是在承建方已經了解了具體使用者方的組織架構、業務流程、硬體環境、軟體環境、現有的執行系統等等具體實際、客觀的資訊基礎上，結合現有的硬體、軟體實現方案，做出簡單的使用者流程頁面，同時結合以往的專案經驗對使用者採用誘導式、啟發式的調研方法和手段，和使用者一起**業務流程設計的合理性、準確性、便易性、習慣性。使用者可以操作簡單演示的demo，來感受一下整個業務流程的設計合理性、準確性等等問題，及時地提出改進意見和方法。
實現手段：拜訪（誘導）、原型演示
輸出成果：調研分析報告、原型反饋報告、業務流程報告
第三階段：「確認式」（afirm）
這一階段是在上述兩個階段成果的基礎上，進行具體的流程細化、資料項的確認階段，這個階段承建方必須提供原型系統和明確的業務流程報告、資料項表，並能清晰地向使用者描述系統的業務流設計目標。使用者方可以通過審查業務流程報告、資料項表以及操作承建方提供的demo系統，來提出反饋意見，並對已經可接受的報告、文件簽字確認。
實現手段：拜訪（回顧、確認），提交業務流程報告、資料項表；原型演示系統
輸出成果：需求分析報告、資料項、業務流程報告、原型系統反饋意見（後三者可以統一歸入需求分析報告中，提交使用者方、監理方進行確認和存檔）
整體來講，需求分析的三個階段是需求調研中不可忽視乙個重要的部分，三個階段或者說三步法的實施和採用，對使用者和承建方都同樣提供了專案成功的保證。當然在系統建設的過程中，特別在採用迭代法的開發模式時，需求分析的工作需一直進行下去，而在後期的需求改進中，工作則基本集中在後兩個階段中。
需求分析方法
專案需求分析是乙個專案的開端，也是專案建設的基石。在以往建設失敗的專案中，80 是由於需求分析的不明確而造成的。因此乙個專案成功的關鍵因素之一，就是對需求分析的把握程度。在原則上，需求階段監理應尊重承建方的專案管理和專案分析能力 在具體的任務開展上，以不深入 不干擾承建方的自主權為主，除非在專案合作...
ERP需求分析方法
專案需求分析是乙個專案的開端，也是專案建設的基石。在以往建設失敗的專案中，80 是由於需求分析的不明確而造成的。因此乙個專案成功的關鍵因素之一，就是對需求分析的把握程度。在原則上，需求階段監理應尊重承建方的專案管理和專案分析能力 在具體的任務開展上，以不深入 不干擾承建方的自主權為主，除非在專案合作...
需求分析的方法
1.識別使用者角色 確定主要參與者 actor 2.識別系統邊界，哪些是本次開發系統要做的，哪些是legacy系統做的等等 3.確定每個主演參與者的目標。4.展示給使用者看系統的主要功能，便於進一步細化 因為跟客戶談的時候是要先把大致的功能確定下來，才能就每個功能進一步談下去的，不可能一次性搞定，要...