對於軟體的需求調研活動，曾經寫過三篇相關的需求管理文章，出發角度是從整體的需求管理過程考慮；在引入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的定律，在一定程度上保證了系統需求的準確性，也使得專案經理或需求分析人員可以非常有序地有條理地開展需求挖掘和調研活動，這樣安排，用 戶配合起來概念也很清晰，知道如何與專案人員配合。其後，在我們的建議下，乙方改進了工作方式，理清了一些工作序列，不過在最終文件的提交上，乙方的專案 經理為了迎合我們的需求，一直對需求文件的格式與內容進行修改，沒有保持需求分析中應該有的從粗到細的階層分析，也導致其需求分析中的不確定性因素較多， 後期的設計工作展開不順，這些算後話，希望能在以後的外包管理方面，就存在的問題進行其它的分析和討論。
需求的獲取 需求調研中的5W 1H定律
在企業的銷售隊伍中，經常聽到的抱怨是 我們的客戶不需要 我們的客戶沒有錢 客戶說要等一段時間 等等一些無法開發和征服客戶的聲音，根本的原因是由於不了解客戶的真實需求，銷售人員在銷售時盲無目的地向客戶介紹或者演示產品，結果徒費口舌，不但沒有把自己產品的特色向特定的消費者闡述清晰，還誤導了其他的銷售人員...
需求變更的5W1H分析
why，需求為什麼變化？甲方的特殊原因 不知道如何說清楚需求 沒有明確的需求 沒有確認乙方描述的需求 乙方的特殊原因 理解錯了需求 沒有很好的誘導客戶的需求 共性原因 業務就是變化 人與人之間的溝通本來就存在障礙 特殊原因是可以消除的，共性原因是難以消除的。who 誰會提出需求變化？客戶 客戶方的高...
5W1H分析法 什麼是5W1H分析法？
5w1h分析法也叫六何分析法，是一種思考方法，也可以說是一種創造技法。是對選定的專案 工序或操作，都要從原因 何因 物件 何事 地點 何地 時間 何時 人員 何人 方法 何法 等六個方面提出問題進行思考。這種看似很可笑 很天真的問話和思考辦法，可使思考的內容深化 科學化。具體見下表 表 5w1h分析...