Page 100 -

Chapter 4 Requirements engineering 83

The requirements for a system are the descriptions of what the system should do—
the services that it provides and the constraints on its operation. These requirements
reflect the needs of customers for a system that serves a certain purpose such as con-
trolling a device, placing an order, or finding information. The process of finding
out, analyzing, documenting and checking these services and constraints is called
requirements engineering (RE).
The term ‘requirement’ is not used consistently in the software industry. In some
cases, a requirement is simply a high-level, abstract statement of a service that a sys-
tem should provide or a constraint on a system. At the other extreme, it is a detailed,
formal definition of a system function. Davis (1993) explains why these differences
exist:

If a company wishes to let a contract for a large software development project,
it must define its needs in a sufficiently abstract way that a solution is not pre-
defined. The requirements must be written so that several contractors can bid
for the contract, offering, perhaps, different ways of meeting the client organi-
zation’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 to system users and the constraints
under which it must operate.

2. System requirements are more detailed descriptions of the software system’s
functions, services, and operational constraints. The system requirements docu-
ment (sometimes called a functional specification) 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 requirements are useful because they communicate informa-
tion about the system to different types of reader. Figure 4.1 illustrates the distinction
between user and system requirements. This example from a mental health care
patient management system (MHC-PMS) shows how a user requirement may be
expanded into several system requirements. You can see from Figure 4.1 that the
user requirement is quite general. The system requirements provide more specific
information about the services and functions of the system that is to be implemented.