Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

Improve requirements analysis to eliminate defects

Posted: 09 Jan 2013 ?? ?Print Version ?Bookmark and Share

Keywords:software development? SRS? requirements management?

Before I landed in a more specialised vocation, I dedicated more than 15 years to developing and testing software. Back then 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 output was a working system that 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 SRSalways a revered document, its quality typically gauged by its thickness and weightidentified 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.

Figure 1: Despite attempts to refine the waterfall process model such as this example from 1987, the idealised notion that requirements can be set in stone usually remained unchallenged1.

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 evangelise 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 traceabilitytypically viewed as unattractive workis 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.

1???2?Next Page?Last Page

Article Comments - Improve requirements analysis to eli...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top