（譯自Rose Enterprise 2000中的RequisitePro 4.5中的隨機文件）
需求管理是對變動的需求進行確定、組織和製作文件的過程。本文將介紹Rational Unified Process (RUP)中的有關於需求管理的基本概念，並展示如何使用RequisitePro來實行需求管理。

RequisitePro是很特別的產品，它整合了一個大家都很熟悉的環境：Microsoft Word，以及一個資料庫來提供強有力的十分容易使用的框架，你可以用它來對產品需求進行管理。你要在需求文件中逐條標記你的需求，然後透過資料庫對它們進行管理。以此為基礎，你的團隊可以對同一個專案進行合作與聯絡，並進行不斷的更新。

理解需求管理的第一步是建立一個通用的詞彙表。Rational把需求定義為：一種在建系統必須遵循的條件或功能。需求管理應該是：可以對系統的需求進行引入、組織和文件化的一種系統化的方法與步驟，以及建立和維護開發團隊和客戶之間關於系統需求變更的確認的過程。

要注意的是目前的需求管理沒有最通用的辦法。以下的各步驟是作為一種起點來提供的。在你的開發環境中，由於你不斷經歷著你的軟體的反覆疊代併為此不斷工作，你需要不斷地重新定義你的過程，並且要找出最適合你開發需要的工作程式。由於這是反覆迭代的過程，所以你要在專案中經常經歷以下的12個步驟。

Step 1: 分析問題並收集stakeholder needs

系統分析對總體任務負有責任。所有的團隊成員，包括核心的stakeholder，都要幫助系統分析員從客戶那裡收集stakeholder needs。可以使用以下方法：
☆面談交流
☆問題調查表
☆集體討論與靈感收集
☆討論板
☆原型

這些和客戶互動的結果可以很方便地記錄到RequisitePro文件中去。

Step 2: 為RequisitePro工程建立一個概要說明

一旦你的團隊已經分析了問題，並且收集了足夠的stakeholder needs，下一步是在RequisitePro中對你的專案組織安排進行規劃。你可以使用Requirements Management Plan outline (rup_rmpln.dot)來建立一個需求管理計劃文件。如果你使用的是RequisitePro Project Template 4.5，那麼你還可以選擇需求管理計劃文件的型別。你可以在需求管理計劃文件中記載以下資訊：

你可能在專案中要用到的Requirements artifacts (RequisitePro文件)，例如Stakeholder需求文件、 Vision（確定性不高的）文件、軟體需求文件、測試計劃書，還有需求型別，例如用於stakeholder NEED,特性 FEAT, 軟體需求SR(software requirement),另外還有需求屬性，跟蹤要點等。

Step 3: 在一個可見的文字中的文件特性

系統分析員可以在推薦的軟體產品的高層次的需求（或功能特性）上獲得客戶的認可。這些關鍵性的使用者需要一個在RequisitePro中的可見的文件。系統分析員可以為功能特性Feature建立需求型別 (使用FEAT)以及Stakeholder需求(使用NEED) 作為文件中預設的需求型別。
每一個經過肯定的特性都被標記為FEAT需求，而每一個stakeholder needs將被標記為NEED需求並放在一個不確定文件中。

此後系統分析員可以在RequisitePro中建立功能特性(例如：客戶優先順序、風險、rationale、來源等)。在輸入完以後，系統分析員為需求管理來定義有關的屬性，因為它們涉及到開發週期中其它的工作。

Step 4: 擴充需求的細節

一旦你的特性需求定義好了，你可以建立底層的需求(它門可能被組織成軟體需求) 。在蒐集了整個團隊的輸入以後，系統分析員將需求輸入到RequisitePro，同時還定義屬性用以進行跟蹤。

還有些組織會選擇use case來規劃他們的需求。系統分析員和所有專案成員聚集在一處，共同探討需求問題，對軟體中所有的use case和actor角色進行鑑定。通常這會在白板或紙上進行記錄，系統分析員使用這些資訊並把這些use case和actor記錄到Rational Rose中去。你可以在Rose中擴充use case，並把它們和RequisitePro中的需求進行關聯 (參見Step 10: 和Rational Rose整合)。如果你的工作過程不包括Rose，那麼何不直接把它們作為需求輸入到RequisitePro。

