How to Ensure You Build the Right Thing
Many software development projects waste time and resources creating system functionality end-users do not want or need while simultaneously failing to deliver things end-users have specifically requested. Often poor traceability practices are to blame for these failures.
21 February 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.