對于需求分析有很多相應(yīng)的書籍說明如何分析，卻沒有具體的過程描述，本文講述一個(gè)實(shí)際的可以操作的需求確認(rèn)過程。

前提

　　在用戶與公司簽定開發(fā)協(xié)議的前提下，完成由公司的銷售人員為重點(diǎn)轉(zhuǎn)變?yōu)楣鞠到y(tǒng)開發(fā)部門為重點(diǎn)過程中的第一步―――需求分析。對于用戶來講是對多家開發(fā)商進(jìn)行挑選，最終明確一家開發(fā)商，并簽訂開發(fā)協(xié)議后，進(jìn)行的提供具體需求明確需求的過程―――明確告訴開發(fā)商要開發(fā)一個(gè)具有什么功能的軟件產(chǎn)品。

約定

　　用戶對于其用什么系統(tǒng)平臺，已經(jīng)大概知道，并且已經(jīng)認(rèn)可。如硬件全部為PC機(jī)，客戶機(jī)軟件是WINDOWS98/ME/2000，服務(wù)器軟件是用WINDOWS　2000，數(shù)據(jù)庫軟件是SQL　20000?；蛘哂脩糇⒅貥I(yè)務(wù)功能，而對于服務(wù)器、客戶機(jī)、數(shù)據(jù)庫等大的系統(tǒng)軟件及硬件平臺認(rèn)可做常規(guī)配置就可以。

　　所用技術(shù)體系一般情況下在進(jìn)行需求分析前最好是明確，不然就要求系統(tǒng)分析人員了解所有的技術(shù)體系。不然運(yùn)氣好，系統(tǒng)分析人員所了解的技術(shù)系和用戶相求的相同，進(jìn)行了正確分析；如果運(yùn)氣不好可能會把一些認(rèn)為可以簡單實(shí)現(xiàn)而實(shí)際實(shí)現(xiàn)卻很難的需求答應(yīng)下來。比如：把DB2的數(shù)據(jù)庫完全備份還原給SYBASE。

　　在所用技術(shù)體系大概范圍已經(jīng)明確的情況下，選擇合適的系統(tǒng)分析人員。要求系統(tǒng)分析人員對相應(yīng)技術(shù)體系有一定的了解，以便在相應(yīng)的分析時(shí)有所依據(jù)。不同的技術(shù)體系有一定的局限性，而有些需求對某些技術(shù)體系有一定的難度。如WAP（手機(jī)上網(wǎng)）是不太可能實(shí)現(xiàn)打印。雖然沒有絕對不能實(shí)現(xiàn)的用戶業(yè)務(wù)需求，但一般情況下開發(fā)協(xié)議上明確的費(fèi)用，已經(jīng)決定系統(tǒng)功能做到什么程度。

其它

　　相應(yīng)的工具的使用熟練程度。如果多人進(jìn)行分析，分工及責(zé)任的明確，及團(tuán)隊(duì)的穩(wěn)定性。相應(yīng)計(jì)劃安排是否合理周全等也是影響獲取需求質(zhì)量的因素。

到用戶前的準(zhǔn)備

組織隊(duì)伍

　　根據(jù)實(shí)際的工作量及其他情況，組建需求調(diào)研隊(duì)隊(duì)伍，提供辦分設(shè)備，明確責(zé)任、啟動任務(wù)。

準(zhǔn)備相應(yīng)文檔

　　開發(fā)商方的系統(tǒng)分析人員同用戶的需求提供人員正式接觸前，完成一個(gè)問詢表及需求分析計(jì)劃。

　　一般情況下只需要完成一個(gè)整體細(xì)節(jié)問詢表，一般問詢用戶為明確需求已經(jīng)完成的文檔情況（如果可以在進(jìn)行正式接觸前可以得到并了解完成最好），業(yè)務(wù)的目的，當(dāng)前的目標(biāo)，長遠(yuǎn)的目標(biāo)，當(dāng)前準(zhǔn)備情況，完成的業(yè)務(wù)功能列表，將來系統(tǒng)操作人員的業(yè)務(wù)及電腦技術(shù)了解情況，最終操作用戶，當(dāng)前及將來的硬件、軟件及網(wǎng)絡(luò)環(huán)境等整體問題。

