維基百科

需求可追蹤性

需求可追蹤性（Requirements traceability）也稱為需求可追溯性，是需求管理中的一部份，和軟體開發及系統工程有關。IEEE Systems and Software Engineering Vocabulary有定義通用的可追溯性（Traceability）[1]，定義如下

  1. 在開發過程中二個或是多個產品相關性的程度，特別是兩者之間有先後關係或主從關係的產品[2]
  2. 在產品層次結構中，工作產品的向上路徑及向下路徑的識別以及[3]
  3. 在軟體開發產品中，有關每一個元件存在原因的說明
  4. 在二個或是多個邏輯實體中（例如需求、系統元件、驗證、任務）建立可以識別的關聯性。

若要定義需求可追蹤性，可以定義為：「描述以及追蹤一個需求的生命週期的能力，追蹤可能會往前追蹤，也可能會往後追蹤（追蹤其來源、其開發過程及對應規格、到最終的布署及使用，以及過程中每一個週期中相關的細化及迭代。）」[4][5]。在需求工程的領域中，可追蹤性是明瞭高階的需求（目標、目的、期望、需求）如何轉換為低階需求的過程，主要關注的是不同資訊層（或開發產物）之間的滿足關係[6]。不過，可追蹤性也可以用文件建立任何種類開發產物之間的關係，例如需求、規格敘述、設法、測試、型號以及所開發的元件[7]。例如在進行展示時，常常需要找到驗證的關係，來確認某一個需求可以由特定的測試所驗證。

在開發安全關鍵系統時，特別會強調可追蹤性，因此在許多安全標準中也會提到，例如DO-178C（英語：DO178C）、ISO 26262及IEC 61508。這些指引中的常見要求是關鍵需求必須經過確認，且驗證過程要可以通過可追蹤性來展現[8]。

需求之前及需求之後的可追蹤性

  • 需求前的可追蹤性（Pre-requirements traceability）[4]：需求會來自不同的來源，例如訂購產品的商務人士、行銷經理或是使用者。這些人會有對產品不同的需求。利用需求可追蹤性，在進行需求引發（英語：requirements elicitation）時可以將要實施的機能追溯到提出需求的人員或是團體。在開發過程中要決定各需求優先順序，判斷各需求對特定用戶的價值時，即可配合需求前的可追蹤性進行。若在產品布署後，若要確認在使用者研究中為何找到了一些未使用的機能，也可以用到需求前的可追蹤性。
  • 需求後的可追蹤性（Post-requirements traceability）[4]：需求本身需要追蹤，也需要追蹤所有因為需求產生，與其有關的開發產物，例如型號、分析結果、測試用例、測試結果以及所有相關的文件。甚至也要追蹤和需求有關的人或是團體。需求需要實現為設計產物、實作，而且最後確認通過。開發後期產生的開發產物也要可以追溯到其原始的需求。這多半會透過需求追蹤矩陣來進行。

要將需求可追蹤性連結到設計、實現及驗證的開發產物可能會相關困難[9]。例如在實現軟體需求時,需求可能是在需求管理軟體中，而設計產物可能是在MagicDraw（英語：MagicDraw）、Mathworks Simulink、Rational Rhapsody（英語：Rational Rhapsody）或Microsoft Visio等工具軟體中。而最後實現的開發產物可能是以原始碼的形式出現。驗證產物可能是由內部測試或是型式驗證工具（像是LDRA Testbed suite（英語：LDRA Testbed）、Parasoft DTP（英語：Parasoft DTP）或SCADE）所產生的結果。

在維護動態系統的可追蹤性時，存儲庫或工具堆棧的整合工具也可能是一大挑戰。

追蹤資訊的用途

可追蹤性的資訊，特別是對應開發工具各階段產物的需求後的可追蹤性，有以下的好處[10][11]：

  • 變更影響分析：若需求改變，可以透過追蹤資訊找到有關及受影響的產物。因此可以確認各產物，若有需要時也可進行調整。可以減少未確認相關產物的風險。
  • 覆蓋率分析：可追蹤性可以確保需求中沒有遺漏的項目，特別是在驗證安全相關產品時，需要確認所有的需求都已實現。
  • 專案狀態分析：可以用需求可追蹤性來追蹤專案的狀態。分析可追蹤性資料可以看到需求的完成情形。若需求沒有對應的連結，或是沒有連結到完整的工具鏈（例如需求有對應的實現，但沒有測試結果），代表還有工作需要進行。缺少的連結表示少了某一個產物，需要實現該產物。
  • 複用產品的組件：可以針對需求以及相關產物加以結構，形成一個模組。之後可以將模組用在不同的產品中。
  • 持續性的關係：專案或是產品的知識多半只存在特定人員們的大腦中。利用需求可追蹤性可以看出不同開發產物之間的關係，可以保留部份知識。就算有人員異動，仍可以保留這些知識。
  • 測試最佳化：在連結需求、原始碼、測試用例及測試結果後，若測試失敗，可以識別可能是哪一段程式影響的。甚至可以找到多餘的測試，進而刪減該測試。

