[{"data":1,"prerenderedAt":49},["ShallowReactive",2],{"wiki-test-management-requirements-traceability-en":3},{"meta":4,"html":8,"headings":9,"words":48},{"title":5,"description":6,"published":7,"updated":7},"Requirements traceability and coverage","Requirements traceability: forward and backward links, the traceability matrix, requirements coverage and how to compute it, impact analysis of changes.","2026-11-03","\u003Cp>\u003Cstrong>Requirements traceability\u003C/strong> is the ability to follow a requirement from its source through design, implementation and tests to the results of testing, and back. Gotel and Finkelstein defined it in 1994 as the ability to describe and follow the life of a requirement in both a forwards and backwards direction. The vocabulary standard ISO/IEC/IEEE 24765 defines traceability in general as the degree to which a relationship can be established between two or more products of the development process.\u003C/p>\n\u003Cp>In testing, traceability means links between the test basis (requirements, \u003Cspan class=\"wiki-term\" tabindex=\"0\" data-wiki-term=\"user-story\">user stories\u003C/span>, risks) and testware (\u003Cspan class=\"wiki-term\" tabindex=\"0\" data-wiki-term=\"test-case\">test cases\u003C/span>, \u003Cspan class=\"wiki-term\" tabindex=\"0\" data-wiki-term=\"test-result\">test results\u003C/span>, \u003Cspan class=\"wiki-term\" tabindex=\"0\" data-wiki-term=\"defect\">defects\u003C/span>). The ISTQB Foundation Level syllabus (version 4.0.1, section 1.4.4) treats establishing and maintaining such traceability throughout the test process as a condition of effective test monitoring and control. Traceability is the basis of two figures that a \u003Cspan class=\"wiki-term\" tabindex=\"0\" data-wiki-term=\"test-management-system\">test management system\u003C/span> computes: requirements coverage and the set of tests affected by a change.\u003C/p>\n\u003Ch2 id=\"the-problem-traceability-solves\" class=\"wiki-heading\">The problem traceability solves\u003Cbutton type=\"button\" class=\"wiki-heading__anchor\" data-wiki-anchor=\"the-problem-traceability-solves\" aria-label=\"Copy link to section\" data-copied-label=\"Link to section copied\">\u003Csvg class=\"wiki-heading__icon\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M117.18,188.74a12,12,0,0,1,0,17l-5.12,5.12A58.26,58.26,0,0,1,70.6,228h0A58.62,58.62,0,0,1,29.14,127.92L63.89,93.17a58.64,58.64,0,0,1,98.56,28.11,12,12,0,1,1-23.37,5.44,34.65,34.65,0,0,0-58.22-16.58L46.11,144.89A34.62,34.62,0,0,0,70.57,204h0a34.41,34.41,0,0,0,24.49-10.14l5.11-5.12A12,12,0,0,1,117.18,188.74ZM226.83,45.17a58.65,58.65,0,0,0-82.93,0l-5.11,5.11a12,12,0,0,0,17,17l5.12-5.12a34.63,34.63,0,1,1,49,49L175.1,145.86A34.39,34.39,0,0,1,150.61,156h0a34.63,34.63,0,0,1-33.69-26.72,12,12,0,0,0-23.38,5.44A58.64,58.64,0,0,0,150.56,180h.05a58.28,58.28,0,0,0,41.47-17.17l34.75-34.75a58.62,58.62,0,0,0,0-82.91Z\"/>\u003C/svg>\u003Csvg class=\"wiki-heading__icon wiki-heading__icon--done\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M232.49,80.49l-128,128a12,12,0,0,1-17,0l-56-56a12,12,0,1,1,17-17L96,183,215.51,63.51a12,12,0,0,1,17,17Z\"/>\u003C/svg>\u003C/button>\u003C/h2>\n\u003Cp>A set of requirements and a set of test cases can exist side by side without any link between them. Each of them can be complete in itself, and the following questions still have no answer:\u003C/p>\n\u003Cul>\n\u003Cli>which requirements have no test at all;\u003C/li>\n\u003Cli>which requirements were checked in this release and with what result;\u003C/li>\n\u003Cli>which test cases have to be executed again when a requirement changes;\u003C/li>\n\u003Cli>why a test case exists and whether it is still needed;\u003C/li>\n\u003Cli>which requirements are affected by the open defects of a release.\u003C/li>\n\u003C/ul>\n\u003Cp>The ISTQB syllabus names the uses of traceability in testing: evaluating coverage, determining the impact of changes, supporting audits and IT governance, and making test progress and completion reports easier to understand, because they can show the status of the elements of the test basis: requirements that passed their tests, failed them or have tests pending.\u003C/p>\n\u003Ch2 id=\"directions-of-traceability\" class=\"wiki-heading\">Directions of traceability\u003Cbutton type=\"button\" class=\"wiki-heading__anchor\" data-wiki-anchor=\"directions-of-traceability\" aria-label=\"Copy link to section\" data-copied-label=\"Link to section copied\">\u003Csvg class=\"wiki-heading__icon\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M117.18,188.74a12,12,0,0,1,0,17l-5.12,5.12A58.26,58.26,0,0,1,70.6,228h0A58.62,58.62,0,0,1,29.14,127.92L63.89,93.17a58.64,58.64,0,0,1,98.56,28.11,12,12,0,1,1-23.37,5.44,34.65,34.65,0,0,0-58.22-16.58L46.11,144.89A34.62,34.62,0,0,0,70.57,204h0a34.41,34.41,0,0,0,24.49-10.14l5.11-5.12A12,12,0,0,1,117.18,188.74ZM226.83,45.17a58.65,58.65,0,0,0-82.93,0l-5.11,5.11a12,12,0,0,0,17,17l5.12-5.12a34.63,34.63,0,1,1,49,49L175.1,145.86A34.39,34.39,0,0,1,150.61,156h0a34.63,34.63,0,0,1-33.69-26.72,12,12,0,0,0-23.38,5.44A58.64,58.64,0,0,0,150.56,180h.05a58.28,58.28,0,0,0,41.47-17.17l34.75-34.75a58.62,58.62,0,0,0,0-82.91Z\"/>\u003C/svg>\u003Csvg class=\"wiki-heading__icon wiki-heading__icon--done\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M232.49,80.49l-128,128a12,12,0,0,1-17,0l-56-56a12,12,0,1,1,17-17L96,183,215.51,63.51a12,12,0,0,1,17,17Z\"/>\u003C/svg>\u003C/button>\u003C/h2>\n\u003Cp>Traceability has two directions.\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>Forward traceability\u003C/strong> goes from a requirement to the work products derived from it: design, code, test cases, test results. It answers the question "is this requirement implemented and tested?".\u003C/li>\n\u003Cli>\u003Cstrong>Backward traceability\u003C/strong> goes from a work product back to the requirement it comes from. It answers the question "why does this test case, this piece of code exist?".\u003C/li>\n\u003C/ul>\n\u003Cp>When links can be followed in both directions, traceability is called \u003Cstrong>bidirectional\u003C/strong>. In a test management system a link between a requirement and a test case is usually one record, and it is read in both directions.\u003C/p>\n\u003Cp>Gotel and Finkelstein also separated traceability by stage. \u003Cstrong>Pre-requirements specification traceability\u003C/strong> links a requirement with its origins: the people, documents and decisions it comes from. \u003Cstrong>Post-requirements specification traceability\u003C/strong> links a requirement with what follows from it: design, implementation, tests. Their study of more than 100 practitioners found that most problems attributed to poor traceability came from the first kind. Test management deals mostly with the second.\u003C/p>\n\u003Ch2 id=\"chain-of-links\" class=\"wiki-heading\">Chain of links\u003Cbutton type=\"button\" class=\"wiki-heading__anchor\" data-wiki-anchor=\"chain-of-links\" aria-label=\"Copy link to section\" data-copied-label=\"Link to section copied\">\u003Csvg class=\"wiki-heading__icon\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M117.18,188.74a12,12,0,0,1,0,17l-5.12,5.12A58.26,58.26,0,0,1,70.6,228h0A58.62,58.62,0,0,1,29.14,127.92L63.89,93.17a58.64,58.64,0,0,1,98.56,28.11,12,12,0,1,1-23.37,5.44,34.65,34.65,0,0,0-58.22-16.58L46.11,144.89A34.62,34.62,0,0,0,70.57,204h0a34.41,34.41,0,0,0,24.49-10.14l5.11-5.12A12,12,0,0,1,117.18,188.74ZM226.83,45.17a58.65,58.65,0,0,0-82.93,0l-5.11,5.11a12,12,0,0,0,17,17l5.12-5.12a34.63,34.63,0,1,1,49,49L175.1,145.86A34.39,34.39,0,0,1,150.61,156h0a34.63,34.63,0,0,1-33.69-26.72,12,12,0,0,0-23.38,5.44A58.64,58.64,0,0,0,150.56,180h.05a58.28,58.28,0,0,0,41.47-17.17l34.75-34.75a58.62,58.62,0,0,0,0-82.91Z\"/>\u003C/svg>\u003Csvg class=\"wiki-heading__icon wiki-heading__icon--done\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M232.49,80.49l-128,128a12,12,0,0,1-17,0l-56-56a12,12,0,1,1,17-17L96,183,215.51,63.51a12,12,0,0,1,17,17Z\"/>\u003C/svg>\u003C/button>\u003C/h2>\n\u003Cp>In testing, traceability forms a chain from the requirement to the defect:\u003C/p>\n\u003Cdiv class=\"wiki-code wiki-code--plain\">\u003Cpre>\u003Ccode>Requirement PAY-7 "An expired card is rejected"\n |\n +-- Test condition: payment with an expired saved card\n       |\n       +-- Test case TC-13 "Pay with an expired card"\n             |\n             +-- Result in run "Release 2.4.0, Safari": failed\n             |     |\n             |     +-- Defect BUG-310\n             |\n             +-- Result in run "Retest, 2.4.1, Safari": passed\u003C/code>\u003C/pre>\u003C/div>\n\u003Cp>Each link in the chain is created by a different activity. The link between a requirement and a \u003Cspan class=\"wiki-term\" tabindex=\"0\" data-wiki-term=\"test-condition\">test condition\u003C/span> appears during test analysis, the link between a test condition and a test case during test design, the link between a test case and a result during execution, the link between a result and a defect during defect reporting. The chain is complete only if every activity records its link.\u003C/p>\n\u003Cp>The granularity of the links matters. A link between a whole specification and a \u003Cspan class=\"wiki-term\" tabindex=\"0\" data-wiki-term=\"test-suite\">test suite\u003C/span> says nothing about coverage. The links are useful when they connect individual, identified items: a numbered requirement, a user story, an acceptance criterion, with individual test cases.\u003C/p>\n\u003Ch2 id=\"traceability-matrix\" class=\"wiki-heading\">Traceability matrix\u003Cbutton type=\"button\" class=\"wiki-heading__anchor\" data-wiki-anchor=\"traceability-matrix\" aria-label=\"Copy link to section\" data-copied-label=\"Link to section copied\">\u003Csvg class=\"wiki-heading__icon\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M117.18,188.74a12,12,0,0,1,0,17l-5.12,5.12A58.26,58.26,0,0,1,70.6,228h0A58.62,58.62,0,0,1,29.14,127.92L63.89,93.17a58.64,58.64,0,0,1,98.56,28.11,12,12,0,1,1-23.37,5.44,34.65,34.65,0,0,0-58.22-16.58L46.11,144.89A34.62,34.62,0,0,0,70.57,204h0a34.41,34.41,0,0,0,24.49-10.14l5.11-5.12A12,12,0,0,1,117.18,188.74ZM226.83,45.17a58.65,58.65,0,0,0-82.93,0l-5.11,5.11a12,12,0,0,0,17,17l5.12-5.12a34.63,34.63,0,1,1,49,49L175.1,145.86A34.39,34.39,0,0,1,150.61,156h0a34.63,34.63,0,0,1-33.69-26.72,12,12,0,0,0-23.38,5.44A58.64,58.64,0,0,0,150.56,180h.05a58.28,58.28,0,0,0,41.47-17.17l34.75-34.75a58.62,58.62,0,0,0,0-82.91Z\"/>\u003C/svg>\u003Csvg class=\"wiki-heading__icon wiki-heading__icon--done\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M232.49,80.49l-128,128a12,12,0,0,1-17,0l-56-56a12,12,0,1,1,17-17L96,183,215.51,63.51a12,12,0,0,1,17,17Z\"/>\u003C/svg>\u003C/button>\u003C/h2>\n\u003Cp>A \u003Cstrong>traceability matrix\u003C/strong> is a table that shows the links between two kinds of items, for example requirements and test cases. Rows are items of one kind, columns of the other, a mark at the intersection means a link. The example below covers five requirements and six test cases:\u003C/p>\n\u003Cdiv class=\"wiki-table wiki-table--cols-6\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Requirement\u003C/th>\n\u003Cth>TC-11\u003C/th>\n\u003Cth>TC-12\u003C/th>\n\u003Cth>TC-13\u003C/th>\n\u003Cth>TC-14\u003C/th>\n\u003Cth>TC-15\u003C/th>\n\u003Cth>TC-16\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>PAY-5 Pay with a new card\u003C/td>\n\u003Ctd>x\u003C/td>\n\u003Ctd>\u003C/td>\n\u003Ctd>\u003C/td>\n\u003Ctd>\u003C/td>\n\u003Ctd>\u003C/td>\n\u003Ctd>\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>PAY-6 Pay with a saved card\u003C/td>\n\u003Ctd>\u003C/td>\n\u003Ctd>x\u003C/td>\n\u003Ctd>\u003C/td>\n\u003Ctd>\u003C/td>\n\u003Ctd>\u003C/td>\n\u003Ctd>\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>PAY-7 Reject an expired card\u003C/td>\n\u003Ctd>\u003C/td>\n\u003Ctd>\u003C/td>\n\u003Ctd>x\u003C/td>\n\u003Ctd>x\u003C/td>\n\u003Ctd>\u003C/td>\n\u003Ctd>\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>PAY-8 Refund a payment\u003C/td>\n\u003Ctd>\u003C/td>\n\u003Ctd>\u003C/td>\n\u003Ctd>\u003C/td>\n\u003Ctd>\u003C/td>\n\u003Ctd>\u003C/td>\n\u003Ctd>\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>PAY-9 Receipt by email\u003C/td>\n\u003Ctd>\u003C/td>\n\u003Ctd>x\u003C/td>\n\u003Ctd>\u003C/td>\n\u003Ctd>\u003C/td>\n\u003Ctd>x\u003C/td>\n\u003Ctd>\u003C/td>\n\u003C/tr>\n\u003C/tbody>\n\u003C/table>\u003C/div>\n\u003Cp>Two kinds of gaps can be read from the matrix directly:\u003C/p>\n\u003Cul>\n\u003Cli>a row without marks is a \u003Cstrong>requirement without tests\u003C/strong>: PAY-8 is not covered;\u003C/li>\n\u003Cli>a column without marks is a \u003Cstrong>test case without a requirement\u003C/strong>: TC-16 is not linked to any of the listed requirements. It can check a requirement that is missing from the list, or it can be an obsolete test.\u003C/li>\n\u003C/ul>\n\u003Cp>A test management system stores the links, not the matrix. The matrix is one of the views computed from the links, together with lists of uncovered requirements, orphan test cases and the status of each requirement in a given run.\u003C/p>\n\u003Ch3 id=\"many-to-many-links\" class=\"wiki-heading\">Many-to-many links\u003Cbutton type=\"button\" class=\"wiki-heading__anchor\" data-wiki-anchor=\"many-to-many-links\" aria-label=\"Copy link to section\" data-copied-label=\"Link to section copied\">\u003Csvg class=\"wiki-heading__icon\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M117.18,188.74a12,12,0,0,1,0,17l-5.12,5.12A58.26,58.26,0,0,1,70.6,228h0A58.62,58.62,0,0,1,29.14,127.92L63.89,93.17a58.64,58.64,0,0,1,98.56,28.11,12,12,0,1,1-23.37,5.44,34.65,34.65,0,0,0-58.22-16.58L46.11,144.89A34.62,34.62,0,0,0,70.57,204h0a34.41,34.41,0,0,0,24.49-10.14l5.11-5.12A12,12,0,0,1,117.18,188.74ZM226.83,45.17a58.65,58.65,0,0,0-82.93,0l-5.11,5.11a12,12,0,0,0,17,17l5.12-5.12a34.63,34.63,0,1,1,49,49L175.1,145.86A34.39,34.39,0,0,1,150.61,156h0a34.63,34.63,0,0,1-33.69-26.72,12,12,0,0,0-23.38,5.44A58.64,58.64,0,0,0,150.56,180h.05a58.28,58.28,0,0,0,41.47-17.17l34.75-34.75a58.62,58.62,0,0,0,0-82.91Z\"/>\u003C/svg>\u003Csvg class=\"wiki-heading__icon wiki-heading__icon--done\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M232.49,80.49l-128,128a12,12,0,0,1-17,0l-56-56a12,12,0,1,1,17-17L96,183,215.51,63.51a12,12,0,0,1,17,17Z\"/>\u003C/svg>\u003C/button>\u003C/h3>\n\u003Cp>Links between requirements and test cases are many-to-many. A requirement is usually checked by several test cases: PAY-7 has TC-13 for the rejection itself and TC-14 for the message shown to the user. A test case can check several requirements: TC-12 pays with a saved card and also checks that the receipt arrives by email, so it is linked to PAY-6 and PAY-9.\u003C/p>\n\u003Cp>This affects how the status of a requirement in a run is derived from the results of its test cases. A common rule is:\u003C/p>\n\u003Cul>\n\u003Cli>the requirement \u003Cstrong>failed\u003C/strong> if at least one of its linked test cases failed;\u003C/li>\n\u003Cli>the requirement \u003Cstrong>passed\u003C/strong> if all of its linked test cases were executed and passed;\u003C/li>\n\u003Cli>otherwise the requirement is \u003Cstrong>not fully tested\u003C/strong>: some of its test cases are blocked, skipped or not executed yet.\u003C/li>\n\u003C/ul>\n\u003Cp>Under this rule a failure of TC-12 marks two requirements as failed at once. A report on requirements and a report on test cases therefore give different numbers for the same run, and both are correct.\u003C/p>\n\u003Ch2 id=\"requirements-coverage\" class=\"wiki-heading\">Requirements coverage\u003Cbutton type=\"button\" class=\"wiki-heading__anchor\" data-wiki-anchor=\"requirements-coverage\" aria-label=\"Copy link to section\" data-copied-label=\"Link to section copied\">\u003Csvg class=\"wiki-heading__icon\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M117.18,188.74a12,12,0,0,1,0,17l-5.12,5.12A58.26,58.26,0,0,1,70.6,228h0A58.62,58.62,0,0,1,29.14,127.92L63.89,93.17a58.64,58.64,0,0,1,98.56,28.11,12,12,0,1,1-23.37,5.44,34.65,34.65,0,0,0-58.22-16.58L46.11,144.89A34.62,34.62,0,0,0,70.57,204h0a34.41,34.41,0,0,0,24.49-10.14l5.11-5.12A12,12,0,0,1,117.18,188.74ZM226.83,45.17a58.65,58.65,0,0,0-82.93,0l-5.11,5.11a12,12,0,0,0,17,17l5.12-5.12a34.63,34.63,0,1,1,49,49L175.1,145.86A34.39,34.39,0,0,1,150.61,156h0a34.63,34.63,0,0,1-33.69-26.72,12,12,0,0,0-23.38,5.44A58.64,58.64,0,0,0,150.56,180h.05a58.28,58.28,0,0,0,41.47-17.17l34.75-34.75a58.62,58.62,0,0,0,0-82.91Z\"/>\u003C/svg>\u003Csvg class=\"wiki-heading__icon wiki-heading__icon--done\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M232.49,80.49l-128,128a12,12,0,0,1-17,0l-56-56a12,12,0,1,1,17-17L96,183,215.51,63.51a12,12,0,0,1,17,17Z\"/>\u003C/svg>\u003C/button>\u003C/h2>\n\u003Cp>\u003Cstrong>Requirements coverage\u003C/strong> is the share of requirements that are covered by tests. In general terms, the ISTQB glossary defines coverage as the degree to which specified coverage items are exercised by a test suite, expressed as a percentage. For requirements coverage, the coverage items are the requirements.\u003C/p>\n\u003Cp>The figure depends on what "covered" means, and there are three common variants:\u003C/p>\n\u003Cdiv class=\"wiki-table wiki-table--cols-3\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Variant\u003C/th>\n\u003Cth>A requirement is covered when\u003C/th>\n\u003Cth>Question it answers\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>Linked\u003C/td>\n\u003Ctd>It has at least one linked test case\u003C/td>\n\u003Ctd>Is there a test for it at all?\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Executed\u003C/td>\n\u003Ctd>At least one linked test case has been executed in the run\u003C/td>\n\u003Ctd>Has it been checked on this build?\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Passed\u003C/td>\n\u003Ctd>All linked test cases executed in the run have passed\u003C/td>\n\u003Ctd>Does it work on this build?\u003C/td>\n\u003C/tr>\n\u003C/tbody>\n\u003C/table>\u003C/div>\n\u003Cp>For the matrix above and a run in which TC-11, TC-12, TC-13 and TC-15 passed and TC-14 failed:\u003C/p>\n\u003Cul>\n\u003Cli>linked coverage: 4 of 5 requirements have a test case (PAY-8 has none), 80 percent;\u003C/li>\n\u003Cli>executed coverage: the same 4 requirements have an executed test case, 80 percent;\u003C/li>\n\u003Cli>passed coverage: PAY-5, PAY-6 and PAY-9 have all their test cases passed, PAY-7 has a failed one, so 3 of 5, 60 percent.\u003C/li>\n\u003C/ul>\n\u003Cp>A report states which variant it uses.\u003C/p>\n\u003Ch3 id=\"limits-of-requirements-coverage\" class=\"wiki-heading\">Limits of requirements coverage\u003Cbutton type=\"button\" class=\"wiki-heading__anchor\" data-wiki-anchor=\"limits-of-requirements-coverage\" aria-label=\"Copy link to section\" data-copied-label=\"Link to section copied\">\u003Csvg class=\"wiki-heading__icon\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M117.18,188.74a12,12,0,0,1,0,17l-5.12,5.12A58.26,58.26,0,0,1,70.6,228h0A58.62,58.62,0,0,1,29.14,127.92L63.89,93.17a58.64,58.64,0,0,1,98.56,28.11,12,12,0,1,1-23.37,5.44,34.65,34.65,0,0,0-58.22-16.58L46.11,144.89A34.62,34.62,0,0,0,70.57,204h0a34.41,34.41,0,0,0,24.49-10.14l5.11-5.12A12,12,0,0,1,117.18,188.74ZM226.83,45.17a58.65,58.65,0,0,0-82.93,0l-5.11,5.11a12,12,0,0,0,17,17l5.12-5.12a34.63,34.63,0,1,1,49,49L175.1,145.86A34.39,34.39,0,0,1,150.61,156h0a34.63,34.63,0,0,1-33.69-26.72,12,12,0,0,0-23.38,5.44A58.64,58.64,0,0,0,150.56,180h.05a58.28,58.28,0,0,0,41.47-17.17l34.75-34.75a58.62,58.62,0,0,0,0-82.91Z\"/>\u003C/svg>\u003Csvg class=\"wiki-heading__icon wiki-heading__icon--done\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M232.49,80.49l-128,128a12,12,0,0,1-17,0l-56-56a12,12,0,1,1,17-17L96,183,215.51,63.51a12,12,0,0,1,17,17Z\"/>\u003C/svg>\u003C/button>\u003C/h3>\n\u003Cp>Requirements coverage counts links, not the depth of checking. A requirement with one superficial test case and a requirement with twenty test cases covering all boundaries both count as covered. A coverage of 100 percent means that there is no requirement without tests. It does not mean that the requirements are tested enough.\u003C/p>\n\u003Cp>All requirements are counted with equal weight. In practice coverage is often reported separately for requirements of different priority or risk: "all High-risk requirements are covered and passed" carries more information than "92 percent of requirements are covered".\u003C/p>\n\u003Cp>The figure is only as complete as the list of requirements. Behavior that nobody wrote down as a requirement does not appear in it, however important it is. Techniques for deriving test cases that cover a requirement in depth are described in the series on test design, starting with \u003Ca href=\"/en/wiki/test-design/equivalence-partitioning-and-boundary-values\" class=\"wiki-link wiki-link--article\">Equivalence partitioning and boundary values\u003C/a>.\u003C/p>\n\u003Ch2 id=\"impact-analysis\" class=\"wiki-heading\">Impact analysis\u003Cbutton type=\"button\" class=\"wiki-heading__anchor\" data-wiki-anchor=\"impact-analysis\" aria-label=\"Copy link to section\" data-copied-label=\"Link to section copied\">\u003Csvg class=\"wiki-heading__icon\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M117.18,188.74a12,12,0,0,1,0,17l-5.12,5.12A58.26,58.26,0,0,1,70.6,228h0A58.62,58.62,0,0,1,29.14,127.92L63.89,93.17a58.64,58.64,0,0,1,98.56,28.11,12,12,0,1,1-23.37,5.44,34.65,34.65,0,0,0-58.22-16.58L46.11,144.89A34.62,34.62,0,0,0,70.57,204h0a34.41,34.41,0,0,0,24.49-10.14l5.11-5.12A12,12,0,0,1,117.18,188.74ZM226.83,45.17a58.65,58.65,0,0,0-82.93,0l-5.11,5.11a12,12,0,0,0,17,17l5.12-5.12a34.63,34.63,0,1,1,49,49L175.1,145.86A34.39,34.39,0,0,1,150.61,156h0a34.63,34.63,0,0,1-33.69-26.72,12,12,0,0,0-23.38,5.44A58.64,58.64,0,0,0,150.56,180h.05a58.28,58.28,0,0,0,41.47-17.17l34.75-34.75a58.62,58.62,0,0,0,0-82.91Z\"/>\u003C/svg>\u003Csvg class=\"wiki-heading__icon wiki-heading__icon--done\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M232.49,80.49l-128,128a12,12,0,0,1-17,0l-56-56a12,12,0,1,1,17-17L96,183,215.51,63.51a12,12,0,0,1,17,17Z\"/>\u003C/svg>\u003C/button>\u003C/h2>\n\u003Cp>\u003Cstrong>Impact analysis\u003C/strong> is, in the wording of the ISTQB glossary, the identification of all work products affected by a change, including an estimate of the resources needed to accomplish the change. In testing it answers the question: which tests have to be updated and executed again after this change?\u003C/p>\n\u003Cp>With traceability, impact analysis follows the links:\u003C/p>\n\u003Cdiv class=\"wiki-code wiki-code--plain\">\u003Cpre>\u003Ccode>Change: requirement PAY-7 now also rejects cards that expire this month\n |\n +-- Linked test cases: TC-13, TC-14       -> review and update\n +-- Their open defects: none\n +-- Related requirements: PAY-6           -> its test case TC-12 goes to regression\u003C/code>\u003C/pre>\u003C/div>\n\u003Cp>Without the links, the affected tests are found by searching the texts of test cases, which misses tests that describe the behavior in other words.\u003C/p>\n\u003Cp>The ISTQB syllabus connects impact analysis with \u003Cspan class=\"wiki-term\" tabindex=\"0\" data-wiki-term=\"regression-testing\">regression testing\u003C/span>: impact analysis helps to determine the extent of regression testing after a change. Links between requirements and tests give one source of impact. Another source is the code: tools that record which tests execute which parts of the code can select the tests affected by a change in the code. The two sources complement each other: the first captures changes of intent, the second changes of implementation. \u003Cspan class=\"wiki-term\" tabindex=\"0\" data-wiki-term=\"confirmation-testing\">Retesting\u003C/span> and regression testing in \u003Cspan class=\"wiki-term\" tabindex=\"0\" data-wiki-term=\"test-run\">test runs\u003C/span> are described in the article \u003Ca href=\"/en/wiki/test-management/test-run\" class=\"wiki-link wiki-link--article\">Test run\u003C/a>.\u003C/p>\n\u003Ch2 id=\"keeping-traceability-up-to-date\" class=\"wiki-heading\">Keeping traceability up to date\u003Cbutton type=\"button\" class=\"wiki-heading__anchor\" data-wiki-anchor=\"keeping-traceability-up-to-date\" aria-label=\"Copy link to section\" data-copied-label=\"Link to section copied\">\u003Csvg class=\"wiki-heading__icon\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M117.18,188.74a12,12,0,0,1,0,17l-5.12,5.12A58.26,58.26,0,0,1,70.6,228h0A58.62,58.62,0,0,1,29.14,127.92L63.89,93.17a58.64,58.64,0,0,1,98.56,28.11,12,12,0,1,1-23.37,5.44,34.65,34.65,0,0,0-58.22-16.58L46.11,144.89A34.62,34.62,0,0,0,70.57,204h0a34.41,34.41,0,0,0,24.49-10.14l5.11-5.12A12,12,0,0,1,117.18,188.74ZM226.83,45.17a58.65,58.65,0,0,0-82.93,0l-5.11,5.11a12,12,0,0,0,17,17l5.12-5.12a34.63,34.63,0,1,1,49,49L175.1,145.86A34.39,34.39,0,0,1,150.61,156h0a34.63,34.63,0,0,1-33.69-26.72,12,12,0,0,0-23.38,5.44A58.64,58.64,0,0,0,150.56,180h.05a58.28,58.28,0,0,0,41.47-17.17l34.75-34.75a58.62,58.62,0,0,0,0-82.91Z\"/>\u003C/svg>\u003Csvg class=\"wiki-heading__icon wiki-heading__icon--done\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M232.49,80.49l-128,128a12,12,0,0,1-17,0l-56-56a12,12,0,1,1,17-17L96,183,215.51,63.51a12,12,0,0,1,17,17Z\"/>\u003C/svg>\u003C/button>\u003C/h2>\n\u003Cp>Links lose their value when they are not maintained. The common causes are known in advance:\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>unstable identifiers\u003C/strong>: a requirement renumbered after a reorganization of the specification breaks all its links;\u003C/li>\n\u003Cli>\u003Cstrong>changed requirements\u003C/strong>: a link to a requirement whose text has changed still exists, although the test case may no longer match it;\u003C/li>\n\u003Cli>\u003Cstrong>links created late\u003C/strong>: links added before an audit, from memory, rather than during test design.\u003C/li>\n\u003C/ul>\n\u003Cp>The practices that address them follow from the causes. Requirements and test cases have identifiers that do not change. A link is created by the person who designs the test case, at the moment of design. When a requirement changes, its links are marked for review until someone confirms that the test cases still match it. The requirement version a test case was written for is recorded.\u003C/p>\n\u003Cp>Requirements often live in a different tool from test cases: a requirements management tool, a task tracker, a document. For the exchange of requirements between tools from different vendors the Object Management Group (OMG) publishes the Requirements Interchange Format (ReqIF), an XML-based format; its current version 1.2 was published in July 2016. Each requirement in a ReqIF file has an identifier that stays the same across exchanges, which makes it possible to keep links when requirements are re-imported.\u003C/p>\n\u003Ch2 id=\"requirements-coverage-and-code-coverage\" class=\"wiki-heading\">Requirements coverage and code coverage\u003Cbutton type=\"button\" class=\"wiki-heading__anchor\" data-wiki-anchor=\"requirements-coverage-and-code-coverage\" aria-label=\"Copy link to section\" data-copied-label=\"Link to section copied\">\u003Csvg class=\"wiki-heading__icon\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M117.18,188.74a12,12,0,0,1,0,17l-5.12,5.12A58.26,58.26,0,0,1,70.6,228h0A58.62,58.62,0,0,1,29.14,127.92L63.89,93.17a58.64,58.64,0,0,1,98.56,28.11,12,12,0,1,1-23.37,5.44,34.65,34.65,0,0,0-58.22-16.58L46.11,144.89A34.62,34.62,0,0,0,70.57,204h0a34.41,34.41,0,0,0,24.49-10.14l5.11-5.12A12,12,0,0,1,117.18,188.74ZM226.83,45.17a58.65,58.65,0,0,0-82.93,0l-5.11,5.11a12,12,0,0,0,17,17l5.12-5.12a34.63,34.63,0,1,1,49,49L175.1,145.86A34.39,34.39,0,0,1,150.61,156h0a34.63,34.63,0,0,1-33.69-26.72,12,12,0,0,0-23.38,5.44A58.64,58.64,0,0,0,150.56,180h.05a58.28,58.28,0,0,0,41.47-17.17l34.75-34.75a58.62,58.62,0,0,0,0-82.91Z\"/>\u003C/svg>\u003Csvg class=\"wiki-heading__icon wiki-heading__icon--done\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M232.49,80.49l-128,128a12,12,0,0,1-17,0l-56-56a12,12,0,1,1,17-17L96,183,215.51,63.51a12,12,0,0,1,17,17Z\"/>\u003C/svg>\u003C/button>\u003C/h2>\n\u003Cp>Requirements coverage and code coverage are both called coverage, but they measure different things.\u003C/p>\n\u003Cdiv class=\"wiki-table wiki-table--cols-3\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>\u003C/th>\n\u003Cth>Requirements coverage\u003C/th>\n\u003Cth>Code coverage\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>Coverage items\u003C/td>\n\u003Ctd>Requirements, user stories, acceptance criteria\u003C/td>\n\u003Ctd>Statements, branches, conditions of the code\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>How it is measured\u003C/td>\n\u003Ctd>From links between requirements and test cases, and from results\u003C/td>\n\u003Ctd>By instrumenting the code while tests run\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>What a gap means\u003C/td>\n\u003Ctd>A required behavior has no test\u003C/td>\n\u003Ctd>Some code is not executed by any test\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>What it cannot show\u003C/td>\n\u003Ctd>Code that implements no requirement; depth of checking\u003C/td>\n\u003Ctd>Missing functionality; whether the results are checked correctly\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Typical level\u003C/td>\n\u003Ctd>System and acceptance tests\u003C/td>\n\u003Ctd>Unit and integration tests\u003C/td>\n\u003C/tr>\n\u003C/tbody>\n\u003C/table>\u003C/div>\n\u003Cp>Each measure finds gaps that the other cannot find. Code coverage cannot find a requirement that was never implemented, because there is no code to cover. Requirements coverage cannot find code that no test executes. The two are used together: requirements coverage for the question "is everything that is required checked?", code coverage for the question "is everything that is written executed by tests?". Test levels and their typical measures are described in the article \u003Ca href=\"/en/wiki/test-automation/automation-levels-and-test-pyramid\" class=\"wiki-link wiki-link--article\">Test automation levels and the test pyramid\u003C/a>.\u003C/p>\n\u003Ch2 id=\"terms\" class=\"wiki-heading\">Terms\u003Cbutton type=\"button\" class=\"wiki-heading__anchor\" data-wiki-anchor=\"terms\" aria-label=\"Copy link to section\" data-copied-label=\"Link to section copied\">\u003Csvg class=\"wiki-heading__icon\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M117.18,188.74a12,12,0,0,1,0,17l-5.12,5.12A58.26,58.26,0,0,1,70.6,228h0A58.62,58.62,0,0,1,29.14,127.92L63.89,93.17a58.64,58.64,0,0,1,98.56,28.11,12,12,0,1,1-23.37,5.44,34.65,34.65,0,0,0-58.22-16.58L46.11,144.89A34.62,34.62,0,0,0,70.57,204h0a34.41,34.41,0,0,0,24.49-10.14l5.11-5.12A12,12,0,0,1,117.18,188.74ZM226.83,45.17a58.65,58.65,0,0,0-82.93,0l-5.11,5.11a12,12,0,0,0,17,17l5.12-5.12a34.63,34.63,0,1,1,49,49L175.1,145.86A34.39,34.39,0,0,1,150.61,156h0a34.63,34.63,0,0,1-33.69-26.72,12,12,0,0,0-23.38,5.44A58.64,58.64,0,0,0,150.56,180h.05a58.28,58.28,0,0,0,41.47-17.17l34.75-34.75a58.62,58.62,0,0,0,0-82.91Z\"/>\u003C/svg>\u003Csvg class=\"wiki-heading__icon wiki-heading__icon--done\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M232.49,80.49l-128,128a12,12,0,0,1-17,0l-56-56a12,12,0,1,1,17-17L96,183,215.51,63.51a12,12,0,0,1,17,17Z\"/>\u003C/svg>\u003C/button>\u003C/h2>\n\u003Cdiv class=\"wiki-table wiki-table--cols-2\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Term\u003C/th>\n\u003Cth>Meaning\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>Requirements traceability\u003C/td>\n\u003Ctd>Ability to describe and follow the life of a requirement in both a forwards and backwards direction\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Traceability\u003C/td>\n\u003Ctd>Degree to which a relationship can be established between two or more products of the development process\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Forward traceability\u003C/td>\n\u003Ctd>Links from a requirement to the work products derived from it: design, code, tests, results\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Backward traceability\u003C/td>\n\u003Ctd>Links from a work product back to the requirement it comes from\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Traceability matrix\u003C/td>\n\u003Ctd>Table that shows the links between two kinds of items, for example requirements and test cases\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Requirements coverage\u003C/td>\n\u003Ctd>Share of requirements covered by tests: linked, executed or passed\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Coverage\u003C/td>\n\u003Ctd>Degree to which specified coverage items are exercised by a test suite, expressed as a percentage\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Impact analysis\u003C/td>\n\u003Ctd>Identification of the work products affected by a change\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>ReqIF\u003C/td>\n\u003Ctd>Requirements Interchange Format: XML format of the OMG for exchanging requirements between tools\u003C/td>\n\u003C/tr>\n\u003C/tbody>\n\u003C/table>\u003C/div>\n\u003Ch2 id=\"sources\" class=\"wiki-heading\">Sources\u003Cbutton type=\"button\" class=\"wiki-heading__anchor\" data-wiki-anchor=\"sources\" aria-label=\"Copy link to section\" data-copied-label=\"Link to section copied\">\u003Csvg class=\"wiki-heading__icon\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M117.18,188.74a12,12,0,0,1,0,17l-5.12,5.12A58.26,58.26,0,0,1,70.6,228h0A58.62,58.62,0,0,1,29.14,127.92L63.89,93.17a58.64,58.64,0,0,1,98.56,28.11,12,12,0,1,1-23.37,5.44,34.65,34.65,0,0,0-58.22-16.58L46.11,144.89A34.62,34.62,0,0,0,70.57,204h0a34.41,34.41,0,0,0,24.49-10.14l5.11-5.12A12,12,0,0,1,117.18,188.74ZM226.83,45.17a58.65,58.65,0,0,0-82.93,0l-5.11,5.11a12,12,0,0,0,17,17l5.12-5.12a34.63,34.63,0,1,1,49,49L175.1,145.86A34.39,34.39,0,0,1,150.61,156h0a34.63,34.63,0,0,1-33.69-26.72,12,12,0,0,0-23.38,5.44A58.64,58.64,0,0,0,150.56,180h.05a58.28,58.28,0,0,0,41.47-17.17l34.75-34.75a58.62,58.62,0,0,0,0-82.91Z\"/>\u003C/svg>\u003Csvg class=\"wiki-heading__icon wiki-heading__icon--done\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M232.49,80.49l-128,128a12,12,0,0,1-17,0l-56-56a12,12,0,1,1,17-17L96,183,215.51,63.51a12,12,0,0,1,17,17Z\"/>\u003C/svg>\u003C/button>\u003C/h2>\n\u003Cul>\n\u003Cli>\u003Ca href=\"https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf\" target=\"_blank\" rel=\"noopener\" class=\"wiki-link wiki-link--external\">ISTQB Certified Tester Foundation Level Syllabus v4.0.1, ISTQB, 2024\u003Csvg class=\"wiki-link__icon\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M228,104a12,12,0,0,1-24,0V69l-59.51,59.51a12,12,0,0,1-17-17L187,52H152a12,12,0,0,1,0-24h64a12,12,0,0,1,12,12Zm-44,24a12,12,0,0,0-12,12v64H52V84h64a12,12,0,0,0,0-24H48A20,20,0,0,0,28,80V208a20,20,0,0,0,20,20H176a20,20,0,0,0,20-20V140A12,12,0,0,0,184,128Z\"/>\u003C/svg>\u003Cspan class=\"wiki-visually-hidden\">(opens in a new tab)\u003C/span>\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"https://glossary.istqb.org/\" target=\"_blank\" rel=\"noopener\" class=\"wiki-link wiki-link--external\">ISTQB Glossary\u003Csvg class=\"wiki-link__icon\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M228,104a12,12,0,0,1-24,0V69l-59.51,59.51a12,12,0,0,1-17-17L187,52H152a12,12,0,0,1,0-24h64a12,12,0,0,1,12,12Zm-44,24a12,12,0,0,0-12,12v64H52V84h64a12,12,0,0,0,0-24H48A20,20,0,0,0,28,80V208a20,20,0,0,0,20,20H176a20,20,0,0,0,20-20V140A12,12,0,0,0,184,128Z\"/>\u003C/svg>\u003Cspan class=\"wiki-visually-hidden\">(opens in a new tab)\u003C/span>\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"https://discovery.ucl.ac.uk/749/\" target=\"_blank\" rel=\"noopener\" class=\"wiki-link wiki-link--external\">An analysis of the requirements traceability problem, O. Gotel, A. Finkelstein, 1994\u003Csvg class=\"wiki-link__icon\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M228,104a12,12,0,0,1-24,0V69l-59.51,59.51a12,12,0,0,1-17-17L187,52H152a12,12,0,0,1,0-24h64a12,12,0,0,1,12,12Zm-44,24a12,12,0,0,0-12,12v64H52V84h64a12,12,0,0,0,0-24H48A20,20,0,0,0,28,80V208a20,20,0,0,0,20,20H176a20,20,0,0,0,20-20V140A12,12,0,0,0,184,128Z\"/>\u003C/svg>\u003Cspan class=\"wiki-visually-hidden\">(opens in a new tab)\u003C/span>\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"https://www.iso.org/standard/71952.html\" target=\"_blank\" rel=\"noopener\" class=\"wiki-link wiki-link--external\">ISO/IEC/IEEE 24765:2017, Systems and software engineering, Vocabulary\u003Csvg class=\"wiki-link__icon\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M228,104a12,12,0,0,1-24,0V69l-59.51,59.51a12,12,0,0,1-17-17L187,52H152a12,12,0,0,1,0-24h64a12,12,0,0,1,12,12Zm-44,24a12,12,0,0,0-12,12v64H52V84h64a12,12,0,0,0,0-24H48A20,20,0,0,0,28,80V208a20,20,0,0,0,20,20H176a20,20,0,0,0,20-20V140A12,12,0,0,0,184,128Z\"/>\u003C/svg>\u003Cspan class=\"wiki-visually-hidden\">(opens in a new tab)\u003C/span>\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"https://www.omg.org/spec/ReqIF/1.2\" target=\"_blank\" rel=\"noopener\" class=\"wiki-link wiki-link--external\">Requirements Interchange Format (ReqIF), version 1.2, OMG\u003Csvg class=\"wiki-link__icon\" viewBox=\"0 0 256 256\" width=\"16\" height=\"16\" fill=\"currentColor\" aria-hidden=\"true\" focusable=\"false\">\u003Cpath d=\"M228,104a12,12,0,0,1-24,0V69l-59.51,59.51a12,12,0,0,1-17-17L187,52H152a12,12,0,0,1,0-24h64a12,12,0,0,1,12,12Zm-44,24a12,12,0,0,0-12,12v64H52V84h64a12,12,0,0,0,0-24H48A20,20,0,0,0,28,80V208a20,20,0,0,0,20,20H176a20,20,0,0,0,20-20V140A12,12,0,0,0,184,128Z\"/>\u003C/svg>\u003Cspan class=\"wiki-visually-hidden\">(opens in a new tab)\u003C/span>\u003C/a>\u003C/li>\n\u003C/ul>\n",[10,14,17,20,23,27,30,33,36,39,42,45],{"id":11,"level":12,"text":13},"the-problem-traceability-solves",2,"The problem traceability solves",{"id":15,"level":12,"text":16},"directions-of-traceability","Directions of traceability",{"id":18,"level":12,"text":19},"chain-of-links","Chain of links",{"id":21,"level":12,"text":22},"traceability-matrix","Traceability matrix",{"id":24,"level":25,"text":26},"many-to-many-links",3,"Many-to-many links",{"id":28,"level":12,"text":29},"requirements-coverage","Requirements coverage",{"id":31,"level":25,"text":32},"limits-of-requirements-coverage","Limits of requirements coverage",{"id":34,"level":12,"text":35},"impact-analysis","Impact analysis",{"id":37,"level":12,"text":38},"keeping-traceability-up-to-date","Keeping traceability up to date",{"id":40,"level":12,"text":41},"requirements-coverage-and-code-coverage","Requirements coverage and code coverage",{"id":43,"level":12,"text":44},"terms","Terms",{"id":46,"level":12,"text":47},"sources","Sources",2065,1793718921228]