編者按:項目需求分析是一個項目的開端,也是項目建設(shè)的基石。在以往建設(shè)失敗的項目中,80%是由于需求分析的不明確而造成的。因此一個項目成功的關(guān)鍵因素之一,就是對需求分析的把握程度。
在原則上,需求階段監(jiān)理應(yīng)尊重承建方的項目管理和項目分析能力;在具體的任務(wù)開展上,以不深入、不干擾承建方的自主權(quán)為主,除非在項目合作過程中發(fā)現(xiàn)承建方的項目管理以及項目分析能力存在很大的差距和不足。
為了保證項目的成功,監(jiān)理方必須加強項目管理和項目分析工作,在具體的操作上可以堅持吸收、同化、貫徹的方法和手段。
其中,需求分析是一個項目的開端,也是項目建設(shè)的基石。在以往建設(shè)失敗的項目中,80%是由于需求分析的不明確而造成的。因此一個項目成功的關(guān)鍵因素之一,就是對需求分析的把握程度。而項目的整體風(fēng)險往往表現(xiàn)在需求分析不明確、業(yè)務(wù)流程不合理,用戶不習(xí)慣或不愿意去用承建方的軟件。作為第三方的監(jiān)理公司,必須提醒承建方、客戶方重視需求分析的重要性,采用必要的手段和方法來進行需求調(diào)研,同時監(jiān)理方也應(yīng)深入具體的需求調(diào)研中去。只有這樣才能切切實實地把握用戶的需求和方向,才能在將來的功能界定、開發(fā)范圍上有發(fā)言權(quán)。
如何進行需求分析
需求分析不象偵探推理那樣需從蛛絲馬跡著手,而是應(yīng)該先了解宏觀的問題,再了解細節(jié)的問題。
一個應(yīng)用軟件系統(tǒng)(記為 S)的涉及面可能很廣,可以按不同的問題域(記為D)分類,每個問題域?qū)?yīng)于一個軟件子系統(tǒng)。
S = { D1,D2,D3,… Dn }
問題域Di 由若干個問題(記為P)組成,每個問題對應(yīng)于子系統(tǒng)中的一個軟構(gòu)件。
Di = { P1,P2,P3,… Pm }
問題Pj有若干個行為(或功能,記為F),每個行為對應(yīng)于軟構(gòu)件中的實現(xiàn)接口。
Pj = { F1,F(xiàn)2,F(xiàn)3,… Fk }
需求說明書應(yīng)該對于那些只想了解宏觀需求的領(lǐng)導(dǎo),和需要了解細節(jié)的技術(shù)員都合適。在寫需求說明書時應(yīng)該注意兩個問題:
1.最好為每個需求注釋“為什么”,這樣可讓程序員了解需求的本質(zhì),以便選用最合適的技術(shù)來實現(xiàn)此需求。
2.需求說明不可有二義性,更不能前后相矛盾。如果有二義性或前后相矛盾,則要重新分析此需求。
圖一 第一階段訪談式項目中角色、流程圖
重點監(jiān)控需求分析
由于項目的特殊性和行業(yè)覆蓋的廣闊性,以及需求分析的高風(fēng)險性,軟件需求分析的重要性是不言而喻的,同時需求分析又的的確確難做。其原因基本是由于以下情況造成的。
客戶說不清楚需求
有些客戶對需求只有朦朧的感覺,當然說不清楚具體的需求。例如全國各地的很多部門、機構(gòu)、單位在進行應(yīng)用系統(tǒng)以及網(wǎng)絡(luò)建設(shè)時,客戶方的辦公人員大多不清楚計算機網(wǎng)絡(luò)有什么用,更缺乏IT系統(tǒng)建設(shè)方面的專家和知識。此時,用戶就會要求軟件系統(tǒng)分析人員替他們設(shè)想需求。工程的需求存在一定的主觀性,為項目未來建設(shè)埋下了潛在的風(fēng)險。
需求自身經(jīng)常變動
根據(jù)以往的歷史經(jīng)驗,隨著客戶方對信息化建設(shè)的認識和自己業(yè)務(wù)水平的提高,他們會在不同的階段和時期對項目的需求提出新的要求和需求變更。事實上,歷史上沒有一個軟件的需求改動少于三次的!所以必須接受“需求會變動”這個事實,在進行需求分析時要懂得防患于未然,盡可能地分析清楚哪些是穩(wěn)定的需求,哪些是易變的需求,以便在進行系統(tǒng)設(shè)計時,將軟件的核心建筑在穩(wěn)定的需求上,同時留出變更空間。咨詢監(jiān)理方在需求分析的功能界定上擔任一個中間、公平、公正的角色,所以也必須積極參與到需求分析的準備中來,以便協(xié)助客戶方和承建方來界定“做什么”、“不做什么”的系統(tǒng)功能界
項目經(jīng)理勝任力免費測評PMQ上線啦!快來測測你排多少名吧~
http://opto-elec.com.cn/pmqhd/index.html