需求跟蹤

出自 MBA智库百科(https://wiki.mbalib.com/)

需求跟蹤（Requirements Tracing）

　　需求跟蹤是指跟蹤一個需求使用期限的全過程，需求跟蹤包括編製每個需求同系統元素之間的聯繫文檔，這些元素包括其他類型的需求，體繫結構，其他設計部件，源代碼模塊，測試，幫助文件等。需求跟蹤為我們提供了由需求到產品實現整個過程範圍的明確查閱的能力。需求跟蹤的目的是建立與維護“需求－設計－編程－測試”之間的一致性，確保所有的工作成果符合用戶需求。

　　需求跟蹤有兩種方式：

　　（1）正向跟蹤。檢查《產品需求規格說明書》中的每個需求是否都能在後繼工作成果中找到對應點。

　　（2）逆向跟蹤。檢查設計文檔、代碼、測試用例等工作成果是否都能在《產品需求規格說明書》中找到出處。

　　正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論採用何種跟蹤方式，都要建立與維護需求跟蹤矩陣（即表格）。需求跟蹤矩陣保存了需求與後繼工作成果的對應關係。

　　跟蹤能力（聯繫）鏈（traceability link）使你能跟蹤一個需求使用期限的全過程，即從需求源到實現的前後生存期。跟蹤能力是優秀需求規格說明書的一個特征。為了實現可跟蹤能力，必須統一地標識出每一個需求，以便能明確地進行查閱。

　　上圖說明瞭四類需求跟蹤能力鏈。客戶需求可向前追溯到需求，這樣就能區分出開發過程中或開髮結束後由於需求變更受到影響的需求。這也確保了需求規格說明書包括所有客戶需求。同樣，可以從需求回溯相應的客戶需求，確 認每個軟體需求的源頭。如果用使用實例的形式 來描述客戶需求，圖的上半部分就是使用實 例和功能性需求之間的跟蹤情況。圖的下半 部分指出：由於開發過程中系統需求轉變為軟體 需求、設計、編寫等，所以通過定義單個需求和 特定的產品元素之間的（聯繫）鏈可從需求向前 追溯。這種聯繫鏈使你知道每個需求對應的產品 部件，從而確保產品部件滿足每個需求。第四類 聯繫鏈是從產品部件回溯到需求，使你知道每個 部件存在的原因。絕大多數項目不包括與用戶需 求直接相關的代碼，但對於開發者卻要知道為什 麽寫這一行代碼。如果不能把設計元素、代碼段 或測試回溯到一個需求，你可能有一個“畫蛇添 足的程式”。然而，若這些孤立的元素表明瞭一 個正當的功能，則說明需求規格說明書漏掉了一項需求。

　　跟蹤能力聯繫鏈記錄了單個需求之間的父層、互連、依賴的關係。當某個需求變更（被刪除或修改）後，這種信息能夠確保正確的變更傳播，並將相應的任務作出正確的調整。下圖2說明瞭許多能在項目中定義的直接跟蹤能力聯繫鏈。一個項目不必擁有所有種類的跟蹤能力聯繫鏈，要根據具體的情況調整。

　　在某種程度上，需求跟蹤提供了一個表明與合同或說明一致的方法。更進一步，需求跟蹤可以改善產品質量，降低維護成本，而且很容易實現重用。

　　需求跟蹤是個要求手工操作且勞動強度很大的任務，要求組織提供支持。隨著系統開發的進行和維護的執行，要保持關聯鏈信息與實際一致。跟蹤能力信息一旦過時，可能再也不會重建它了。由於這些原因，應該正確使用需求跟蹤能力。

• 下麵是在項目中使用需求跟蹤能力的一些好處：
  • 審核（certification） 跟蹤能力信息可以幫助審核確保所有需求被應用。
  • 變更影響分析跟蹤能力信息在增、刪、改需求時可以確保不忽略每個受到影響的系統元素。
  • 維護可靠的跟蹤能力信息使得維護時能正確、完整地實施變更，從而提高生產率。要是一下子不能為整個系統建立跟蹤能力信息，一次可以只建立一部分，再逐漸增加。從系統的一部分著手建立，先列表需求，然後記錄跟蹤能力鏈，再逐漸拓展。
  • 項目跟蹤在開發中，認真記錄跟蹤能力數據，就可以獲得計劃功能當前實現狀態的記錄。還未出現的聯繫鏈意味著沒有相應的產品部件。
  • 再設計（重新建造） 你可以列出傳統系統中將要替換的功能，記錄它們在新系統的需求和軟體組件中的位置。通過定義跟蹤能力信息鏈提供一種方法收集從一個現成系統的反向工程中所學到的方法。
  • 重覆利用跟蹤信息可以幫助你在新系統中對相同的功能利用舊系統相關資源。例如：功能設計、相關需求、代碼、測試等。
  • 減小風險使部件互連關係文檔化可減少由於一名關鍵成員離開項目帶來的風險。
  • 測試測試模塊、需求、代碼段之間的聯繫鏈可以在測試出錯時指出最可能有問題的代碼段。

　　以上所述許多是長期利益，減少了整個產品生存期費用，但同時要註意到由於積累和管理跟蹤能力信息增加了開發成本。這個問題應該這樣來看，把增加的費用當作一項投資，這筆投資可以使你發佈令人滿意同時更容易維護的產品。儘管很難計算，但這筆投資在每一次修改、擴展或代替產品時都會有所體現。如果在開發工程中收集信息，定義跟蹤能力聯繫鏈一點也不難，但要在整個系統完成後再實施代價確實很大。

　　CMMI要求具備需求跟蹤能力。軟體產品工程活動的關鍵過程域有關於它的陳述，“在軟體工作產品之間，維護一致性。工作產品包括軟體計劃，過程描述，分配需求，軟體需求，軟體設計，代碼，測試計劃，以及測試過程。”需求跟蹤過程中還定義了一些關於一個組織如何處理需求跟蹤能力的期望。

　　表示需求和別的系統元素之間的聯繫鏈的最普遍方式是使用需求跟蹤能力矩陣。下表展示了這種矩陣，這是一個“化學製品跟蹤系統”實例的跟蹤能力矩陣的一部分。這個表說明瞭每個功能性需求向後連接一個特定的使用實例，向前連接一個或多個設計、代碼和測試元素。設計元素可以是模型中的對象，例如數據流圖、關係數據模型中的表單、或對象類。代碼參考可以是類中的方法，源代碼文件名、過程或函數。加上更多的列項就可以拓展到與其它工作產品的關聯，例如線上幫助文檔。包括越多的細節就越花時間，但同時很容易得到相關聯的軟體元素，在做變更影響分析和維護時就可以節省時間。

　　跟蹤能力聯繫鏈可以定義各種系統元素類型間的一對一，一對多，多對多關係。表1中允許在一個表單元中填入幾個元素來實現這些特征。這裡是一些可能的分類：

• 一對一一個代碼模塊應用一個設計元素。
• 一對多多個測試實例驗證一個功能需求。
• 多對多每個使用實例導致多個功能性需求，而一些功能性需求常擁有幾個使用實例。

　　手工創建需求跟蹤能力矩陣是一個應該養成的習慣，即使對小項目也很有效。一旦確立使用實例基準，就準備在矩陣中添加每個使用實例演化成的功能性需求。隨著軟體設計、構造、測試開發的進展不斷更新矩陣。例如，在實現某一功能需求後，你可以更新它在矩陣中的設計和代碼單元，將需求狀態設置為“已完成”。 表示跟蹤能力信息的另一個方法是通過矩陣的集合，矩陣定義了系統元素對間的聯繫鏈。例如：

• 一類需求與另一類需求之間。
• 同類中不同的需求之間。
• 一類需求與測試實例之間。

　　可以使用這些矩陣定義需求間可能的不同聯繫，例如：指定/被指定、依賴於、衍生為以及限制/被限制。

　　下表2中說明瞭兩維的跟蹤能力矩陣。矩陣中絕大多數的單元是空的。每個單元指示相對應行與列之間的聯繫，可以使用不同的符號明確表示“追溯到”和“從.. 回溯”或其他聯繫。表2中使用一個箭頭表示一個功能性需求是從一個使用實例追溯來的。這些矩陣相對於表16-6中的單跟蹤能力表更容易被機器自動支持。

　　跟蹤能力聯繫鏈無論誰有合適的信息都可以定義。下表3定義了一些典型的知識源，即關於不同種類源和目標對象間的聯繫鏈。定義了可以為工程項目提供每種跟蹤能力信息的角色和個人。

　　由於聯繫鏈源於開發組成員的頭腦中，所以需求跟蹤能力不能完全自動化。然而，一旦已確定聯繫鏈，特定工具就能幫你管理巨大的跟蹤能力信息。可以使用電子數據表來維護幾百個需求的矩陣，但更大的系統需要更“魯棒”的解決辦法。

　　具有強大需求跟蹤能力的商業需求管理工具均使用如表16 -7的跟蹤能力矩陣。可以在工具的資料庫中存儲需求和其他信息，定義不同對象間的聯繫鏈，甚至包括同類需求的對等聯繫鏈。有一些工具需要區分“追溯到（跟蹤進）”與“從..回溯（跟蹤出）”關係，自動定義相對的聯繫鏈。這就是說，如果你指出需求R追溯到測試實例T，工具會自動定義相對的聯繫“ T從R回溯”。還有一些工具可以在聯繫鏈某端變更後將另一端標為“可疑”。可以讓你檢查確保知道變更的後續效果。

　　這些工具允許定義“跨項目”或“跨子系統”的聯繫鏈。一個有20個子系統的大項目，某些高層產品需求建立在多個子系統之上。有些情況下，分配給一個子系統的需求，實際上是由另一個子系統提供的服務完成的。這樣的項目採用商業需求管理工具可以成功地跟蹤這些複雜的跟蹤能力關係。

　　當你應用需求跟蹤能力來管理工程時，可以考慮下列步驟：

• 決定定義哪幾種聯繫鏈，可以參見圖2來進行。
• 選擇使用的跟蹤能力矩陣的種類，是表1還是表2。
• 確定對產品哪部分維護跟蹤能力信息。由關鍵的核心功能、高風險部分或將來維護量大的部分開始做起。
• 通過修訂過程和核對錶來提醒開發者在需求完成或變更時更新聯繫鏈。
• 制定標記性的規範，用以統一標識所有的系統元素，達到可以相互聯繫的目的。若必要，作文字記錄，這樣就可以分析系統文件，便於重建或更新跟蹤能力矩陣。
• 確定提供每類聯繫鏈信息的個人。
• 培訓項目組成員，使其接受需求跟蹤能力的概念和瞭解重要性、這次活動的目的、跟蹤能力數據存儲位置、定義聯繫鏈的技術—例如，使用需求管理工具的特點。確保與會人員明白擔負的責任。
• 一旦有人完成某項任務就要馬上更新跟蹤能力數據，即要立刻通知相關人員更新需求鏈上的聯繫鏈。
• 在開發過程中周期性地更新數據，以使跟蹤信息與實際相符。要是發現跟蹤能力數據沒完成或不正確那就說明沒有達到效果。

　　對有很多子系統的巨大產品進行跟蹤能力管理是一項巨大的工程，但這很必要。並不是所有的公司都會因為軟體問題而造成嚴重的結果，然而應該嚴肅地對待需求跟蹤，尤其對涉及你業務核心的信息系統。考慮了應用技術的成本和不使用的風險後，才能決定是否使用任何改進的需求工程實踐。隨著軟體的發展，要把時間投向回報豐厚的地方。