需求跟蹤方法研究

摘要：對需求跟蹤方法進行了分析、歸納，認為需求跟蹤方法應易于掌握、能跟蹤復雜系統、能自動生成跟蹤鏈、跟蹤鏈維護簡單、有工具和文檔支持等特性。

關鍵詞：需求跟蹤；靜態需求跟蹤；動態需求跟蹤；跟蹤鏈

0 引言

Frederick Brooks在他1987年經典文章“No Silver Bullet”中闡述了需求的重要性：開發軟件系統最困難的部分就是準確描述要開發什么，此工作一旦做錯，將會給系統帶來極大的損害，并且以后對它修改也極為困難。Van Lamsweerde在2000年的一篇文章中提到，“軟件需求在過去25年的實踐中被反復證實是—個確實存在的問題”。

需求跟蹤技術是在需求與后續階段工作產品之間建立跟蹤關系，以便對需求變更進行影響分析的一項技術。它可以驗證設計與需求是否一致，驗證編碼是否與設計一致，確認需求是否被實現和滿足。在風險評估，變更影響分析，系統級測試覆蓋度分析等活動中，它被認為是很有效的支持技術。軟件需求跟蹤就是“一種描述和跟蹤整個需求生命周期(包括前向和后向)的能力”。實踐表明，軟件開發生命周期中，如果忽略了需求跟蹤，將會導致系統質量的下降和反復的修改，從而增加系統開發的時間和成本。

在本文中，我們對需求跟蹤方法的研究現狀進行了分析和歸納，提出了需求跟蹤方法應具備的特性，并指出了現有需求跟蹤方法存在的不足。

1 需求跟蹤方法研究現狀

需求跟蹤方法有靜態跟蹤和動態跟蹤兩種。傳統的需求跟蹤大多以靜態跟蹤為主，主要有跟蹤矩陣、跟蹤圖和交叉引用等方法，其跟蹤鏈只能靜態表示，不能自動生成。靜態需求跟蹤由人手動設置，面臨著容易出錯，時間消耗過多等問題。特別是在項目規模較大，周期較長的時候，跟蹤鏈的維護更成了—個巨大的負擔。

動態需求跟蹤技術提出了跟蹤鏈的動態生成問題。在2005年的需求工程大會上，Cleland-Huang給出了“dynamicrequirement traceability(動態需求跟蹤)”方案，它與傳統需求跟蹤的不同在于需求跟蹤關系的建立是自動化的，而且在需求發生變更時可以根據跟蹤關系進行變更提醒。這對于傳統需求跟蹤活動所面臨的維護困難、容易出錯、成本高等問題，是一個很好的解決方案。因此，對動態需求跟蹤的研究是現階段的主要方向。當前的動態跟蹤方法主要有基于信息檢索的跟蹤、基于規則的跟蹤、基于事件觸發的跟蹤等。下面將對以上幾種需求跟蹤技術作—概述。

1.1 需求跟蹤矩陣

需求跟蹤矩陣保存了需求與后繼工作成果的對應關系，矩陣單元之間可能存在“一對一”、“一對多”或“多對多”的關系。需求跟蹤有兩種方式：“正向跟蹤”和“逆向跟蹤”。“正向跟蹤”檢查每個需求是否都能在后繼工作成果中找到對應點。“逆向跟蹤”檢查設計文檔、代碼、測試用例等工作成果是否都能在需求說明書中找到出處。“正向跟蹤”和“逆向跟蹤”合稱為“雙向跟蹤”。不論采用何種跟蹤方式，都可以建立與維護需求跟蹤矩陣。使用需求跟蹤矩陣的優點是易于創建和維護，可以很容易發現需求與后繼工作成果之間的不一致，有助于開發人員及時糾正偏差，避免做無用功。其缺點是，當需求或工作成果發生變更時，開發人員要及時更新需求跟蹤矩陣。如果不及時更新，隨著工作的進展，跟蹤鏈就會變的不可用，并最終導致跟蹤的失敗。

1.2 跟蹤圖

