引言
本文描述了 IBM Rational® RequisitePro® 2003 和 IBM Rational® XDE™ Developer v2003 之間的集成如何幫助軟件團隊保持設計活動與需求的一致性。目的在于能夠交付實際滿足客戶需求的軟件。

Rational RequisitePro 是 IBM Rational 市場領先的需求管理工具。借助于 Rational RequisitePro，您可以在 Microsoft Word 文檔中管理需求，這些需求已鏈接到需求數據庫中，利用該數據庫可以高效組織和管理其他需求信息。

Rational XDE Developer 是一個完全可視的設計和開發環境，它在開發人員的集成開發環境（IDE）中加入了 UML（統一建模語言）建模，從而增進了交流，并提高了軟件設計的文檔化。本文描述的集成適用于以下 Rational XDE Developer 家族成員：

Rational XDE. Developer - Java. Platform Edition，可以通過內建的 Eclipse IDE 單獨實現集成，或者將其安裝到 IBM WebSphereTM Studio Application Developer 和 Integration Edition IDE 中。 Rational XDE. Developer - .NET Platform Edition，擴展了 Microsoft Visual StudioTM .NET IDE。 Rational XDE. Modeler Edition，它提供了 Rational XDE Developer 功能的子集，從而使架構人員和設計人員能夠為架構、業務需要、可重用資產和管理級通訊創建通過平臺實現的 UML 模型。

本文首先回顧了保持需求與設計一致的挑戰，然后深入探討了 Rational XDE Developer 和 Rational RequisitePro 之間的集成如何提供了針對這些挑戰的解決方案。

本文第二部分詳細描述了如何利用該項集成來創造效益。

背景：從需求出發進行設計的挑戰
需求為軟件開發人員定義了應該創建何種系統。通過需求來記錄客戶需要，這些需要是為了使客戶能夠創造價值，軟件必須要解決的。同樣，應該通過需求來驅動所需的全部軟件活動，從而實現最終目標：交付能夠為客戶創造價值的軟件。

實際上，在記錄了需求之后，軟件團隊需要一直遵照這些需求，并且確保按照這些需求來進行設計和編寫代碼。

以往的需求工具和設計工具都是相對獨立的，這兩種工具之間存在一道屏障，將業務分析人員和開發人員分割開來。這樣就產生了不良的軟件開發后果，最終導致所開發的應用程序沒有實現需求所指定的功能。這種普遍現象的根源在于需求與開發人員之間貧乏的交流，特別是需求變更與開發人員之間的交流不足。將需求規格說明書的初次調整傳遞給開發人員，這并不難實現，但是當需求頻繁地發生變更時，如果不將不斷變更的需求傳遞給開發人員，他們將還按原來的需求來開發系統，從而使所交付的應用程序無法滿足不斷變化的用戶需要。特別是創建大型系統時，開發團隊極易疏忽某些需求。在設計階段評估需求的覆蓋程度，對于確保應用程序能夠滿足客戶在項目開始時所設定的期望值非常重要。

現在還沒有一個很好的方法，來回答以下問題：

需求處于何種最新的狀態？ 全部經商定的需求在設計中都考慮到了嗎？ 設計模型的哪個部分受到了最新的需求變更的影響？ 如何才能知道設計是可行的？能否滿足用戶需要？

為回答第一個問題，我們將 IBM Rational RequisitePro 和 IBM Rational XDE Developer 進行了集成，通過將存儲在 Rational XDE Developer 模型中的用例圖，和存儲在 Rational RequisitePro 中的相關用例需求信息（事件流、優先級、難度、風險等）鏈接起來，從而解決了向開發人員高效傳遞需求這項挑戰。

為回答其他兩個關鍵問題，我們將 Rational RequisitePro 和 Rational XDE Developer 進行了集成，通過在需求和實現該項需求的相關設計要素之間建立直接關系，從而解決了保持軟件設計與需求一致這項挑戰。

利用 IBM Rational 工具，從需求出發進行設計
為了說明 IBM Rational RequisitePro 和 IBM Rational XDE Developer 集成所帶來的利益，本小節講一下，將這兩種工具的集成用于軟件團隊的日常工作中，這里軟件團隊遵從 IBM Rational Unified Process? 中規定的軟件開發最佳實踐。用斜體分別列出了 Rational RequisitePro 和 Rational XDE Developer，以及它們二者的集成為該軟件活動所帶來的特定價值。

