編者按：項目需求分析是一個項目的開端，也是項目建設的基石。在以往建設失敗的項目中，80％是由于需求分析的不明確而造成的。因此一個項目成功的關鍵因素之一，就是對需求分析的把握程度。

　　在原則上，需求階段監(jiān)理應尊重承建方的項目管理和項目分析能力；在具體的任務開展上，以不深入、不干擾承建方的自主權為主，除非在項目合作過程中發(fā)現承建方的項目管理以及項目分析能力存在很大的差距和不足。

　　為了保證項目的成功，監(jiān)理方必須加強項目管理和項目分析工作，在具體的操作上可以堅持吸收、同化、貫徹的方法和手段。

　　其中，需求分析是一個項目的開端，也是項目建設的基石。在以往建設失敗的項目中，80％是由于需求分析的不明確而造成的。因此一個項目成功的關鍵因素之一，就是對需求分析的把握程度。而項目的整體風險往往表現在需求分析不明確、業(yè)務流程不合理，用戶不習慣或不愿意去用承建方的軟件。作為第三方的監(jiān)理公司，必須提醒承建方、客戶方重視需求分析的重要性，采用必要的手段和方法來進行需求調研，同時監(jiān)理方也應深入具體的需求調研中去。只有這樣才能切切實實地把握用戶的需求和方向，才能在將來的功能界定、開發(fā)范圍上有發(fā)言權。

　　如何進行需求分析

　　需求分析不象偵探推理那樣需從蛛絲馬跡著手，而是應該先了解宏觀的問題，再了解細節(jié)的問題。

　　一個應用軟件系統（記為 S）的涉及面可能很廣，可以按不同的問題域（記為D）分類，每個問題域對應于一個軟件子系統。

　　S = { D1，D2，D3，… Dn }

　　問題域Di 由若干個問題（記為P）組成，每個問題對應于子系統中的一個軟構件。

　　Di = { P1，P2，P3，… Pm }

　　問題Pj有若干個行為（或功能，記為F），每個行為對應于軟構件中的實現接口。

　　Pj = { F1，F2，F3，… Fk }

　　需求說明書應該對于那些只想了解宏觀需求的領導，和需要了解細節(jié)的技術員都合適。在寫需求說明書時應該注意兩個問題：

　　1.最好為每個需求注釋“為什么”，這樣可讓程序員了解需求的本質，以便選用最合適的技術來實現此需求。

　　2.需求說明不可有二義性，更不能前后相矛盾。如果有二義性或前后相矛盾，則要重新分析此需求。

　　

　　圖一 第一階段訪談式項目中角色、流程圖

　　重點監(jiān)控需求分析

　　由于項目的特殊性和行業(yè)覆蓋的廣闊性，以及需求分析的高風險性，軟件需求分析的重要性是不言而喻的，同時需求分析又的的確確難做。其原因基本是由于以下情況造成的。

　　客戶說不清楚需求

　　有些客戶對需求只有朦朧的感覺，當然說不清楚具體的需求。例如全國各地的很多部門、機構、單位在進行應用系統以及網絡建設時，客戶方的辦公人員大多不清楚計算機網絡有什么用，更缺乏IT系統建設方面的專家和知識。此時，用戶就會要求軟件系統分析人員替他們設想需求。工程的需求存在一定的主觀性，為項目未來建設埋下了潛在的風險。

　　需求自身經常變動

　　根據以往的歷史經驗，隨著客戶方對信息化建設的認識和自己業(yè)務水平的提高，他們會在不同的階段和時期對項目的需求提出新的要求和需求變更。事實上，歷史上沒有一個軟件的需求改動少于三次的！所以必須接受“需求會變動”這個事實，在進行需求分析時要懂得防患于未然，盡可能地分析清楚哪些是穩(wěn)定的需求，哪些是易變的需求，以便在進行系統設計時，將軟件的核心建筑在穩(wěn)定的需求上，同時留出變更空間。咨詢監(jiān)理方在需求分析的功能界定上擔任一個中間、公平、公正的角色，所以也必須積極參與到需求分析的準備中來，以便協助客戶方和承建方來界定“做什么”、“不做什么”的系統功能界限。

