使用需求管理加速交付更高質量的應用程序

2004 年 10 月

今天的軟件行業有許多方面值得驕傲。全球軟件和服務市場產值超過 2210 億美元，已經成為當今時代最重要的經濟支柱。從技術上講，該行業引領著非凡的新技術開發，這些技術開發每天都在提高企業生產力。舉幾個例子，如圖形用戶界面、關系數據庫、面向對象的編程、第四代語言，以及 Internet。

軟件開發所面臨的問題？
今天的軟件行業有許多方面值得驕傲。全球軟件和服務市場產值超過 2210 億美元，已經成為當今時代最重要的經濟支柱。從技術上講，該行業引領著非凡的新技術開發，這些技術開發每天都在提高企業生產力。舉幾個例子，如圖形用戶界面、關系數據庫、面向對象的編程、第四代語言，以及 Internet。

但是在前進的同時存在一個令人擔憂的潛在問題。軟件開發仍然是藝術多于科學。盡管軟件在藝術方面需要一定的美學和情感因素，但事實是軟件的藝術方面從來就不是一個可依賴的過程。如同藝術本身一樣，軟件取決于創造力爆發和個人天賦，而不是取決于團隊工作和工程規則。另外，現在軟件解決的僅僅是 10 年前我們未想到的問題領域。

在 Scientific Americani 近期的一篇文章中，廣泛地探討了軟件開發中奇缺的科學進步，這也是作者的觀點。盡管許多業內人士認為本文不公正，但 The Standish Groupii 近期的一項研究肯定了幾項關鍵統計數據，這些我們不得不承認：

超過 30% 的軟件項目在完成前就被取消。
剩余的項目中有 70% 沒有交付預期的功能。
項目平均超預算 189%，并且超過日程計劃 222%。

這些問題觸及了軟件行業內部的軟筋，因為我們都有過如此的經歷。在子例程發明 40 年后，為什么我們還受到這些失敗的困擾呢？大多數的開發者和研究者都同意以下的原因：

1. 極差的需求管理。我們只顧向前邁進，缺乏用戶參與并且沒有清楚地了解有待解決的問題。

2. 極差的變更管理。需求和軟件開發的變更是無法避免的，然而我們很少跟蹤這些變更或了解它們產生的影響。

3. 極差的質量控制。對于系統質量缺乏準確的度量，對影響質量的過程所知甚少，并且在特定的開發策略產生影響后，無相應的反饋信息來修改過程。

4. 對日程安排和成本極少進行控制。從來就沒有過精確的規劃。

這些問題的根源在于需求管理。畢竟，如果我們對于系統的預期行為沒有徹底的了解，那么：1）我們如何能夠確定那種行為？2）我們如何設計系統？3）我們如何知道系統是否能按預期的設想工作？4）我們如何度量系統達到的質量水平？5）我們如何預計所涉及的工作？

第1部分 需求管理簡介

簡單地說，需求就是用戶用于解決某一問題或實現某種目標所需的功能或特性。需求管理是一項系統的方法，用于識別、組織、交流和管理某一軟件應用程序不斷變化的需求。需求管理的首要任務是產生一個需求規格說明書，該規格說明書"定義并文檔化待構建系統的完整外部行為" iii。

一個良好實現的需求管理程序提供了集中的信息庫。該信息庫包括需求、需求的屬性、需求相關的狀態信息，以及其他有關企業環境的管理信息。該信息庫不僅對項目成功至關重要，它還是一種極具價值的企業資產?？梢园l展、調整和重用需求和其相關屬性，從而降低項目后期開發成本。

更好的需求管理所帶來的重要受益

即使根據以上信息，一些人仍然會爭論：為什么在這個不必要的步驟上浪費時間；為什么不直接轉向實現步驟？經驗表明，有效的需求管理可以帶來如下利益：

