Better requirements analysis eliminates design defects
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 up through all the phases with source code and design inevitably affected. Once the SRS is updated, changes ripple back down again no doubt spinning off secondary and tertiary problems along the way.
Second-class status
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. Unfortunately, the greatest investment has been in improving 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—is often relegated to a secondary task, if done at all.
Although the commercial pressures of modern life have sharpened up processes in recent years, it remains the case that in general the automotive industry lags behind other sectors. It is no longer fair to suggest that testing is squeezed into the end of the project plan only if time allows, or that requirements documentation becomes little more than a historical curiosity once the pressures of milestones loom. However, in many cases there are too many echoes of the past problems, and few would argue that even the most recent development of automotive software has matched the rigorous ideals of aerospace with its strict DO-178C standard.
Unfortunately, for companies with project teams who operate like this, 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.
Faulty specs problems
With up to 70% of all project defects traceable to faulty requirement specifications, it is sheer madness to relegate the management of requirements to a low-priority task. Evidence demands that requirements management and traceability should be a key, over-arching activity on any project where quality and stakeholder satisfaction is a concern – and the advent of the ISO 26262 standard with its insistence on it provides a new stick to supplement this carrot.
Project managers need to apply the same enthusiasm for investment in requirements analysis as they do for design and coding. Where system and software modelling has been adopted to increase clarity, reduce ambiguity and achieve abstraction, introduce Use Cases or User Stories for the very same reasons. Where source code is subjected to automated rules checking (e.g. MISRA) and quality analysis (e.g. cyclometric complexity), introduce similar automated checking of requirement specifications (e.g., the presence of particular keywords, the absence of imprecise phrases). Where trace links are specified between code components and the design elements which they implement, add further trace links to requirements and confirm that (i) all requirements in scope have been implemented and (ii) there is no design or implementation element which cannot 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, missed deadlines and worse litigation for on-the-road failures. 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.
1 Software Quality Assurance and Management, Michael W Evans & John J Marciniak, 1987.ISBN 0-471-80930-6
About the author:
Mark Pitchford, a senior FAE, has more than 25 years’ experience in software development for engineering applications. He has worked on many significant industrial and commercial projects in development and management, both in the UK and internationally including extended periods in Canada and Australia. Since 2001, he has specialised in software test, and works throughout Europe and beyond as a Field Applications Engineer with LDRA Ltd.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
