What is software traceability? What is a software requirements traceability matrix?

What is Traceability in software development?

In my experience working on custom software development projects, the number one cause of project failure is inadequate requirements. When programmers code either without requirements or with inadequate requirements, nothing good ever comes of it.

The relationship between the requirements, the source of those requirements, and the system design that is ostensibly being built to enable those requirements, is what code traceability is all about.

I think it is very important to point out that regardless of the software development lifecycle process model you and your team happen to be following, be it a traditional “Waterfall” type software model or a so-called “Agile” fixed-iteration development lifecycle, documentation and code traceability is paramount.

If your software has provided for a high level of traceability, then the requirements can flow down through the design and code and then can be traced back up at every stage of the process.

This makes it a simple matter to trace a coding decision back to a design decision to satisfy a corresponding requirement.

In embedding systems software engineering, traceability is vital because hardware constraints can act as limiting factors on design and coding decisions that may not be as easily associated with a requirement as in a non-embedded system design.

When even a basic “traceability matrix” is not provided for on a software project, then the lack of a traceability path from design and coding decisions back through to the requirements can lead to severe difficulties in extending and maintaining the system.

What is a software traceability matrix?

A software traceability matrix document can take many different forms, but one of the most common forms is a table-like document that serves simply as a graphical representation of all of the cross referenced links between project deliverables and artifacts, and the code.

This cross referenced table is constructed, usually using a spreadsheet application program, by listing the relevant software documents and then the doe unit as columns, and each software requirement as a row.

An example of a software requirement tracing matrix.

If you use a spreadsheet program, then you can create multiple matrices sorted and cross-refernced by each column as needed. For example, you could provide a traceability matrix sorted by test case number, which could serve as a very apropos appendix to the test plan.

The traceability matrices should be updated at each step in the software life cycle. For example, the column for the code unit names, things like procedure names, object classes, etc., can not be added until after the code is developed.

What are the elements of a good traceability matrix?

A traceability matrix is a document, sometimes in the form of a table, that will provide a cross reference between all the documentation and software code in a system.

At a very minimum, a good traceability matrix will provide links, or cross references showing the associations between the following elements:

1. From the requirements to the stakeholders who first proposed these requirements, with the dates they were first proposed.

2. The associations between any dependent requirements listed.

3. From the requirements through to the system design, or functional specification document.

4. From the design to the relevant code segments. (oftentimes referencing the technical specification document).

5. From the requirements to the test plan document.

6. From the test plan to the relevant test cases.

What is requirements traceability?

Software requirements traceability is the ability for a project team to provide references that document the relationships between the software requirements, their sources, and the system design. If software requirements traceability has been provided well, then the requirements can be linked to their source, to other requirements, and to design elements.

Requirements traceability links between the different requirements, source traceability links these requirements to the stakeholders who proposed those requirements, and design traceability link from the requirements to the system design documents.

The software requirements document, sometimes referred to as the SRS, or software requirements specification document, MUST be “traceable”, because the software requirements provide the starting point for the entire traceability chain.

It is very common within professional project management organizations, or PMOs, to enact and enforce traceability policies which codify how much information regarding requirement relationships is required to be maintain, and the format in which this information is to be presented. There are a number of open source and proprietary open-source tools which can be used to help improve a software organization’s requirements traceability.

A traceability matrix sorted by requirement numbers that correspond to a numbering scheme

The overarching goal of software traceability and software traceability matrix is to ensure that for critical software, nothing falls through the cracks. Ultimately there is a way of mapping for each requirement which test cases exist to cover that requirement and the functional specification.

As shown in the sample traceability matrix above, one way to show the traceability from requirements through design and testing is through the use of an appropriate numbering system throughout the documentation for the system. For example, a requirement numbered 3.2.2.1 would be linked to a design element with a similar number (the numbers don’t have to be the same so long as the annotation in the document provides traceability). The main intent here is to show that all the appropriate documents and project deliverables are connected through referencing and notation.

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which is Tshirtnow.net.

More Articles From Boston’s Hub Tech Insider:

• Twelve Tips For Agile Project Planning and Estimating
• Eight ways to tell if your Project Team is on the Way Up, or on the Way Down
• The Twenty Laws of Testing Computer Software
• What are the qualities of bad software code?
• What is a software requirements traceability matrix?
• Why Designing for a VUI is harder than designing for a GUI
• The Hub Tech Insider Glossary of Mobile Web Terminology
• The Hub Tech Insider Glossary of Stock Options Terminology
• How many Stock Options should executives at a startup be granted?
• Agile Development In Practice
• What is ‘Management By Walking Around’?
• Boston Area Video Game Companies
• Demandware eCommerce
• How to expand your professional network on LinkedIn
• How to use LinkedIn in your job search
• Twitter and network effects
• How much bandwidth does a smartphone use? How much bandwidth does an Apple iPad use? How much bandwidth does an Apple iPhone use?
• What is Scrum?
• What is a “Use Case”?
• What is a “User Story”?
• What is Indirect Spend?
• What is EDIINT? What is AS2, AS1, AS3 and AS4?

Related articles

• Traceability Woes (bulldozer00.com)