更好地控制復雜項目。對系統預期行為和需求蔓延缺乏了解，是項目失控的常見因素。需求管理使開發團隊清楚地知道要交付什么，何時交付以及為什么要交付?？梢愿鶕蛻魧虻膬炏燃壓拖嚓P的實施工作來配置資源。能夠更好地了解和管理變更帶來的影響。 改進的軟件質量和更高的客戶滿意度。軟件質量的基本度量標準是"本軟件實現了它的預期行為嗎？"只有在開發人員和測試人員精確地了解必須構建和測試的內容之后，才能達到更高的軟件質量。 減少項目成本和延期事件。研究表明需求錯誤是最普遍的錯誤，這些錯誤最難以糾正。在開發周期中盡早地減少這些錯誤，可以減少錯誤總量，并且降低項目成本且縮短產品投放市場時間。 改進團隊交流。需求管理有助于盡早處理客戶有關問題，確保應用程序滿足客戶需要。集中的存儲庫在用戶社區、管理層、分析師、開發人員和測試人員之間，建立了對項目需要和承諾方面的公共理解。 利用標準和規則輕松地達到一致性。多數涉及軟件一致性和過程改進的主要標準組織和管理機構，都對需求管理問題有透徹的了解。例如，軟件工程協會（Software Engineering Institute）的能力成熟度模型（Capability Maturity Model，CMM）使用需求管理作為改進軟件質量的第一步。DOD、FDA 和 ISO 9000 的標準和規定都要求企業證明軟件過程的成熟度和該過程的控制。

顯而易見，做好上述工作可節省可觀的時間和資金，更毫無疑問地減少了不成功或部分成功的軟件開發所造成的職業挑戰。

需求錯誤的高昂代價
有力的證據表明有效的需求管理能夠節省整體項目成本。這有三個主要原因：

1. 需求錯誤通常比其他錯誤多花費 10 倍時間來修復。

2. 需求錯誤通常占軟件項目總錯誤的 40% 以上。

3. 需求錯誤的稍微減少能顯著地降低返工成本和日程延期。

GTE、TRW 和 IBM 所做的研究度量指出了項目生命周期各個階段發生錯誤的成本2。盡管這些研究是獨立進行的，但它們幾乎得到了相同的結論：如果指出編寫代碼階段的錯誤檢測和修復成本單位為 1，那么檢測和修復需求階段錯誤的成本要小 5 到 10 倍。并且，檢測和修復維護階段的成本大于 20 倍。圖 1 顯示了結果概要。

圖 1 軟件生命周期中，需求階段節約的錯誤檢測成本與維護階段錯誤檢測成本相比，多達 200:1 。

這個巨大差別的原因在于，很多這樣的錯誤直到發生后一段時間才檢測到。檢測錯誤的延遲意味著修復成本既包括糾正錯誤本身的成本，也包括糾正后期階段的錯誤相關投資成本。這些投資包括重新設計和替換代碼的成本、文檔重寫成本和返工或在工作區內替換軟件的成本。

需求錯誤是最常見的錯誤

這些研究表明，需求階段的錯誤修復起來要付出特別高昂的代價。如果這樣的錯誤很少出現，那么這項支出占總成本的比例將不再顯得突出。但是，需求錯誤確實是復雜軟件項目中典型的最大比例的錯誤。在 Sheldon 做的一項 US Air Forceiv 的項目研究中，根據錯誤的種類將它們進行了歸類。結果表明需求錯誤占錯誤總數的 41%，而邏輯設計錯誤僅占 28%。其他案例研究也支持這項結論。例如，Tom DeMarco 引用的 Tavolato 和 Vincena 項目，56% 的bug 可以追溯到需求階段所犯下的錯誤4。

圖 2 一個美國空軍項目中的錯誤來源

通過更有效的需求管理節約成本

在 Raytheon 公司所做的一項研究中，Dion 報告了大約 40% 的項目總投資用于返工成本5。其他研究也表明，對于現在的大多數企業，返工成本占項目總成本的 30 - 40%。由于它們的巨大數額和多重影響，找到并修復需求錯誤占項目返工總成本的 70 - 85%。

企業（如 Raytheon）已經證實，改進其開發過程。從 CMM 級別 1 升級到CMM 級別 3（在下文中討論），可以降低返工成本的 50 - 60%，盡管實際的情況有所不同，但顯而易見的是，需求錯誤的稍微減少將顯著地節約成本。

