Code Quality: Requirements traceability: Just as important as Design & Coding
BlogJuly 01, 2013
Mark Pitchford
LDRA Technology
So, the software development process is all thought through, planned out, documented, structured, in place. You’ve invested good money in test tools that can generate as many artifacts as you could possibly need. You have reports from static analysis, dynamic analysis, functional test, unit test, object code verification…. Nothing has been left to chance. Everything is in place and prepared for the onslaught of the assessment team. Bring it on!
(The sounds of tires screaming to a halt after going a hundred miles an hour.)
DO-178B/C is littered with references to traceability and none of your traditional test documents provide it. What’s more, that traceability has to work both ways―downstream (requirements to implementation) and upstream (implantation to requirements). “Bidirectional traceability” may only be a two-word phrase, but when it comes to military embedded systems, it packs a serious punch. To understand its significance, let’s look at software evolution.
A couple of decades ago, the waterfall process dominated software development with its distinct phases of analysis, design, code, and test. The theory was that each phase would be performed in isolation with the output of one being the input for the next. The intended result was a working system that passed all tests.
With the waterfall approach, the purpose of the analysis phase was to refine the stakeholders’ vision of the system and produce a list of requirements, with those for software being itemized in the Software Requirements Specification (SRS). You were somebody if you could proudly display it on your bookshelf!
Of course, no sooner had a print run finished than the SRS was out of date due to a new-found error or ambiguity. No matter how much a project manager wished for the SRS to be error-free, it never was. The change log would begin increasing in size until a new print run became inevitable. The SRS lagged behind reality, and errors were a fact of life.
Today, requirements traceability is widely accepted as development best practice. It ensures that all requirements are implemented and that all development artifacts can be traced back to one or more requirements. Yet despite good intentions, many projects still fall into a pattern of disjointed software development in which requirements, design, implementation, and testing phases are isolated from each other―something often dubbed the “silo effect”. Such isolation results in tenuous links between requirements, the development stages, and/or the development teams.
For software development to be considered complete, you must include tools that help you achieve “bidirectional traceability”. . The requirements themselves need to be clear and unambiguous, perhaps aided by means of use cases or user stories. Automated checking of requirement specifications can help by confirming the presence of particular keywords, and the absence of imprecise phrases.
With the resulting precise requirements in place, the use of trace links from requirements to specific lines of code, and then to tests of that code and so on…throughout the lifecycle, can implement bidirectional traceability by confirming that all requirements in scope have been implemented, and that all design or implementation elements can be traced to a requirement. What’s more, automated reporting on those the trace links ensures that requirements maintenance can never become a secondary issue.
Requirements are the foundation of every project. A weak foundation results in high numbers of defects, unforeseen remedial work, spiralling costs, and missed deadlines. Investment in requirements management should stand on an equal footing with design and coding. Requirements traceability secures the firm foundation on which to construct a successful project. Without that foundation, even a project equipped with the best test tools available is potentially flawed.
