Software Engineering for Students A Programming Approach

4.2 The concept of a requirement 37
Establishing the requirements for a software system is the first step in trying to
ensure that a system does what its prospective users want. This endeavor continues
throughout the software development and is called validation.
The requirements specification has a second vital role. It is the yardstick for assessing
whether the software works correctly – that it is free from bugs. The job of striving
to ensure that software is free from errors is a time-consuming and difficult process that
takes place throughout development. It is called verification.
Errors in specification can contribute hugely to testing and maintenance costs.
The cost of fixing an error during testing can be 200 times the cost of fixing it during
specification. It is estimated that something like 50% of bugs arise from poor
specification. The remedy of course is to detect (or prevent) bugs early, that is, during
specification.
It is easy to write poor requirements specifications for software; it is difficult to write
good specifications. In this chapter we will examine guidelines for writing specifications.
Remember that specifications are not usually written once and then frozen. More
typically, requirements change during the software development as the users’ requirements
are clarified and modified.
4.2 ● The concept of a requirement
The task of analyzing and defining the requirements for a system is not new or peculiar to
software. For generations, engineers have been carrying out these activities. For example,
the following is part of the requirements specification for a railway locomotive:
On a dry track, the locomotive must be able to start a train of up to 100 tonnes on an
incline of up to 30% with an acceleration of at least 30 km/h/h.
This statement serves to emphasize that a requirement tells us what the user (in this case
the railway company) wants. It says nothing about how the locomotive should be built.
Thus, it does not state whether the locomotive is diesel, coal or nuclear powered. It says
nothing about the shape or the wheel arrangements.
One of the great controversies in computing is whether it is desirable (or even possible)
to specify what a system should do without considering how the system will do it. This is
the relationship between specification and implementation. We will now look at both sides
of this argument.
On the one hand, there are several reasons why the requirements specification
should avoid implementation issues. The prime reason is that the user cannot reasonably
be expected to understand the technical issues of implementation and cannot
therefore be expected to agree such elements of the specification. To emphasize the
point, how many users of a word processor really understand how software works? A
second reason for minimizing implementation considerations is to avoid unduly constraining
the implementation. It is best if the developer has a free reign to use whatever
tools and techniques he or she chooses – so long as the requirements are met.