這些高昂成本還不包括與需求錯誤相關的無形成本。無形成本包括缺少可能交付的產品特性、項目團隊喪失信心，以及失去可重獲的市場，也失去了相關的收入和利益。綜合了這些因素，這些成本表明公司不能忽視更好的需求管理帶來的利益。

需求管理――來自 SEI 的能力成熟度模型的觀點
1986 年 11 月，美國國防部成立的軟件工程研究所（SEI）開始開發過程成熟度框架，用來幫助開發人員改進軟件過程6。1987 年 9 月，SEI 發布了過程成熟度框架的簡介，Watts Humphrey 后來在他的著作（1991年出版的 Managing the Software Process.7）中詳細闡述了該框架，該框架后來演進成眾所周知的 Capability Maturity Model（能力成熟度模型）1.0 版，也稱為 CMM。1994年，發布了 CMM 1.1 版8。

CMM 為企業定義了 5 個軟件成熟度級別，并提供了從一個級別改變到另一級別的框架。CMM 通過幫助企業改進其軟件過程（目的是獲得可重復性、可控制性和可度量性）為開發人員提供指導。CMM 已在軟件密集行業獲得很大的信任度。采用 CMM 和相應的軟件質量改進，能夠顯著地降低大型商業企業內部應用程序開發成本9。這些成本節約首先來自返工成本的降低10。

按照 CMM 的定義，過程改進使用"關鍵過程域"。它們影響到開發過程和最終軟件質量的各個方面。表4 顯示了 CMM 的 5 個級別和它們的關鍵過程域。顯而易見，表1 表明從級別 1 升級到級別 2 必須用到的關鍵過程域是需求管理。CMM 的定位是：需求管理是達到過程成熟度的首要步驟之一。

CMM 推薦的需求管理
SEI 發布的"Key Practices of the Capability Maturity Model, Version 1.1（能力成熟度模型的關鍵實踐 1.1 版）"11，描述了 CMM 每一個關鍵過程域的目標和活動。根據這個文件，"需求管理的目的是在客戶和軟件項目之間建立對客戶需求的公共理解，以用于軟件項目"。

在 CMM 模式下，必須了解、分析和文檔化軟件需求。再進一步，需求集合是軟件開發計劃的最初入口。企業務必要確保所有的軟件計劃和相關活動與文檔化的需求保持一致。這樣，需求成為核心項目焦點，并且將需求管理和項目管理不可分割地連接起來。

在 CMM 模式下要嚴格地管理需求變更。需求變更時，必須更新說明文檔。企業同樣有責任確保變更軟件開發計劃和活動，使之與需求變更保持一致。CMM 為每個關鍵過程域的度量和分析提供了建議域。這些度量為進行中的關鍵過程域自身改進提供了反饋信息。建議的需求管理中度量的樣例包括：

需求管理是邁向過程成熟度的第一步
1. 每個已分配的需求的狀態。

2. 每個已分配的需求的變更活動。

3. 累積的需求變更數量。包括跟蹤變更的數量，這些數字是提議的、開放的、經核準的，并且合并到系統基準中。

4. 顯然，管理這些屬性的最佳方法是通過一個數據庫，該數據庫應了解需求本身、需求之間的關系，以及每一項需求的相關屬性。

ISO 9000 和 FDA GMP 推薦的需求管理
ISO 9000 質量指導方針已廣泛地為北美洲、歐洲和亞洲的制造商所認可。同樣，美國食品和藥品管理局（FDA）已提議徹底改變制造和銷售醫療設備的管理規定。FDA 所提議的新的 GMP（良好生產規范）采用了相當大比例的 ISO 9000 標準。特別地，Subpart C、Design Controls 的主要基礎就是 ISO 指導方針。

ISO 9000-312，即"ISO 9001 用于軟件開發、供應和維護的指導方針"，明確地將軟件和嵌入式軟件系統制造商作為管理對象。了解質量標準面向供應商的質量控制的原則后，不難發現焦點明顯地集中在需求管理上。特別是在 5.3.1 小節規定：

