IT項(xiàng)目需求分析的注意事項(xiàng)

1、IT工程需求分析的考前須知在需求開(kāi)發(fā)階段發(fā)現(xiàn)的一個(gè)錯(cuò)誤，平均僅需要花30分鐘修復(fù)，假設(shè) 在系統(tǒng)測(cè)試時(shí)發(fā)現(xiàn)那么需要5到17個(gè)小時(shí)來(lái)修復(fù)。要改正在產(chǎn)品付諸應(yīng) 用后所發(fā)現(xiàn)的一個(gè)需求方面的缺陷比在需求階段改正這個(gè)錯(cuò)誤要多付 出大約100倍的本錢(qián)。因此需求管理作為軟件工程管理的一個(gè)重要內(nèi) 容，貫穿工程實(shí)施的全生命周期。俗話說(shuō)：萬(wàn)事開(kāi)頭難。需求作為軟 件開(kāi)發(fā)的第一個(gè)環(huán)節(jié)，其重要性不言而喻。市面上關(guān)于需求管理的相 關(guān)理論和書(shū)籍很多，但多數(shù)停留在理論層面，實(shí)操性不強(qiáng)。1、與用戶進(jìn)行充分溝通通常，與用戶溝通前的準(zhǔn)備時(shí)間要遠(yuǎn)遠(yuǎn)大 于正式會(huì)面溝通的時(shí)間。一般情況下，用戶在和你連續(xù)交談兩個(gè)小時(shí) 之后，就會(huì)失去熱情和耐

2、心，這是大局部人的共同特點(diǎn)。所以充分的 準(zhǔn)備工作至關(guān)重要。準(zhǔn)備工作包括對(duì)工程整體環(huán)境熟悉的準(zhǔn)備工作和 對(duì)具體業(yè)務(wù)進(jìn)行調(diào)研前的準(zhǔn)備工作。工程整體環(huán)境的熟悉工作需要了 解：工程的背景、工程的目的、工程的利益相關(guān)方等信息，以便對(duì)當(dāng)前 工程的整體情況有一定了解。對(duì)具體業(yè)務(wù)調(diào)研前的準(zhǔn)備工作包括：需求 調(diào)研問(wèn)題的準(zhǔn)備、需求調(diào)研模板的設(shè)計(jì)、需求調(diào)研時(shí)間安排等內(nèi)容。 要充分珍視用戶的時(shí)間，盡量防止由于準(zhǔn)備工作缺乏而反復(fù)約見(jiàn)用戶， 給用戶造成效率低下的印象。一旦發(fā)生這樣的錯(cuò)誤，以后可能就會(huì)很 難約見(jiàn)到用戶。需求獲取的核心內(nèi)容是通過(guò)調(diào)研掌握軟件工程的實(shí)際 需求，以便于指導(dǎo)整個(gè)工程的實(shí)施。需求獲取的主要方法包括：用

3、戶 訪談、問(wèn)卷調(diào)查、現(xiàn)場(chǎng)觀摩、頭腦風(fēng)暴等方法。在實(shí)際的工程操作過(guò)程中，相比照擬明確的需求，我們可采用比擬固定的需求獲取方式， 比方：?jiǎn)柧碚{(diào)查等。而對(duì)于相比照擬模糊的需求或者說(shuō)用戶無(wú)法清晰 表述自己需要的是什么的時(shí)候，我們可采用比擬靈活的方式，例如： 用戶訪談、現(xiàn)場(chǎng)觀摩等。需求的類(lèi)型主要包括：業(yè)務(wù)需求、用戶需求 和功能需求。在需求獲取的過(guò)程中，無(wú)論采用哪種方法，我們都需要 自頂向下或自下向上去了解用戶真實(shí)的想法。業(yè)務(wù)需求的獲取對(duì)象主 要是客戶的高層領(lǐng)導(dǎo)，我們都知道，工程的發(fā)起、實(shí)施、最終的成敗 很大程度上都取決于高層領(lǐng)導(dǎo)，我們需要對(duì)他們進(jìn)行訪談，了解高層 領(lǐng)導(dǎo)的公司戰(zhàn)略、開(kāi)展方向，更為重要的是獲

4、取他們對(duì)將要開(kāi)發(fā)的軟 件系統(tǒng)的期望，以及希望該系統(tǒng)在解決現(xiàn)有業(yè)務(wù)問(wèn)題，對(duì)公司整體戰(zhàn) 略的支撐方面的期望。幫助我們?nèi)ジ玫乩斫庀到y(tǒng)的宏觀構(gòu)想。在掌 握了業(yè)務(wù)需求后，我們需要對(duì)中層管理人員進(jìn)行調(diào)研，核心問(wèn)題是搞 清楚在宏觀戰(zhàn)略目標(biāo)落地的這層，或者說(shuō)指標(biāo)細(xì)化并負(fù)責(zé)實(shí)施的中層 他們對(duì)軟件系統(tǒng)的期望以及實(shí)際要求，他們或希望此系統(tǒng)能夠帶來(lái)工 作便利，或希望此系統(tǒng)能夠做到精細(xì)化管理，如此等等。但他們都是 具體的業(yè)務(wù)部門(mén)負(fù)責(zé)人，對(duì)自身的業(yè)務(wù)以及系統(tǒng)對(duì)業(yè)務(wù)的促進(jìn)方面， 有比擬深刻的體會(huì)。最后，我們需要在掌握了業(yè)務(wù)需求、用戶需求的 基礎(chǔ)之上，通過(guò)對(duì)IT管理部門(mén)、主要操作人員的需求調(diào)研或根據(jù)我們 對(duì)需求的理解，細(xì)化

