使用 Rational RequisitePro 進行需求管理的新技術

 

使用 Rational RequisitePro 進行需求管理的新技術
  作者：Kumar Mani 出處：IBM
  本文內容包括： 介紹 業務需求 1. Identify business requirements in RequisitePro 用例 2. Connecting use cases to requirements 跟蹤性 3. Trace coverage and danglers 總結 參考資料 從 Kumar Mani 的這個系列中發現捕獲，管理和跟蹤構架需求的新方法。這種方法是建立在構架理論基礎上的，且適用于所有的 IT 項目。如果您是一位在公司或者綜合項目中面臨復雜請求的IT構架師或者經理，您就可以利用這些方法來管理這個項目，并有助于保證及時交付的時間。這篇文章探究了利用 IBM® Rational® 工具集的實現，但是它能夠被復制，就像使用其它產品一樣簡單。介紹

這篇文章描述了一個構架方法和一個著重強調 需求項目、獲取需求的科學、分析以及項目整個生命周期的管理需求的技術。盡管這篇文章是利用 Rational 工具集來闡述這些技術的，但是并不是特意為這些產品來做指導的。你們的目的是利用基本的構架技術并將它們運用到您的項目中。IT 構架師對 Rational 都比較熟悉，當然也應該能夠很容易地在他們的項目中復制這些技術。

需求非常重要是因為它們是來自開發架構的中心的。 圖 1顯示了 Open Group Architecture Framework Architecture Development Method (TOGAF ADM) 和它的八個階段。

圖1. TOGAF Architecture Development Method

　

需求作為一種需要、機會或者缺乏的表現，貫穿整個開發過程驅動著其他的階段。然而需求管理在項目中由于許多不同的原因通常被忽略或者并沒有被充分地處理。IT 構架師通常會問：

"我正在利用 Rational 產品來建?；蛘唛_發，可是我怎樣才能將它們與需求聯系起來呢？" "我們已經擁有了 XYZ 工具并有可比較的特性，這里所說的有什么更好的特性呢？" IT 專家喜歡清晰地陳述他們的技術需求，以便他們能夠開始編碼。項目經理和消費者們并不清楚像 Rational RequisitePro® 這類工具的好處，也不清楚它們與 Rational Portfolio Manager，諸如此類項目管理工具的適應性。（有些項目使用了整個 Rational 工具集，除了 RequisitePro?。┰谶@篇文章中還回答了一些有效的問題。

　

像 Rational 這樣的工具，如果我們適當地運用，就具有重要的意義。有些項目經理把工具（比如 RequisitePro）作為需求的智囊庫，也就是說，這些需求被輸入了這個工具，然后報告就從這個工具中發布。于是項目經理就對他們為什么看不見切實的利益而感到奇怪。

這篇文章的目的就是填補產品文檔與方法文檔之間的空白。這個 Rational 工具文檔很好地描述了它的特性和能力，方法文檔中含有大量的方法和最佳實踐。然而，IT 構架師仍然面對著如何將這個工具的利益最大化的問題。在這篇文章中，您將學到業務需求、用例，以及基本的跟蹤能力，并附有系統級別的需求、組件，以及測試過程中的跟蹤性。

Empire Systems Corporation

為了論證如何最佳使用構架需求技術，這個系列的文章將會涉及到來自 Empire Systems Corporation (ESC) 的特殊的，假定的例子，個人計算機、膝上電腦、電腦組件以及相關硬件，比如 Web 照相機和麥克風的虛構的制造商和供應商。ESC 已經有一個 Web 應用，并且已經啟用了許多它的應用軟件?，F在公司的領導者想通過流線的過程把公司轉型到下一個級別，使業務能力自動化，采用一個企業構架，最終，提高稅收和利益率。

業務需求

成功的 IT 項目都是以良好的業務需求開始的。技術文檔含有需求工程的方法、技術和最佳實踐。然而，對于需求的討論，尤其是業務需求通常非常模糊、散漫，并且一般而言都比較難于理解。由于缺乏清晰的需求表達會影響到業務需求的傳遞，隨后會影響映射到技術需求。讓我們重新回顧一下一些基本的需求工程的原則。