有些文件會進一步討論需求可追蹤性可以支援的開發工作，以及彼此之間的關係[12]。

對專案的影響

許多研究指出了需求可追蹤性的效果，不過也提到確認相關資訊的困難度：

  • 需求可追蹤性可以加速開發工具，而且可以提昇成果：有一個針對71個群體進行的研究，其中有些在修改原始碼時有使用需求可追蹤性的資訊，有些沒有，結果可以看出可追蹤性的好處。配合可追蹤性的資訊，開發者完成任務的速度快了24%，而且正確性提昇了50%[13]。
  • 越完整的可追蹤性，越可以減少軟體中的錯誤：在一個針對24個中型及大型開源專案的分析中，發現可追蹤性的完整性和所開發軟體代碼的錯誤率之間有顯著的統計關係。軟體模組的可追蹤性越完整，所發現的軟體錯誤越少[14]。
  • 要實現符合規範的可追蹤性非常困難：2013年美國食品藥物管理局針對醫療器材軟體上市前測試的分析發現：在處方和歸檔的可追蹤性資訊之間有很大的差距[8]。若要實施符合規範的可追蹤性，最後往往會出現「大凍結」。會讓公司不再進行後續旳開發，因為重新認證需要花上大量的資源及心力[15]。

需求可追蹤性的視覺化

可追蹤性的目的之一是讓讓各產物之間的關係可以視覺化。當追蹤連結變多，複雜性變高時，就需要導入可追蹤性視覺化的技術。視覺化可以包括有關各產物的資訊（產物型態、元資料及屬性）以及連結（連結種結、元資料、連結強度）等[16]。

常用的需求可追蹤性視覺化資料包括有矩陣、圖、列表及超連結等。

  • 可追蹤性矩陣：類似表格的表示方式，將某一種類的產物（例如需求）放在欄，另一種類的產物（例如原始碼）放在列。兩者有若關連，表格的每一格都有標記，若沒有關連，則維持空白[16]。可追蹤性矩陣的好處是在產物不多時，，可以一眼看出兩類產物連結的概況。可追蹤性矩陣適用於管理任務[16]。不過在產業中，專案可能會包括上千個產物，若全部列出，表格會非常大，而且不容易閱讀[17]。
  • 可追蹤性圖（Traceability graph）：是以節點表示產物的表示方式。若二個產物之間有可追溯性，且二個產物的結點都存在的話，各節點之間就可以用邊連接。圖特別適合用在開發任務，可以探索性的瀏覽各個邊，其資訊比較容易理解[16]。通過瀏覽圖形，很容易找到遺漏的連結，可以視為後續要建立對應產物的提示。
  • 列表：列表可以列出一個進入點的可追蹤性連結。此進入點可以有關來源、目的產物及屬性的資訊。若需要針對許多不同的產物進行批量操作時，此方式特別適用。篩選器以及排機制有助於整理及顯示資訊。不過相較於上述的視覺化方式，列表比較不適合用在專案的管理、開發或是測試工作[16]。
  • 超連結：超連結可以連結二個產物，可以從來源產物跳到目標產物。此視覺化方式適用於需要有關產物細節資訊的情形，也允許在其原生環境內瀏覽相關產物[16]。只使用超連結的缺點是超連結在視覺上不夠緊湊，為了要追蹤連結的狀態，需要花許多的心力瀏覽各連結。

各視覺化的方式都有其限制，因此可以結合多種視覺化的方式，可以克服各方式的限制。

實現方式

人工建立可追蹤性

可以用人工或是簡易工具輔助（例如試算表或是Excel）的方式建立可追蹤性。此方式廣為使用，但作法非常的麻煩，容易出錯，而且會因為各開發工具的問題，而且要追蹤的產物很多，可追蹤性資訊的品質會比較差[18]。

