fbpx
维基百科

需求可追蹤性

四月 01, 2023

需求可追蹤性（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. . 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. ^ . 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. . 2019 [2020-05-27]. （原始内容存档于2021-03-04）. 
  18. ^ Kannenberg, Andrew; Saiedian, Hossein. (PDF). CrossTalk Magazine - the Journal of Defense Software Engineering. 2009 [2020-05-27]. （原始内容 (PDF)存档于2019-05-28）. 
  19. ^ . [2020-05-27]. （原始内容存档于2021-05-25）. 
  20. ^ Laplante, Phillip A. Requirements Engineering for Software and Systems. CRC Press. 2009. 
  21. ^ . [2020-05-27]. （原始内容存档于2019-04-03）. 
  22. ^ . [2020-05-27]. （原始内容存档于2020-10-26）. 
  23. ^ . [2020-05-27]. （原始内容存档于2021-03-04）. 
  24. ^ . [2020-05-27]. （原始内容存档于2021-01-23）. 

四月 01, 2023
需求可追蹤性, requirements, traceability, 也稱為需求可追溯性, 是需求管理中的一部份, 和软件开发及系统工程有關, ieee, systems, software, engineering, vocabulary有定義通用的可追溯性, traceability, 定義如下, 在開發過程中二個或是多個產品相關性的程度, 特別是兩者之間有先後關係或主從關係的產品, 在產品層次結構中, 工作產品的向上路徑及向下路徑的識別以及, 在軟體開發產品中, 有關每一個元件存在原因的說明, 在二個或是多. 需求可追蹤性 Requirements traceability 也稱為需求可追溯性 是需求管理中的一部份 和软件开发及系统工程有關 IEEE Systems and Software Engineering Vocabulary有定義通用的可追溯性 Traceability 1 定義如下 在開發過程中二個或是多個產品相關性的程度 特別是兩者之間有先後關係或主從關係的產品 2 在產品層次結構中 工作產品的向上路徑及向下路徑的識別以及 3 在軟體開發產品中 有關每一個元件存在原因的說明 在二個或是多個邏輯實體中 例如需求 系統元件 驗證 任務 建立可以識別的關聯性 若要定義需求可追蹤性 可以定義為 描述以及追蹤一個需求的生命週期的能力 追蹤可能會往前追蹤 也可能會往後追蹤 追蹤其來源 其開發過程及對應規格 到最終的布署及使用 以及過程中每一個週期中相關的細化及迭代 4 5 在需求工程的領域中 可追蹤性是明瞭高階的需求 目標 目的 期望 需求 如何轉換為低階需求的過程 主要關注的是不同資訊層 或開發產物 之間的滿足關係 6 不過 可追蹤性也可以用文件建立任何種類開發產物之間的關係 例如需求 規格敘述 設法 測試 型號以及所開發的元件 7 例如在進行展示時 常常需要找到驗證的關係 來確認某一個需求可以由特定的測試所驗證 在開發安全關鍵系統時 特別會強調可追蹤性 因此在許多安全標準中也會提到 例如DO 178C 英语 DO178C ISO 26262及IEC 61508 這些指引中的常見要求是關鍵需求必須經過確認 且驗證過程要可以通過可追蹤性來展現 8 目录 1 需求之前及需求之後的可追蹤性 2 追蹤資訊的用途 3 對專案的影響 4 需求可追蹤性的視覺化 5 實現方式 5 1 人工建立可追蹤性 5 2 工具輔助的可追蹤性 6 相關條目 7 參考資料需求之前及需求之後的可追蹤性 编辑需求前的可追蹤性 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 缺點是需要延伸工具鏈 包括另一個可追蹤性的工具 相關條目 编辑需求 產品開發 需求分析 需求管理參考資料 编辑 Systems and software engineering Vocabulary 2010 12 01 1 418 ISBN 978 0 7381 6205 8 doi 10 1109 IEEESTD 2010 5733835 journal 被忽略 帮助 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 被忽略 帮助 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 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 被忽略 帮助 Gotel Orlena Cleland Huang Jane Hayes Jane Huffman Zisman Andrea Egyed Alexander Grunbacher 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 英语 Hull Elizabeth Ken Jackson Jeremy Dick Requirements Engineering Second Edition Springer 2005 9 13 131 151 ISBN 978 1 85233 879 4 Pinheiro F A C and Goguen J A An object oriented tool for tracing requirements IEEE Software 1996 13 2 pp 52 64 8 0 8 1 Mader 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 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 Wiegers Karl Requirements Traceability Links in the Requirements Chain Part 1 jama 2013 2016 12 14 原始内容存档于2018 06 13 Wiegers K Beatty J Software Requirements Microsoft Press 2013 Bouillon Elke Mader 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 英语 Mader 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 英语 Rempel Patrick Mader 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 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 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 Lerche Felix 5 REASONS WHY A REQUIREMENTS TRACEABILITY MATRIX IS NOT ENOUGH 2019 2020 05 27 原始内容存档于2021 03 04 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 Visure Requirements 2020 05 27 原始内容存档于2021 05 25 Laplante Phillip A Requirements Engineering for Software and Systems CRC Press 2009 缺少或 url 为空 帮助 Traceability Information Model 2020 05 27 原始内容存档于2019 04 03 Eclipse Capra 2020 05 27 原始内容存档于2020 10 26 Reqtify german page 2020 05 27 原始内容存档于2021 03 04 YAKINDU Traceability 2020 05 27 原始内容存档于2021 01 23 取自 https zh wikipedia org w index php title 需求可追蹤性 amp oldid 73577491, 维基百科，wiki，书籍，书籍，图书馆，

文章

，阅读，下载，免费，免费下载，mp3，视频，mp4，3gp， jpg，jpeg，gif，png，图片，音乐，歌曲，电影，书籍，游戏，游戏。