重視業務 業務需求應該重視實際的業務需求，并要與其它的業務概念有明顯特性（比如遠景、任務、目標或者結果）。通常的一個錯誤將業務的目標（例如，“達到縮減20％成本的目標”）陳述為一個業務的需求。 盡可能簡潔 需求必須是具體的、可測量的、 可控的、 可現實的以及限時的。這比看起來更有挑戰性?？墒?，通過尋問以下的問題就能夠很容易地完成： 為什么要用這種方式來處理？ 您將獲得什么樣的結果，或者如果這個問題被解決您將能夠做什么？ 明確地說，什么過程將會受到這個障礙的影響？ 通過補償這個過程將會得到什么利益（盡可能是可計算的）？ 做什么來改變事情？

這通常很難回答，涉眾們往往回到問題的陳述上來。需求工程可以以一些如果……怎么樣 的建議來獲取一些可能性。盡管如此，還是要在涉眾們回到正軌時立即撤回。

關于時間框架，對于背景和業務環境什么時候可以完成？

這并不是特意為項目交付而設的點，而是推理業務背景的起點。例如，一個上網卡的商人想要以節日為目標開張他的新 Web 站點。

確定并闡明范圍 什么是進什么是出？ 什么被執行了或者被交付了，什么時間？ 確定“主語”和“謂語” 這是經常最容易被忽略的，也是范圍頻繁變化的主要原因。如果這不僅僅是一個動詞，可以將它規定為獨特的需求。這提高了明確性并促進涉眾們之間更好的理解。 關注需求本身，而不是如何實現 業務需求通常陳述完成了什么 ，并且應該避免任何關于怎樣完成的提示。例如，一個企業想要主觀的、綜合的觀點融合到他們的業務數據中。重點應該是他們想要做什么，而不是他們需要得到什么（例如，數據庫）。

需求樣例

ESC 有幾個基于 Web 的應用軟件。因為每個應用軟件都是獨立開發的，消費者面臨著像需要分別在每個應用軟件上注冊以及對于每個業務功能需要不同的窗口的問題，引起了他們的抱怨。為了解決這些抱怨，ESC 業務小組制定了下面的需求：

BR264： 消費者應該能夠通過一個兼容的界面訪問所有的 ESC 應用軟件，并且只需要注冊一次。ESCWeb（主要的商業 Web 網站）對于所有的消費者應該有相同的外觀和感覺。這將減少用戶差錯并提高用戶的體驗。ESCWeb 最終也將支持移動的和遠程的客戶。

很顯然，這個需求能夠被改善。通過運用這些原則，我們能夠對它進行如下的重述。

BR264：在 ESC5.0 版本中，消費者想要注冊一次就可以應用所有的 ES C應用軟件，包括 ESCWeb、 ESCOrderStatus、 ESCVendor 以及 ESCSupport。

BR265：在 ESC5.0 版本中，所有的 ESC 應用軟件將執行 ESC Web Standard 273-1 和 273-2，這將再減少10％的用戶差錯。 技術1. 確定 RequisitePro 中的業務需求

在這個記錄將需求記錄在 RequisitePro 的技術中，關鍵是保持獲取和澄清這個需求的原則。這個技術包括三個步驟：

確定一個業務需求的 Requirement Type 。所有的業務需求都將分配這個類型。BUS 是一個習慣性的前綴。 當規定一個 Requirement Type 時，利用 Requirement Must Contain 選項來指定一個分隔符(比如 "|")。這個主語和謂語可被安置在分隔符的任何一邊。這并不是強制性的要求，RequisitePro 手冊有更多的細節。方法是在識別主謂成為需求的過程中使用逐漸導出的原則。 在最高層次為業務需求創建一個包。您可以立即看到它是如何幫助跟蹤的。

技術1現在已經完成。您已經獲取了一個清晰而且簡潔的業務需求，并準備好轉向下一個階段。 圖 2 顯示了這個技術。

