IT項目管理之需求管理工作流

         1.問題分析
    
　　問題分析可以通過了解問題及涉眾的最初需要，并提出高層解決方案來實現。它是為找出“隱藏在問題之后的問題”而進行的推理和分析。問題分析期間，將對“什么是面臨實際問題”和“誰是涉眾”等問題達成一致。而且，您還要從業務角度界定解決方案，以及制約該解決方案的因素。您應該已經對項目進行過商業理由分析，這將便于您更好地預計能從構建中的項目中得到多少投資回報。

　　2.理解涉眾需要

　　需求來自各個方面，比如來自客戶、合作伙伴、最終用戶或是某領域的專家。您需要掌握如何準確判斷需求應來源于哪方面、如何接近這些來源并從中獲取信息。提供這些信息主要出處的個人在本項目中稱為涉眾。如果您正在開發一個在您公司內部使用的信息系統，那么在開發團隊中應包括具有最終用戶經驗和業務領域專業知識的人員。通常討論將在業務模型這一級上展開，而不是在系統這一級上展開。如果正在開發一個要在市場上出售的產品，那么您可以充分調動營銷人員，以便更好地了解該市場中用戶的需要。獲取需要的活動可使用這樣一些技巧：訪談、集體討論、概念原型設計、問卷調查和競爭性分析等。獲取結果可能是一份圖文并茂的請求或需要列表，并按相互之間的優先級列出。

　　3.定義系統
    
　　定義系統指的是解釋涉眾需求，并整理為對要構建系統的意義明確的說明。在系統定義的初期要確定以下內容：需求構成、文檔格式、語言形式、需求的具體程度（需求量及詳細程度）、需求的優先級和預計工作量（不同人在不同的實踐中通常對這兩項內容的看法大不相同）、技術和管理風險以及最初規模。系統定義活動還可包括與最關鍵的涉眾請求直接聯系的初期原型和設計模型。系統定義的結果是用自然語言和圖解方式表達的系統說明。

　　4.管理項目規模

　　為使項目高效運作，應仔細根據所有涉眾的需求確定優先級，并對項目規模進行管理。有的開發人員僅僅重視所謂的“復活節彩蛋”（即開發人員感興趣或覺得有挑戰性的特性），而不是及早將精力投入降低項目風險或提高應用程序構架穩定性方面，這已使太多的項目蒙受損失。為確保盡早解決或降低項目中的風險，應以遞增的方式開發系統。要慎重選擇需求，以確保每次增加都能緩解項目中的已知風險。要達到目的，您需要和項目的涉眾協商每次迭代的范圍。通常，這要求具備管理項目各個階段的期望結果的良好技能。除了控制開發過程本身，您還需控制需求的來源，并控制項目可交付工件的外觀。

　　5.改進系統定義
    
　　系統的詳細定義應能讓涉眾理解、同意并認可。它不僅需要具備所有功能，而且應符合法律或法規上的要求，符合可用性、可靠性、性能、可支持性和可維護性。感覺構建過程復雜的系統就應該有復雜的定義，這是一種常見的錯誤看法。這會給解釋項目和系統的目的造成困難。人們可能印象深刻，但他們會因不甚理解而無法給出建議。應該致力于了解您制作的系統說明文檔的讀者。您可能常會發現需要為不同的讀者準備不同的說明文檔。
    
　　我們認為用例方法是傳達系統目的和定義系統細節的一種行之有效的方法，它常與簡單的可視化原型結合使用。用例有助于為需求提供一個環境，利用它可生動地說明系統使用的方式。 

　　系統詳細定義的另一個構件是說明系統采用的測試方式。測試計劃及要執行測試的定義將會說明要核實哪些系統功能。

　　6.管理需求變更
    
　　定義需求時無論怎樣謹慎小心，也總會有可變因素。變更的需求之所以變得難以管理，不僅是因為一個變更了的需求意味著要花費或多或少的時間來實現某一個新特性，而且也因為對某個需求的變更很可能影響到其他需求。應確保賦予需求一個有彈性的結構，使它能適應變更，并且確保使用可追蹤性鏈接可以表達需求與開發生命周期的其他工件之間的依賴關系。管理變更包括建立基線、確定需要追蹤的重要依賴關系、建立相關項之間的可追蹤性，以及變更控制等活動

原文轉自：http://www.anti-gravitydesign.com