跟蹤圖通過用戶自定義的對象和關系，將需求項、概念、測試過程、設計文檔和代碼等軟件開發過程中制品之間的關系運用圖形方式表述。跟蹤圖一大特點是用關系表達跟蹤鏈，它允許對象之間可以有多種鏈存在。這些關系是用戶可定義的，需要的時候可以對關系進行調整，以適應各種連接類型。運用數學方法，在沒有直接鏈接關系的對象之間也可以建立跟蹤。由于跟蹤圖中的對象和關系都是由用戶定義的，它們所表達的意義易于被軟件人員理解。但另一方面，它仍然沒有解決跟蹤維護困難的問題，相反，由于多種鏈的存在，使得跟蹤維護變得更加困難。

1.3 交叉引用

交叉引用的主要思想是兩個實體之間有相互關聯時，在其中一個實體中放入另一個實體的引用。這種特別的跟蹤方式被Martin Glinz用于保持場景和類模型之間一致性。在他們的方法中，在創建場景和類模型時可以以非形式化的方式描述。為了保持一致性，他們引入了兩個交叉引用機制：簡單機制和合作機制。簡單機制直接將對類模型的引用放入場景的文本中，類模型維持不變。在合作機制中，細化了對場景的描述。在類模型中，類名、類中的屬性和操作均為可被引用的項目；在場景模型中，場景名稱可被引用，如果對場景的描述是結構化和有編號的，那么場景中每一個部分也可被引用。交叉引用實現了兩個軟件制品之間的單向跟蹤，但跟蹤能力有限，并且當跟蹤實體增大時，仍然面臨著跟蹤難以維護的難題。

1.4 基于信息檢索(IR)的跟蹤

基于信息檢索的動態需求跟蹤利用瓜模型計算需求文本與工作產品文本之間的相似度，按照相似度的大小進行排列，通過設定一定的閾值就可以篩選得到需求所跟蹤的工作產品。需求與工作產品之間的相似度越大，它們之間的跟蹤關系就越有可能是正確的，反之則越有可能是錯誤的。IR技術的優點在于簡單，通過對本文進行分析，能夠自動地建立關聯，不需要人的介入。其缺點是該模式通過需求與工作產品中標引詞(term)的匹配計算出相似度，如果標引詞無法匹配，那么即使兩個標引詞描述的意義相同或者相近，計算得出的相似度也會很低，可能會造成相似度過低而無法建立跟蹤關系，與實際的語義相悖。在一個周期長、規模大的項目中，需求、設計和編碼通常都是由不同的人來完成的，采用不同的標引詞來表示相同語義的情況相當普遍。而且在軟件開發的各個階段，由于描述的領域不同(比如需求是對問題領域的描述，編碼是對解決方案--領域的描述)，采用的描述語言一般會有所不同，因此采用不同的詞對同一個概念進行表示是可以理解的。從以上分析可以看出，采用IR技術來解決需求跟蹤的一個關鍵問題是如何解決一詞多義和同義多詞。

1.5 基于規則的跟蹤

Spanoudakis等人提出了一種基于規則的跟蹤方法。在該研究中，Spanoudakis將動態需求跟蹤分為兩種情況，其一是需求文檔或用例與工作產品之間的跟蹤關系；另一種是需求文檔以及用例相互之間的跟蹤關系。對于這兩種不同情況，定義了不同的匹配規則。所有的跟蹤關系按照其邏輯上的關聯分為4大類，工作人員可以據此清晰地了解具有跟蹤關系的項目之間彼此驅動的先后順序和邏輯關系。在具體實現過程中首先對需求文檔和用例分別進行語法分析，標出句中詞語的詞性以及在句子中所構成的成分；然后將各個句子按詞拆開，標注其成分標記，存儲成XML的格式；最后根據前面提到的規則，將各個XML文件的內容進行跟蹤關系的匹配。該方法的優點在于可以建立任何文檔之間的關系，缺點在于需要針對不同的項目定制不同的跟蹤關系匹配的規則。