"為了進行軟件開發，供應商應有一個全面的、明確的功能需求集合。另外，這些需求應包括滿足買方需要的各個方面?？梢园ǖ痪窒抻谙率龅姆矫妫?STRONG>性能、安全性、可靠性、保密性。應足夠精確地表明這些需求，以便在產品驗收期間進行確認。"

本標準的目的是提供關于需求、變更管理和需求管理其他方面的一致的方法。但是，上述內容清楚地表達了兩個主要問題：1）在開發之前，必須有一個完全的功能性和非行為性類型的需求集。2）需求必須足夠詳細，以支持產品確認。

總之，需求管理是一個關鍵域，必須用它來達到并保持與 ISO 9000 標準一致，并且由此獲取質量利益，這也正是標準旨在提供的。

快速原型環境中的需求管理
需求難以了解，想要詳細了解就更難。這個問題的錯誤解決方法是對需求規格說明書的泛泛的工作，并且急于設計，徒勞地編寫代碼，這樣做的原因是：

1. 有一個系統好過沒有系統。

2. 需求遲早會自己就顯現出來，或者，

3. 工作時，開發人員將指出創建什么。

正確的解決辦法首先是要采取各種方法盡可能多地了解需求。采取面談的方式、團體座談、發送問題調查表，以及召開討論會和聯系人會議?；仡?bug 報告和現有系統的加強要求。了解正在設計何種相似的或競爭性的應用程序來滿足這些需求。最后，使用原型。

在取得一致的用戶界面和實現特定功能方面，沒有什么能比原型的作用更大。不僅能夠通過原型來明確需求，而且還能通過它們來了解客戶的需要和想法。

原型有兩種：一次性原型和進化式原型。一次性原型以快速、粗略的方法構建，提供給客戶用來得到反饋信息，一旦得到所需信息，該原型就廢棄不用。一次性原型通常是一個非常短的需求文檔，或者是單頁的需求清單。一次性文檔完成其工作后，在全面開發之前，務必要捕獲所得到的需求，形成一個更健壯的需求規格說明書。

進化式原型以高質量方式構建，提供給客戶用來得到反饋信息，并且修改它使其更接近用戶的要求。一直重復此過程直到其內容集合了所需產品的特性。進化式原型將發展成最終產品，因此不要走開發捷徑，相反，在項目開始就應該創建高質量、可全面跟蹤的需求規格說明書。

當不了解關鍵的產品特性或產品結構時，可使用一次性原型。當對產品關鍵功能有很好的了解，但不了解其他特性時，可使用進化式原型。每一次返回修改時，都要將已了解的需求編輯成文檔并規劃創建滿足這些需求的系統。

值得重復一提的是，一定要記錄對需求規格說明書的了解。我們都曾聽軟件開發者說過，"我已經完成了設計，就差把它編寫成文檔了"。這毫無意義，特別對于今天的團隊環境（要求通過清楚地溝通需求來達到成功）而言。您能接受一個建筑師這樣說嗎？"我已經完成了您新家的設計，就差畫一張設計圖了"，或一個小說家這樣說，"我已經完成了小說，就差把它寫出來了"。

如果您要大量改動需求，那么先不用記錄；先規劃創建增加的需求項，但這也不是對任意一個增加項的需求規格說明書泛泛工作的借口。

第2部分 使需求管理發揮作用
確定需求--當遇到一個需求時，如何來了解它？通常情況下，開始時需求是抽象的，例如，"我需要一個控制電梯的系統"。然后經過探討，需求變得更加詳細，分解并以一個新的方式重新組合，并且產生樣例需求（特別是存在多重案例時）。最后，可以得到一個非常詳細的需求集，例如，"當按下上升按鈕時，按鈕后的指示燈在一秒鐘內亮起"。

需求不僅變得更詳細了，而且變得更加明確。需求最初產生于客戶或用戶?？梢允褂枚喾N技術來獲得需求，如面談、討論會、原型、問題調查表、質量函數部署技術等等。一旦得出需求之后，一項至關重要的任務是，從每個需求到更多抽象的前需求，和到更詳細的后繼需求的跟蹤。跟蹤有助于管理變更，并且是保證質量和健康需求管理的基礎。