工具輔助的可追蹤性

工具輔助的可追蹤性需要散佈在開發工具鏈上的開發資訊可以同質化，並且可以聚合。以下是一些可以達成此條件的作法：

  • 透過應用程式生命週期管理（ALM）工具，將工具環境同質化：ALM工具可以包含系統的整個生命週期，以全面的作法來管理開發過程中產生的所有產物。像是在分散式的環境中，已成功的使用以Volere需求模版實現的問題追蹤器。此作法的好處是配合ALM工具的專門軟體，產物的同質化會讓管理以及分析變簡單。缺點是要實現整個ALM工具鏈。若引入了，很很難更換工具鏈中的特定軟體。
  • 透過代理需求將資料同質化：專案管理（RM）工具可以儲存、組織及管理系統規格內的所有需求，一般會整理成規格樹（英語：specification tree），將每一個需求連結到較高級規格的父需求]。有支援可追蹤性的專案管理商業軟體有3SL Cradle、CASE Spec、IRise（英語：IRise）、GatherSpace（英語：GatherSpace (company)）、IBM Rational RequisitePro（英語：RequisitePro）、IBM DOORS（英語：IBM Rational DOORS）、Visure Requirements[19]、CaliberRM（英語：CaliberRM）、QFDCapture（英語：QFDCapture）及Matrix Requirements Medical（英語：Matrix Requirements Medical）。免費工具有FreeMind及Concordion（英語：Concordion）[20]。依照記錄追蹤資訊的典型分析功能有完整性檢查（也就是檢查所有系統層級的需求都有對應到設備層級的需求，可能有修改或是沒有修改）、評估各一層對於需求的調整、並且顯示驗證的狀態。為了確保需求之前產物的可追蹤性，專案管理工具多半可以將需求之前的產物匯出為代理需求（surrogate requirements），可以用工具的需求追蹤方式來追蹤。例如，Simulink模型的元件可以匯入到Rational DOORS的代理模組，和需求關聯。此作法的缺點是會針對不同的產物有不同的轉接器或是轉換器，需要有一均的版本以及資料格式。若是使用應用程式生命週期管理（ALM）工具，會自動處理一致性的問題。
  • 用專用追蹤工具達到資料的均質化：專用追蹤工具的基本定義包括以下三個基本步驟：
    • 定義資料模型，也就是可追蹤性資料模型（Traceability Information Model、TIM）[21]。此模型可以標示產物的種類（例如風險承擔者的需求、軟體需求、整合測試、系統模型元件）以及連結的方式。
    • 所有工具中相關資料的定義映射（definition of mappings），工具是工具鏈中的一部份，以及這些資料如何映射到可追蹤性資料模型。
    • 矩陣以及分析函數是由TIM所定義，不是由特定工具上的資料所定義。
此作法結合了上述方式的好處：以全面的作法來包涵所有的工具以及是產物，將資料同質化，避免因為過時的代理造成資料的不一致。流行的工具有開源的Eclipse Capra[22]、商品化的工具Reqtify[23]及YAKINDU Traceability[24]。缺點是需要延伸工具鏈，包括另一個可追蹤性的工具。

相關條目

