Invest in requirements management to reduce defects and improve quality

By Shan Bhattacharya, Field Application Engineer at LDRA Ltd. 

Before becoming an IT consultant, I spent over 10 years in the defence industry developing and testing software for naval and aerospace systems. Back then the “waterfall” process dominated software development with its distinct phases of analysis, design, code and test. Each
phase was performed in isolation with the output of one being the input for the
next. The final output was a working system which passed all tests.

 

With the Waterfall approach, the purpose of the analysis phase was to refine the stakeholder’s vision of the system and produce a list of requirements, with those for software being itemized in the Software Requirements Specification (SRS). The SRS—always a revered document,
its quality typically gauged by its thickness and weight—identified your status
in the project team. 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 newly-found error or ambiguity. No matter how much a project manager wished for the SRS to be error-free, it never was and the change log would begin increasing in size until a new print run

became inevitable.

While the Waterfall adherent’s wish for a stable requirements baseline was understandable, the process by its very design dooms a project to a constant state of instability. At its core is an ideal belief that each phase flows with near-perfection into the next and any errors

or inconsistencies can be quickly smoothed out via a feedback loop. This may
work for two phases; you effectively have a cut-down spiral process. But when
you introduce a third or fourth phase, the feedback loops multiply to the point
of being unmanageable.

Thus when testing uncovers a problem with the SRS, that problem ripples out across all the phases with source code and design inevitably affected. Once the SRS is updated, changes ripple back again no doubt spinning off secondary and tertiary problems along the way.

Contemporary software development processes and practices address many of the deficiencies found in the Waterfall process. The unified process and agile methods evangelize iterative approaches, which are well supported by modern configuration management, modelling, development and testing tools.

Similarly, safety-critical standards, such as DO-178B, prescribe frameworks and processes by which systems are developed and have been widely adopted for military and aerospace projects. DO-178B in particular sets downs specific and detailed criteria for testing according to
the famous safety levels A-E. However, other phases of development are
described less strictly, allowing plenty of scope for process implementation.

Thus projects which must meet DO-178B level C or above invest in development tools by necessity, therefore a testing tool which can deliver code coverage metrics will be high on the list. But as the investment driver switches from necessity to process improvement, the next
tools to be considered are usually for the design and coding phases since engineers find software construction the most productive and exciting periods on a project. Requirements management and traceability, typically viewed as unattractive work, are usually ranked as lowly tasks and handled by existing office software already installed on team members’ workstations.

With up to 70% of all project defects traceable to faulty requirement specifications, it is very short-sighted to relegate the management of requirements to a low-priority task. The cost of identifying and correcting software defects grows by orders of magnitude as they progress
undetected from one process phase to the next. Catching defects as early as possible is critical to controlling cost and meeting project timescales. This kind of evidence demands that requirements management and traceability be considered a key, over-arching activity with equal, if not higher priority.

Modern requirements management and traceability tools address many of the traditional prejudices held against these phases of work. Tools such as LDRA’s TBreq are easy to use, integrate with a host of document types and repositories, offer visual user interfaces,
produce automated reports on-demand, and deliver clear productivity and efficiency gains. Vendors are doing their utmost to make their requirements tools as useful and attractive as design and coding tools in a bid to see more widespread deployment.

Project managers need to apply the same enthusiasm for investment in requirements analysis as they do for design and coding. System and software modelling is commonly used to increase clarity, reduce ambiguity and achieve abstraction – so introduce use cases or user stories
for the very same reasons. Source code may be subjected to automatic rules checking
(e.g. MISRA) and quality analysis (e.g. cyclometric complexity) – so apply similar automated checking to requirement specifications (e.g. the presence of particular keywords, the absence of imprecise phrases). Instead of constructing the requirements traceability matrix at the last minute, build and maintain it from the very start of the project, so that the classic traceability questions can be addressed on a regular basis. You can then ensure that all requirements in
scope have been implemented and all design and implementation elements can be traced to a requirement.

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, equal to that made for design and coding, is necessary to secure a firm foundation on which to construct a successful project whether you’re motivated by DO-178B or not.

 

About the author:

Shan Bhattacharya is a Field Application Engineer for LDRA Ltd. He graduated
from Cameron University and began his career in factory automation and
robotics. He continued his career with various defense contractors including
Lockheed Martin where he served as a Lead Engineer and finished his time as a
Deputy IPT Lead. Shan has been with LDRA since 2007 and provides consultation
for clients in various industries focusing on requirements management, software
certifications, and development best practices.