　　由開發(fā)商系統(tǒng)分析人員根據(jù)對業(yè)務(wù)的了解程度，適當(dāng)編寫各業(yè)務(wù)功能細(xì)節(jié)問詢表。不過業(yè)務(wù)功能細(xì)節(jié)問詢表的使用，是在業(yè)務(wù)需求調(diào)研過程中用戶表明其需求后，再根據(jù)問題還沒有明確的情況下再進(jìn)行問詢的。不過有時(shí)業(yè)務(wù)功能細(xì)節(jié)問詢表由于用戶的需求和原計(jì)劃不同，使業(yè)務(wù)功能細(xì)節(jié)表不在發(fā)揮作用。

　　其他業(yè)務(wù)相關(guān)政策法規(guī)、技術(shù)文檔、技術(shù)支持人員的通信錄等也要進(jìn)行相應(yīng)的準(zhǔn)備。

聯(lián)系及了解用戶方

　　同用戶進(jìn)行聯(lián)系并取得對方的人員名單、分工情況、權(quán)重、工作計(jì)劃、工作時(shí)間、節(jié)假日安排（特別是用戶公司內(nèi)部的額外規(guī)定），如果可能的情況下要求也有用戶的IT人員參加需求過程，實(shí)際的需求如果沒有IT人員的參加，在后面的更改一般是IT人員提出的。應(yīng)在需求過程中把用戶IT人員的需求調(diào)研，作為業(yè)務(wù)調(diào)研中一部分。

編寫計(jì)劃

　　根據(jù)當(dāng)前情況，編寫需求分析計(jì)劃，明確正式開始日期，中間階段性日期（時(shí)間長可多個(gè)，調(diào)研時(shí)間不大于3天可沒有），結(jié)束時(shí)間，人員名單，分工情況，需用戶提供的幫助等。

　　將計(jì)劃發(fā)送給用戶請其確認(rèn)，在可能的情況下協(xié)調(diào)用戶和開發(fā)商的計(jì)劃，以便共同開展工作。

　　對于計(jì)劃如果能編寫及控制到每日是最好的，但是否可以達(dá)到真正可控制到日，那就看你的能力了。如果每3天為一個(gè)中間性階段進(jìn)行控制，延遲的時(shí)間可以通過加班來彌補(bǔ)。計(jì)劃最好根據(jù)一天工作8小時(shí)進(jìn)行。如果計(jì)劃一天是工作10個(gè)小時(shí)，也許第一次延遲可以通過加班8小時(shí)（一天工作24小時(shí)）來彌補(bǔ)，但再有延遲你會發(fā)現(xiàn)你的工作人員沒有精力再加班了。

　　如果要去用戶所在地進(jìn)行工作，還要準(zhǔn)備相應(yīng)的辦公工具，人手一臺筆記本電腦（電源插座及網(wǎng)絡(luò)互連線也要考慮）是比較好的資源配置。

需求調(diào)研

第一日

　　本次所說的第一日是開發(fā)商系統(tǒng)開發(fā)人員到用戶處正式需求調(diào)研過程的第一日。如果是異地調(diào)研，那么在第一日前一日開發(fā)商系統(tǒng)開發(fā)人員應(yīng)到達(dá)用戶所在地，結(jié)解住宿，了解住宿地周邊情況。最好是早些休息，為第一日工作開始做好準(zhǔn)備。

　　一般第一日的上午是開發(fā)商系統(tǒng)分析人員和用戶業(yè)務(wù)需要者進(jìn)行整體介紹，了解辦公環(huán)境，建立需求調(diào)研過程辦公環(huán)境。如果是小型項(xiàng)目涉及人員不多（雙方人員共同不多于3人），一般上午可以進(jìn)行調(diào)研工作1到2小時(shí)，不然下午才能正式開始工作（也就說做計(jì)劃時(shí)第1天一般只有半日的工作時(shí)間）。

調(diào)研過程

　　調(diào)研的過程推薦開發(fā)商系統(tǒng)開發(fā)人員有專人進(jìn)行會議記錄，并在每日會議結(jié)束后，當(dāng)場宣布本次會議的結(jié)果，并由參加會議人員進(jìn)行簽字。第二日復(fù)印或發(fā)送電子文件給參加會議人員及相關(guān)人員。以便做到有據(jù)可查，明確過程。

