The Importance of Traceability

Many software development projects waste time and resources creating system functionality end-users do not want or need while failing to deliver things end-users have specifically requested. Often poor traceability practices are to blame for these failures.

Publication Date:  25 January 2024

Software development projects often fail to deliver everything end-users want and need. They also often waste time and resources creating unrequired items. Following good traceability practices can keep both of these things from happening.

Traceability refers to the practice of ensuring everything that is built as part of a software development effort can be directly “traced” to something requested by end-users. As such, good traceability begins with good requirements gathering.

Requirements gathering is the first step of most software development projects. This process entails members of the development team interviewing end-users about what they need the system to do and documenting these needs in some form of functional requirements.

A functional requirement is simply a statement about some function end users need a system to perform. For example, a set of end-users might need to be able to capture the first and last names of customers who have purchased a product. The functional requirement for this would be something like “The system shall allow users to capture the first and last names of customers who purchase a product.”

Functional requirements simply state what a system needs to do to meet the needs of end users. They do not say anything about how the system will meet this need. This is defined by technical requirements.

Technical requirements define how a system will meet the end user needs specified in functional requirements. The technical requirements for the example of capturing the first and last names of customers might be something like the following:

The system shall provide a 15-character text input field for users to type a customer’s first name
The system shall provide a 50-character text input field for users to type a customer’s last name

These two technical requirements spell out in detail what will be built to meet the end-user needs stated in the associated functional requirement.

Ideally, every functional requirement should be traceable to at least one technical requirement, and every technical requirement should be traceable to at least one functional requirement. Any requirement, whether functional or technical, that does not achieve this is said to be an orphan. An orphan functional requirement is one that does not have any associated technical requirements. Orphan functional requirements represent user needs that the system will not fulfill. An orphan technical requirement is one that is not associated with any functional requirement. Orphan technical requirements represent system functionality that users do not need or want.

To ensure software development efforts meet all of the needs of end-users and do not waste time and resources building things that are not required, end-users should review and formally approve all functional and technical requirements before the associated features are developed. Part of this review should focus on ensuring full traceability between the two sets of requirements. Development teams can facilitate this review by specifying which technical requirements trace to which functional requirements and vice versa.

Software development projects that do not follow good traceability practices run the very real risk of creating systems that do not meet all of the needs of end-users and wasting time and resources developing system features that users do not want. Given how easy it is to ensure full traceability between functional and technical requirements, there really is no excuse for this to happen.

Recent Posts

Rules Should Not apply

Some organizational rules are critically important to keeping people safe from harm. Organizational leaders should ensure these rules are always followed. Other organizational rules exist to help staff know what to expect and to keep operations running smoothly. Making project teams working on critical change initiatives follow these rules can often do more harm than good.

How and When You Communicate Matters

Most organizations understand that communication can make or break a project. Nonetheless, few organizations actually effectively communicate with staff and stakeholders about key initiatives. In particular, many organizations wait too long to communicate with staff and stakeholders and use horribly ineffective channels when they finally do communicate.

It is So Shiny! I Need to Have It!

It seems like every few years some new, must have process or piece of technology sweeps through industries. When this happens, it can very difficult for leaders of organizations to resist the urge to jump on the bandwagon and adopt the newest thing, even if doing so might be in their organization’s best interest.

The Most Important Aspect of Change Management

It can take a lot of time and effort to complete all of the work required by many formal change management methodologies. If an organization has the resources to complete all of this work, it is often very beneficial to do so. However, if an organization does not have the resources to do this much work, significant gains can still be made by focusing solely on the most important aspect of change management.

The Misapplication of Agile and the Myth that Waterfall is Dead

The popularity of Agile project management has led some organizations to use it exclusively and declare other project management methodologies like Waterfall dead. This often leads to Agile being used in situations in which a different project management methodology would work much better, and this in turn results in poor project outcomes and disappointed end users.

You Might Also Like

It is So Shiny! I Need to Have It!

It is So Shiny! I Need to Have It!

It seems like every few years some new, must have process or piece of technology sweeps through industries. When this happens, it can very difficult for leaders of organizations to resist the urge to jump on the bandwagon and adopt the newest thing, even if doing so might be in their organization’s best interest.

The Misapplication of Agile and the Myth that Waterfall is Dead

The Misapplication of Agile and the Myth that Waterfall is Dead

The popularity of Agile project management has led some organizations to use it exclusively and declare other project management methodologies like Waterfall dead. This often leads to Agile being used in situations in which a different project management methodology would work much better, and this in turn results in poor project outcomes and disappointed end users.

The Need for Enterprise Systems Engineering

The Need for Enterprise Systems Engineering

Many modern enterprise IT systems fall far short of the ideal of operating as fully integrated wholes. In many instances, this is the result of too much focus on sub-system optimization and not enough focus on overall system performance. This situation can often be brought back into alignment through an increased focus on enterprise systems engineering.