Rational提倡在詳細描述uses case時使用分層次等級的需求。如果你在一個很大的非常複雜的系統中，那麼你可以決定是否要為某一個use case使用分離的需求型別。如果你要為2個不同的需求型別使用不同的安全設定，或者你可能希望在use case和在其中定義的需求之間建立外在的可跟蹤性，或者你需要一套2個不同的需求型別中彼此分離的屬性，那麼這還是有必要的。

一旦需求被加入到RequisitePro，系統分析員（透過團隊的輸入協助下）可以定義一些屬性來對需求進行管理。Use case用例在專案的某個過程中可能接著被加入。你的列表可能還不完善，但這沒有關係，因為它可以在任何時候得到進一步的更新和完善。

Step 5: 跟蹤需求，並擴充套件到功能上去

一旦所有的需求都已經輸入到RequisitePro中了，系統分析員在軟體需求(SR)和特性(FEAT)需求之間建立了可跟蹤性。我們推薦對從SR型別到FEAT型別需求的過程進行跟蹤，由此可以顯示SR對FEAT依賴關係。
如果你選擇使用use case，我們推薦對Use Case需求到FEAT需求的過程進行跟蹤,因為use case依賴於對功能的定義。但在某些時候，功能特性並不和use case相對應，或者，很難透過特殊的use case來進行跟蹤。在這種情況下，系統分析員要對功能需求進行Supplementary Specification (SUPL)跟蹤。

Step 6: 對需求區分優先順序

在需求之間設定了可跟蹤性以後，系統分析員和整個團隊成員要蒐集並決定輸入RequisitePro的需求的有限級別。

在你確定優先順序的時候，要考慮這樣一些因素：

需求是如何體現到產品功能、可用性、可靠性和效能中去的？
在進度約束下，需求實現後的效果是否值得？
現實下需求是否帶來風險？
該需求如果實現了，對你進行產品維護的能力有什麼影響？
你還必須檢查你的進度。是否有時間完成所有高優先順序需求？

在此階段建立比較現實的期望將幫助你的團隊在進度和預算範圍內開展工作。

使用需求屬性可以幫助你確定需求的優先順序別。一旦你輸入了需求資料，你就可以對它們進行查詢、排序並決定它們的位置。

在RequisitePro學習工程中，屬性"Planned Iteration"欄位被設為一個數值，該數值反映了軟體中的反覆，團隊準備用該軟體來實現特定的use case。一旦第一次反覆疊代的範圍被定義完成，而且反覆疊代次數被指定到use case，系統分析員對用例執行一項Attribute Matrix查詢來分離那些在軟體中首次反覆可被定位的用例。你可以將該Attribute Matrix儲存並在以後再次檢視它。

Step 7: 對需求進行分派

對需求指定優先順序以後，系統分析員和團隊將每一個use case或者requirement指派給團隊成員，這可透過使用 "Assigned To"需求屬性來完成。團隊中的一些人將對每一個特性的具體實現負責。
透過參考上面步驟中的Attribute Matrix，分析員為每一個需求或用例填寫"Assigned To"屬性。這將被作為第一次反覆。
使用use case方法的組織將把use cases分派給use case定義者，他將對所有和流程相關的所有需求負責。

如果你的組織使用其它的方法，則分派也可能是其它形式：
SRS系統規格文件，可以包括多組需求；
或者特定格式的需求記錄

Step 8: 細化需求規格

團隊成員 (或者use case 定義者)透過在RequisitePro中"Assigned To"屬性來確認他們被分派了哪些需求。他們可以得到一張顯示所有需求對個人的分派情況的列表。
從該表中你可以查詢一個FEAT需求型別的Traceability Matrix，以及分派給你的需求型別。你可以透過選擇需求型別得到所有特性跟蹤的列表，並透過它生成一個特定的文件。

Use case specifier將進行查詢，這些查詢基於從用例的型別的跟蹤，然後可使用來自requirement workshop的use case描述來建立Use-Case Specification文件。
Rational推薦在詳細描述use case時使用分等級管理。你可以使用“屬性Property”來組織你的use case需求。可以用use case的名字來建立父一級的用例需求，並設定屬性"Name"的值。你可能還要使用屬性"Brief Description"或者"Basic Flow"來定義子一級的用例需求，他們可提供用例的細節。