最后，可以得到更多的詳細需求，這樣的文檔稱為需求規格說明書（requirements specification）。本規格說明書必須經過溝通使所有相關方同意。它是設計（使設計者知道要設計何種系統）和測試（使測試者知道要測試何種系統）的基礎。好的需求規格說明書具有如下特性：

1. 更低的模糊性。如果需求有多種岐意，那么產品不大可能會滿足用戶需要。

2. 完全性。盡管不可能了解一個系統的所有特性要求，至少應該詳細列出已知的需求。

3. 一致性。如果兩種需求互相沖突，那么不可能構建出滿足所有需求的系統。

4. 可以追溯至開始。應該確定每一個需求的來源?？赡苁怯梢粋€抽象的需求細化而來，或是來自于一次與目標用戶的特定會議。

5. 避免設計。只要需求還利用外部行為，例如被用戶或其他交互系統查看，那么不管是何種詳細程度，它們還是需求。當力圖用需求來指明特定次要成分或其算法的存在，那么它不再是需求了，而變成了設計信息。

6. 需求是可以列舉的。大多數的需求規格說明書都通過本身不是需求類的信息作為輔助，來提高需求規格說明書的易讀性。這些信息包括介紹性的段落或語句，摘要陳述、表格、術語表，以及其他。應該以某種方式很容易分辨出文檔中哪些是實際的需求內容，可以使用特定的字體、標識標簽，或者其他突出方式。

此處完整地列出了制定需求規格說明書的原則，引自 Davis 的《201 項軟件開發原則》（201 Principles of Software Development）一書中的第 3 章14。

編寫 SRS－－良好的開端是成功的一半

在您的開發項目中存在許多重要的文檔：用戶需求描述、設計文檔、測試計劃等等。但有一個特殊的文檔，即 SRS 軟件需求規格說明書，是軟件開發人員首先關注的文檔。這個文檔的目的是定義待建系統完整的外部特征。它定義了所有的行為方式需求（如本系統應在環境為 B 的情況下執行 A）和非行為方式需求（如本系統可用性應為 99.9%）。盡管標準不是萬能的，但企業采用 SRS 標準將獲得如下利益：

標準可用作待確定事項的清單，因此不會有任何遺漏。 有助于閱讀者快速定位和評審需求，并且 節省新需求編寫人員和其他項目團隊成員的時間。

起草 SRS 時，大量的軟件規范標準都可用作起始點。其中一項提供了大量的指導和靈活性，它就是 IEEE/ANSI 830-1993"IEEE 關于軟件需求規格說明書的推薦實踐"。還可以采用許多其他的標準來滿足您的需要。Thayer 和 Dorfman13 編篡了一個很好的資源。13。他們的再版著作中包含了 26 種不同的需求規格說明書，包括國內、國際、IEEE、ANSI、NASA 和美國軍事標準。

重要的是，文檔提綱應具有準確性、一致性和便于理解。ANSI IEEE 830 可以作為 SRS 的一個好的起點。然后在使用的基礎上，您會發現它還有益于修改標準使其成為與企業特定過程和文化更匹配的企業標準。

從文檔選擇需求

需求文檔包含許多并非是系統需求的信息。例如，引言、總體系統描述、術語表和其他解釋信息。盡管它們對理解需求起到重要作用，但它們不是系統要完成的需求。

為使需求交流更加簡便，并且允許需求管理，編寫者應為那些必須實現和隨后要測試的部分（文本、圖形或嵌入對象）加標簽。最好是實際的需求保持"in situ"（拉丁語"在其最初的位置"），而不是存儲在多個位置。也就是，即使作為單個需求選擇后，也能夠在項目文檔中對其進行編輯和維護。這樣更易于在需求改變時，對項目文檔進行更新。

將需求組織起來

無論是采用公認的標準還是您自己的標準，都應該有一個部分用于特定的需求描述。假設有 500 項獨立的需求，與其把它們列舉為一個長串，還不如找到一種方法將它們分組，這也有助于理解它們。我們推薦的分組依據2：

