軟體需求調研中的5W 1H定律

2022-05-14 19:00:40 字數 2411 閱讀 9431

軟體需求調研中的5w+1h定律

2005.06.28  來自:mypm  泓崢蕭瑟

對於軟體的需求調研活動,雖然曾經寫過三篇相關的需求管理文章,出發角度是從整體的需求管理過程考慮;在引入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 toaccomplish the system了。

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