5、出系統(tǒng)的功能需求，這個(gè)需求是最低層次的需求, 也是一個(gè)層層落地的過(guò)程。2、主動(dòng)積極了解客戶業(yè)務(wù)和相關(guān)知識(shí)在技術(shù)方面我們可能非常專(zhuān)業(yè)， 但對(duì)于具體的用戶業(yè)務(wù)可能并不十分清楚。這個(gè)工程對(duì)用戶是否有幫 助、某一系統(tǒng)功能是否有用、某一流程處理是否合理，在不了解用戶 業(yè)務(wù)的情況下，我們將很難做出判斷。因此只有在了解業(yè)務(wù)的基礎(chǔ)上， 我們才和用戶有共同的溝通語(yǔ)言和業(yè)務(wù)理解，才能真正理解系統(tǒng)應(yīng)具 有哪些功能。曾在經(jīng)銷(xiāo)商管理系統(tǒng)調(diào)研過(guò)程中，由于財(cái)務(wù)方面的知識(shí) 有限，使得在對(duì)經(jīng)銷(xiāo)商財(cái)務(wù)部門(mén)的調(diào)研中對(duì)局部問(wèn)題不是特別的理解。 向用戶虛心進(jìn)行請(qǐng)教，并在調(diào)研結(jié)束后及時(shí)對(duì)自己的財(cái)務(wù)知識(shí)進(jìn)行了 補(bǔ)充。應(yīng)用領(lǐng)域的知識(shí)是無(wú)邊無(wú)

6、際的，在各種工程的調(diào)研過(guò)程中，肯 定會(huì)出現(xiàn)由于需求分析者缺乏某一領(lǐng)域的知識(shí)而影響需求分析工作的 準(zhǔn)確、順利進(jìn)行。遇到此類(lèi)問(wèn)題時(shí)，需求分析者應(yīng)虛心向用戶請(qǐng)教， 同時(shí)應(yīng)及時(shí)補(bǔ)充應(yīng)用領(lǐng)域的知識(shí)。最好能夠在調(diào)研前做好充分的準(zhǔn)備。3、引導(dǎo)用戶，使用戶充分表達(dá)自己的想法在與用戶交談中，如何引導(dǎo) 用戶說(shuō)出他們的需求是非常關(guān)鍵的。恰當(dāng)?shù)奶釂?wèn)，會(huì)使用戶滔滔不絕， 充分發(fā)表自己的意見(jiàn)和建議。而不恰當(dāng)?shù)奶釂?wèn)，可能會(huì)導(dǎo)致用戶無(wú)法 回答或敷衍了事地進(jìn)行回答。提問(wèn)可分為封閉式提問(wèn)和開(kāi)放式提問(wèn)。封閉式提問(wèn)目的明確。如：現(xiàn)在你們的送貨單是手工填寫(xiě)還是電腦打印? 但過(guò)多使用封閉式提問(wèn)，會(huì)導(dǎo)致談話枯燥，讓用戶感覺(jué)自己好像在接 受

7、審問(wèn)。開(kāi)放式提問(wèn)是請(qǐng)對(duì)方對(duì)某一事物做進(jìn)一步的解釋?zhuān)墒拐勗?到達(dá)一定的深度和廣度。如：你認(rèn)為目前的工作中存在哪些可以改進(jìn)的 地方？開(kāi)放式提問(wèn)缺點(diǎn)是容易使談話內(nèi)容偏離主題。因此在談話過(guò)程中，應(yīng)采用封閉式和開(kāi)放式提問(wèn)相結(jié)合的方式。以簡(jiǎn)單問(wèn)題開(kāi)始、從 用戶熟悉的內(nèi)容開(kāi)始。每次只提一個(gè)問(wèn)題、集中一個(gè)重點(diǎn)，寧問(wèn)勿猜。 并盡量防止使用IT相關(guān)的一些術(shù)語(yǔ)，以便用戶能夠很好地理解我們的 表達(dá)。4、對(duì)用戶進(jìn)行正確分類(lèi)組織中的用戶在很多方面存在差異，例如：使 用系統(tǒng)的頻度和程度、計(jì)算機(jī)系統(tǒng)知識(shí)、所進(jìn)行的業(yè)務(wù)過(guò)程以及個(gè)人 的素質(zhì)和喜好等。根據(jù)用戶的特點(diǎn)，可對(duì)用戶進(jìn)行一定的分類(lèi)。將用 戶分類(lèi)并歸納各自特點(diǎn)，詳細(xì)描述他