運行模式 用戶種類 目標 特性 促進因素 以上任意項的結合

對于明確定義了狀態的應用程序，可以按照對應的運行模式把它們的需求分組。具有大量不同用戶的系統，按照用戶種類分組可能是最好的方法。例如，電梯控制系統規范可分成三個主要的子部分：乘客、消防人員和維護人員。這提供了一個邏輯方法，用來把特定需求進行分組，使每一類用戶都能評審和了解各自的需求。

其他的應用程序根據特點來分組可能最合適－－也就是說，把突出特點和預期行為作為用戶查看的依據。但是還有一些其他的系統，如空運系統，它在現實世界中有豐富的服務對象，它的最佳分組方法也許是根據系統對象的行為。這種方法也適用于已采用對象技術作為其開發范例的軟件企業。

使用屬性管理需求

所有的需求都具有屬性，無論我們是否識別它們。這些屬性是一個豐富的資源，有助于規劃、交流和跟蹤整個生命周期中的項目活動。每個項目都有特定的需要，并且應該選擇對于項目成功至關重要的那些屬性。這里舉一個實例：
用戶利益――所有需求都不是以同等級別創建的。按照它們對終端用戶的重要性劃分等級，為您與客戶、分析師和開發團隊成員開設了一個對話窗口。
工作――顯然，某些需求或變更比其他需求或變更需要更多的時間和資源。例如，估計人員工作周期或所需的代碼行數，是預期在給定期限內哪些能夠完成，哪些不能完成的最佳方法。

開發的優先級――只有在考慮了需求相關的用戶利益，和實現這些利益所需的工作之后，團隊才能在項目日程和預算的雙重限制下作出功能權衡。把優先級傳達給整個企業，哪些功能要首先完成，哪些功能在時間允許的情況下完成，以及哪些功能可以推遲。在許多項目中，我們可以發現盡管還有更好的分級方法，但只要把相關的需求重要性按照高、中和低或重要、需要和可選這樣的等級分類就足夠了。

狀態――應該能夠通過一個或多個狀態域跟蹤關鍵決策和進程。在定義項目基準期間，如建議的、批準的和集成的這樣的狀態選擇是恰當的。當進入開發階段后，可以使用正在進行、完成和驗證這樣的狀態來跟蹤項目的關鍵階段。

編寫者――應在數據庫中記錄需求的個人（或團隊）責任。這些責任可能是輸入文本的人員責任或驗證需求的人員責任。

責任方――負責確保需求達到滿意程度的人。

基本原理――需求由于一些特定的原因而存在。這項屬性記錄了說明或是說明的參考資料。例如，參考資料可能是需求規格說明書中的一頁或幾行，或是重要的客戶會見錄音磁帶中的某一分鐘的標記。

日期――應在文檔中記錄需求創建或變更的日期。

需求的版本――隨著需求的轉化，標識需求變更的版本數（和歷史版本）很有幫助。

與其他需求的關系――可以保持需求之間的很多關系。例如，屬性域可以記錄：

1. 作為本項需求來源的更為抽象的需求。

2. 從本項需求出發得到的更為詳細的需求。

3. 本項需求是其子集的需求。

4. 作為本項需求子集的需求。

5. 必須在滿足本項需求之前滿足什么需求，等等。

保持從需求到所有開發產品（從需求開發而來）的鏈接非常重要。通過提供這些鏈接，人們易于確定任何變更帶來的影響，并且快速確定開發狀態（本狀態應作為那些下游存在狀態的屬性）
上述列出的不盡詳盡。其他公共屬性還有穩定性、風險、安全性、安全發布實現、功能域等等。不管用何種方法跟蹤它們，屬性都應易于定制，以適應每個團隊和每個應用程序的特定需要。

需求可跟蹤性――確保質量并且管理變更

