軟體項目需求調研中的5W+1H定律案例分析

轉自：http://www.cioage.com/art/200909/85777.htm

      對於軟體的需求調研活動，雖然曾經寫過三篇相關的需求管理文章，出發角度是從整體的需求管理過程考慮；在引入CMM（二）需求管理KPA活動的基礎
上，列舉了如何進行需求調研前的需求管理計劃活動；在失敗的項目中，找出規範和管理軟體需求過程的關健點及需求關聯的模型架構（這些可以參考以前寫過的
《CMM需求管理實踐經驗記錄談》、《從CMM角度考慮需求管理計劃》、《如何用CRC模型來確定需求》）。一直以來，感覺自己在經過幾個項目實驗的基礎
上對於軟體的需求管理應該是有一定的基礎和經驗了，然而在最近參與的一個大型項目過程中，在新加坡專案經理的引導與協助下，對於軟體需求調研又有了更深一
層的體會和認識；總結出需求調研中的5W+1H定律，在此把自己的一些過程和經驗描述出來，希望能與各同仁一起分享與討論。

項目背景：一個中型的公司資訊化項目，其中乙方的專案經理是一個擁有PMP認證的資深專案管理
人員。甲方的專案經理是一個有著豐富項目實施和管理經驗的新加坡專案管理
人員。（在這裡需要補充的時，在調研產生衝突過程中，外籍人員如何用自己的經驗和技巧，讓乙方完全可以接收）

項目成員：
甲方：外包專案經理、外包專案管理
人員
乙方：專案經理、系統分析員、介面製作人員

      工作內容：項目需求階段的活動，對於系統的需求，甲乙雙方與終端使用者能達成一致，甲方作為外包管理者，主要是對乙方項目組的項目進度、項目階段成果進行跟蹤與驗收，以保證項目在預期的時間內完成預期的工作任務。

流程說明：項目啟動後，乙方的專案經理列了一份詳細的需求調研時間表、調研階段成果目錄清單、介面成果等的計劃內容，可以用一個 “贊”
字來形容；從計划上看，乙方的專案經理計劃真的是完美無缺；在與使用者進行業務需求調研的活動中，乙方不僅記錄下目前使用者現有的商務程序，包括目前流程的局
限性，流程的執行性等方面，還為使用者進行了將來系統流程的規劃，的確是一個不錯的開始。可是在乙方提交其階段的需求分析文檔和介面時，卻發現二者存在了種
種的衝突和矛盾，我們無法將需求分析文檔與介面結合在一起。此時，乙方的專案經理解釋是因為文檔比介面細，所以二者存在一些理解上的差異。而我們甲方卻總
覺得有些不太對勁，但因為同樣存在著對使用者流程細節的不熟悉，所以我們也提不出具體的問題，直到有一天，跟著乙方一起做使用者的需求活動後，從乙方專案經理
的提問方面，我們終於明白為什麼他們會做出這樣的文檔和介面。

首先，乙方專案經理對使用者的提問是沒有序列的，我們所謂的序列就是專案經理的邏輯是否清晰，除了問及目前的流程外，最重要的引入項目（即新的軟體系統）的
目的，所需達到的效果，可以對使用者輔助的東東，而這些乙方的專案經理一字未提與問，只記錄使用者所說的過程、局限和要求。這樣，乙方專案經理在分析與規劃系
統的需求時，就沒有一個明確的目的性和方向性，這裡就要引入第一個W定律---WHY定律。WHY就是為什麼使用者要引入系統，引入新的資訊系統對使用者有什
麼協助，在總體工作效能上如何?一個最終的結果？WHY定律是要求在需求開始時，專案經理就應該明確的，這個項目是為了改進使用者工作效率；提高部門間的
協作機制；加快對客戶反應的體系服務；提升企業的競爭力等等。有了這麼一個WHY引入思想，專案經理就可以理清使用者最終要的是可以提供給他們什麼樣的系
統，在系統的定位和建立上，就有一個明確地最終目標。

其次，有了一個總體的目標性，從各商務程序的要求入手，引入第二個W定律---WHAT定律，WHAT則是這個系統要做什嗎？實現什嗎？就是乙方
專案經理提出的各商務程序問題、流程局限性問題、系統要解決的問題等，在這個WHAT的基礎上，把系統劃分成各功能模組，逐步弄清模組流程需求、功能需
求、結構需求。引入WHAT定律可以讓我們瞭解到系統的初步需求。

      再次，引入第三、四、五個定律---WHO、WHEN、WHERE定律，這個階段其實就是需求細化階段，在WHAT定律的基礎上，細分系統的使用者需
求：分析什麼人，在什麼時間，什麼階段可以或必須操作這個功能，結合前面的WHAT定律，理清系統的流程階段劃分，記錄並分析系統功能實現的細節，在這個
階段就可以產生系統需求的使用案例圖（Use Case），作為下階段設計的依據。

最後，就是所謂的1H定律---HOW定律，就是怎樣實現系統了，在前面的WHY、WHAT、WHO、WHEN、WHERE基礎上，我們已經搭建了
一個非常好的系統需求基礎架構，如何在這些使用者需求的基礎上，分析系統的需求，如何進行需求規格的分析與下階段的設計、實現工作，就是HOW TO
ACCOMPLISH THE SYSTEM了。

      
在需求階段引入這5W+1H的定律，在一定程度上保證了系統需求的準確性，也使得專案經理或需求分析人員可以非常有序的有條理的開展需求挖掘和調研
活動，這樣的安排使用者在配合上也非常清晰，知道如何與項目人員配合。其後，在我們的建議下，乙方改進了工作方式，理清了一些工作序列，不過在最終文檔的提
交上，乙方的專案經理為了迎合我們的需求，一直對需求文檔的格式與內容進行修改，沒有保持需求分析中應該有的從粗到細的階層分析，也導致其需求分析中的不
確定性因素較多，後期的設計工作展開不順，這些算後話，希望能在以後的外包管理方面，就存在的這些問題進行其它的分析和討論。