8、們的個(gè)性特點(diǎn)及任務(wù)狀況，將有 助于需求的獲取和分析。不同的問(wèn)題需要詢(xún)問(wèn)不同的人，對(duì)于操作細(xì) 節(jié)的問(wèn)題，要和實(shí)際負(fù)責(zé)操作的用戶進(jìn)行溝通，而對(duì)于關(guān)乎全局的問(wèn) 題，那么要和相應(yīng)的管理層用戶進(jìn)行溝通。5、應(yīng)實(shí)地了解用戶工作流程實(shí)地觀察用戶執(zhí)行業(yè)務(wù)任務(wù)的過(guò)程。了解 用戶什么時(shí)候獲得什么數(shù)據(jù)，并怎樣使用這些數(shù)據(jù)，業(yè)務(wù)處理過(guò)程中 需要處理哪些單據(jù)，需要和哪些角色的用戶發(fā)生關(guān)聯(lián)等。這都將有助 于明確產(chǎn)品的功能需求。經(jīng)驗(yàn)證明，與人們面談關(guān)于他們?nèi)绾瓮瓿扇?務(wù)時(shí)會(huì)有許多限制和不準(zhǔn)確性，而這是任務(wù)觀察可以直接解決的。特 別是對(duì)于某些組織中普遍接受的規(guī)那么和方法，用戶認(rèn)為你也應(yīng)理所當(dāng) 然知道，而不曾提起時(shí)。在用戶需求

9、已經(jīng)確認(rèn)后，將用戶需求進(jìn)行條 目化，把每一條需求形成需求開(kāi)發(fā)任務(wù)，借助軟件工程管理平臺(tái)，將其直接推送給需求分析人員，而需求分析人員的分析結(jié)果可以通過(guò)該 平臺(tái)導(dǎo)出成為格式化的需求規(guī)格說(shuō)明。一旦需求規(guī)格說(shuō)明編寫(xiě)任務(wù)完 成，管理平臺(tái)直接推送需求評(píng)審任務(wù)給相關(guān)人員。后續(xù)的設(shè)計(jì)、編碼、 測(cè)試等任務(wù)都以類(lèi)似的方式融入流程。6、分析需求可行性沒(méi)錢(qián)賺的事我們不干;有錢(qián)賺但投不起錢(qián)的事不干; 有錢(qián)賺也投得起錢(qián)但沒(méi)有可靠的人選，這樣的事也不干?？尚行苑治?主要是針對(duì)某一需求決定是做還是不做。一般可行性主要考慮兩個(gè)方 面的因素：技術(shù)和人。技術(shù)方面主要是分析在給定的時(shí)間段內(nèi)是否可實(shí) 現(xiàn)所需的功能并滿足產(chǎn)品的質(zhì)量要求等

10、相關(guān)指標(biāo)。很多時(shí)候，用戶的 想法在實(shí)際實(shí)施過(guò)程中是不現(xiàn)實(shí)的。假設(shè)一味地求全和盲目遵從用戶的 設(shè)想，將為工程的后續(xù)工作帶來(lái)很大的風(fēng)險(xiǎn)。因此應(yīng)盡量防止在需求 分析中包含技術(shù)實(shí)施上有難度的功能。在曾經(jīng)負(fù)責(zé)的一個(gè)工程中，用 戶要求新的管理系統(tǒng)應(yīng)實(shí)現(xiàn)和管理系統(tǒng)的數(shù)據(jù)接口，以方便這些系統(tǒng) 中的數(shù)據(jù)導(dǎo)入新的管理系統(tǒng)。許諾提供系統(tǒng)的數(shù)據(jù)接口，將為新系統(tǒng) 的成功實(shí)施帶來(lái)很大的風(fēng)險(xiǎn)。因?yàn)槭煜み@些系統(tǒng)需要時(shí)間，開(kāi)發(fā)與它 們的接口也需要時(shí)間，而且等這些商業(yè)系統(tǒng)存在多個(gè)不同的版本。因 此與外部系統(tǒng)接口的可行性定義為：不可行。對(duì)于復(fù)雜的工程，還應(yīng)從 經(jīng)濟(jì)方面和環(huán)境方面進(jìn)行考慮。經(jīng)濟(jì)方面主要從投入、收益、短期、 長(zhǎng)遠(yuǎn)利益等

