項(xiàng)目需求技巧

IT 業(yè)內(nèi)人士多未能把握的實(shí)際應(yīng)用技巧。而有如工作量估算，錯誤的工作細(xì)節(jié)將對項(xiàng)目計劃不利。

每一個項(xiàng)目都有不同的交付物，而每一件交付物需要經(jīng)過不同的里程碑才能夠產(chǎn)生，同時每一個里程碑也需要經(jīng)過不同的階段才能夠達(dá)到里程的目標(biāo)。每一個階段需要經(jīng)過不同的步驟去完成，而每一個步驟需要進(jìn)行不同的工作。

每一個步驟需要完成一系列工作才能進(jìn)行第二步驟，直至同一階段的步驟完成才開始第二階段，而直至全部階段完成后才能到達(dá)一個里程碑。有些里程碑內(nèi)的工作可以同期進(jìn)行，但有些里程碑內(nèi)的工作得等另一個里程碑完成后才能夠開始。到最終完成全部的里程碑內(nèi)的工作后才能夠交付項(xiàng)目中的某一件交付物。

利用 WBS技巧來建立交付組合架構(gòu)，為每一件交付物建立本身的工作需求，可以讓很明確地說明每一件交付物所包含的工作。這個交付組合架構(gòu)更可以讓在同一時間為項(xiàng)目建立有關(guān)的工作計劃。

大部分IT項(xiàng)目缺乏支持文檔，縱然擁有商業(yè)案例（ Business Case ）或其他相關(guān)文檔，也不能很明確地把項(xiàng)目所需的工作涵蓋起來，只能建立項(xiàng)目的周邊，對項(xiàng)目的實(shí)際工作量缺乏描述，這很容易導(dǎo)致項(xiàng)目過程中所產(chǎn)生的變動。

為解決這個和問題，國際上已于上世紀(jì) 80 年代末期開始采用“”（ Statements of Work 或簡稱 SOW ）來固定范圍，同時放棄范圍定義（ Scope Definition ）的應(yīng)用。因?yàn)?IT 項(xiàng)目有別于其他基建項(xiàng)目的地方在于基建項(xiàng)目有其他附屬文檔來支持范圍定義，比如在基建項(xiàng)目的項(xiàng)目范圍中，一般都有諸如項(xiàng)目的有關(guān)設(shè)計圖則、用料標(biāo)準(zhǔn)等等明文規(guī)定，讓范圍能夠非常明確地涵蓋基本的工作需求。而 IT 項(xiàng)目的項(xiàng)目范圍中往往沒有這樣的定義。

以商業(yè)效益來確認(rèn)功能需求，再利用功能需求來建立。而在范圍確認(rèn)后，緊跟著必需建立詳細(xì)的工作需求和，否則項(xiàng)目的工作便像橄欖球內(nèi)的充氣量一般，可以按照客戶的要求隨意變動。

工作需求和項(xiàng)目計劃基本上是利用（ Work Breakdown Structure ）建立。明確的工作陳述（ SOW ）讓渠道商或服務(wù)商了解本身的服務(wù)承諾，有效地建立項(xiàng)目的成本，降低項(xiàng)目過程中所產(chǎn)生的變動。這些應(yīng)該在銷售過程中建立，成為服務(wù)合約的內(nèi)容一部分。萬一合約中只有項(xiàng)目范圍定義，那么交付小組必須在交付初期建立有關(guān)的項(xiàng)目工作陳述，避免交付期間所產(chǎn)生的爭議。

所謂的“項(xiàng)目需求”到底是要明確什么呢，是明確管理的目標(biāo)，還是管理的方法，這卻是企業(yè)很難把握的。另外，需求是怎樣產(chǎn)生的？或者說需求應(yīng)該怎樣產(chǎn)生，才可以保證最后產(chǎn)生的需求是既完整又合理的？這同樣也是很多企業(yè)都很難做得好的一件事。

一般來講，在最初的需求調(diào)研階段，這部分工作大都是由公司的管理部門或從事分析工作的人員來完成，而調(diào)研人員考慮問題的出發(fā)點(diǎn)往往只是讓企業(yè)的管理水平有一個飛躍，但是卻容易忽略企業(yè)的現(xiàn)狀，或未能完整深刻地對企業(yè)的實(shí)際潛在性需求進(jìn)行調(diào)研，這導(dǎo)致在實(shí)際應(yīng)用階段之時，很多部門覺得不太適用，甚至導(dǎo)致各個部門怨聲載道，于是不得不宣告失敗或推倒重來。所以處在這個階段的企業(yè)，需要有一種科學(xué)的方法來指導(dǎo)自己確定真實(shí)準(zhǔn)確的需求。

首先，企業(yè)要明白一點(diǎn)，現(xiàn)在所需要了解的不單單是企業(yè)的需求，而是要制定出企業(yè)長期發(fā)展的階段性，并以此為依據(jù)，來制定各個階段的需求和發(fā)展計劃。特別是對于處在快速成長發(fā)展期的企業(yè)而言，企業(yè)會在較短的時間內(nèi)經(jīng)歷多個成長的階段，在不同的階段會派生許多不同的管理需求。只有企業(yè)明白了自己需要管理什么，才可能制定對應(yīng)的管理方法。這樣的戰(zhàn)略目標(biāo)的確定是分階段的,企業(yè)只有根據(jù)自己企業(yè)的特點(diǎn)或者行業(yè)的特點(diǎn)制定出階段目標(biāo)，才能夠明確自己每個階段的管理需求。

