Functional requirements

The functional requirements for a system describe what the system should do. These
requirements depend on the type of software being developed, the expected users
of the software and the general approach taken by the organisation when writing
requirements. When expressed as user requirements, the requirements are usually
described in a fairly abstract way. However. functional system requirements
describe the system function in detail, its inputs and outputs, exceptions, and so on.
Functional requirements for a software system may be expressed in a number of
ways. For example, here are examples of functional requirements for a university
library system called L:"BSYS, used by students and faculty to order books and documents
from other libraries.
I. The user shall be able to search either all of the initial set of databases or select
a subset from it.
2. The system shall provide appropriate viewers for the user to read documents
in the document store.
3. Every order shall be allocated a unique identifier (ORDER_ill), which the user
shall be able to copy to the account's permanent storage area.
These functional user requirements define specific facilities to be provided by
the system. These have been taken from the user requirements document, and they

illustrate that functional requirements may be written at different levels of detail
(contrast requirements I and 3).
The UBSYS system is a single interface to a range of article databases. It allows
users to download copies of published articles in magazines, newspapers and scientific
journals. I give a more detailed description of the requirements for the system
on which UBSYS is based in my book with Gerald Kotonya on requirements
engineeC'.ng (Kotonya and Sommerville, 1998).
Imprecision in the requirements specification is the cause of many software engineering
problems" It is natural for a system developer to interpret an ambiguous
requirement to simplify its implementation. Often, however, this is not what the customer
wants. New requirements have to be established and changes made to the
system. Of course, this delays system delivery and increases costs.
Consider the second example requirement for the library system that refers to
appropnate viewers provided by the system. The library system can deliver documents
in a range of formats; the intention of this requirement is that viewers for
all of these formats should be available. However, the requirement is worded
ambiguously; it does not make clear that viewers for each document format should
be provided. A developer under schedule pressure nught simply provide a text viewer
and claim that th~: requIrement had been met.
In principle, the functional requirements specification of a system should be both
complete and consistent. Completeness means that all services required by the user
should be defined. Consistency means that requirements should not have contradictory
definitions. In practice, for large, complex systems, it is practically impossible
to achieve requirements consistency and completeness.
One reason for this is that it is easy to make mistakes and omissions when writing
speCifications for large, complex systems. Another reason is that different system
stakeholders hav~: different-and often inconsistent-needs. These
inconsistencies may not be obvious when the requirements are first specified, so
inconsistent requirements are included in the specification. The problems may only
emerge after deeper analysis or, sometimes, after development is complete and the
system is delivered to the customer.