11、方面進(jìn)行分析。環(huán)境方面主要考慮市場(chǎng)環(huán)境和政策因素。 需求變更對(duì)大型IT開(kāi)發(fā)工程成敗有重要影響，既不能一概拒絕客戶的 變更要求，也不能一味地遷就客戶，所以，實(shí)施需求變更之前必須做好控制。需求變更控制的目的不是控制變更的發(fā)生，而是對(duì)變更進(jìn)行 管理，確保變更有序進(jìn)行。7、確定需求的優(yōu)先級(jí)別當(dāng)客戶的期望很高、開(kāi)發(fā)時(shí)間很短且資源有限 時(shí)，設(shè)定需求的相對(duì)優(yōu)先級(jí)將有助于工程管理人員解決沖突、安排階 段性交付并做出必要的取舍。建立每個(gè)需求的重要性有助于規(guī)劃軟件 的構(gòu)造，以最少的費(fèi)用提供產(chǎn)品的最大功能。特別是對(duì)漸進(jìn)式的工程， 優(yōu)先級(jí)的設(shè)定就顯得更為重要，因?yàn)樵谶@些開(kāi)發(fā)中，工程時(shí)間安排極 為緊迫并且交付日期不可改

12、變，一些低優(yōu)先級(jí)的需求就需要推遲到后 續(xù)版本中進(jìn)行實(shí)現(xiàn)或直接取消。當(dāng)眾多用戶因期望不同而就某些需求 優(yōu)先級(jí)的設(shè)定難以達(dá)成一致意見(jiàn)時(shí)，需求分析者可指出每一需求所需 的費(fèi)用、難度、技術(shù)風(fēng)險(xiǎn)或其他特定的與權(quán)衡需求有關(guān)的指標(biāo)，來(lái)客 觀評(píng)價(jià)每一需求的優(yōu)先級(jí)。8、正確理解需求分析文檔確認(rèn)需求分析是 一項(xiàng)繁瑣枯燥的工作，需要和用戶不斷的商討、確認(rèn)和反復(fù)。但大部 分用戶并不只做這項(xiàng)工作，特別當(dāng)他被很多其他的事情纏身的時(shí)候。 在需求分析文檔上簽字確認(rèn)，通常被認(rèn)為是用戶同意需求分析內(nèi)容的 標(biāo)志行為。而實(shí)際操作中，簽字確認(rèn)工作并未得到用戶的充分重視?！八麄円笪以谛枨笪臋n上簽名，于是我就簽了，否那么開(kāi)發(fā)人員不開(kāi) 始

13、編碼?！庇脩舻倪@種態(tài)度將可能給工程帶來(lái)潛在的風(fēng)險(xiǎn)，如不斷地 進(jìn)行需求變更等。對(duì)于需要用戶確認(rèn)的需求分析文檔，最好在用戶確 認(rèn)前，就文檔內(nèi)容對(duì)用戶進(jìn)行一定的講解，以確保用戶完全理解并認(rèn) 可文檔中的內(nèi)容。假設(shè)用戶對(duì)文檔中的內(nèi)容存在修改意見(jiàn)，那么修改后再與用戶進(jìn)行確認(rèn)，直至用戶完全認(rèn)可文檔中的內(nèi)容為止。通常為對(duì)項(xiàng) 目有一個(gè)整體、準(zhǔn)確的理解，需求分析所包含的內(nèi)容通常大于工程范 圍所包含的內(nèi)容。因此，應(yīng)讓用戶理解對(duì)于某些功能的討論并不意味著即將在系統(tǒng)中實(shí) 現(xiàn)它。應(yīng)使用戶明白對(duì)需求分析文檔的簽字確認(rèn)是建立一個(gè)需求的基 線，進(jìn)一步的變更可在此基線上通過(guò)工程定義的變更過(guò)程來(lái)進(jìn)行。需 求確認(rèn)將給初步的需求開(kāi)發(fā)工作畫(huà)上了雙方都明確的句號(hào)，并有助于 形成一個(gè)持續(xù)良好的用戶與需求分析人員的關(guān)系，為工程的成功奠定 堅(jiān)實(shí)的基礎(chǔ)。將知識(shí)從一個(gè)地方傳送到另一個(gè)地方并不是一件簡(jiǎn)單的 事情，而且原始的需求通常是以不完整的形式呈現(xiàn)的。它也許只是在 某個(gè)現(xiàn)有系統(tǒng)的用戶腦中，甚至有時(shí)用戶都沒(méi)有意識(shí)到