同時，無論是制造業(yè)還是流通行業(yè)，都強(qiáng)調(diào)和這兩個閉環(huán)。那么，這兩個閉環(huán)中的每個環(huán)節(jié)都存在管理上的需求。在對這些環(huán)節(jié)進(jìn)行定義時，不單單是要定義管理的各個環(huán)節(jié)的管理目標(biāo)，更重要的是要定義各個環(huán)節(jié)之間的關(guān)系。企業(yè)只有按照這樣的方法制定階段性的發(fā)展目標(biāo)，才可以完整地對各個環(huán)節(jié)進(jìn)行管理方法的定義。

其次，當(dāng)企業(yè)已經(jīng)制定了企業(yè)各發(fā)展階段的性目標(biāo)之后，根據(jù)各階段的目標(biāo)進(jìn)行管理的規(guī)劃就比較簡單了，因?yàn)槠髽I(yè)已經(jīng)明白了自己需要管理什么，剩下的只需要探討管理的方法就可以了。按照既定的戰(zhàn)略性目標(biāo)制定每個環(huán)節(jié)的管理方法的時候，一定要本著立足本部門的需求，放眼整個公司的管理目標(biāo)的原則來制定管理方法，只有這樣才能保證本階段的管理方法的科學(xué)性以及合理性。

最后，在對各個環(huán)節(jié)的管理方法進(jìn)行定義的時候，不但要考慮管理的目標(biāo)通過管理方法的實(shí)現(xiàn)，而且要注意前后兩種管理方法的差異。只有注意了兩種管理的方法的差異，才可能保證兩種管理方法的平穩(wěn)過渡。

同時，公司的管理部門或從事分析工作的人員在做各個部門的需求調(diào)研的時候，也要在立足企業(yè)的管理目標(biāo)的前提下，充分了解各個環(huán)節(jié)實(shí)際的管理需求。了解他們?nèi)粘９ぷ鲗?shí)現(xiàn)了哪些目標(biāo)，對于整個公司的管理目標(biāo)，他們還缺少哪些，需要補(bǔ)充的是哪些。只有這樣才能避免調(diào)研開始的時候“沒得說”，到了應(yīng)用的階段卻“說不完”的情況發(fā)生。

所以，在初期的選型階段，企業(yè)要明確的需求不可單一理解為明確要管理什么，而是對要管理的目標(biāo)怎樣實(shí)現(xiàn)。整個過程強(qiáng)調(diào)的是管理的目標(biāo)和管理的方法之間的關(guān)系，只有立足在這個關(guān)系的基礎(chǔ)上，才可以保證做到真正明確需求。

項(xiàng)目開發(fā)的目標(biāo)對軟件用戶來說，目地是項(xiàng)目及時開發(fā)完成，達(dá)到管理要求，并成功應(yīng)用于企業(yè)管理，為企業(yè)創(chuàng)造效益。方案的用途可以讓用戶在沒有使用最終軟件的情況下，對未來軟件的使用方法和計算原理有足夠的認(rèn)識方案可以正確指導(dǎo)軟件開發(fā)商進(jìn)行正確的開發(fā)方案可以幫助軟件測試工作正常進(jìn)行方案可以指導(dǎo)用戶去使用未來的軟件方案可以作為雙方認(rèn)可的項(xiàng)目驗(yàn)收標(biāo)準(zhǔn)。 2100433B

資源的需求是指項(xiàng)目發(fā)展過程對于資源的需要程度。資源的需求決定著資源的重要性、價值和關(guān)聯(lián)強(qiáng)度。

資源的需求通?？梢苑譃樗姆N類型：

1、必需型

2、急需型

3、一般型

4、儲備型

需求分析階段的工作,可以分為四個方面:問題識別,分析與綜合,制訂規(guī)格說明,評審.

問題識別

就是從系統(tǒng)角度來理解軟件,確定對所開發(fā)系統(tǒng)的綜合要求,并提出這些需求的實(shí)現(xiàn)條件,以及需求應(yīng)該達(dá)到的標(biāo)準(zhǔn).這些需求包括：功能需求(做什么),性能需求(要達(dá)到什么指標(biāo)),環(huán)境需求(如機(jī)型,操作系統(tǒng)等),可靠性需求(不發(fā)生故障的概率）,安全保密需求,用戶界面需求,資源使用需求(軟件運(yùn)行時所需的內(nèi)存,CPU等),軟件成本消耗與開發(fā)進(jìn)度需求,預(yù)先估計以后系統(tǒng)可能達(dá)到的目標(biāo).

分析與綜合

逐步細(xì)化所有的軟件功能,找出系統(tǒng)各元素間的聯(lián)系,接口特性和設(shè)計上的限制,分析他們是否滿足需求,剔除不合理部分,增加需要部分.最后,綜合成系統(tǒng)的解決方案,給出要開發(fā)的系統(tǒng)的詳細(xì)邏輯模型(做什么的模型).

制訂規(guī)格說明書

即編制文檔,描述需求的文檔稱為軟件需求規(guī)格說明書.請注意,需求分析階段的成果是需求規(guī)格說明書(好象軟考曾經(jīng)考過這個問題),向下一階段提交.

評審

對功能的正確性,完整性和清晰性,以及其它需求給予評價.評審?fù)ㄟ^才可進(jìn)行下一階段的工作,否則重新進(jìn)行需求分析。

項(xiàng)目需求分析過程中，用戶的確是處在主導(dǎo)地位，需求分析工程師和項(xiàng)目經(jīng)理要負(fù)責(zé)整理用戶需求，為之后的軟件設(shè)計打下基礎(chǔ)。需求分析階段結(jié)束后，要求得到：1.SRS文檔(System Requirement Specification); 2.DRM 文檔；3.Acceptance Plan. 從廣義上理解：需求分析包括需求的獲取、分析、規(guī)格說明、變更、驗(yàn)證、管理的一系列需求工程。狹義上理解：需求分析指需求的分析、定義過程。