　　開發(fā)商系統(tǒng)開發(fā)人員每周對用戶提供開發(fā)周報(bào)，告訴用戶當(dāng)前開發(fā)的進(jìn)展、是否有問題、是否用戶協(xié)助等，這是一個(gè)好的加強(qiáng)雙方溝通的方法。

　　注意：在調(diào)研過程的中系統(tǒng)開發(fā)人員的變更會對計(jì)劃產(chǎn)生重大的影響，不要簡單認(rèn)為是人員更換的問題。因?yàn)樵谡{(diào)研過程中對業(yè)務(wù)的理解，不是通過看看文檔就可以達(dá)到。3天通過討論達(dá)到對需求理解的程序，9天對文檔的學(xué)習(xí)也不一定能達(dá)到。

整體調(diào)研

　　對于調(diào)研過程中的整體調(diào)研，一定要其用戶主管者及用戶全體人員（含用戶IT人員）參加，第一個(gè)目的是了解用戶的整體需求細(xì)節(jié)，第二個(gè)目的使用戶人員從各自的角度也了解到用戶方要做一個(gè)什么樣的系統(tǒng)。

　　需求提供者如果是一個(gè)人，他知道自己要一個(gè)什么樣的系統(tǒng)。但如果是多人，在開發(fā)商系統(tǒng)分析人員進(jìn)行調(diào)研前，每人也不過是計(jì)劃自己的需求而已，即使有時(shí)溝通，一般也是在討論而不是進(jìn)行結(jié)論。使業(yè)務(wù)需求并不是很明確。整體調(diào)研的其中一個(gè)目的就是把用戶的多人需求組成一個(gè)整體，整體調(diào)研過程也是一個(gè)用戶人員溝通并整合需求的一個(gè)過程。

　　用戶方多人在進(jìn)行開發(fā)商需求確認(rèn)前，業(yè)務(wù)互相有分歧是相當(dāng)正常的，開發(fā)商系統(tǒng)分析人員必須要在需求調(diào)研過程，使其達(dá)成一致。

　　一般情況下需明確以下問題:

　　當(dāng)前整體業(yè)務(wù)需求的目的

　　要求提供的需求功能列表

　　已經(jīng)定義的需求規(guī)則

　　將來發(fā)展的設(shè)想

　　明確服務(wù)器、客戶機(jī)的軟、硬件及性能要求（容量、速度、可操作性等）

　　用戶目前相關(guān)的技術(shù)人員和業(yè)務(wù)人員情況

　　將來最終系統(tǒng)操作人員的技術(shù)及業(yè)務(wù)人員情況

　　用戶需求的系統(tǒng)及用戶本身或其它系統(tǒng)的接口要求

用戶的其它要求

需求完全明確情況

　　對于整體調(diào)研過后就要進(jìn)行各個(gè)具體業(yè)務(wù)需求的調(diào)研，對于具體需求調(diào)研如果是用戶提供的現(xiàn)有的文檔，開發(fā)商的系統(tǒng)分析人員只是對業(yè)務(wù)進(jìn)行了解及進(jìn)行修改為系統(tǒng)分析人員及業(yè)務(wù)人員全可以看懂的需求說明書，那么這個(gè)過程就比較容易。

　　只要系統(tǒng)分析人員把業(yè)務(wù)文檔看懂看明白，并且對于一些難理解的業(yè)務(wù)描述修改為易懂（有些業(yè)務(wù)名詞有一定的專業(yè)性就要進(jìn)行額外的說明）、明確進(jìn)出的單據(jù)（數(shù)據(jù)項(xiàng)）就可以。當(dāng)然編寫需求說明書具體的細(xì)節(jié)可以參見其他的眾多的書籍及文件模版了。

需求不完全明確情況

　　如果用戶對于自己的需求在調(diào)研開始并沒有完全明確，需要進(jìn)行引導(dǎo)及細(xì)化，那么這個(gè)過程就比較麻煩了。

　　對于用戶本身需求不明情況下，對于業(yè)務(wù)要先從基本業(yè)務(wù)進(jìn)行細(xì)化，對于不明業(yè)務(wù)或不確定業(yè)務(wù)在后面進(jìn)行。對于進(jìn)出的單據(jù)一般在這種情況下用戶當(dāng)沒有現(xiàn)在的文檔，這個(gè)過程只需明確單據(jù)的進(jìn)出的必須數(shù)據(jù)源就可以，如果做到細(xì)節(jié)，由用戶在需求調(diào)研期確定單證，是不太可能的----只是設(shè)計(jì)單據(jù)的樣式、風(fēng)格就不是短時(shí)間可以完成的。對于報(bào)表也只能明確基本報(bào)表要求及數(shù)據(jù)項(xiàng)。一般這種情況使用原型法進(jìn)行，先做一個(gè)簡單的，在簡單的上面再進(jìn)行完善。

　　對于用戶本身需求不明情況下的調(diào)研要做每日（或2到3天,最多3天為間隔）的工作（分析進(jìn)展）記錄，由雙方簽字，因?yàn)檎{(diào)研過程會出現(xiàn)為用戶要求添加一支新業(yè)務(wù)，對新業(yè)務(wù)進(jìn)行分析后，因某些原因發(fā)現(xiàn)不能添加。這個(gè)過程的結(jié)果是一個(gè)0，但為證明是0這結(jié)果可能花了很長的時(shí)間。要記錄這個(gè)過程，說明調(diào)研過程中做了什么事情，有時(shí)有些人可能會說為什么這么長時(shí)間才出這點(diǎn)點(diǎn)東西，到時(shí)以便說明原因。

關(guān)于選取開發(fā)模型

　　有時(shí)開發(fā)模型的選取不是很容易判斷的，這里面有時(shí)不單是需求及開發(fā)的問題，對于開發(fā)商有開發(fā)周期、開發(fā)費(fèi)用的問題，對于用戶同樣有內(nèi)部計(jì)劃、公司發(fā)展計(jì)劃等因素進(jìn)行影響。

　　一般來說對于應(yīng)用開發(fā)―――為客戶開發(fā)軟件，客戶在開發(fā)及測試完畢軟件后就要實(shí)際開始使用，那么就使用瀑布模型。

　　當(dāng)然在需求明確的情況下自然也要使用瀑布模型

　　對于自主開發(fā)及客戶需求不明并有較長的設(shè)計(jì)時(shí)間―――可以用演化模型。

　　而螺旋模型適于適合于大型軟件開發(fā)，吸收了"演化"概念，不過有時(shí)也用于用戶需求不明的情況下。

　　當(dāng)然還有其他開發(fā)模型，沒有在本文討論。

名詞定義

　　瀑布模型：規(guī)定了各項(xiàng)軟件工程活動。包括：制定開發(fā)計(jì)劃、進(jìn)行需求分析和說明、軟件設(shè)計(jì)、程序編碼、測試及維護(hù)。

　　特點(diǎn)：自上而下，相互銜接的固定次序，如瀑布流水、逐級下落。

　　演化模型：第一次只是試驗(yàn)開發(fā)，其目標(biāo)只在于探索可行性，弄清軟件需求;第二次則在此基礎(chǔ)上獲得較為滿意的軟件產(chǎn)品，通常把一次得到的試驗(yàn)性產(chǎn)品稱"原型"。

　　特點(diǎn)：減少由于軟件需求不明確而給開發(fā)帶來的風(fēng)險(xiǎn)。

　　螺旋模型：將瀑布模型及演化螺旋模型結(jié)合起來，并且加入被兩種模型都忽略了的風(fēng)險(xiǎn)分析，彌補(bǔ)了兩者的不足。

完成需求確認(rèn)

　　對于需求最終的確認(rèn)需求先由系統(tǒng)開發(fā)人員對編寫的文檔進(jìn)行內(nèi)部審核及修訂，特別是文字問題。系統(tǒng)分析人員（在中國這些人員一般是物科專業(yè)人員）編寫的文檔文字語法上一般有一定問題。

　　內(nèi)部審核后交由用戶業(yè)務(wù)人員進(jìn)行確認(rèn)，明確系統(tǒng)開發(fā)人員已經(jīng)了解業(yè)務(wù)需求，并進(jìn)行簽字確認(rèn)。

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