引言
IBM Rational DOORS，簡稱DOORS，是被業界廣泛認可的需求管理工具，在國內外需求管理領域具有較高的市場占有率。需求管理作為傳統的工程領域，理論發展相對成熟和健全。隨着越來越多的企業開始注重在需求管理工程層面的投入，企業的需求管理成熟度也在逐步提高。在需求管理實施過程中，不可避免的會依托相關的需求管理工具支撐。而實施過程中所存在的關鍵困難之一就是：工具與業務如何緊密結合。很多企業雖然購買了相應的產品，但是工具層面的操作培訓不足以使得企業的項目在需求管理工具中落地。鑒於此種情況，本文將基於具有較大受眾的DOORS工具，對實施需求管理的工作流進行論述。
需求管理的關鍵要素
要實施需求管理，總要明確需求管理要實施那些內容。本質上，實施那些內容沒有統一的規定或約束。但我們可以從一般的需求管理理論層面入手，明確需求管理的理論范疇。
需求管理屬於需求工程范疇，需求管理強調四個方面：需求狀態管理、需求追蹤、需求版本管理和需求變更管理。
狀態管理：需求除了自身的主題內容描述之外，還具有相應的狀態屬性。這些屬性標識了需求在整個系統研發的生命周期中的狀態。基於不同的業務需求，需求需要不同的狀態進行描述。從工程師角色維度分析，作為測試工程師，我們可能關注需求的驗證狀態（驗證結果：測試通過、測試未通過或未測試等等）。而作為軟件開發人員，我們可能關注哪些需求是由我負責，當前需求的實現狀態是什么。作為項目經理，我們可能關注需求的滿足狀態是什么，又或者是需求的成本等等。同樣的，我們還可能關注需求是不是被評審通過了、需求的變更狀態等等。
需求追蹤：需求追蹤是需求管理中非常關鍵且極為重要的方面之一。需求追蹤提現在兩個層面：需求層級內部的追蹤以及跨領域的追蹤。需求層級內部的追蹤是指在分層的需求間建立的關聯關系，例如從用戶需求到系統需求間的追蹤，從系統需求到子系統需求間的追蹤，以及子系統需求到組件需求間的追蹤等等。跨領域的需求追蹤，是指關聯不僅僅發生在需求之間，需求還應該和測試、設計、實現相關的工件建立關聯，以實現在系統研發整個生命周期的可追蹤性。
版本管理：對需求的版本進行管理，記錄需求數據的歷史記錄，方便歷史數據的追溯。
需求變更管理：變更管理也是需求管理至關重要的一環，也是需求管理中最為常見的活動。變更管理要記錄變更的原因、時間、變更內容、變更歷史等內容。
當然，以上四個是需求管理的基本要素，至少在需求管理的實現效果中會體現。初次之外，需求管理還有一個橫貫所有要素的方面 - 流程管理。對，就是流程，管理離不開流程，高效的流程是實施需求管理的關鍵。需求管理中經常出現的流程包括但不限於以下幾個層面：
需求評審流程
基線發布流程
需求變更流程
需求入庫流程
需求實施的典型過程
- 啟動項目：召集項目相關人員召開項目啟動會，明確實施目的、范圍、願景以及協調組織機制，宣布項目啟動。該階段必須要有高層參與，得到高層的潛力支持，這是保證實施項目成功的關鍵要素之一。
- 確定試點項目：在企業內部選定一個典型項目作為需求管理實施的試點項目，以此確定當前實施的范圍。
- 確定項目核心成員：需求管理項目以試點項目為起點，須要試點項目核心成員的參與。明確參與人員列表、角色、職責等。
- 需求管理現狀調研：實施團隊人員要對客戶當前的需求管理現狀有明確的認識，通過現狀調研，了解企業目前存在的問題及痛點。 -- 生成需求管理現狀調研報告。
- 業務流程調研：調研企業內部當前的需求管理相關的業務流程，例如當前的需求管理規范、項目實施的階段划分、需求變更流程、需求基線發布流程、需求評審流程等等相關流程。-- 生成業務流程調研報告
- 實施方案制定：基於已調研的信息，並結合行業經驗，形成需求管理實施方案。
- 實施方案落地：實施方案必然涉及到相關信息化工具的支撐，該階段基於已評審的實施方案進行實施。
- 試點項目試運行：將定制的方案在試點項目中試運行，解決試運行過程中出現的問題，發現並記錄方案潛在的優化點。
- 方案優化：基於試運行的反饋信息，對已有方案進行優化。
- 方案退關：在企業內部更大的范圍內推廣需求管理實施方案。
基於DOORS的特定實踐
結合DOORS的實踐主要體現在實施方案的制定階段，在該階段的方案細節要充分考慮DOORS工具的功能特點。典型的，包括以下幾個層面
- 定義需求信息架構模型：所謂信息架構模型是指需求在DOORS中的組織結構，項目、文件夾、模塊、鏈接模塊如何組織，這當然隱式的包括了納入需求管理的文檔范圍。
- 定義需求跟蹤矩陣： 定義模塊間需求的條目的追中關系，例如是從系統需求指向用戶需求，還是從用戶需求向下指向系統需求。將模塊間的鏈接關系定義好。
- 定義需求屬性：基於業務需要，對需求所需要具備的屬性進行定制。不同的模塊可能定義的屬性不太一樣。而該定義那些，不同企業和業務流程可能不同。
- 定義模塊視圖：視圖的定制有利於不同角色或用戶便捷的定位所需要的數據。同樣，基於DOORS的視圖機制，根據實際的業務需要定義不同的視圖。
- 定義用戶權限分配：為用戶或角色進行權限分配。
典型的最佳實踐
- 以分層的方式存儲需求：用戶需求、系統需求、子系統需求、組件需求等
- 鏈接模塊單獨存在一個文件夾中
- 需求存儲條目化，表達多條需求的文字描述要進行拆分
- 需求鏈接的方向保持一致
- 通用視圖：需求評審視圖、變更影響分析視圖、標准視圖、測試視圖、實現視圖等等
- 通用屬性：優先級、來源、分配人員、評審狀態、滿足狀態、驗證狀態、可驗證性、成本、風險、需求類型、是否需求等等
- DOORS模塊中只有葉子結點存放需求，非葉子結點不是需求。
總結
不同企業內的需求管理實踐各有不同，但共性的都包括需求的狀態管理、跟蹤、版本、變更以及與之相配套的流程。即使沒有需求管理工具的支撐，企業還是可以按照需求管理的理念進行實踐。只不過基於需求管理工具能夠降低需求管理的復雜性，一定程度上降低成本，提高需求管理的效率。