Objectives

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

04/24/23 CSC430-Fall 2019 Prof. Zhanyang Zhang 3

 What is a requirement?
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.

04/24/23 CSC430-Fall 2019 Prof. Zhanyang Zhang 4

 Types of requirement
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 system’s functions, services and operational constraints.
Defines what should be implemented so may be part of a
contract between client and contractor.

04/24/23 CSC430-Fall 2019 Prof. Zhanyang Zhang 5

 Definitions and specifications
User requirement

1. The software must provide a means of representing and accessing

1. external files created by other tools.

Syst em requir ements specification

1.1 The user should be pr o vided with facilities to define the type of
1.2 external files .
1.2 Each e xternal file type ma y hav e an associa ted tool w hich ma y be
1.2 applied to the file .
1.3 Each e xternal file type ma y be r epr esented as a specific icon on
1.2 the user’ s displa y.
1.4 F acilities should be pr o vided f or the icon r epr esenting an
1.2 e xternal file type to be defined b y the user .
1.5 When a user selects an icon r epr esenting an e xternal file , the
1.2 effect of that selection is to apply the tool associated with the type of
1.2 the external file to the file represented by the selected icon.

04/24/23 CSC430-Fall 2019 Prof. Zhanyang Zhang 6

 Functional and non-functional requirements

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.
Non-functional requirements
 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.

04/24/23 CSC430-Fall 2019 Prof. Zhanyang Zhang 7

Functional requirements
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 high-level
statements of what the system should do but functional
system requirements should describe the system services in
detail.

04/24/23 CSC430-Fall 2019 Prof. Zhanyang Zhang 8

The LIBSYS system
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.

04/24/23 CSC430-Fall 2019 Prof. Zhanyang Zhang 9

Examples of functional requirements
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
account’s permanent storage area.

04/24/23 CSC430-Fall 2019 Prof. Zhanyang Zhang 10

 Non-functional requirements
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.

04/24/23 CSC430-Fall 2019 Prof. Zhanyang Zhang 11

 Non-functional classifications
Product requirements
 Requirements which specify that the delivered product must behave in a
particular way e.g. execution speed, reliability, etc.
Organisational requirements
 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.

04/24/23 CSC430-Fall 2019 Prof. Zhanyang Zhang 12

 Non-functional requirement types
Non-functional
requir ements

Product Organisational External

r equir ements requir ements requir ements

Efficiency Relia bility Porta bility Inter oper a bility Ethical

requir ements r equir ements requir ements requir ements requir ements

Usa bility Deli very Implementa tion Standar ds Leg islative

requir ements requir ements requir ements requir ements requir ements

Perfor mance Space Pri vacy Safety

requir ements requir ements requir ements requir ements

04/24/23 CSC430-Fall 2019 Prof. Zhanyang Zhang 13

Non-functional requirements examples
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.

04/24/23 CSC430-Fall 2019 Prof. Zhanyang Zhang 14

Goals and requirements
Non-functional requirements may be very difficult to state
precisely and imprecise requirements may be difficult to verify.
Goal
 A general intention of the user such as ease of use.

Verifiable non-functional requirement

 A statement using some measure that can be objectively tested.

Goals are helpful to developers as they convey the intentions of

the system users.

04/24/23 CSC430-Fall 2019 Prof. Zhanyang Zhang 15

System requirements
More detailed specifications of system functions, services
and constraints than user requirements.
They are intended to be a basis for designing the system.
They may be incorporated into the system contract.
System requirements may be defined or illustrated using
system models discussed in UML.

04/24/23 CSC430-Fall 2019 Prof. Zhanyang Zhang 16

Requirements and design
In principle, requirements should state what the system
should do and the design should describe how it does this.
In practice, requirements and design are inseparable
A system architecture may be designed to structure the
requirements;
The system may inter-operate with other systems that
generate design requirements;
The use of a specific design may be a domain requirement.

04/24/23 CSC430-Fall 2019 Prof. Zhanyang Zhang 17

 The requirements document
The requirements document is the official statement of
what is required of the system developers.
Should include both a definition of user requirements and
a specification of the system requirements.
It is NOT a design document. As far as possible, it should
set of WHAT the system should do rather than HOW it
should do it

04/24/23 CSC430-Fall 2019 Prof. Zhanyang Zhang 18

Users of a requirements document
Specify the requirements and
System read them to check that they
customers meet their needs. T hey
specify changes to the
requirements

Use the requirements

Managers document to plan a bid for
the system and to plan the
system development process

System Use the requirements to

understand what system is to
eng ineers
be developed

System test Use the requirements to

eng ineers develop validation tests for
the system

System Use the requirements to help

maintenance understand the system and
eng ineers the relationships between its
par ts

04/24/23 CSC430-Fall 2019 Prof. Zhanyang Zhang 19

 IEEE requirements standard
Defines a generic structure for a requirements document
that must be instantiated for each specific system.
Introduction.
General description.
Specific requirements.
Appendices.
Index.

04/24/23 CSC430-Fall 2019 Prof. Zhanyang Zhang 20

Requirements document structure
Preface
Introduction
Glossary
User requirements definition
System architecture
System requirements specification
System models
System evolution
Appendices
Index

04/24/23 CSC430-Fall 2019 Prof. Zhanyang Zhang 21

 IEEE Requirement Document Template

04/24/23 CSC430-Fall 2019 Prof. Zhanyang Zhang 22

 Key points
Requirements set out what the system should do and define
constraints on its operation and implementation.
Functional requirements set out services the system should
provide.
Non-functional requirements constrain the system being
developed or the development process.
User requirements are high-level statements of what the system
should do. User requirements should be written using natural
language, tables and diagrams.

04/24/23 CSC430-Fall 2019 Prof. Zhanyang Zhang 23

 Key points
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.

04/24/23 CSC430-Fall 2019 Prof. Zhanyang Zhang 24