項目調研經驗談[2]

　　2、和業務關鍵用戶用開會的方式討論業務流程細節，并繪制業務流程圖。當關鍵用戶和項目 團隊通過對需求報告的編寫、閱讀和討論后，就可以開始對業務流程的細節討論。這個討論內容是涉及到每一個細小的業務流程環節，環節之間的關系，和業務流程流轉相關的輸入輸出信息，例如在審核出庫單時，出庫數量和可用庫存數量就是和流程相關的信息。（這時應避免偏離重心，過多討論系統界面、和流程無關的軟件操作方式）。業務流程圖是一份正式的文檔，需要讓用戶簽字確認，和需求規格說明書一起作為以后的需求文檔。占總調研時間的15%

　　3、打通業務流程圖后，根據業務流程每個環節，討論在每個環節上的詳細輸入輸出項和操作。這里的討論會增加更多的信息項，這些信息項可能和業務流程流轉沒有必然關系，但對于業務用戶方便地獲取各種業務信息是必要的描述。這里的討論也有可能會部分更改前期描繪的業務流程圖。我個人認為，此時也不建議過多在操作方便性上做討論，原因在概要設計里講。占總調研時間的35%。

　　4、編寫需求規格說明書，編寫過程中會對不少需求細節再討論，再確認。千萬別埋頭編寫，不和用戶做 溝通討論！占總調研時間的50%。最后要讓用戶簽字確認需求規格說明書。

　　5、需求規格說明書寫的要有多細？其實這個問題沒有唯一準確的答案，各個項目未必一樣。文檔的目的是在整個項目周期中，讓項目團隊及關鍵用戶所有人對相關需求的理解都是足夠細致，沒有歧義的，并且可以依據其內容準確工作。系統越大越復雜，信息量就越大，項目周期一般較長，那么對需求文檔的質量要求應該更高；對于小系統或簡單系統，如果你決定在較短的時間內完成需求規格說明書，那么也一定要和關鍵用戶、項目團隊做充分細致的需求溝通（這種需求溝通往往占 項目經理一半以上的時間），要做需求變更記錄，對容易引起歧義的部分需求要描述詳細，并且做好心理準備和時間準備，在軟件和用戶見面后，會有較多的修改。

原文轉自：http://www.kjueaiud.com