To introduce the concepts of user and

system requirements
To describe functional and non-functional
requirements
To explain how software requirements may
be organised in a requirements document

Functional and non-functional

requirements
User requirements
System requirements
Interface specification
The software requirements document

The process of establishing the services

that the customer requires from a system
and the constraints under which it
operates and is developed.
The requirements themselves are the
descriptions of the system services and
constraints that are generated during the
requirements engineering process.

It may range from a high-level abstract

statement of a service or of a system
constraint to a detailed mathematical
functional specification.
This is inevitable as requirements may serve a
dual function

May be the basis for a bid for a contract - therefore

must be open to interpretation;
May be the basis for the contract itself - therefore
must be defined in detail;
Both these statements may be called
requirements.

Ifacompanywishestoletacontractforalargesoftwaredevelopmentproject,it
mustdefineitsneedsinasufficientlyabstractwaythatasolutionisnotpredefined.
Therequirementsmustbewrittensothatseveralcontractorscanbidforthecontract,
offering,perhaps,differentwaysofmeetingtheclientorganisationsneeds.Oncea
contracthasbeenawarded,thecontractormustwriteasystemdefinitionfortheclient
inmoredetailsothattheclientunderstandsandcanvalidatewhatthesoftwarewill
do.Bothofthesedocumentsmaybecalledtherequirementsdocumentforthe
system.

User requirements

Statements in natural language plus diagrams of

the services the system provides and its
operational constraints. Written for customers.

System requirements

A structured document setting out detailed

descriptions of the systems functions, services
and operational constraints. Defines what should
be implemented so may be part of a contract
between client and contractor.

User requirement defi nition

1. The software must provide a means of
representing and
1. accessing xternal
e
fi les eated
cr
by other tools
.
System requirements specifi cation
1.1 The user should beovided
pr
with facilities to defi ne the type of
1.2 external fi les
.
1.2 Each xternal
e
fi le type ma
y have an associa
ted tool w
hich may be
1.2 applied to the fi. le
1.3 Each xternal
e
fi le type ma
y be epresented
r
as a specifi c icon on
1.2 the user
s display.
1.4 Facilities should be ovided
pr
or
f the icon epr
r esenting an
1.2 external fi le type to be defi ned
y the
b user
.
1.5 When a user selects an icon
epresenting
r
an xternal
e
fi le
, the
1.2 effect of that selection is to apply the tool associated with the type of
1.2 the external fi le to the fi le represented by the selected icon.

User
requirements

Client mana
gers
System end-users
Client eng
ineers
Contractor mana
gers
System ar
chitects

System
requirements

System end-users
Client eng
ineers
System ar
chitects
Software developers

Software design
specifi ca
tion

Client eng
ineers (perha
ps)
System ar
chitects
Software developers

Functional requirements

Non-functional requirements

Statements of services the system should provide, how the

system should react to particular inputs and how the system
should behave in particular situations.
constraints on the services or functions offered by the system
such as timing constraints, constraints on the development
process, standards, etc.

Domain requirements

Requirements that come from the application domain of the

system and that reflect characteristics of that domain.

Describe functionality or system services.

Depend on the type of software, expected
users and the type of system where the
software is used.
Functional user requirements may be highlevel statements of what the system should
do but functional system requirements
should describe the system services in
detail.

A library system that provides a single

interface to a number of databases of
articles in different libraries.
Users can search for, download and print
these articles for personal study.

The user shall be able to search either all of the

initial set of databases or select a subset from it.

The system shall provide appropriate viewers for

the user to read documents in the document
store.

Every order shall be allocated a unique identifier

(ORDER_ID) which the user shall be able to copy
to the accounts permanent storage area.

Problems arise when requirements are not

precisely stated.
Ambiguous requirements may be interpreted
in different ways by developers and users.
Consider the term appropriate viewers

User intention - special purpose viewer for each

different document type;
Developer interpretation - Provide a text viewer
that shows the contents of the document.

In principle, requirements should be both complete and

consistent.
Complete

Consistent

They should include descriptions of all facilities

required.
There should be no conflicts or contradictions
in the descriptions of the system facilities.

In practice, it is impossible to produce a complete and

consistent requirements document.

These define system properties and constraints

