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

?????????????????????????????????????????

前言
對于需求分析有很多相應的書籍說明如何分析，卻沒有具體的過程描述，本文講述一個實際的可以操作的需求確認過程。
前提
在用戶與公司簽定開發協議的前提下，完成由公司的銷售人員為重點轉變為公司系統開發部門為重點過程中的第一步―――需求分析。對于用戶來講是對多家開發商進行挑選，最終明確一家開發商，并簽訂開發協議后，進行的提供具體需求明確需求的過程―――明確告訴開發商要開發一個具有什么功能的軟件產品。
約定
用戶對于其用什么系統平臺，已經大概知道，并且已經認可。如硬件全部為PC機，客戶機軟件是WINDOWS98/ME/2000，服務器軟件是用WINDOWS　2000，數據庫軟件是SQL　20000。或者用戶注重業務功能，而對于服務器、客戶機、數據庫等大的系統軟件及硬件平臺認可做常規配置就可以。
所用技術體系一般情況下在進行需求分析前最好是明確，不然就要求系統分析人員了解所有的技術體系。不然運氣好，系統分析人員所了解的技術系和用戶相求的相同，進行了正確分析；如果運氣不好可能會把一些認為可以簡單實現而實際實現卻很難的需求答應下來。比如：把DB2的數據庫完全備份還原給SYBASE。
在所用技術體系大概范圍已經明確的情況下，選擇合適的系統分析人員。要求系統分析人員對相應技術體系有一定的了解，以便在相應的分析時有所依據。不同的技術體系有一定的局限性，而有些需求對某些技術體系有一定的難度。如WAP（手機上網）是不太可能實現打印。雖然沒有絕對不能實現的用戶業務需求，但一般情況下開發協議上明確的費用，已經決定系統功能做到什么程度。
其它
相應的工具的使用熟練程度。如果多人進行分析，分工及責任的明確，及團隊的穩定性。相應計劃安排是否合理周全等也是影響獲取需求質量的因素。
到用戶前的準備
組織隊伍
根據實際的工作量及其他情況，組建需求調研隊隊伍，提供辦分設備，明確責任、啟動任務。
準備相應文檔
開發商方的系統分析人員同用戶的需求提供人員正式接觸前，完成一個問詢表及需求分析計劃。
一般情況下只需要完成一個整體細節問詢表，一般問詢用戶為明確需求已經完成的文檔情況（如果可以在進行正式接觸前可以得到并了解完成最好），業務的目的，當前的目標，長遠的目標，當前準備情況，完成的業務功能列表，將來系統操作人員的業務及電腦技術了解情況，最終操作用戶，當前及將來的硬件、軟件及網絡環境等整體問題。
由開發商系統分析人員根據對業務的了解程度，適當編寫各業務功能細節問詢表。不過業務功能細節問詢表的使用，是在業務需求調研過程中用戶表明其需求后，再根據問題還沒有明確的情況下再進行問詢的。不過有時業務功能細節問詢表由于用戶的需求和原計劃不同，使業務功能細節表不在發揮作用。
其他業務相關政策法規、技術文檔、技術支持人員的通信錄等也要進行相應的準備。
聯系及了解用戶方
同用戶進行聯系并取得對方的人員名單、分工情況、權重、工作計劃、工作時間、節假日安排（特別是用戶公司內部的額外規定），如果可能的情況下要求也有用戶的IT人員參加需求過程，實際的需求如果沒有IT人員的參加，在后面的更改一般是IT人員提出的。應在需求過程中把用戶IT人員的需求調研，作為業務調研中一部分。
編寫計劃
根據當前情況，編寫需求分析計劃，明確正式開始日期，中間階段性日期（時間長可多個，調研時間不大于3天可沒有），結束時間，人員名單，分工情況，需用戶提供的幫助等。
將計劃發送給用戶請其確認，在可能的情況下協調用戶和開發商的計劃，以便共同開展工作。
對于計劃如果能編寫及控制到每日是最好的，但是否可以達到真正可控制到日，那就看你的能力了。如果每3天為一個中間性階段進行控制，延遲的時間可以通過加班來彌補。計劃最好根據一天工作8小時進行。如果計劃一天是工作10個小時，也許第一次延遲可以通過加班8小時（一天工作24小時）來彌補，但再有延遲你會發現你的工作人員沒有精力再加班了。
如果要去用戶所在地進行工作，還要準備相應的辦公工具，人手一臺筆記本電腦（電源插座及網絡互連線也要考慮）是比較好的資源配置。
需求調研
第一日
本次所說的第一日是開發商系統開發人員到用戶處正式需求調研過程的第一日。如果是異地調研，那么在第一日前一日開發商系統開發人員應到達用戶所在地，結解住宿，了解住宿地周邊情況。最好是早些休息，為第一日工作開始做好準備。
一般第一日的上午是開發商系統分析人員和用戶業務需要者進行整體介紹，了解辦公環境，建立需求調研過程辦公環境。如果是小型項目涉及人員不多（雙方人員共同不多于3人），一般上午可以進行調研工作1到2小時，不然下午才能正式開始工作（也就說做計劃時第1天一般只有半日的工作時間）。
調研過程
調研的過程推薦開發商系統開發人員有專人進行會議記錄，并在每日會議結束后，當場宣布本次會議的結果，并由參加會議人員進行簽字。第二日復印或發送電子文件給參加會議人員及相關人員。以便做到有據可查，明確過程。
開發商系統開發人員每周對用戶提供開發周報，告訴用戶當前開發的進展、是否有問題、是否用戶協助等，這是一個好的加強雙方溝通的方法。
注意：在調研過程的中系統開發人員的變更會對計劃產生重大的影響，不要簡單認為是人員更換的問題。因為在調研過程中對業務的理解，不是通過看看文檔就可以達到。3天通過討論達到對需求理解的程序，9天對文檔的學習也不一定能達到。
整體調研
對于調研過程中的整體調研，一定要其用戶主管者及用戶全體人員（含用戶IT人員）參加，第一個目的是了解用戶的整體需求細節，第二個目的使用戶人員從各自的角度也了解到用戶方要做一個什么樣的系統。
需求提供者如果是一個人，他知道自己要一個什么樣的系統。但如果是多人，在開發商系統分析人員進行調研前，每人也不過是計劃自己的需求而已，即使有時溝通，一般也是在討論而不是進行結論。使業務需求并不是很明確。整體調研的其中一個目的就是把用戶的多人需求組成一個整體，整體調研過程也是一個用戶人員溝通并整合需求的一個過程。
用戶方多人在進行開發商需求確認前，業務互相有分歧是相當正常的，開發商系統分析人員必須要在需求調研過程，使其達成一致。
一般情況下需明確以下問題:
當前整體業務需求的目的
要求提供的需求功能列表
已經定義的需求規則
將來發展的設想
明確服務器、客戶機的軟、硬件及性能要求（容量、速度、可操作性等）
用戶目前相關的技術人員和業務人員情況
將來最終系統操作人員的技術及業務人員情況
用戶需求的系統及用戶本身或其它系統的接口要求
用戶的其它要求
需求完全明確情況
對于整體調研過后就要進行各個具體業務需求的調研，對于具體需求調研如果是用戶提供的現有的文檔，開發商的系統分析人員只是對業務進行了解及進行修改為系統分析人員及業務人員全可以看懂的需求說明書，那么這個過程就比較容易。
只要系統分析人員把業務文檔看懂看明白，并且對于一些難理解的業務描述修改為易懂（有些業務名詞有一定的專業性就要進行額外的說明）、明確進出的單據（數據項）就可以。當然編寫需求說明書具體的細節可以參見其他的眾多的書籍及文件模版了。
需求不完全明確情況
如果用戶對于自己的需求在調研開始并沒有完全明確，需要進行引導及細化，那么這個過程就比較麻煩了。
對于用戶本身需求不明情況下，對于業務要先從基本業務進行細化，對于不明業務或不確定業務在后面進行。對于進出的單據一般在這種情況下用戶當沒有現在的文檔，這個過程只需明確單據的進出的必須數據源就可以，如果做到細節，由用戶在需求調研期確定單證，是不太可能的----只是設計單據的樣式、風格就不是短時間可以完成的。對于報表也只能明確基本報表要求及數據項。一般這種情況使用原型法進行，先做一個簡單的，在簡單的上面再進行完善。
對于用戶本身需求不明情況下的調研要做每日（或2到3天,最多3天為間隔）的工作（分析進展）記錄，由雙方簽字，因為調研過程會出現為用戶要求添加一支新業務，對新業務進行分析后，因某些原因發現不能添加。這個過程的結果是一個0，但為證明是0這結果可能花了很長的時間。要記錄這個過程，說明調研過程中做了什么事情，有時有些人可能會說為什么這么長時間才出這點點東西，到時以便說明原因。
關于選取開發模型
有時開發模型的選取不是很容易判斷的，這里面有時不單是需求及開發的問題，對于開發商有開發周期、開發費用的問題，對于用戶同樣有內部計劃、公司發展計劃等因素進行影響。
一般來說對于應用開發―――為客戶開發軟件，客戶在開發及測試完畢軟件后就要實際開始使用，那么就使用瀑布模型。
當然在需求明確的情況下自然也要使用瀑布模型
對于自主開發及客戶需求不明并有較長的設計時間―――可以用演化模型。
而螺旋模型適于適合于大型軟件開發，吸收了"演化"概念，不過有時也用于用戶需求不明的情況下。
當然還有其他開發模型，沒有在本文討論。
名詞定義：
瀑布模型：規定了各項軟件工程活動。包括：制定開發計劃、進行需求分析和說明、軟件設計、程序編碼、測試及維護。
特點：自上而下，相互銜接的固定次序，如瀑布流水、逐級下落。
演化模型：第一次只是試驗開發，其目標只在于探索可行性，弄清軟件需求;第二次則在此基礎上獲得較為滿意的軟件產品，通常把一次得到的試驗性產品稱"原型"。
特點：減少由于軟件需求不明確而給開發帶來的風險。
螺旋模型：將瀑布模型及演化螺旋模型結合起來，并且加入被兩種模型都忽略了的風險分析，彌補了兩者的不足。
完成需求確認
對于需求最終的確認需求先由系統開發人員對編寫的文檔進行內部審核及修訂，特別是文字問題。系統分析人員（在中國這些人員一般是物科專業人員）編寫的文檔文字語法上一般有一定問題。
內部審核后交由用戶業務人員進行確認，明確系統開發人員已經了解業務需求，并進行簽字確認。
參考：
《軟件工程》　鄭人杰

總結

以上是生活随笔為你收集整理的从用户接触到完成需求说明书的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。