模板
教程
環境
性能
功能
管理
IBM 軟件產品需求管理流程
本文內容包括:
1. 簡介
2. 背景——IPD
3. IPD 與產品需求管理流程
4. 產品需求管理流程中的角色
5. 產品需求管理流程的三個階段
6. 產品需求管理流程的價值
7. RATLC——通過ClearQuest實現需求管理流程
8. 總結
參考資料
關于作者
IBM 軟件產品的版本(V.R.M.F)從市場規劃和客戶需求開始，到研發以及后續的交付遵循 IBM 軟件部集成產品設計(IPD)流程。
1. 簡介
IBM 軟件產品的版本(V.R.M.F)從市場規劃和客戶需求開始，到研發以及后續的交付遵循IBM軟件部集成產品設計(IPD)流程。IBM 軟件產品需求管理流程是IPD的一個體現，也就是一個由市場/客戶驅動的，跨市場部門、研發產品管理部門及研發工程部門的端到端需求管理流程。同時，此次內容我們將描述IPD和產品需求管理流程，及流程中的角色（市場、研發產品管理部門及研發工程部門），以及他們之間是如何通過協作來管理需求的。
2. 背景——IPD
IPD指導如何對軟件產品發布版本進行投資決策和如何協調部門間工作以實現這些決策所定義目標，IBM軟件產品需求管理基于IPD流程，要了解這個需求管理的流程，首先我們要了解IBM所有產品開發所遵循的IPD的流程，包括其決策點。
IPD流程分為六個步驟：
概念：即概念驗證階段，主要對需求包進行評審，以確定其是否有足夠的商業價值； 計劃：即資源投入計劃階段，主要對需求包進行評估，以確定是否有足夠的資源且在一定的時間范圍內將需求包開發出來； 開發：即對需求包進行開發成產品階段； 驗證：即對產品進行驗證階段； 交付：即將產品交付市場階段； 生命周期：即產品在市場上銷售，使用，維護和退出市場的階段。 其中包括了幾個重要的決策檢查點(DCP)： 概念決策檢查點：即經過概念階段各方面進行的一系列評審，在此檢查點確定（1）我們對需求包是否有足夠的理解；（2）需求包是否有足夠的商業價值。如果是，繼續進入計劃階段； 計劃決策檢查點：即經過計劃階段的評估，在此檢查點確定（1）我們是否有足夠的資源在既定的時間范圍內完成需求包的開發（2）研發部門是否能在(1)的估計上承諾進行開發。如果是，繼續進入開發階段； 可交付決策檢查點：即經過開發和驗證階段，在此檢查點確定（1）產品是否質量合格以交付給客戶（2）我們產品的相應支持和銷售是否已經準備好服務客戶,如果是，產品交付市場； 生命周期結束決策檢查點：即產品在市場使用一定時期后，在此檢查點確定產品是否退出市場。一個產品從市場需求開始，經過概念驗證，時間、資源等計劃的支持，然后進行開發，驗證，直至發布到市場供客戶使用，最后在某個特定的時候結束產品在市場上的銷售，在IBM都遵循著IPD流程。在其中過程中，這個產品的概念是否被接受，是否能得到資源上的投入的承諾，是否通過最終驗證可以在市場上發布，以及什么時候在市場上停售，這些關鍵的決策都通過相應的委員會在不同的決策點上進行決策。
3. IPD 與產品需求管理流程
以上描述了IBM IPD的基本概念，我們接下來看IBM軟件產品的需求管理是如何基于IPD的。首先，請看下圖一：產品需求管理流程。
圖一：產品需求管理流程
這個產品需求管理流程是如何與以上IPD的階段相映射的呢？主要為以下幾點：
而產品需求管理流程與決策點的映射，主要為以下幾點：
概念決策點-評估需求給IBM帶來市場價值，決定是否接納，如需求是不是有足夠的業務潛力使得IBM產品能夠成為市場的領導者； 計劃決策點-評估需求開發的投入，決定是否將其放入開發計劃，如是否有相應的資源使得我們能在既定的時間范圍內實現需求； 可交付決策點-評估需求實現的狀況，決定是否放入發布計劃，如驗證需求的功能及質量等是否滿足要求。4. 產品需求管理流程中的角色
產品需求管理流程中通過以下幾類角色的參與并互相協作，推動需求通過評審并納入到產品開發路線圖里面。
市場部門
根據市場、競爭對手的信息，客戶的反饋，技術發展方向以及IBM現在的產品組合，定義IBM在此市場領域需要提供的解決方案(O/SBP)。
研發產品管理部門
根據市場部門制訂的解決方案(O/SBP)，及客戶反饋的的改善和缺陷，定義產品發布版本所要提供的功能－即產品的需求。
研發工程部門
根據產品需求，評估開發需求所需要的資源、時間等，并對需求進行設計、開發和測試等，建立需求與設計開發之間的追蹤關系。
技術支持
代表IBM與客戶進行溝通，反饋需求所處的狀態。
以上角色的互相協作關系請參考以下產品需求管理流程的三個階段描述。
5. 產品需求管理流程的三個階段
此流程是通過IBM內部系統RATLC實現，這個將在后面第7部分介紹。
IPD概念階段
研發產品管理部門根據市場部門制訂的解決方案(O/SBP)，定義產品所要提供的功能－即產品的需求。研發產品管理部門將這些需求信息提交到RATLC，包括：
需求描述及提出理由 需求所涉及的產品模塊如果此需求是因為客戶反饋的改善和缺陷而產生，那么研發產品管理部門將其與需求關聯。改善是指客戶在使用此產品的過程中提出的功能改善的要求，而缺陷是指：客戶在使用此產品的過程中發現的缺陷。
當備選需求進入RRM以后，評審委員會，包括市場部門、研發產品管理部門，研發工程部門的代表會復審備選需求以決定那些需求通過概念決策點 （當前的版本）。評估的條件包括其業務的重要性和對產品開發的影響（初步的需求規模評估）在評估的過程中，任何對此需求開發風險的認識，如需要的開發時間、性能要求等都被記錄下來，作為此需求的風險記錄，作為整個開發過程的參考。
對已經批準需求進行排序，同時需要增加以下內容：
將在哪個版本實現 負責人 業務的重要性沒有通過概念決策點的需求：
被拒絕，即現在沒有任何實現的時間表； 被延遲，將在下次版本的概念階段被重新考慮； 需要添加負責人和注釋以備查。IPD計劃階段
為了了解開發的投入，并能夠給每個需求制訂詳細的開發計劃，所有需求都要進行規模評估。評估的內容包括現在或將來開發此需求所需要的人力，時間和資源。通過研發工程部門和研發產品管理部門的多次和及時的溝通，需求的規模被確定。如果需求規模被修改，研發產品管理部門將再次和市場部門和技術支持部門溝通，以確認修改。修改的記錄會記錄在需求變更流程里面。通過規模評估的需求，需求會關聯一條或多條的規模評估記錄：需求開發所需要的資源、人力及計劃。
同時，開發團隊根據IRUP指導對需求進行詳細的描述和設計，包括用例建模，建立測試策略和項目計劃等。
沒有通過計劃決策點的需求：
被拒絕，即現在沒有任何實現的時間表； 被延遲，將在下次版本的Concept Phase重新考慮； 需要添加負責人和注釋以備查。IPD 開發和驗證階段
在此階段，開發團隊決定是否針對需求制訂開發計劃, 并對需求進行開發和測試，如果制訂計劃，需要提供以下信息：開發的狀態。在開發過程中，需求一直處于InPlan狀態，直到通過Availability DCP后，需求狀態轉變為Delivered。
如果由于開發計劃延后，或開發過程中出現技術問題而導致開發團隊決定不將其放入開發計劃，需求會被Decommitted。如果有變更情況，負責人需要將變更記錄與需求關聯。
6. 產品需求管理流程的價值
1． 統一的版本需求管理流程：無論是外部的客戶需求，IBM的市場規劃需求都使用相同的流程，統一的評估，統一的規劃，確保需求的開發與業務目標發展一致。
2． 需求端到端狀態的可視化：需求記錄包含豐富的信息包括變更的記錄，使得市場部門、研發產品管理部門和研發團隊能夠及時了解需求所處的狀態，減少多方溝通的時間，并能夠及時的向客戶傳遞相應的信息，提高客戶的滿意度。
3． 需求信息的集中管理：每條需求都有相應的屬性，如客戶優先級別，所涉及的產品模塊等，需求開發時間等。有了這些信息，市場部門和研發團隊可以定制各種報表對需求進行查詢、過濾和排序，多角度的了解需求的狀況。
4． 全球同步進行需求管理：雖然IBM市場部門及研發團隊都分布在全球不同地點，但是所有相關人員可以通過WEB的方式訪問需求，進行需求的溝通。
7. RATLC——通過ClearQuest實現需求管理流程
在IBM內部是使用什么系統來支撐需求管理流程的呢？答案是RATLC。 它既是 IBM 軟件部用于管理產品需求和產品缺陷的系統。 RATLC通過Rational ClearQuest工具定制實現。同時由于IBM的軟件研發團隊分布在全球各地，為了實現每個地區團隊能快捷地訪問需求，RATLC通過ClearQuest MultiSite實現了“本地復本，全球同步”的模式?，F在RATCL在全球一共有 11個復本，分別位于北美、印度、法國和中國，復本之間的一致性通過ClearQuest MultiSite的自動同步功能實現。
IBM Rational ClearQuest 是一個強大而高度靈活的需求、缺陷和變更、測試計劃和用例管理平臺，能在整個開發周期內捕獲、跟蹤并管理各種類型的記錄，幫助您以更高的效率交付出更高質量的軟件。無論您使用的平臺是Windows、UNIX或是Web，可完全自主定制的界面和工作流程引擎都能適應任何開發流程。由于ClearQuest支持業內標準數據庫，所以它可任意擴展，以支持任何規模的項目。
RATLC的具體實現方式：
（1） 通過ClearQuest Designer定制RATLC中的需求管理流程。ClearQuest本身內嵌了需求管理、缺陷管理和測試管理流程。同時，鑒于IBM需求管理流程有特殊性的需求， ClearQuest提供了靈活的手段在上述的內嵌流程中進行客戶化定制。RATLC就是通過ClearQuest Designer的狀態過渡矩陣定制產品需求管理流程中的需求狀態和其過渡關系，如圖二：
圖二：ClearQuest Designer的狀態過渡矩陣
圖三是通過ClearQuest Designer定制好后的需求管理流程的狀態圖，圖中的橢圓代表的是需求的狀態，箭頭上的文字代表用戶經過何種操作后，需求的狀態發生了相應的變化。如需求處在“Submitted”狀態，用戶經過評審，確定了此需求的優先級別并更新了界面中此需求的優先級別屬性后，按下界面中“Prioritize”按鈕，需求的狀態變為“Prioritized”。
圖三：通過ClearQuest定制的需求在流程中的狀態
?。?）通過ClearQuest Designer表單定制功能直觀地定制RATLC用戶界面。
我們可以通過ClearQuest Designer提供的可視化表單定制功能直觀地定制用戶界面?；旧鲜峭ㄟ^Designer提供的界面工具集如按鈕、文字框等拖拽地設計用戶界面。如圖四：
圖四：ClearQuest Designer表單定制功能
圖五是通過ClearQuest Designer表單定制功能定制出來的RATLC需求錄入界面。
圖五：RATLC的需求錄入界面
?。?） 通過ClearQuest客戶端定制各式報表
在RATLC中系統管理員配置了不同產品的缺省報表，當用戶和登錄到系統的時候可以根據報表的類型（如按產品名稱分類的報表）來選擇需要查看的需求記錄。
或者，用戶登錄到系統后，可以自定義報表，如產品經理需要反復查看某個客戶所提交的所有需求和缺陷記錄的狀態，他可以自定義這樣的報表，以方便在每次登錄系統后都能很迅速地查詢到所需要的信息。
報表的定制也是非常簡單，通過拖拽字段的方式就可以便捷地建立所需要的報表。
圖六：通過ClearQuest定制各式報表
?。?）多客戶端界面選擇-Web/Windows UI/Eclipse
RATLC充分利用了ClearQuest多客戶端的特點，為不同類型的用戶提供了不同的使用界面。如市場部門及研發管理部門人員，由于他們的日常操作多為查詢需求的狀態和修改需求記錄等，RATLC為這部分人員提供了WEB訪問的方式；而對于研發工程人員，由于他們需要對需求進行開發，這就涉及到與配置管理工具的集成實現變更記錄與代碼的結合，RATLC為他們提供了Windows客戶端或Eclipse客戶端，這樣研發工程人員的開發環境就能很方便地與ClearQuest結合起來。
（4）ClearQuest與ClearCase集成
在RATLC系統中，當某個需求經過批準后被分發到相應的開發人員，此開發人員可以通過ClearQuest與ClearCase的集成，在檢出代碼或文檔修改的時候選擇相應RATLC系統的記錄。這樣，變更的原因（需求）和變更的結果（代碼或文檔）就能緊密的集成在一起，方便隨后進行雙向的查詢，如QA可以通過RATCL了解此需求變更涉及到哪些代碼改變，或某個文件的新版本是由于什么原因而產生的。
8. 總結
此次我們介紹了IBM軟件產品需求管理流程， 它是IBM IPD的一個實例，也就是一個由市場/客戶驅動的，跨市場部門、研發產品管理部門及研發工程部門的端到端需求管理流程。此流程在IBM內部的支撐系統RATLC是通過Rational ClearQuest這一優秀生命周期管理集成器來實現（如圖七）。Rational ClearQuest涵蓋了需求管理、變更管理、缺陷管理和測試管理。
圖七：Rational ClearQuest – 生命周期管理集成器
參考資料
developerWorks 中國網站 Rational 專區
如果您對Rational ClearQuest感興趣并想繼續研究，您可以參考以下網頁：ClearQuest 產品頁面
如果您想試用Rational ClearQuest，您可以到以下網址下載試用版：ClearQuest 試用版
關于作者
劉昀，現任 IBM 中國有限公司軟件部 Rational 華南大區技術主管?，F主要負責 Rational 產品在華為的推廣和技術支持工作。在此之前，劉昀曾任職于 Bea 中國有限公司，從事J2EE解決方案的咨詢工作。在加入 Bea 之前，劉昀在美國通用電器從事電子商務系統的設計開發。在軟件工程技術方面，劉昀有著多年的實踐經驗，對于 Rational 的軟件工程技術有著深刻的理解。
原文轉自：http://www.anti-gravitydesign.com
