項目需求分析是一個(gè)項目的開(kāi)端，也是項目建設的基石。在以往建設失敗的項目中，80％是由于需求分析的不明確而造成的。因此一個(gè)項目成功的關(guān)鍵因素之一，就是對需求分析的把握程度。
在原則上，需求階段監理應尊重承建方的項目管理和項目分析能力；在具體的任務(wù)開(kāi)展上，以不深入、不干擾承建方的自主權為主，除非在項目合作過(guò)程中發(fā)現承建方的項目管理以及項目分析能力存在很大的差距和不足。
為了保證項目的成功，監理方必須加強項目管理和項目分析工作，在具體的操作上可以堅持吸收、同化、貫徹的方法和手段。
其中，需求分析是一個(gè)項目的開(kāi)端，也是項目建設的基石。在以往建設失敗的項目中，80％是由于需求分析的不明確而造成的。因此一個(gè)項目成功的關(guān)鍵因素之一，就是對需求分析的把握程度。而項目的整體風(fēng)險往往表現在需求分析不明確、業(yè)務(wù)流程不合理，用戶(hù)不習慣或不愿意去用承建方的軟件。作為第三方的監理公司，必須提醒承建方、客戶(hù)方重視需求分析的重要性，采用必要的手段和方法來(lái)進(jìn)行需求調研，同時(shí)監理方也應深入具體的需求調研中去。只有這樣才能切切實(shí)實(shí)地把握用戶(hù)的需求和方向，才能在將來(lái)的功能界定、開(kāi)發(fā)范圍上有發(fā)言權。
如何進(jìn)行需求分析
需求分析不象偵探推理那樣需從蛛絲馬跡著(zhù)手，而是應該先了解宏觀(guān)的問(wèn)題，再了解細節的問(wèn)題。
一個(gè)應用軟件系統（記為S）的涉及面可能很廣，可以按不同的問(wèn)題域（記為D）分類(lèi)，每個(gè)問(wèn)題域對應于一個(gè)軟件子系統。
S={D1，D2，D3，…Dn}
問(wèn)題域Di由若干個(gè)問(wèn)題（記為P）組成，每個(gè)問(wèn)題對應于子系統中的一個(gè)軟構件。
Di={P1，P2，P3，…Pm}
問(wèn)題Pj有若干個(gè)行為（或功能，記為F），每個(gè)行為對應于軟構件中的實(shí)現接口。
Pj={F1，F2，F3，…Fk}
需求說(shuō)明書(shū)應該對于那些只想了解宏觀(guān)需求的領(lǐng)導，和需要了解細節的技術(shù)員都合適。在寫(xiě)需求說(shuō)明書(shū)時(shí)應該注意兩個(gè)問(wèn)題：
1.最好為每個(gè)需求注釋“為什么”，這樣可讓程序員了解需求的本質(zhì)，以便選用最合適的技術(shù)來(lái)實(shí)現此需求。
2.需求說(shuō)明不可有二義性，更不能前后相矛盾。如果有二義性或前后相矛盾，則要重新分析此需求。
重點(diǎn)監控需求分析
由于項目的特殊性和行業(yè)覆蓋的廣闊性，以及需求分析的高風(fēng)險性，軟件需求分析的重要性是不言而喻的，同時(shí)需求分析又的的確確難做。其原因基本是由于以下情況造成的。
客戶(hù)說(shuō)不清楚需求
有些客戶(hù)對需求只有朦朧的感覺(jué)，當然說(shuō)不清楚具體的需求。例如全國各地的很多部門(mén)、機構、單位在進(jìn)行應用系統以及網(wǎng)絡(luò )建設時(shí)，客戶(hù)方的辦公人員大多不清楚計算機網(wǎng)絡(luò )有什么用，更缺乏IT系統建設方面的專(zhuān)家和知識。此時(shí)，用戶(hù)就會(huì )要求軟件系統分析人員替他們設想需求。工程的需求存在一定的主觀(guān)性，為項目未來(lái)建設埋下了潛在的風(fēng)險。
需求自身經(jīng)常變動(dòng)
根據以往的歷史經(jīng)驗，隨著(zhù)客戶(hù)方對信息化建設的認識和自己業(yè)務(wù)水平的提高，他們會(huì )在不同的階段和時(shí)期對項目的需求提出新的要求和需求變更。事實(shí)上，歷史上沒(méi)有一個(gè)軟件的需求改動(dòng)少于三次的！所以必須接受“需求會(huì )變動(dòng)”這個(gè)事實(shí)，在進(jìn)行需求分析時(shí)要懂得防患于未然，盡可能地分析清楚哪些是穩定的需求，哪些是易變的需求，以便在進(jìn)行系統設計時(shí)，將軟件的核心建筑在穩定的需求上，同時(shí)留出變更空間。咨詢(xún)監理方在需求分析的功能界定上擔任一個(gè)中間、公平、公正的角色，所以也必須積極參與到需求分析的準備中來(lái)，以便協(xié)助客戶(hù)方和承建方來(lái)界定“做什么”、“不做什么”的系統功能界限。
分析人員或客戶(hù)理解有誤
軟件系統分析人員不可能都是全才，更不可能是行業(yè)方面的專(zhuān)家?？蛻?hù)表達的需求，不同的分析人員可能有不同的理解。如果分析人員理解錯了，可能會(huì )導致以后的開(kāi)發(fā)工作勞而無(wú)功。記得一則笑話(huà)，有個(gè)外星人間諜潛伏到地球刺探情報，它給上司寫(xiě)了一份報告：“主宰地球的是汽車(chē)。它們喝汽油，靠四個(gè)輪子滾動(dòng)前進(jìn)，嗓門(mén)極大，雙眼在夜里能射出強光……有趣的是，車(chē)里住著(zhù)一種叫作‘人’的寄生蟲(chóng)，這些寄生蟲(chóng)完全控制了車(chē)。”所以分析人員知識的專(zhuān)一性也會(huì )造成需求分析的誤解和失敗。這時(shí)，咨詢(xún)監理公司就必須根據實(shí)際的項目需求調研計劃，提醒承建方加強業(yè)務(wù)了解程度和注重溝通技巧。
需求分析方法論
根據以往的工程經(jīng)驗，需求分析工作方法，應該定位在“三個(gè)階段”（也稱(chēng)“三步法”）。
第一階段：“訪(fǎng)談式”（Visitation）
這一階段是和具體用戶(hù)方的領(lǐng)導層、業(yè)務(wù)層人員的訪(fǎng)談式溝通，主要目的是從宏觀(guān)上把握用戶(hù)的具體需求方向和趨勢，了解現有的組織架構、業(yè)務(wù)流程、硬件環(huán)境、軟件環(huán)境、現有的運行系統等等具體情況、客觀(guān)的信息。建立起良好的溝通渠道和方式。針對具體的職能部門(mén)以及各委辦局，最好能指定本次項目的接口人。
實(shí)現手段：訪(fǎng)談、調查表格
輸出成果：調查報告、業(yè)務(wù)流程報告
第二階段：“誘導式”（Inducement）
這一階段是在承建方已經(jīng)了解了具體用戶(hù)方的組織架構、業(yè)務(wù)流程、硬件環(huán)境、軟件環(huán)境、現有的運行系統等等具體實(shí)際、客觀(guān)的信息基礎上，結合現有的硬件、軟件實(shí)現方案，做出簡(jiǎn)單的用戶(hù)流程頁(yè)面，同時(shí)結合以往的項目經(jīng)驗對用戶(hù)采用誘導式、啟發(fā)式的調研方法和手段，和用戶(hù)一起探討業(yè)務(wù)流程設計的合理性、準確性、便易性、習慣性。用戶(hù)可以操作簡(jiǎn)單演示的DEMO，來(lái)感受一下整個(gè)業(yè)務(wù)流程的設計合理性、準確性等等問(wèn)題，及時(shí)地提出改進(jìn)意見(jiàn)和方法。
實(shí)現手段：拜訪(fǎng)（誘導）、原型演示
輸出成果：調研分析報告、原型反饋報告、業(yè)務(wù)流程報告
第三階段：“確認式”（Afirm）
這一階段是在上述兩個(gè)階段成果的基礎上，進(jìn)行具體的流程細化、數據項的確認階段，這個(gè)階段承建方必須提供原型系統和明確的業(yè)務(wù)流程報告、數據項表，并能清晰地向用戶(hù)描述系統的業(yè)務(wù)流設計目標。用戶(hù)方可以通過(guò)審查業(yè)務(wù)流程報告、數據項表以及操作承建方提供的DEMO系統，來(lái)提出反饋意見(jiàn)，并對已經(jīng)可接受的報告、文檔簽字確認。
實(shí)現手段：拜訪(fǎng)（回顧、確認），提交業(yè)務(wù)流程報告、數據項表；原型演示系統
輸出成果：需求分析報告、數據項、業(yè)務(wù)流程報告、原型系統反饋意見(jiàn)（后三者可以統一歸入需求分析報告中，提交用戶(hù)方、監理方進(jìn)行確認和存檔）
整體來(lái)講，需求分析的三個(gè)階段是需求調研中不可忽視一個(gè)重要的部分，三個(gè)階段或者說(shuō)三步法的實(shí)施和采用，對用戶(hù)和承建方都同樣提供了項目成功的保證。當然在系統建設的過(guò)程中，特別在采用迭代法的開(kāi)發(fā)模式時(shí)，需求分析的工作需一直進(jìn)行下去，而在后期的需求改進(jìn)中，工作則基本集中在后兩個(gè)階段中。
聯(lián)系客服