Step 9: 在RequisitePro中將需求屬性公佈(Populating)

在此之前，系統分析員已透過整個團隊的輸入而定義了需求管理的有關屬性(見前面章節)。被分派了需求的團隊成員可以將這些屬性在RequisitePro中透過賦予特定的用於需求管理的值來使之公佈(Populating) 。

Step 10: 和Rational Rose進行整合

如果你同時擁有Rational Rose和RequisitePro，那麼有2種方法來共享資料。
我們推薦使用Integrated Use Case Management來開始你的開發週期。系統分析員在Rose中定義use case ，然後在RequisitePro中使用Integrated Use Case Management特性來建立use case文件。該方法只需要透過幾項選單操作即可實現Rose和RequisitePro之間的轉化和關聯。對use case的修改將自動在Rose或RequisitePro中得到更新。

但是，如果你在RequisitePro中開發use case，並且想轉換到Rose use case圖，並且帶有關聯屬性，那麼你要使用Rational Synchronizer，此後你可以透過Integrated Use Case Management將這些use case關聯到RequisitePro需求和文件。
Rational Synchronizer可以幫助你在Rose中從RequisitePro中已經存在的需求中建立use case。如果你已經在RequisitePro中建立了大量的use case，那麼這時候將很有幫助。在這種情況下，你可以用Rational Synchronizer中的rules feature來把RequisitePro中的use case需求以批處理方式轉換到Rose中。然後你可以使用Integrated Use Case Management來把這些Rose use case和已經存在的RequisitePro中的use case需求進行關聯。

Step 11: 透過查詢來找出專案的進展狀況

在查詢以前，要在FEAT需求和指派給你的需求型別之間建立一個Traceability Matrix，(Use case specifiers將在FEAT和用例需求之間建立Traceability Matrix)。檢視將以行方式顯示你的FEAT需求，以列方式顯示其它需求。
點選Query column requirements按鈕，並且在Select Attribute對話方塊中選擇"Planned Iteration" 屬性，點選OK。在Query Requirements對話方塊中，選擇Equal to選項，然後鍵入你期望的反覆次數。如果要看哪一項屬性沒有反覆計劃，則可以什麼也不填。點選OK，並關閉每個對話方塊以執行查詢。

查詢結果將給出這些FEAT需求型別的跟蹤情況。如果你選擇了沒有反覆計劃的型別，這樣的列表可以在團隊會議上被檢閱，而被指派到這些需求上的反覆疊代則沒有任何指示。

Step 12: 對變更進行管理

每一個專案都會在發展過程中產生變化，如何跟蹤這些變化，以及如何將這些變化及時地與你的團隊和經理進行及時溝通，這將是一種挑戰。是否成功將取決於你跟蹤需求變更的能力。系統分析員在整個專案生命週期內應進行各種檢視以確定對各種不同的專案的估計是否合理正確。RequisitePro可以確定哪種需求已經變更，該需求是否需要重新定位，從而使專案的描述保持正確。這些關聯將作為一種可覺察到的因素引起注意。
RequisitePro包含了2個強力管理工具來幫助你記載需求的狀態，跟蹤對需求的變更，並加強你在變更發生時對所實行處理的分析能力。

Traceability提供了一種有系統性的方法來管理變更，可以建立較高層次的需求和它們的更詳細精確的後期需求之間的連線。Traceability連線關係使得需求變更的跟蹤變得簡便。
透過Rational ClearCase, Microsoft Visual SourceSafe, 或Merant (Intersolv) PVCS Version Manager 進行的版本控制可以允許你透過專案存檔來跟蹤變化。版本控制可以幫助你在整個開發週期內保持專案檔案的變化。你可以管理多種專案的修訂版。你可以用一種有組織的、協同一致的方式來找回、修改並把修訂版返回到檔案中去。如果你沒有版本管理經理，那麼你可以使用RequisitePro的Archive命令進行專案備份。[@more@]

RequisitePro中需求管理的12個步驟(轉)

相關文章