Software Engineering for Students A Programming Approach

4.5 The requirements specification 41
enriching their jobs. They may resent any attempt to speed up or intensify their work.
They may object to any facilities in the system to monitor their work rate. The management
in the bank, however, will probably be concerned with costs, performance and
effectiveness. There may very well be a conflict of interest between the cashiers and the
managers. This paints an extreme picture, but illustrates that the users will not necessarily
present a single, uniform view.
Another example of a potential gulf between users and analysts is to do with the level
of expectation of users. Some users have seen science fiction films and come to believe
that computers can do anything – or at least can offer a high level of artificial intelligence.
Others, perhaps, are naive in the opposite direction and believe that computers
can carry out only the most mundane tasks.
To sum up, the role of the analyst is:
■ to elicit and clarify the requirements from the users
■ to help resolve possible differences of view amongst the users and clients.
■ to advise users on what is technically possible and impossible.
■ to document the requirements (see the next section).
■ to negotiate and to gain the agreement of the users and clients to a (final) requirements
specification.
The journey from the users’ initial idea to an agreed requirements specification will
often be long and tortuous.
4.5 ● The requirements specification
The end product of requirements elicitation and analysis is the requirements specification.
It is a vital piece of documentation that is crucial to the success of any software
development project. If we cannot precisely state what the system should do, then how
can we develop the software with any confidence, and how can we hope to check that
the end product meets its needs? The specification is the reference document against
which all subsequent development is assessed.
Three important factors to be considered are:
1. the level of detail
2. to whom the document is addressed
3. the notation used.
The first factor is about the need to restrict the specification as much as possible to
specify what the system should do rather than how it should do it. As we have seen, the
specification should ideally be the users’ view of the system rather than anything about
how the system is to be implemented.
The second factor arises because the specification has to be understood by two different
sets of people – the users and the developers. The people in these two sets have
different backgrounds, expertise and jargon. They share the common aim of clearly