圖 2. 利用技術1獲取業務需求
用例

技術2 (將用例與需求連接起來)覆蓋了這個項目的下一個階段。只要業務需要被確定，這個業務構架師或者分析師就會開發用例來對它們進行說明。尤其對于大的或者復雜的項目，業務分析師經常會遇到這樣兩個問題：

需求存在于文檔中(除非您使用技術1)，用例位于模型中，比如 Rational Rose® Enterprise (Rose)。 由于需求(和用例)的數量逐漸增長，拆分也變得越來越難于管理。

　

業務需求與用例是如何連接起來的？用例捕獲用戶的視角，他們說明了用戶的行為和系統的回應。但是業務需求遠遠超越了作為一個服務于用例的數據源。當規定了屬性或者限制時，它們就變成了用例的屬性（或者備用信息流）。我們應該能夠記錄業務需求和一個用例之間正常的連接，并用它做一些有意義的事情，比如跟蹤或者分析。

建模用例時需要大量的資料。在 資源部分中的文章都是很好的起點。查看這些案例屬于這篇文章以外的范圍，但是我們將介紹一個應用于這個技術實現的命名習慣。

用例的命名原則

為什么用例的名字非常重要？回憶一下我們介紹過定義需求時主謂一致的結構。這個概念在這里得到延伸。主語由這個用例模型中的施動者來代表。我們的用例命名原則規定，用例應該以現在時態或者動詞的動名詞形式(ing)。在有些情況下，它有助于包括被動詞修飾的賓語的名稱。

技術 2. 連接用例與需求

現在是定義用例并把它們與需求連接起來的時候了。這個技術的目的是維持定義用例的明確性，使它們與需求保持連接（可跟蹤的），可以采用下面的步驟：

如果您的 RequisitePro 項目不包含用例的包或者用例的需求類型，那么就創建一個。 利用 Associate Model to RequisitePro project 對話框將 Rose 模型和 RequisitePro 項目聯系起來。Default Requirement Type 被設置為 Use Case。 現在您可以在 Rose 中創建您的模型。對于每個用例，首先根據命名原則創建一個 Use Case 類型的 RequisitePro 需求，如 圖 3所示。在 Requirement Text 中輸入這個名字。

圖3. 用例命名原則


　 在 Rose 中創建這個用例。右鍵點擊這個用例獲取 Associate Requirement to Use Case 的對話框。 選擇 Use Case in RequisitePro 然后點擊 OK。這將產生 Resolve Use Case Name 對話框，這個對話框非常重要因為它利用動詞連接著用例和需求，如圖 4所示。

圖4. 連接用例和需求


　 您現在可以看到 Requirement Properties 的對話框。選擇 Traceability 鍵，用例就回到了 BUS 需求。

這個技術已經完成。您可以通過對 RequisitePro 中的用例命名 來開始，它能夠讓您完全在 Rose 中進行定義、細化，并跟蹤這個用例。這突出了 Rational 中的一個重大的優點：需求、建模和設計的整合。

跟蹤性

為什么可跟蹤性如此重要？ 可跟蹤性就是對需求的生命周期從它的開始到各種轉化，前前后后的跟隨。隨著企業的發展，也會對支持他們的系統（和他們的需求）進行跟蹤?？筛櫺允锹摵闲枨蟮倪^去、現在和將來關鍵的連接?？筛櫺钥梢蕴峁┮恍祿?，項目的各種分析，比如成本，覆蓋范圍以及影響力都可以根據這些數據來執行。

在實際中跟蹤是很難做到的。主要的問題是可跟蹤性被看作需求工程的一個附屬的方面。這些需求被規定在文檔和構建在 Rose 中的模型中?？筛櫺酝ǔＪ墙９ぷ魍瓿芍?，手工記錄在電子表格中的。維護這些電子表格非常麻煩而且容易出錯。但是對項目影響更大的是，電子表格本身充當了跟蹤報告從而逃避了詳細審查。

