跳转到内容

需求可追蹤性：修订间差异

维基百科，自由的百科全书
以互动方式浏览历史
←上一版本下一版本→
删除的内容 添加的内容
可视化wikitext
Wolfch（留言 | 贡献）
延伸确认用户
161,433次编辑
Wolfch（留言 | 贡献）
延伸确认用户
161,433次编辑
第36行： 第36行：
* 越完整的可追蹤性，越可以減少軟體中的錯誤：在一個針對24個中型及大型開源專案的分析中，發現可追蹤性的完整性和所開發軟體代碼的錯誤率之間有顯著的統計關係。軟體模組的可追蹤性越完整，所發現的軟體錯誤越少<ref>{{Cite journal|last=Rempel|first=Patrick|last2=Mäder|first2=Patrick|date=2016-01-01|title=Preventing Defects: The Impact of Requirements Traceability Completeness on Software Quality|url=https://www.researchgate.net/publication/309523115|journal=IEEE Transactions on Software Engineering|volume=PP|issue=99|pages=777–797|doi=10.1109/TSE.2016.2622264|issn=0098-5589}}</ref>。
* 越完整的可追蹤性，越可以減少軟體中的錯誤：在一個針對24個中型及大型開源專案的分析中，發現可追蹤性的完整性和所開發軟體代碼的錯誤率之間有顯著的統計關係。軟體模組的可追蹤性越完整，所發現的軟體錯誤越少<ref>{{Cite journal|last=Rempel|first=Patrick|last2=Mäder|first2=Patrick|date=2016-01-01|title=Preventing Defects: The Impact of Requirements Traceability Completeness on Software Quality|url=https://www.researchgate.net/publication/309523115|journal=IEEE Transactions on Software Engineering|volume=PP|issue=99|pages=777–797|doi=10.1109/TSE.2016.2622264|issn=0098-5589}}</ref>。
* 要實現符合規範的可追蹤性非常困難：2013年美國食品藥物管理局針對醫療器材軟體上市前測試的分析發現：在處方和歸檔的可追蹤性資訊之間有很大的差距<ref name=":2" />。若要實施符合規範的可追蹤性，最後往往會出現「大凍結」。會讓公司不再進行後續旳開發，因為重新認證需要花上大量的資源及心力<ref>{{Cite web|url=http://www.open-do.org|title=open-DO {{!}} Toward a cooperative and open framework for the development of certifiable software|website=www.open-do.org|language=en-US|access-date=2017-04-15}}</ref>。
* 要實現符合規範的可追蹤性非常困難：2013年美國食品藥物管理局針對醫療器材軟體上市前測試的分析發現：在處方和歸檔的可追蹤性資訊之間有很大的差距<ref name=":2" />。若要實施符合規範的可追蹤性，最後往往會出現「大凍結」。會讓公司不再進行後續旳開發，因為重新認證需要花上大量的資源及心力<ref>{{Cite web|url=http://www.open-do.org|title=open-DO {{!}} Toward a cooperative and open framework for the development of certifiable software|website=www.open-do.org|language=en-US|access-date=2017-04-15}}</ref>。

== 需求可追蹤性的視覺化 ==
可追蹤性的目的之一是讓讓各產物之間的關係可以視覺化。當追蹤連結變多，複雜性變高時，就需要導入可追蹤性視覺化的技術。視覺化可以包括有關各產物的資訊（產物型態、元資料及屬性）以及連結（連結種結、元資料、連結強度）等<ref name=":0">{{Cite book|title=Which Traceability Visualization Is Suitable in This Context? A Comparative Study.|last=Li|first=Y.|last2=Maalej|first2=W.|publisher=Springer|year=2012|isbn=|location=|pages=194–210|quote=|via=}}</ref>。

常用的需求可追蹤性視覺化資料包括有矩陣、圖、列表及超連結等。
* {{le|可追蹤性矩陣|Traceability matrix}}：類似表格的表示方式，將某一種類的產物（例如需求）放在欄，另一種類的產物（例如原始碼）放在列。兩者有若關連，表格的每一格都有標記，若沒有關連，則維持空白<ref name=":0" />。可追蹤性矩陣的好處是在產物不多時，，可以一眼看出兩類產物連結的概況。可追蹤性矩陣適用於管理任務<ref name=":0" />。不過在產業中，專案可能會包括上千個產物，若全部列出，表格會非常大，而且不容易閱讀<ref>{{cite web|url=https://blogs.itemis.com/en/5-reasons-why-a-requirements-traceability-matrix-is-not-enough |title=5 REASONS WHY A REQUIREMENTS TRACEABILITY MATRIX IS NOT ENOUGH|last=Lerche |first=Felix |date=2019}}</ref>。
* 可追蹤性圖（Traceability graph）：是以節點表示產物的表示方式。若二個產物之間有可追溯性，且二個產物的結點都存在的話，各節點之間就可以用邊連接。圖特別適合用在開發任務，可以探索性的瀏覽各個邊，其資訊比較容易理解<ref name=":0" />。通過瀏覽圖形，很容易找到遺漏的連結，可以視為後續要建立對應產物的提示。
* 列表：列表可以列出一個進入點的可追蹤性連結。此進入點可以有關來源、目的產物及屬性的資訊。若需要針對許多不同的產物進行批量操作時，此方式特別適用。篩選器以及排機制有助於整理及顯示資訊。不過相較於上述的視覺化方式，列表比較不適合用在專案的管理、開發或是測試工作<ref name=":0" />。
* 超連結：超連結可以連結二個產物，可以從來源產物跳到目標產物。此視覺化方式適用於需要有關產物細節資訊的情形，也允許在其原生環境內瀏覽相關產物<ref name=":0" />。只使用超連結的缺點是超連結在視覺上不夠緊湊，為了要追蹤連結的狀態，需要花許多的心力瀏覽各連結。

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


== 相關條目 ==
== 相關條目 ==

2020年5月27日 (三) 08:31的版本

需求可追蹤性（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]。只使用超連結的缺點是超連結在視覺上不夠緊湊，為了要追蹤連結的狀態，需要花許多的心力瀏覽各連結。

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

相關條目

參考資料

  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]. 
  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] （美国英语）. 
  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. 
检索自“https://zh.wikipedia.org/w/index.php?title=需求可追蹤性&oldid=59835842”