Software requirements

The requirements for a system are the descriptions of the services provided by the
system and its operational constraints. These requirements reflect the needs of customers
for a system that helps solve some problem such as controlling a device,
placing an order or finding information. The process of finding out, analysing, documenting
and checking these services and constraints is called requirements engineering
(RE). In this chapter, I concentrate on the requirements themselves and how
to describe them.
The term requirement is not used in the software industry in a consistent way.
In some cases, a requirement is simply a high-level, abstract statement of a service
that the system should provide or a constraint on the system. At the other extreme,
it is a detailed, formal definition of a system function. Davis (Davis, 1993) explains
why these differences exist:
If a company wishes to let a contract for a large software development project,
it must defme its needs in a sufficiently abstract way that a solution is not predefined.
The requirements must be written so that several contractors can bid for
the contract, offering, perhaps, different ways of meeting the client organisation's
needs. Once a contract has been awarded, the contractor must write a system
definition for the client in more detail so that the client understands and can validate
what the software will do. Both of these documents may be called the requirements
document for the system.
Some of the problems that arise during the requirements engineering process are a result
of failing to make a clear separation between these different levels of description. I distinguish
between them by using the term user requirements to mean the high-level abstract
requirements and system requirements to mean the detailed description of what the system
should do. User requirements and system requirements may be defined as follows:
1. User requirements are statements, in a natural language plus diagrams, of what
services the system is expected to provide and the constraints under which it
must operate.
2. System requirements set out the system's functions, services and operational
constraints in detail. The system requirements document (sometimes called a
functional specification) should be precise. It should define exactly what is to
be implemented. It may be part of the contract between the system buyer and
the software developers.
Different levels of system specification are useful because they communicate infor
mation about the system to different types of readers. This example from a library system
shows how a user requirement may be expanded into several system requirements.
You can see from Figure 6.1 that the user requirement is more abstract, and the
system requirements add detail, explaining the services and functions that should
be provided by the system to be developed.

User requirement definition
I. L1BSYS shall keep track of all data required by <copyright licensing
agencies in the UK and elsewhl!re
System requirements spedflcd(ln
1.1 On making a request for a document from L1BSYS, the requestor shall
be presented with aform that rl!Cords details of tile user and the request
made.
1.2 LIBSYS request forms shall be stored on the system for five years from
the date of the request.
1.3 All L1BSYS request forms must be indexed by user, by the name of the
material requested and by the supplier of the request.
1.4 L1BSYS shall maintain a log elf all requests that have been made to the
system.
1.5 For material where authors' lending rights apply, loan details shall be
sent monthly to copyright Iicensiing agencies that have registered
with L1BSYS.