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

轉：http://www.educity.cn/se/620915.html

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

　　　項目背景：一箇中型的企業信息化項目，其中乙方的項目經理是一個擁有PMP證書的資深項目管理人員。甲方的項目經理是一個有着豐富項目實施和管理經驗的新加坡項目管理人員。（在這裏須要補充的時，在調研產生衝突過程當中，外籍人員如何用本身的經驗和技巧，讓乙方徹底能夠接收）

　　項目成員：甲方：外包項目經理、外包項目管理人員。乙方：項目經理、系統分析員、界面製做人員

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

　　過程描述：項目啓動後，乙方的項目經理列了一份詳細的需求調研時間表、調研階段成果目錄清單、界面成果等的計劃內容，能夠用一個 「贊」字來形容；從計劃上看，乙方的項目經理計劃真的是天衣無縫；在與用戶進行業務需求調研的活動中，乙方不只記錄下目前用戶現有的業務流程，包括目前流程的侷限性，流程的執行性等方面，還爲用戶進行了未來系統流程的規劃，的確是一個不錯的開始。但是在乙方提交其階段的需求分析文檔和界面時，卻發現兩者存在了種種的衝突和矛盾，咱們沒法將需求分析文檔與界面結合在一塊兒。此時，乙方的項目經理解釋是由於文檔比界面細，因此兩者存在一些理解上的差別。而咱們甲方卻總以爲有些不太對勁，但由於一樣存在着對用戶流程細節的不熟悉，因此咱們也提不出具體的問題，直到有一天，跟着乙方一塊兒作用戶的需求活動後，從乙方項目經理的提問方面，咱們終於明白爲何他們會作出這樣的文檔和界面。

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

　　其次，有了一個整體的目標性，從各業務流程的要求入手，引入第二個W定律---WHAT定律，WHAT則是這個系統要作什麼？實現什麼？就是乙方項目經理提出的各業務流程問題、流程侷限性問題、系統要解決的問題等，在這個WHAT的基礎上，把系統劃分紅各功能模塊，逐步弄清模塊流程需求、功能需求、結構需求。引入WHAT定律可讓咱們瞭解到系統的初步需求。

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

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

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