我們的下一個技術解決了這個問題。這個技術的第 1 部分是，當需求被創建時歸納出跟蹤需求的原則。 （我們利用用例在前面的技術中已經證明的這一點。）這個思想是在需求的整個生命周期和測試中都要維持原則。第 2 部分是生成覆蓋和附屬 報告。這個附屬報告是影響分析的第一個層次。中心思想是，這些自動生成的報告在檢查中需要詳細審查。

覆蓋，正如其名字所示，確保同一個層次的每個需求在下一個層次都被覆蓋（或者更進一步的規定）到。例如，每個用例都必須被測試用例覆蓋到。附屬需求就是那些在無意中悄悄混進這一層次的需求，它們在之前一個層次中并不存在。在生命周期的早期把它們都捕獲是十分重要的，因為在這個階段的警告比系統交付后的錯誤報告更容易處理。使這些功能自動化操作同樣十分重要。

技術3. 跟蹤覆蓋和附屬需求

這個技巧顯示了如何構建 Coverage and Dangler 視圖來業務需求和用例之間的差距。這些視圖符合標準的 RequisitePro 視圖框架。采用下面的步驟。

從業務需求包的 Coverage中，選擇一個新的 View，這里的 View Type 是一個跟蹤性矩陣，Row Requirement Type 是 BUS，Column Requirement Type 是 UC。注意如何從技術1重新利用 BUS 包。 在 View Properties 框中，在行需求中創建一個名為 Business Requirements Coverage Query ?，F在為這個 Query 增加一個 Traced-from 屬性。 這將產生 Query Requirements 對話框。如 圖 5所示，選擇 Not Traced 并選中 Direct links only。

圖5. 跟蹤覆蓋


　 刷新這個 View。您將可以看到這個沒有相關用例的業務需求。您可以省略步驟2和3創建一個完整報告 View。 Dangler 視圖是通過在這個技術中反向 Query 標準來創建的。我們以列需求類型（用例）開始，并選擇 Traced-to BUS 需求。這個視圖顯示了所有的附屬用例。

這個技術已經完成。您可以跟蹤用例到最初的業務需求，并可以排除虛假的用例和不完善的業務需求。您的項目現在可以安全地進入解決方案領域了。

總結

在這篇文章中，您研究了需求工程的基本原理并介紹了三個管理構架需求的新技術?；仡櫫诵枨蟮幕驹瓌t，描述了三個管理業務需求，用例和跟蹤性的技術。

然而，我們仍然處于問題領域中。在本系列文章的第 2 部分，我我們將進入解決方案領域和解決方案開發的各個階段（從架構的角度），并且探索管理解決方案交付的新技術。

參考資料 學習 您可以參閱本文在 developerWorks 全球站點上的 英文原文 。 "Requirements: An introduction" (developerWorks,2004年4月)：精確的需求是軟件項目成功法則中必不可少的部分。我們在這篇文章找到了其中的原因，并學習到一種進行有效需求文檔化的三重方法。 "Agile requirements methods"：這篇 Rational Edge e-zine 文章(PDF)討論了一個敏捷需求方法。 "Transitioning from requirements to design": 這篇 Rational Edge e-zine 文章 (PDF) 闡明了業務需求和用例的區別。 "Use case management with Rational Rose and Rational RequisitePro"：這篇 Rational Edge e-zine 文章討論了用例與需求的集成。 "Adopting use cases, Part 1" (developerWorks,2003年5月)：審查了用例和構架的不同類型。 訪問developerWorks Architecture獲得您所需要的資源，提高您在構架領域中的技術。 找到更多關于 Rational Portfolio Manager 的資源。 找到更多關于 Rational Rose Enterprise 的資源。 Rational Rose Enterprise：試用版下載。 瀏覽技術書店找到關于這些或者其它技術話題的書籍。 獲得產品和技術 下載一個 Rational RequisitePro 的試用版本。 下載 IBM 產品評估試用版，并使用來自 DB2®、Lotus®、Rational、Tivoli® 以及 WebSphere ®的應用程序開發工具和中間件產品。 討論 參與論壇討論。

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