Better requirements analysis eliminates design defects

Before finding a more specialized vocation, I spent more than 15 years in
industry 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 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.

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 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.

Of course it is true in any design or building effort that inadequate plans lead to inadequate results. So the majority of the effort needs to be spent in designing the specifications. After that, the project is just writing code. Of course, writing good and efficient code is no small task, it is a major challenge, no doubt. BUT the first part of the effort is in the development of an adequate specification. Defining responses to all possible exceptions at each stage of a program is both hard and tedious indeed. But if the task were trivial than everybody could do it well, and we can see that is not what happens.