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

前提

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

約定

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

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

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

其它

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

到用戶前的準備

組織隊伍

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

準備相應(yīng)文檔

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

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

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

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

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

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

編寫計劃

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

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

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

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

需求調(diào)研

第一日

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

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

調(diào)研過程

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

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

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

整體調(diào)研

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

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

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

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

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

　　要求提供的需求功能列表

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

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

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

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

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

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

用戶的其它要求

需求完全明確情況

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

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

需求不完全明確情況

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

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

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

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

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

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

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

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

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

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

名詞定義

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

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

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

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

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

完成需求確認

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

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

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