1.6 基于事件觸發的跟蹤

基于事件觸發的需求跟蹤方法是從組織維護跟蹤信息的角度來解決問題。在時間緊、任務重的項目環境中，開發人員可能會忽略對變更的響應，以至于工作產品的生產和維護與需求不一致。基于事件的需求跟蹤模型引入了事件消息通知機制。開發人員將工作產品訂閱到需求上，當需求發生變更時，系統會以消息通知的形式提醒開發人員需要進行更新的模塊。整個模型不但可以對直接的跟蹤關系中需求的變更發出通知，還可以對間接的多層跟蹤關系路徑上需求或者工作產品的變更發出通知。在通知發出的時間控制上，既可以采用暫時緩存通知的“延遲通知”方式，又可以采用立即發送通知的“悲觀通知”方式。在追蹤關系的維度上，既可以在需求與工作產品之間建立跟蹤關系，又可以在不同版本的需求之間建立跟蹤關系，從而在空間和時間上對需求的變更進行全面的跟蹤。

2 需求跟蹤方法應具備的特性

需求跟蹤提供了—個表明與合同或說明一致的方法。更進一步，需求跟蹤可以改善產品質量，降低維護成本，而且很容易實現重用。需求跟蹤方法的目標是系統化需求跟蹤的全過程，提高需求跟蹤效率和需求跟蹤質量。為達到此目標，我們認為，一個成熟的需求跟蹤方法應該具備以下的主要特征或功能：

易于掌握：需求跟蹤方法的一個目的是為了減輕需求跟蹤人員的工作量，所以應該具有易于掌握的特點，但這不應以犧牲表達能力為代價，即需求跟蹤方法應該能對需求的各個方面進行全面詳細的跟蹤。為平衡表達能力和掌握難度，可采用的方法是封裝細節，對那些具有共性的細節進行抽象，以模式的方式提供選擇，這樣跟蹤方法為跟蹤者提供的是高層次的設計概念和方法，掩藏了細節，在不犧牲表達能力的基礎上降低了掌握難度，但必要時跟蹤者仍然可以對細節進行設計以滿足特殊的情況。另外，跟蹤方法應充分考慮用戶已有的跟蹤經驗和技術。

對復雜系統跟蹤的能力：近年來，隨著軟件項目的規模越來越大，開發周期拉長，需求也越來越復雜，變更也變得越來越頻繁。成熟的需求跟蹤方法應該能適應這種變化，能對復雜多變的需求進行跟蹤，并能和系統開發的其他部分有機地結合起來。為此，需求跟蹤方法應該具備：

(1)跟蹤關系自動生成能力。能否提供跟蹤關系自動生成能力以及能力的大小是需求跟蹤方法成熟度的—個重要衡量標準，理想的需求跟蹤方法應能提供需求跟蹤關系的自動生成。

(2)跟蹤鏈維護簡單。跟蹤關系聯系鏈記錄了單個需求之間的父層、互連、依賴的關系，由于軟件開發項目普遍存在需求變更頻繁的現象，當某個需求變更(被刪除或修改)后，要能夠方便地建立和及時地維護需求跟蹤關系。

(3)非功能性的需求跟蹤能力。傳統的跟蹤方法多關注于功能性需求的跟蹤，而對非功能性需求的跟蹤研究的較少。一個良好的需求跟蹤方法應該既能對功能性的需求提供跟蹤，也可以對非功能性的需求提供跟蹤。

(4)工具和文檔支持。理想的工具應能支持在用戶參與下，完成從需求確定到需求跟蹤、維護的整個過程。豐富的文檔支持是設計者能否掌握需求工作方法的重要方面。可以說，工具和文檔的支持能力是跟蹤方法能否得到廣泛應用的關鍵。

3 分析比較