確保軟件能夠為客戶創造價值
項目開始時，用一個可視的文檔（通常由分析人員來編寫，但要在團隊和客戶之間傳閱，并得到他們的批準）來說明客戶問題和這些問題的建議解決方案。在可視文檔中，用高級產品功能來說明所建議的解決方案。

用 Rational RequisitePro 來管理可視文檔和高級產品功能，同時也管理從這些產品功能和其他涉眾獲取的詳細需求。

在 Rational RequisitePro 中，通過保持需求之間的關系（稱作"可跟蹤性鏈接"），來提供覆蓋報告（用來確保全部的高級需求都通過更詳細的需求得到實現）和影響分析報告（用來度量需求變更對其他需求產生的影響）。

當可視文檔達成一致意見后，為了能夠讓軟件團隊將精力集中于為客戶創造價值上，使用一個用例圖，以用戶的視角，來描述應用程序能夠帶來的價值。通過用例圖來描述某一系統與用戶和其他系統發生交互時，將產生何種系統行為。在過去 10 年中，用例已經得到驗證，它是一個高效的方法，從用戶的視角來記錄系統功能，該用戶視角既為軟件團隊也為他們的客戶提供了一個關于待建系統期望行為的公共理解。通過最大限度地降低誤解風險，用例提高了軟件團隊必須交付成功系統的機會。

在 Rational XDE Developer 中創建用例圖，同時創建參與者和用例簡短描述。

圖1 典型的用例圖解


為用例劃分優先級
當團隊和客戶對用例中圖解中的值達成一致意見后，要對用例劃分優先級，從而使開發團隊可以首先集中精力于最重要的用例上。最重要的用例指的是，能夠自動聚焦于業務過程的核心和自動驅動軟件架構的那些用例。

為了使優先級劃分過程具有客觀性，要為每個用例設置屬性。屬性特別有益于迭代軟件開發， 它提供了一個簡單的方法來設置項目中每個迭代過程的管理范圍。用例屬性通常包括：實現難度、架構的有效性、風險和特定的客戶價值。

利用 IBM Rational XDE Developer，使用 Rational XDE Developer 和 Rational RequisitePro 的集成，可以為用例分配需求屬性。這些需求屬性作為用例屬性。

IBM Rational RequisitePro 提供了默認的用例需求屬性。

可以使用 Rational RequisitePro 來創建用例報告，根據屬性對用例進行排序和過濾。

對優先用例進行詳細分析
為了實現具有高優先級的用例，開發人員要創建順序圖，來開始構建軟件架構，并確定設計類別。為了創建順序圖，開發人員需要訪問用例圖中用例橢圓之外的更多詳細信息。因此，每個具有高優先級的用例被細化為一個步驟集，該步驟集描述了一個對話，對話的雙方分別為初始化用例的參與者（圖 1 中的客戶），和用于實現用例（例如，圖 1 中的 Sort Catalog）中描述功能的系統，該步驟集通常稱作用例的事件流。通常用例有一個單個的事件流（描述用戶與系統之間所期望的交互）和幾個可選（有時稱作異常）事件流（記錄系統處理應該如何處理異常事件，如打印機缺紙）。注意在這一點上，無需詳述每個單個用例；只需詳述被選為高優先級的那些用例即可。

因為用例中的事件流通常是用 Microsoft? Word 來記錄的，并且 IBM Rational RequisitePro 允許用戶在 Microsoft Word 中編輯需求，因此 Rational RequisitePro 是用來管理用例的一個理想的工具。在使用 Rational XDE Developer 時，為用例附加一個簡單的 Word 文檔，與之相比，使用 Rational RequisitePro 來詳細描述用例，是一項關鍵性的優勢。

可以清楚地識別用例事件流文本中所包含的功能性需求。
因為使用 Rational RequisitePro，需求文本在顯示方式上，不同于文檔中其他描述性信息（見圖 9），因此很容易識別用例事件流中所表述的功能性需求。您可以選擇在用例流級別上標記功能性需求，或在單個的步驟流級別上標記功能性需求。當某一測試場景典型地用于測試基本步驟流與備用流結合時，在流級別上標記需求，有利于從用例出發，來創建測試用例。 自動跟蹤對用例文檔的修改。
每項需求變更的審計跟蹤（誰做出的變更、內容、時間、原因）存儲在 Rational RequisitePro 數據庫中。這些修訂幫助您實現對用例變更的控制。 跟蹤功能性需求
用例事件流中包含的功能性需求標記為軟件需求，并為它們分配了屬性（優先級、難度、風險等），而且與高級業務需求或產品功能鏈接起來。 可以將用例文檔中的需求與相關的其他需求鏈接起來
通過跟蹤用例到業務需求，或跟蹤到產品功能，更易于度量與需求相關的變更所帶來的影響，并且驗證覆蓋度。

