Talk:Traceability matrix

Questions and Issues
Hi, I have some questions about traceability matrices that I hope can be answered on the page.


 * Where did they come from? Who invented them and where did they first become commonly used?
 * Can traceability only refer to documents or can it refer to any project development artefact? (eg requirements entered into an Req Mgt System)
 * Must a traceability matrix be in a document, or are other media also okay?
 * What does vertical vs horizontal traceability look like in a traceability matrix?
 * How can bi-directional traceability be represented in an RTM
 * Do people use traceability matrices outside of projects (e.g. in product development, business as usual software development, etc
 * rather than the table is it possible to insert images to demonstrate the concept?

Craigwbrown (talk) 09:44, 16 January 2012 (UTC)


 * Talk pages are not forums so you should only be asking questions related to the article. I realized that these are not related to the article. --Walter Görlitz (talk) 15:50, 16 January 2012 (UTC)
 * Walter Görlitz these are all related to the topic, and suggestions for inclusion. — Preceding unsigned comment added by Craigwbrown (talk • contribs) 2012-01-16T21:42:32


 * OK since I don't understand your questions, perhaps you'd be good enough to elaborate on them so that I can understand what improvements you're trying to achieve.
 * As for other artifacts, anything that is a baselined document can be traced. The article already indicates this. Perhaps what that means needs to be explained to people who don't know what that means. In short, anything with an item number that will not change over time is traceable.
 * As for bi-directional traceability, look for non-zero intersections and move to the other axis. I've seen that done in a different form of document, but the matrix is much more elegant. --Walter Görlitz (talk) 22:06, 16 January 2012 (UTC)

Sticky Minds
The StickyMinds reference is pretty worthless, content is in broken english, barely readable, I suggest someone who has an account remove it.


 * Absolutely correctly. If it was entirely unreadable, I would say remove it. However, it is able to explain a few important points, if you take the time to understand the broken English. The diagrams are useful, and it conveys a small amount of information that is not presented anywhere else. Instead of of removing it, please offer a document or site that offers what the article does. --Walter Görlitz (talk) 18:28, 20 August 2009 (UTC)


 * Another point worth mentioning is that while projects are generally software related, tracability matrix's can be used for non-software based projects to trace requirements to actions (poor terminology, but close enough) and deliverables. As such, it is not necessary to trace requirements to test cases. You can use it to trace anything, from requirements to deliverables to documents and stakeholders. —Preceding unsigned comment added by 203.10.111.38 (talk) 00:20, 21 October 2009 (UTC)


 * The plural of matrix is matrices. I have attempted to indicate, in the article, that it's for any baselined documents to any other. They are frequently used in software development so there may be that bias in the article. --Walter Görlitz (talk) 01:39, 21 October 2009 (UTC)

The Sticky Minds article is not a peer reviewed or industry journal. It's just an essay on a community website. Same goes for the other references below. It would be nice to incorporate any critical content into the page proper, otherwise the link should be removed. Any objections? Craigwbrown (talk) 09:58, 16 January 2012 (UTC)

Requirements Traceability by Neville Turbitt
Same issue as above. This is a blog/commercial site. And while Neville's content is both good quality and relevant I have to ask whether it is suitable as a reference for this page. Should it be removed? Craigwbrown (talk) 09:58, 16 January 2012 (UTC)

Bidirectional Requirements Traceability by Linda Westfall
While a relevant and useful article, this is no more than an industry paper. It has some good content that would be useful for the wiki page, but it is not founded on anything more than someone's opinion. SHould it be removed? Craigwbrown (talk) 09:58, 16 January 2012 (UTC)

Software Development Life Cycles: Outline for Developing a Traceability Matrix by Diana Baldwin
I am removing this link immediately because the content relates to traceability in general and has no direct bearing on the traceability matrix per se. Craigwbrown (talk) 09:58, 16 January 2012 (UTC)

Title Change
The title "Traceability Matrix" is in my opinion quite meaningless. I propose "Requirement Verification Matrix" instead. At first I thought about making a redirect from "Requirement Verification Matrix" to the article but I'm more and more convinced that "Requirement Verification Matrix" should be the correct choice. (I'm a senior quality manager, active in military industry). Werner Stauffacher (talk) 20:46, 9 December 2015 (UTC)
 * I'm sorry it's meaningless to you. "Requirement Verification Matrix" has about 2,850 results in a Google search, where as the current title has about 232,000 results. That's two orders of magnitude more. You also missed the "requirement validation matrix". In fact, I saw a few sources that state that a requirement verification matrix a specific type of traceability matrix. Since traceability matrix is used across several disciplines, not only software testing, it is the appropriate term. In short, I oppose a move. Walter Görlitz (talk) 06:51, 10 December 2015 (UTC)
 * Hello Walter, thanks for your reply. The google-results-counting cannot be used as a method to decide whether the title is correct or not. My first impression is that the title does not match the content of the article AND it is per se meaningless. I will proceed as follow: first I will scrutinize all Wikipedia material on the argument and find references, then I'll come back on title change proposal. Due date: end of 2015. Best regards, Werner Stauffacher (talk) 11:21, 10 December 2015 (UTC)
 * Of course the Google counts can be, especially in this situation where it's clear one term is used 100 times more often than the other. It's called WP:COMMONNAME. But let's see what a software testing/development website, StickyMinds.com, says.
 * traceability matrix: 18
 * requirement verification matrix: 0
 * requirements verification matrix: 0
 * requirement validation matrix: 0
 * requirements validation matrix: 0
 * matrix: 137
 * So the term is not common in the software testing world. Since the term is not common, it's meaningless to have it be the article name.
 * Since the example is only one type of a traceability matrix, you could potentially argue that it could be labelled as such, but moving the article makes no sense. The article will not be moving because the term is not used. Having read greatly on the topic of software testing, this is the first time I've heard it. That sort of anecdotal example is useless, when it's not in books or articles (or conference topics) it's not appropriate since people will not be looking for the term. Walter Görlitz (talk) 15:40, 10 December 2015 (UTC)
 * Here only some partial responses and thoughts: Requirements can be verified but not validate. You validate a product not a requirement. By testing you verify a requirement, usually previously verifying the specifications of that requirement.
 * A "traceability matrix" has per se no meaning in the wording used: Trace what? (should be Req's), on which purpose? (should be "verification --> Test Cases).
 * SW is just one of the field of interest. In business you need Requirement Verification Matix to make sure contractual obligations (~= Req's) have been fulfilled (for example by use of Project activities ~= Test Cases). Werner Stauffacher (talk) 21:48, 10 December 2015 (UTC)
 * In order of your comments. There is such a thing as a requirements validation matrix. It too is a type of traceability matrix.
 * Traceability matrix is the common term. I have shown that. Every term has whatever meaning is assigned to it. Your argument that it has no meaning is without merit.
 * Software is just one of the fields of interest. In business you need traceability matrices. If there are no requirements to map you can still create a traceability matrix, but not a requirement verification matrix. Your definition is a traceability matrix.
 * You have failed to make a case. Walter Görlitz (talk) 05:03, 11 December 2015 (UTC)


 * Werner Stauffacher - I suggest keep the title 'Traceability matrix'. This article is the general concept, and a software requirement verification matrix is a subset of that.  Just like the name indicates, that would be a verification role applied to software requirements.  Traceability can be more widely used for consistency, completeness, and correctness.  It can address many things like content (data items or documents), process (statement of work or plan), and basis (authority or requirement).  One might have a Design Validation Matrix, or a Responsibility Assignment Matrix or other flavors.   In general Traceability Matrix is a matrix that shows Traceability of how group-of-items links to other-group-of-items, and 'Traceability matrix' seems the best sense for naming the general concept.   Markbassett (talk) 18:33, 14 January 2016 (UTC)

Is this better wording or not?
I don't like:

A traceability matrix is a document, usually in the form of a table, that correlates any two baselined documents that require a many-to-many relationship to determine the completeness of the relationship.

Is this better wording or not?

A traceability matrix is a document, usually in the form of a table, used to determine the completeness of a relationship by correlating any two baselined documents using a many-to-many relationship comparison.

Thanks 73.163.28.44 (talk) 16:55, 3 April 2016 (UTC)