　　分析人員或客戶理解有誤

　　軟件系統分析人員不可能都是全才，更不可能是行業(yè)方面的專家?？蛻舯磉_的需求，不同的分析人員可能有不同的理解。如果分析人員理解錯了，可能會導致以后的開發(fā)工作勞而無功。記得一則笑話，有個外星人間諜潛伏到地球刺探情報，它給上司寫了一份報告：“主宰地球的是汽車。它們喝汽油，靠四個輪子滾動前進，嗓門極大，雙眼在夜里能射出強光……有趣的是，車里住著一種叫作‘人’的寄生蟲，這些寄生蟲完全控制了車?！彼苑治鋈藛T知識的專一性也會造成需求分析的誤解和失敗。這時，咨詢監(jiān)理公司就必須根據實際的項目需求調研計劃，提醒承建方加強業(yè)務了解程度和注重溝通技巧。

　　

　　圖二 第二階段訪談式項目中角色、流程圖


　　需求分析方法論


　　根據以往的工程經驗，需求分析工作方法，應該定位在“三個階段”（也稱“三步法”）。

　　第一階段：“訪談式”（Visitation）

　　這一階段是和具體用戶方的領導層、業(yè)務層人員的訪談式溝通，主要目的是從宏觀上把握用戶的具體需求方向和趨勢，了解現有的組織架構、業(yè)務流程、硬件環(huán)境、軟件環(huán)境、現有的運行系統等等具體情況、客觀的信息。建立起良好的溝通渠道和方式。針對具體的職能部門以及各委辦局，最好能指定本次項目的接口人。

　　實現手段：訪談、調查表格

　　輸出成果：調查報告、業(yè)務流程報告

　　第二階段：“誘導式”Inducement

　　這一階段是在承建方已經了解了具體用戶方的組織架構、業(yè)務流程、硬件環(huán)境、軟件環(huán)境、現有的運行系統等等具體實際、客觀的信息基礎上，結合現有的硬件、軟件實現方案，做出簡單的用戶流程頁面，同時結合以往的項目經驗對用戶采用誘導式、啟發(fā)式的調研方法和手段，和用戶一起探討業(yè)務流程設計的合理性、準確性、便易性、習慣性。用戶可以操作簡單演示的DEMO，來感受一下整個業(yè)務流程的設計合理性、準確性等等問題，及時地提出改進意見和方法。

　　實現手段：拜訪（誘導）、原型演示

　　輸出成果：調研分析報告、原型反饋報告、業(yè)務流程報告

　　第三階段：“確認式”Afirm

　　這一階段是在上述兩個階段成果的基礎上，進行具體的流程細化、數據項的確認階段，這個階段承建方必須提供原型系統和明確的業(yè)務流程報告、數據項表，并能清晰地向用戶描述系統的業(yè)務流設計目標。用戶方可以通過審查業(yè)務流程報告、數據項表以及操作承建方提供的DEMO系統，來提出反饋意見，并對已經可接受的報告、文檔簽字確認。

　　實現手段：拜訪（回顧、確認），提交業(yè)務流程報告、數據項表；原型演示系統

　　輸出成果：需求分析報告、數據項、業(yè)務流程報告、原型系統反饋意見（后三者可以統一歸入需求分析報告中，提交用戶方、監(jiān)理方進行確認和存檔）

　　整體來講，需求分析的三個階段是需求調研中不可忽視一個重要的部分，三個階段或者說三步法的實施和采用，對用戶和承建方都同樣提供了項目成功的保證。當然在系統建設的過程中，特別在采用迭代法的開發(fā)模式時，需求分析的工作需一直進行下去，而在后期的需求改進中，工作則基本集中在后兩個階段中。

　　

　　圖三 第三階段訪確認式項目中角色、流程圖

【?發(fā)表評論?0條?】