根據詳細的用例，生成設計類別
根據用例規格說明書的事件流，設計人員可以構建順序圖，將事件流作為對象之間的一連串消息來表述。

在 IBM Rational XDE Developer 中創建順序圖，并且與 Rational XDE Developer 對用例圖的標注鏈接起來。請注意：我們經常被問起工具是否可以將用例事件流自動轉換成順序圖。最好的回答是，不良的設計可能來源該方法，而好的設計卻進行優化，來表達所有的關鍵性事件流。

根據順序圖中確認的對象，可以進行設計分類。

在 Rational XDE Developer 中創建類圖和其他 UML 圖，并與它們的源順序圖鏈接起來.用來表示用例設計的 UML 圖的集合通常被稱作"用例實現"。該命名說明了這樣一個事實，通過設計實現了用例中的需求。

使設計與需求變更保持一致
當設計活動開始時，需求促使原始用例（和隨后的順序圖及類）變更的創建。不斷變更的需求是（軟件）生命周期中的事實，也是（軟件）生命周期的信號，同時也是健全的項目的信號。在項目開始時，不可能 100% 了解軟件需求和用戶需要，因此變更反映了從您必須創建的（如果只是等待得到全部需求，那么您永遠也不會有一個開始，最終將導致分析過程癱瘓）最初的需求集向最終的需求匯聚的過程。為了確保所交付的軟件確實能夠滿足用戶需要，需要使設計與不斷變更的需求保持同步。

IBM Rational RequisitePro 可跟蹤性矩陣將需求之間鏈接起來。

利用 Rational RequisitePro 和 Rational XDE Developer 的集成，還可以將設計要素與它們所實現的需求鏈接起來。The IBM Rational XDE Developer 設計要素反映在 Rational RequisitePro 可跟蹤性矩陣中。

通過過濾需求和設計之間的可跟蹤性矩陣，可以訪問所需的特定信息。

利用 IBM Rational XDE Developer 和 Rational RequisitePro 的集成
本小節詳細闡述了采用 Rational XDE Developer 和 Rational RequisitePro 進行集成的步驟。這里提供了Rational XDE Developer - Java? Platform Edition 的屏幕截圖，但是正如介紹中所提到的，該集成同樣適用于 Rational XDE Developer 和 .NET Edition and Rational XDE Modeler Edition 的集成。

在 Rational XDE Developer 中，可以從兩個地方調用集成：Tools > Rational RequisitePro 菜單和對上下文敏感的右鍵菜單。當選定了一個 Rational XDE Developer 要素后，或者從圖開始，或者從 Model Explorer 開始。上下文敏感菜單選項根據所選 Rational XDE Developer 要素的不同（軟件包、用例或其他 UML 語言）而變化。

用例的菜單選項：

打開/新建用例文檔，該選項用來創建一個新的用例文檔或者將用例與現存的 IBM Rational RequisitePro 用例文檔關聯起來。 查看需求屬性，該選項用來查看和編輯用例的屬性和可跟蹤性（依賴性）鏈接。

軟件包的菜單選項：

關聯/取消關聯 RequisitePro，該選項用來指定一個 Rational RequisitePro 項目，該項目包中所有的要素都要參與集成。

設置集成
默認情況下，IBM Rational XDE Developer 模型未被激活以用于該集成，通過選用模型的 AppliedProfiles 屬性中的"RequisitePro" profile，可以在 Rational XDE Developer 模型中激活該集成。

圖2 在 Rational XDE Developer 中激活集成


選用了 "RequisitePro" profile 后，每次打開 IBM Rational XDE Developer 模型時，可以從 Rational XDE Developer 主菜單（圖3）中使用需求管理功能，也可以從 Model Explorer 或用例圖的上下文右鍵菜單來使用。

圖3 Rational XDE Developer 主菜單的需求選項