參考資料

  1. ^ Systems and software engineering – Vocabulary. 2010-12-01: 1–418. ISBN 978-0-7381-6205-8. doi:10.1109/IEEESTD.2010.5733835.  |journal=被忽略 (幫助)
  2. ^ IEEE Guide for Developing System Requirements Specifications. 1998-12-01: 1–36. ISBN 978-0-7381-1723-2. doi:10.1109/IEEESTD.1998.88826.  |journal=被忽略 (幫助)
  3. ^ IEEE Guide for Information Technology - System Definition - Concept of Operations (ConOps) Document. 1998-12-01: 1–24. ISBN 978-0-7381-1407-1. doi:10.1109/IEEESTD.1998.89424.  |journal=被忽略 (幫助)
  4. ^ 4.0 4.1 4.2 Gotel, O.C.Z.; Finkelstein, C.W. An analysis of the requirements traceability problem. April 1994: 94–101. CiteSeerX 10.1.1.201.7137  . ISBN 978-0-8186-5480-0. doi:10.1109/icre.1994.292398 （美國英語）.  |journal=被忽略 (幫助)
  5. ^ Gotel, Orlena; Cleland-Huang, Jane; Hayes, Jane Huffman; Zisman, Andrea; Egyed, Alexander; Grünbacher, Paul; Dekhtyar, Alex; Antoniol, Giuliano; Maletic, Jonathan. Cleland-Huang, Jane; Gotel, Orlena; Zisman, Andrea , 編. Software and Systems Traceability . Springer London. 2012-01-01: 3–22. ISBN 9781447122388. doi:10.1007/978-1-4471-2239-5_1 （英語）. 
  6. ^ Hull, Elizabeth; Ken Jackson; Jeremy Dick. Requirements Engineering (Second Edition). Springer. 2005: 9–13, 131–151. ISBN 978-1-85233-879-4. 
  7. ^ Pinheiro F.A.C. and Goguen J.A., "An object-oriented tool for tracing requirements", IEEE Software 1996, 13(2), pp. 52-64
  8. ^ 8.0 8.1 Mäder, P.; Jones, P. L.; Zhang, Y.; Cleland-Huang, J. Strategic Traceability for Safety-Critical Projects. IEEE Software. 2013-05-01, 30 (3): 58–66. ISSN 0740-7459. doi:10.1109/MS.2013.60. 
  9. ^ Li, Yin; Juan Li; Ye Yang; Mingshu Li. Requirement-Centric Traceability for Change Impact Analysis:A Case Study. Springer Berlin/Heidelberg. 2008: 100–111. ISBN 978-3-540-79587-2. 
  10. ^ Wiegers, Karl. Requirements Traceability: Links in the Requirements Chain, Part 1. jama. 2013 [2016-12-14]. （原始內容存檔於2018-06-13）. 
  11. ^ Wiegers, K.; Beatty, J. Software Requirements. Microsoft Press. 2013. 
  12. ^ Bouillon, Elke; Mäder, Patrick; Philippow, Ilka. Doerr, Joerg; Opdahl, Andreas L. , 編. Requirements Engineering: Foundation for Software Quality . Lecture Notes in Computer Science. Springer Berlin Heidelberg. 2013-04-08: 158–173. CiteSeerX 10.1.1.659.3972  . ISBN 9783642374210. doi:10.1007/978-3-642-37422-7_12 （英語）. 
  13. ^ Mäder, Patrick; Egyed, Alexander. Do developers benefit from requirements traceability when evolving and maintaining a software system?. Empirical Software Engineering. 2015-04-01, 20 (2): 413–441. ISSN 1382-3256. doi:10.1007/s10664-014-9314-z （英語）. 
  14. ^ Rempel, Patrick; Mäder, Patrick. Preventing Defects: The Impact of Requirements Traceability Completeness on Software Quality. IEEE Transactions on Software Engineering. 2016-01-01, PP (99): 777–797. ISSN 0098-5589. doi:10.1109/TSE.2016.2622264. 
  15. ^ open-DO | Toward a cooperative and open framework for the development of certifiable software. www.open-do.org. [2017-04-15]. （原始內容存檔於2021-02-25） （美國英語）. 
  16. ^ 16.0 16.1 16.2 16.3 16.4 16.5 Li, Y.; Maalej, W. Which Traceability Visualization Is Suitable in This Context? A Comparative Study.. Springer. 2012: 194–210. 
  17. ^ Lerche, Felix. 5 REASONS WHY A REQUIREMENTS TRACEABILITY MATRIX IS NOT ENOUGH. 2019 [2020-05-27]. （原始內容存檔於2021-03-04）. 
  18. ^ Kannenberg, Andrew; Saiedian, Hossein. Why Software Requirements Traceability Remains a Challenge (PDF). CrossTalk Magazine - the Journal of Defense Software Engineering. 2009 [2020-05-27]. （原始內容 (PDF)存檔於2019-05-28）. 
  19. ^ Visure Requirements. [2020-05-27]. （原始內容存檔於2021-05-25）. 
  20. ^ Laplante, Phillip A. Requirements Engineering for Software and Systems. CRC Press. 2009. 
  21. ^ Traceability Information Model. [2020-05-27]. （原始內容存檔於2019-04-03）. 
  22. ^ Eclipse Capra. [2020-05-27]. （原始內容存檔於2020-10-26）. 
  23. ^ Reqtify (german page). [2020-05-27]. （原始內容存檔於2021-03-04）. 
  24. ^ YAKINDU Traceability. [2020-05-27]. （原始內容存檔於2021-01-23）. 
取自「https://zh.wikipedia.org/w/index.php?title=需求可追蹤性&oldid=81824395」