大多數的美國國防部軟件合同中都要求需求可跟蹤性，所有高可靠性產品和系統的制造商典型地實踐了這個能力。在衛生保健行業中，需求可跟蹤性取決于良好生產實踐管理（Good Manufacturing Practices Regulation）建議的變更。但是，這些行業外的大多數企業都不常規地實踐需求跟蹤?？筛櫺允莾蓚€事物間的鏈接或可定義的關系。使用需求可跟蹤性的用戶發現，它提供的項目控制水平和質量保證，是其他方法很難達到的。在 Abbott 實驗室，1987 年就創立了可跟蹤性，他們這樣形容："如果您不能跟蹤某項事物，那么就無法管理它"15。這形成了一項基本概念，原因就是如果沒有某種形式的需求可跟蹤性，那么就不可能確保需求測試的覆蓋度。

可跟蹤性幫助管理各類項目的變更和成本。

需求跟蹤帶來的利益：簡而言之，需求跟蹤證明了軟件按照設計工作。本過程的關鍵利益包括：

確認所有的用戶需求已經實現，并且進行了充分的測試。 確認所有系統行為都可以追溯到用戶需求。 了解需求變更帶來的影響。

實現需求可跟蹤性

圖 3 顯示了一個項目文檔的簡單層次。在這個例子中，產品需求文檔是所有需求的"源文檔"。在其他例子中，源文檔可能是用戶需要文檔、系統規格說明等。

圖中兩個文檔間的層次關系表明，文檔中特定元素之間可能存在相互關系。例如，產品需求文檔和軟件需求規格說明文檔的關系意味著，任何特定的產品需求都通過某個或多個軟件需求來滿足。同樣，任何軟件需求可以用于滿足某個或多個產品需求。顯然，一項產品需求如果沒有相關的軟件需求或硬件需求，它將無法得到滿足。反之也一樣，一項軟件需求如果沒有相關的產品需求，那么它就是多余的，應該將其刪除。

除建立文檔關系來支持可跟蹤性外，還需要某些形式的系統來保持文檔層次中單個項之間的鏈接。完成這項工作有兩種方法，可以通過直接在文檔內部嵌入鏈接和標識符來完成，或者通過使用一個獨立的電子表格或數據庫來管理文檔外部的鏈接。每種方法都有優勢和劣勢。一種新的需求管理工具可以自動保持可跟蹤性鏈接。理論上，相同的工具也集成了這項功能，來管理和控制文檔和文檔的單個需求。

變更管理

可跟蹤性提供了一個系統的、可控制的過程，來管理應用程序開發過程中必然要出現的變更。如果不進行跟蹤，那么對于每項變更，都要求檢查特定基礎上的文檔，來判斷哪個項目元素需要更新。因為很難確定所有受變更影響的組件都已經做過標識，因此變更可能導致系統可靠性下降。

利用可跟蹤性，變更管理可以按有序的方式進行?？梢酝ㄟ^文檔層次中可跟蹤性關系，來了解變更帶來的影響。例如，如果用戶需要變更，開發人員能夠迅速確定需要改變哪些項目要素，測試人員也可以查明必須修訂哪些測試計劃，項目經理也可以更好地確定實施變更的難度和可能要花費的成本。

需求報告――易于進行管理評審
需求庫為項目經理提供了一個功能強大的工具，來跟蹤和報告項目情況。更易于確定項目關鍵里程碑。更好地量化調度風險。使優先級和所有權保持可見性。通過查詢資料庫，可以迅速獲得以下問題的答案：

本項目共有多少項需求？哪些需求具有高的優先級？基本需求所占百分比有多大？何時實現這些需求？自從上次客戶檢查后，哪些需求發生了變更？誰負責這些變更？估計變更帶來的成本變化是多少？

高水平的報告有助于產品功能的管理評審?？梢园凑湛蛻粜枰?、難易程度、所需成本或用戶安全需要，來劃分需求的優先級。這些專項報告有助于項目經理集中精力于關鍵的項目問題上，更好地配置有限資源。最終可以達到：項目經理做出更英明的決策，由此改進企業應用程序開發工作的成果。