在默認情況下，整個 Rational XDE Developer 模型與 IBM Rational RequisitePro 關聯起來，但是您可以為單個的軟件包覆蓋這種模型級的關聯（圖4）。這樣就允許用例（或設計要素）存儲于不同的軟件包中，從而可以使用不同的 Rational RequisitePro 項目來存儲需求信息。該軟件包級的關聯將其自身提供給大型軟件項目，這些項目可能使用多個 Rational RequisitePro 項目（通常每個子系統使用一個），或使用不同的用例文檔模板（例如，系統級用例和低級別的用例）。

圖4 使用 Rational RequisitePro 項目來關聯軟件包


下一步是指定 IBM Rational RequisitePro 項目，該項目將與 IBM Rational XDE Developer 模型進行集成。

從 Rational XDE Developer Tools 菜單中選擇 Rational RequisitePro > Associate Model to Project，并且定位 Rational RequisitePro 項目，將項目與該模型關聯起來（圖5）。一個 Rational RequisitePro 項目包括文檔類型和需求類型。文檔類型用于選定 Microsoft Word 文檔模板，該文檔模板以 Word 文檔記錄不同的需求，需求類型用于按具有共同屬性（優先級、風險、難度、狀態等）的類別，將需求進行分組。

圖5 Rational RequisitePro 項目和用例信息選擇


當使用 Rational XDE Developer 進行新用例詳細設計時，選擇一個文檔類型來作為用例文檔模板，并且選擇一個用例需求類型。Rational RequisitePro 提供了我們所推薦的默認項目結構，您可以從它開始工作。隨著對工具的逐漸熟悉，您可以創建自己的文檔類型和需求類型，以及項目模板，以便再次工作時使用。

當在 Rational XDE Developer 模型中指定了 Rational RequisitePro 項目后，下一步您可以從 Rational XDE Developer 用例圖開始，將用例文檔和 Rational RequisitePro 關聯起來，并且為 Rational XDE Developer 設計要素添加跟蹤功能。

為用例添加需求屬性
在本文第一部分中討論了為用例劃分優先級過程，為該過程作準備，我們在 IBM Rational XDE Developer 中為用例設置需求屬性，單擊用例右鍵菜單，選擇 RequisitePro?View Requirement Properties。在對話框中單擊 Attributes 標簽，然后設置用例屬性值。注意您可以在與 Rational XDE Developer 模型關聯后的 IBM Rational RequisitePro 項目中，改變"即開即用"的用例屬性和它們的默認值。還可以從該對話框中，單擊 Traceability 標簽，來建立用例和其他需求之間的可跟蹤性。

圖6 在 Rational XDE Developer 中查看并編輯用例需求屬性


為用例劃分優先級
當在 Rational XDE Developer 中，為用例附加了用例文檔或分配了需求屬性后，用例即成為 Rational RequisitePro 中需求集的一部分。同樣，可以使用 Rational RequisitePro 需求管理功能將用例排序（按優先級、按迭代等），來查詢特定用例（例如只計劃用于下一個迭代的用例，），并且生成用例矩陣。

IBM Rational RequisitePro 中一個屬性矩陣視圖（見圖7）提供了一個全部用例（或所選的用例子集）和其對應屬性的視圖。該視圖幫助您組織用例信息，來回答本文開始時的第一個問題：我如何組織用例？可以運行查詢來確定將哪個用例分配給哪位設計人員，它們的實現難度有多大，或者應當在哪個版本中實現它們。這同時也回答了本文開始部分的另外一個問題：如何才能知道在哪個版本中實施某個特定的用例？

圖7 Rational RequisitePro 中用例屬性矩陣視圖


創建用例文檔
為了在 IBM Rational XDE Developer 中詳細設計用例（為用例附加一個用例文檔），可以在 Rational XDE Developer 中（從 Rational XDE Developer Model Explorer 或用例圖）單擊用例右鍵菜單，選擇 RequisitePro>New Use Case Document。

在 Rational RequisitePro 控制下運行 Microsoft Word，可以顯示基于模板的用例文檔，并準備對其進行編輯。如果只想用 Microsoft Word 將用例規格說明記錄下來，過后再將其輸入到 Rational RequisitePro 中，那么您可以使用 RequisitePro ? Associate to RequisitePro 菜單選項，將現有的 Rational RequisitePro 文檔和 Rational XDE Developer 中的用例關聯起來。

在這點上，您應該擁有在 Rational RequisitePro 中完成的用例文檔。

圖8 從 Rational XDE Developer 創建用例規格說明