e.g. reliability, response time and storage
requirements. Constraints are I/O device
capability, system representations, etc.
Process requirements may also be specified
mandating a particular CASE system,
programming language or development method.
Non-functional requirements may be more
critical than functional requirements. If these
are not met, the system is useless.

Product requirements

Organisational requirements

Requirements which specify that the delivered product must

behave in a particular way e.g. execution speed, reliability, etc.
Requirements which are a consequence of organisational policies
and procedures e.g. process standards used, implementation
requirements, etc.

External requirements

Requirements which arise from factors which are external to the

system and its development process e.g. interoperability
requirements, legislative requirements, etc.

Non-functional
requirements

Product
requirements

Efficiency
requirements

Reliability
requirements

Usability
requirements

Performance
requirements

Organisational
requirements

Portability
requirements

Delivery
requirements

Space
requirements

External
requirements

Interoperability
requirements

Implementation
requirements

Ethical
requirements

Standards
requirements

Pri vacy
requirements

Legislative
requirements

Safety
requirements

Product requirement
8.1 The user interface for LIBSYS shall be implemented as simple
HTML without frames or Java applets.

Organisational requirement
9.3.2 The system development process and deliverable
documents shall conform to the process and deliverables
defined in XYZCo-SP-STAN-95.

External requirement
7.6.5 The system shall not disclose any personal information
about customers apart from their name and reference number
to the operators of the system.

Non-functional requirements may be very difficult to

state precisely and imprecise requirements may be
difficult to verify.
Goal

Verifiable non-functional requirement

A general intention of the user such as ease of use.

A statement using some measure that can be objectively tested.

Goals are helpful to developers as they convey the

intentions of the system users.

A system goal

The system should be easy to use by experienced controllers and

should be organised in such a way that user errors are minimised.

A verifiable non-functional requirement

Experienced controllers shall be able to use all the system

functions after a total of two hours training. After this training, the
average number of errors made by experienced users shall not
exceed two per day.

Property

Measure

Speed

Processed transactions/second
User/Event response time
Screen refresh time

Size

M Bytes
Number of ROM chips

Ease of use

Training time
Number of help frames

Reliability

Mean time to failure

Probability of unavailability
Rate of failure occurrence
Availability

Robustness

Time to restart after failure

Percentage of events causing failure
Probability of data corruption on failure

Portability

Percentage of target dependent statements

Number of target systems

Conflicts between different non-functional

requirements are common in complex
systems.
Spacecraft system

To minimise weight, the number of separate chips

in the system should be minimised.
To minimise power consumption, lower power
chips should be used.
However, using low power chips may mean that
more chips have to be used. Which is the most
critical requirement?

Derived from the application domain and

describe system characteristics and
features that reflect the domain.
Domain requirements be new functional
requirements, constraints on existing
requirements or define specific
computations.
If domain requirements are not satisfied,
the system may be unworkable.

There shall be a standard user interface to

all databases which shall be based on the
Z39.50 standard.
Because of copyright restrictions, some
documents must be deleted immediately on
arrival.
Depending
on
the
users
requirements, these documents will either
be printed locally on the system server for
manually forwarding to the user or routed to
a network printer.

The deceleration of the train shall be

computed as:

Dtrain = Dcontrol + Dgradient

where
Dgradient
is
9.81ms2
*
compensated
gradient/alpha
and
where the values of 9.81ms2 /alpha
are known for different types of train.

Understandability

Requirements are expressed in the language of

the application domain;
This is often not understood by software
engineers developing the system.

Implicitness

Domain specialists understand the area so well

that they do not think of making the domain
requirements explicit.

Should describe functional and nonfunctional requirements in such a way that

they are understandable by system users
who dont have detailed technical
knowledge.
User requirements are defined using
natural language, tables and diagrams as
these can be understood by all users.

Lack of clarity

Requirements confusion

Precision is difficult without making the

document difficult to read.
Functional and non-functional requirements
tend to be mixed-up.

Requirements amalgamation

Several different requirements may be

expressed together.

Invent a standard format and use it for all

requirements.
Use language in a consistent way. Use shall
for mandatory requirements, should for
desirable requirements.
Use text highlighting to identify key parts
of the requirement.
Avoid the use of computer jargon.

System requirements are intended to

communicate the functions that the system
should provide.
A software requirements document is an
agreed statement of the system
requirements.
The IEEE standard is a useful starting point
for defining more detailed specific
requirements standards.