軟件測試過程中Rational RequisitePro 進行需求管理

 從 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%成本的目標”)陳述為一個業務的需求。

盡可能簡潔

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