在用例文檔中管理需求
在 IBM Rational RequisitePro 中，當完成對不同的用例事件流記錄后，您可以識別功能性需求并將它們標記為需求（圖9）。這樣做使您能夠為這些功能性需求附加需求屬性，并且對其進行跟蹤，直到它們成為高級需求。

圖9 Rational RequisitePro 中的功能性需求


保持用例與業務需要一致
當為需要實現的用例劃分了優先級后，應該確保這些用例與它們要實現的不斷演進的用戶需要一致。圖 10 中的可跟蹤性視圖顯示了在用例和變更需要之間建立的關系。使用可跟蹤性矩陣，您可以查詢業務需求，而不僅僅是對用例進行跟蹤，這使您可以回答這個問題：這個用例是用于哪個特定業務需要的？另外，當業務需要發生變更時，您可以迅速獲悉哪些用例可能受到該變更的影響，從而確保用例能夠自始至終反映不斷演進的業務需要。這里的一項可疑鏈接（圖 10 中的紅色箭頭）表明由于業務需要 BUS1.4 的變更，可能需要對用例 UC1.2 進行修訂。對可疑鏈接進行查詢，可以回答這個問題：用例與它們所要解決的不斷演進的業務需要一直保持密切聯系嗎？

圖10 用例和業務需要之間的可跟蹤性關系


確保設計能夠實現全部需要的功能
同樣，為了確保設計能夠真正實現需求，應該將 IBM Rational RequisitePro 中的需求與 IBM Rational XDE Developer 實現這些需求的設計要素鏈接起來，

在 Rational XDE Developer 中創建了設計要素（類、圖等）后，可以單擊設計要素的右鍵菜單，選擇 RequisitePro ?Add Traceability（圖11）， 將這些要素與驅動生成它們的需求鏈接起來。這樣就在 Rational RequisitePro 中為該設計要素添加了表示法。

圖11 完成 Rational RequisitePro 中設計要素的變更


當 IBM Rational XDE Developer 設計要素名稱或簡短描述發生變更時，可以調用同一個菜單中的 RequisitePro? Update Traceability 選項來完成變更。如果要對 Rational XDE Developer 作出多項變更，可以通過選擇 Tools ? Rational RequisitePro ? Update All Traceability 來快速完成所有變更（圖12）。

圖12 完成 Rational RequisitePro 多項設計變更


為 Rational XDE Developer 設計要素添加可跟蹤性后，可以在 IBM Rational RequisitePro 中創建需求到設計的可跟蹤性矩陣（圖13）。需求（如用例）和設計之間的可跟蹤性矩陣，是驗證設計活動是否覆蓋全部商定的需求的一種方法。

圖 13 用例和設計之間的可跟蹤性關系


在該鏈接建立之后，可以運行 IBM Rational RequisitePro 的報告功能，來評估設計對需求的覆蓋度，并且用一個定量的答案來回答："全部經商定的需求，在設計中都考慮到了嗎？"從而說明設計模型將要實現的已簽發的每項需求。

需求與設計之間的鏈接，對于檢測需求變更對設計要素產生的影響也至關重要。在鏈接到設計要素的某項需求發生變更時，在圖 13 中，可疑鏈接（紅色箭頭）將取代藍色箭頭。對需求和設計之間的可疑鏈接進行查詢，可以回答這樣的關鍵問題：設計模型中的哪部分將受到最新需求變更的影響？

圖 14 用例和設計之間的可疑關系


如需查看集成工作方面的更多信息，請參見 Rational XDE Developer 在線幫助。

結束語
總的來說，IBM Rational RequisitePro 和 IBM Rational XDE Developer 之間的集成，使開發人員能夠清楚地交流需求信息，并且使設計與不斷變更的需求保持一致。

這是達到最終目的的關鍵：交付能夠實際解決客戶需要的應用程序。

如果沒有這項集成，用例將以 Microsoft Word 文檔形式記錄，不能夠跟蹤功能性需求，包括用例規格說明。這項缺陷將導致設計與需求無法保持一致。

如果沒有這項集成，軟件設計將置于偏離需求軌道的風險中。當某項需求發生變更時，迅速評估哪部分設計將受到該項變更的影響，最大限度地提高了設計滿足客戶需要的解決方案的成功概率，從而解決需求所表述的客戶需要。

通過訪問 http://www.rational.com/events/webinars/index.jsp 您可以查看如何使用該項集成的更多信息。

參考資料
書籍

- Kurt Bittner & Ian Spence, Use Case Modeling

- Alistair Cockburn, Writing Effective Use Cases