項目需求分析是壹個項目的開始，是項目建設的基石。過去失敗的項目80%都是因為需求分析不清造成的。因此，項目成功的關鍵因素之壹是對需求分析的把握程度。原則上，需求階段的監理應尊重承包商的項目管理和項目分析能力；在具體任務的開發中，不要深入，不要幹預承辦人的自主權，除非在項目合作過程中發現承辦人的項目管理和項目分析能力有很大的差距和不足。為了保證項目的成功，監理方必須加強項目管理和項目分析，在具體操作中堅持吸收、同化和實施的方法和手段。其中，需求分析是壹個項目的開始，是項目建設的基石。過去失敗的項目80%都是因為需求分析不清造成的。因此，項目成功的關鍵因素之壹是對需求分析的把握程度。項目的整體風險往往表現在需求分析不清晰，業務流程不合理，用戶不習慣或不願意使用承包商的軟件。作為第三方監理公司，必須提醒承包方和委托方需求分析的重要性，采取必要的手段和方法進行需求調研。同時，監理方也要深入具體需求調研。這樣才能真正把握用戶的需求和方向，對未來的功能定義和開發範圍有發言權。如何進行需求分析？需求分析不需要像偵探推理壹樣從線索入手，而應該先了解宏觀問題，再了解細節。壹個應用軟件系統(標記為S)可以覆蓋很大的範圍，並且可以被分類為不同的問題域(標記為D)，每個問題域對應於壹個軟件子系統。S={D1，D2，D3，…Dn}問題域Di由幾個問題(表示為P)組成，每個問題對應子系統中的壹個軟組件。Di={P1，P2，P3，…Pm}問題Pj有幾個行為(或函數，記為F)，每個行為對應軟件組件中的實現接口。Pj={F1，F2，F3，…Fk}需求規格說明書要適合只想知道宏觀需求的領導和需要知道細節的技術人員。寫需求說明書要註意兩個問題:1。每個需求最好都註明“為什麽”，這樣程序員才能理解需求的本質，選擇最合適的技術來實現這個需求。2.需求陳述不能模棱兩可，更不能前後矛盾。如果有不明確或不壹致的地方，應該重新分析這個需求。重點監控需求分析由於項目的特殊性和行業的廣泛性，以及需求分析的高風險性，軟件需求分析的重要性不言而喻，同時需求分析確實很難做。究其原因，基本上是因為以下幾個條件。客戶說不清楚需求。有的客戶只是對需求有壹個模糊的感覺，當然也說不清楚具體的需求。例如，當全國許多部門、機構和單位都在建設應用系統和網絡時，客戶端的大多數辦公人員對計算機網絡的使用並不清楚，他們缺乏IT系統建設方面的專家和知識。此時，用戶會要求軟件系統分析師為他們設想需求。項目的需求具有壹定的主觀性，這為項目的未來建設埋下了潛在的風險。根據以往的歷史經驗，隨著客戶對信息化建設的理解和自身業務水平的提高，在不同的階段和時期會對項目的需求提出新的要求和變化。其實歷史上沒有軟件需求變更少於三次的！因此，我們必須接受“需求會改變”的事實。在分析需求的時候要懂得防患於未然，盡量分析哪些需求是穩定的，哪些是可變的，這樣才能把軟件的核心建立在穩定的需求上，在設計系統的時候留有變化的空間。咨詢主管在定義需求分析的功能時起著中介、公平、公正的作用，因此也必須積極參與需求分析的準備工作，從而幫助客戶和承包商定義“做什麽”和“不做什麽”的系統功能邊界。分析師或客戶誤解軟件系統分析師不可能都是通才，更不要說行業內的專家了。不同的分析師可能對客戶表達的需求有不同的理解。如果分析師理解錯了，可能會導致以後的開發工作白費。我記得壹個笑話，壹個外星間諜潛入地球刺探信息。他給老板寫了壹份報告:“汽車主宰地球。它們喝汽油，用四個輪子向前滾動，聲音很大，眼睛在晚上能射出強光...有趣的是，車內生活著壹種叫做‘人’的寄生蟲，這些寄生蟲完全控制了汽車。”因此，分析師知識的特異性也會導致需求分析的誤解和失敗。這時候咨詢監理公司壹定要根據實際項目需求研究方案，提醒承包商加強業務理解，註意溝通技巧。需求分析的方法論根據以往的工程經驗，需求分析的工作方法應該定位在“三階段”(也叫“三步法”)。第壹階段:“面談”是與特定用戶的領導、業務人員進行面談溝通。主要目的是從宏觀角度把握用戶的具體需求方向和趨勢，了解現有的組織架構、業務流程、硬件環境、軟件環境、現有操作系統等具體的訪問和客觀信息。建立良好的溝通渠道和方式。對於具體的職能司局，最好指定這個項目的接口人。實施手段:訪談、調查表格輸出:調查報告、業務流程報告第二階段:“誘導”這壹階段是在承包商了解組織架構、業務流程、硬件環境、軟件環境、現有操作系統等具體實用客觀信息的基礎上，制作壹個簡單的用戶流程頁面。，結合現有的軟硬件實現方案。同時，結合以往的項目經驗，采用歸納和啟發式的研究方法和手段，與用戶探討業務流程設計的合理性、準確性、便捷性和習慣性。用戶可以通過操作壹個簡單的DEMO來感受整個業務流程的設計合理性和準確性，並及時提出改進的建議和方法。實現手段:拜訪(歸納)、原型演示、輸出結果:調查分析報告、原型反饋報告、業務流程報告。第三階段:“Afirm”是根據以上兩個階段的結果進行流程細化和數據項確認的階段。在此階段，承包商必須提供原型系統、清晰的業務流程報告和數據項表，並向用戶清晰描述系統的業務流程設計目標。用戶可以通過查看承包商提供的業務流程報告、數據項列表和運行演示系統給出反饋，並在接受的報告和文件上簽字確認。實施手段:拜訪(審核確認)並提交業務流程報告和數據項列表；原型演示系統輸出:需求分析報告、數據項、業務流程報告、原型系統反饋(後三者可以統壹在需求分析報告中，提交給用戶和主管確認存檔)。總的來說，需求分析的三個階段是需求調查的重要組成部分，三個階段或三步法的實施和采用也為用戶和承包商雙方提供了項目成功的保證。當然，在系統建設過程中，尤其是采用叠代開發模式時，需求分析需要壹直進行，而在後期的需求改進中，工作基本集中在後兩個階段。