Benefits of requirements traceability

“The hardest single part of building a software system is deciding precisely what to build.
No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all interfaces to people, to machines, and to other software systems.
No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”

Frederick P. Brooks Jr. in “No Silver Bullet: Essence and Accidents of Software Engineering.”

Bad foundations guarantee the instability of the entire building. Nevertheless The opposite is not always true. In order to have a stable building, the existence of good foundations is mandatory, but it’s not enough.

This premise is applicable to other domains than construction. In software engineering, the Software Requirement Specification (SRS) is the foundation of the entire system.

Writing a good SRS is mandatory in order to correctly start constructing stable software. However, the SRS is one of the more instable parts of software.

The number of modifications to the SRS grows very fast; we can say that 30% of requirements are modified in a midsize project.

“Changing requirements is as certain as death and taxes”

Daniel Amyot; Lecture in Software Engineering; Ottawa University

This presentation gives a brief description of the problem, then it remark the consequences and gives some advices in order to correctly write and trace requirements. Finally, it gives some examples of traceability by using the Reqtify tool.

This powerful traceability requires the specification document to be written by following strict naming rules so they can be correctly traced. In another post I give the code of a tool allowing you to add an "Automatic requirements numbering" to your Software Requirement Specifications.

Take a look to this presentation named Benefits of requirements traceability by David Garduno

D. GARDUNO