您能夠做什么？
1. 繼續學習通過需求管理可以實現的利益。進行安全培訓和閱讀資料。我們為您提供了推薦的書目。
2. 開發并利用新的工具，使需求管理變得更加簡單。
3. 采用個性化策略，更好地傳遞您現有的需求。

結束語
軟件開發是當代最激動人心、最能獲得回報的職業。不幸的是，我們中的許多人都嘗過應用程序帶來的失望滋味。有許多常見的問題，如超過了計劃日程的 1/2，交付的功能要比預計的少，或在發布之前項目就被取消了。為了與新出現的復雜性和不斷增加的用戶要求保持同步，我們首先就要改進需求管理。務必使開發、測試和管理軟件項目的方法成熟起來。

需求管理提供了應用程序需求和其相關屬性、鏈接的"實時"庫。本"實時"庫是與軟件設計初衷一致的。它提供了大量信息，可以用于管理和控制項目。軟件質量將得到改善，更好地滿足客戶的需要。由于所有團隊成員都可以訪問需求數據，極大地改善了團隊交流。

現在就開始。通過早期捕獲需求錯誤，顯著削減項目成本。試著用簡單的描述寫下當前項目的所有需求（提示：如果這難以做到，或還沒做完，就查明原因）。將這些需求歸納到一個合適的、簡短的報告中，并與客戶和同事共享。取得他們的反饋意見。是否遺漏了某項需求？是否具有完全性？是否有錯誤？這是一個好機會來取得這三個問題的答案。如果現在所處階段太早，不能糾正這些錯誤，那么就把它們集中存儲起來。如果所處階段太遲，那么征求一下哪些過程可以變更，并預計一下首先做什么工作。

參考書目
1Gibbs, W., Software's Chronic Crisis, Scientific American, September 1994.

ii CHAOS, The Standish Group International, Inc., Dennis, MA, 1994

iii Davis, A., Software Requirements, Objects, Functions, and States, Englewood Cliffs, NJ., Prentice Hall, 1993.

iv Sheldon, F. et al, Reliability Measurement from Theory to Practice, IEEE Software, 9,4 (July 1992)

4 Tavolato, P., and K. Vincena. "A Prototyping Methodology and Its Tool." In Approaches to Prototyping, R Budde et al., eds., Berlin: Springer-Verlag, 1984. pp. 434-46

5 Dion, R. "Process Improvement and the Corporate Balance Sheet," IEEE Software, 10,4 (July 1993),pp. 28-35

6 Paulk, M., et al, "Capability Maturity Model , Version 1.1", IEEE Software, 10, 4(July 1993), pp. 18-27.

7 Humphrey, W.S., Managing the Software Process, Reading Mass,Addison Wesley, 1989.

8 Paulk, M., et al, "Capability Maturity Model for Software, Version 1.1," Software Engineering Institute, Pittsburgh, PA, SEI-93-TR-024

9 Humphrey, W., et al., "Software Process Improvement at Hughes Aircraft," IEEE Software, 8, 4 (July 1991), pp. 11-23.

10 Dion, R. "Process Improvement and the Corporate Balance Sheet," IEEE Software, 10,4 (July 1993),pp. 28-35

11 Paulk, M., et al, "Capability Maturity Model for Software, Version 1.1," Software Engineering Institute, Pittsburgh, PA, SEI-93-TR-024

12 ISO 9000-3, "Guidelines for the Application of ISO 9001 to the Development, Supply, and Maintenance of Software", Int'l Organization for Standardization, Geneva, 1991

v Davis, A., 201 Principles of Software Development, New York, NY. McGraw-Hill, Inc., 1995

14 Davis, A., 201 Principles of Software Development, New York, NY: McGraw Hill, 1995.

13 Dorfman, M., and R. Thayer, Standards, Guidelines and Examples of System and Software Requirements Engineering, Los Alamitos, CA: IEEE Computer Society, 1991.

15 Watkins, R., and M. Neal, Why and How of Requirements Tracing ," IEEE Software, 11,4 (July 1994), pp. 104-106.

關于作者
Alan M. Davis and Dean A. Leffingwell,高級系統與軟件工程師,Rational Brand Services,IBM Software Group。

　

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