前面介紹了幾種典型的需求跟蹤方法，可以看到雖然它們各具特點，但都還不具備我們所提出的需求跟蹤方法應具有的特性。這也使得這些方法缺乏工程應用。目前對動態需求跟蹤的研究，大多只是停留在理論上，只有極少的工程人員知道這些方法的存在。造成這種狀況的原因是多方面的，一是這些方法只出現在一些學術雜志或會議上，工程人員缺乏對它們的關注，二是技術慣性阻礙了工程人員采用新技術，但更主要的還是這些需求跟蹤方法本身存在著不完備性和缺陷。據我們的調查，在這么多方法中，在實際中應用較多的仍然是跟蹤矩陣。究其原因無非是它容易理解，實現起來比較簡單，工具支持也比較簡單，用Excel表格就可以完成跟蹤工作。但是靜態跟蹤矩陣的局限性也是有目共睹的，比如手動設置容易出錯，時間消耗過多，特別是在項目規模較大，周期較長的時候，需求跟蹤鏈的維護更成了一個巨大的負擔。具體來說，現有的需求跟蹤方法主要存在以下問題：

方法比較復雜，難于掌握。需求方法研究人員基于各自的研究領域所提出的方法一般自成體系，不熟悉其研究領域的人員在掌握上存在一定的難度。近期，也有的方法基于面向對象理論，采用UML作為描述手段，這也是工程實現人員熟悉的技術，掌握難度有所降低。但大多數方法濫用了UML擴展機制，仍然比較復雜。

對復雜系統跟蹤困難。復雜系統的項目周期較長，規模較大，目標構成復雜，而且大都是在需求不十分清晰的情況下開工的，因此存在著更多的變數。目前的跟蹤方法對復雜系統的特點缺少合適的描述手段，通常把大型復雜系統當作傳統軟件系統一樣處理，或者在實現層次上定義一些擴展，無法根本解決復雜系統需求跟蹤問題。

跟蹤關系自動生成能力弱。靜態跟蹤方法的跟蹤關系不能自動生成。雖然動態需求方法大多能自動生成跟蹤關系，但大多都比較簡略，需求與軟件制品之間的結構和操作關系過于簡單，生成的跟蹤關系一般會存在錯誤，并可能漏掉部分正確的關系，無法滿足用戶的需求。正確無誤的跟蹤關系對于精確性和安全性要求較高的項目來說，是系統順利演化的保證，是項目成功的一個前提。

跟蹤鏈維護困難。靜態跟蹤面臨的一個最大難題就是跟蹤鏈的維護。由于在軟件開發的過程中變更總是存在著，每一次的變更都要求及時維護整個跟蹤鏈，由于靜態跟蹤方法的跟蹤鏈維護是由手工完成的，維護起來比較困難。現有動態跟蹤方法雖然提供了在變更發生時跟蹤鏈的自動維護，但仍顯不夠，主要是不能滿足跟蹤的完整性和正確性，在跟蹤鏈生成時，易于出錯和跟蹤不完整。

缺少工具和文檔支持。盡管需求跟蹤可以用電子表格或簡單的數據庫來管理，也可以使用商業需求管理工具來定義和管理需求跟蹤能力聯系鏈，讓需求同其他軟件開發工具相連等，但是電子表格只能適用于小一點的項目，而對于商業需求管理工具來說除了入門級的QSSrequireit，其他工具都不便宜，而且由于目前的方法缺少完善的開發過程支持，工具還不能給開發人員全面的支持，特別是方法普遍缺少文檔和用戶說明，嚴重影響了需求跟蹤方法的實用程度。

4 結束語

需求跟蹤的方法能夠實現需求和工作產品的雙向跟蹤，并且能夠有效地管理變更。隨著輔助工具的增多，需求跟蹤在項目實踐中將會得到越來越多的使用，從而為項目的最終成功打下堅實的基礎。

本文對需求跟蹤的研究現狀進行了綜述，包括動態需求跟蹤和靜態需求跟蹤。在對目前需求跟蹤方法進行分析的基礎上，得出了目前需求跟蹤方法所存在的不足之處，并闡述了需求跟蹤方法應具備的特性。當然，本文只在粗淺的層面提出了需求跟蹤方法應具備的特性，需求跟蹤的具體方法以及實現還有待于深入研究。