從用戶接觸到完成需求說明書

前言

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

前提 
在用戶與公司簽定開發協議的前提下，完成由公司的銷售人員為重點轉變為公司系統開發部門為重點過程中的第一步―――需求分析。對于用戶來講是對多家開發商進行挑選，最終明確一家開發商，并簽訂開發協議后，進行的提供具體需求明確需求的過程―――明確告訴開發商要開發一個具有什么功能的軟件產品。

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

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

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

其它 
相應的工具的使用熟練程度。如果多人進行分析，分工及責任的明確，及團隊的穩定性。相應計劃安排是否合理周全等也是影響獲取需求質量的因素。

到用戶前的準備

組織隊伍 
根據實際的工作量及其他情況，組建需求調研隊隊伍，提供辦分設備，明確責任、啟動任務。

準備相應文檔 
開發商方的系統分析人員同用戶的需求提供人員正式接觸前，完成一個問詢表及需求分析計劃。

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

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

其他業務相關政策法規、技術文檔、技術支持人員的通信錄等也要進行相應的準備。

聯系及了解用戶方 
同用戶進行聯系并取得對方的人員名單、分工情況、權重、工作計劃、工作時間、節假日安排（特別是用戶公司內部的額外規定），如果可能的情況下要求也有用戶的IT人員參加需求過程，實際的需求如果沒有IT人員的參加，在后面的更改一般是IT人員提出的。應在需求過程中把用戶IT人員的需求調研，作為業務調研中一部分。

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

將計劃發送給用戶請其確認，在可能的情況下協調用戶和開發商的計劃，以便共同開展工作。

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

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

需求調研

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

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

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

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

注意：在調研過程的中系統開發人員的變更會對計劃產生重大的影響，不要簡單認為是人員更換的問題。因為在調研過程中對業務的理解，不是通過看看文檔就可以達到。3天通過討論達到對需求理解的程序，9天對文檔的學習也不一定能達到。

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

原文轉自：http://www.anti-gravitydesign.com