Overview of Software Requirements

Descriptions and specifications of a system and

the process whereby they are derived
Objectives

To introduce the concepts of user and system requirements

To describe functional and non-functional requirements
To describe the principal requirements engineering
activities
To introduce techniques for requirements elicitation and
analysis

Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 1

Requirements engineering

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
Requirements specify what the system is supposed to
do, but not how the system is to accomplish its task

Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 2

What is a requirement?

It may span a wide range of statements

from a high-level abstract statement of a service or of a system constraint

to a detailed mathematical functional specification

Types of requirements

User requirements
System requirements
Software specifications provide more (design) detail

Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 3

User requirements

Should describe functional and non-functional

requirements so that they are understandable by
system users who dont have detailed technical
knowledge
User requirements are defined using natural language,
tables, and diagrams
Problems with natural language

Precision vs. understandability

Functional vs. non-functional requirements confusion
Requirements amalgamation

Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 4

System requirements

More detailed specifications of user requirements

Serve as a basis for designing the system
May be used as part of the system contract
System requirements may be expressed using system
models discussed on January 30

Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 5

Definitions and specifications

Re q u i re me n ts d e f i n iti on
1 . Th e s oft w a re m u st pro v id e a m e a ns o f re pr e se n ti ng a n d
1 . a c c e ss in g e x te rna l fi le s c re a t ed by othe r t oo ls .
Re q u i re me n ts s p e c ifi c ati on
1 .1 The us e r sh ou ld b e pro v id ed w it h fa c ili ti e s to de fi ne th e ty pe of
1 .2 e x te rna l fi le s.
1 .2 Ea c h e x te rna l f i le t yp e m a y hav e a n a ss oc i at ed t oo l w h ic h m a y be
1 .2 a p pl ie d to th e f i le.
1 .3 Ea c h e x te rna l f i le t yp e m a y be re pre sen te d a s a s pe c i fic i c on o n
1 .2 t he u se rs di sp la y.
1 .4 Fa c il it ie s s ho ul d b e p r ov id ed fo r th e ico n re pr e se n ti ng a n
1 .2 e x te rna l fi le t yp e t o b e d e fin e d by th e us e r.
1 .5 Wh en a u se r se l e c ts a n ic o n r e pr e se n ting a n e x te rna l fi le, th e
1 .2 e ffe c t of th a t s e le c t io n is to a p pl y t he to ol a ss oc i a te d w it h t he ty pe o f
1 .2 t he e x te rn a l fil e to t he fi le re pre s e nt e d b y th e se l e c te d i c on .
Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 6

Functional and non-functional requirements

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

Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 7

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 accounts permanent storage area.

Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 8

Requirements precision, completeness, and

consistency

In principle requirements should be precise, complete,

and consistent
Precise

Complete

They should include descriptions of all facilities required

Consistent

They should state exactly what is desired of the system

There should be no conflicts or contradictions in the descriptions of

the system facilities

In practice, it is very difficult to produce a complete

and consistent requirements document
Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 9

Ambiguous/imprecise requirement
4.A.5 The database shall only support the generation and
control of configuration objects; that is, objects which are
themselves groupings of other objects in the database. The
configuration control facilities shall allow access to the objects
in a version group by the use of an incomplete name.
What about non-configuration objects?
What about other database functionality?
What about level of service other than support?
Something else?
Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 10

Non-functional requirement types

Non-functional
requir ements

Product
requir ements

Ef ficiency
requir ements

Reliability
requir ements

Usability
requirements

Performance
requirements

Or ganizational
requir ements

Portability
requirements

Delivery
requirements

Interoperability
requirements

Implementation
requir ements

Space
requir ements
Ian Sommerville 2000

External
requirements

Software Engineering, 6th edition.

Ethical
requirements

Standards
requirements

Legislative
requirements

Privacy
requirements

Safety
requirements
Slide 11

Non-functional requirements examples

Product requirement

Organisational requirement

4.C.8 It shall be possible for all necessary communication between the APSE
and the user to be expressed in the standard Ada character set
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

Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 12

Non-functional requirements measures

Pro perty
Speed
Size
Eas e of u se
Rel iabi li ty

Rob u st ness
P ortabi li ty
Ian Sommerville 2000

Meas ure
P ro cess ed t rans acti o ns /s econ d
User/ Event res po n se ti me
Screen refresh t ime
K By tes
Nu mb er o f RAM ch ip s
Train in g time
Nu mb er o f h elp frames
Mean ti me t o failu re
P ro b ab il ity o f u n av ailab ili ty
Rat e of failu re o ccu rren ce
Av ai lab i lit y
Time to rest art aft er failu re
P ercent ag e o f event s caus in g fail ure
P ro b ab il ity o f d ata co rru pt io n on fail ure
P ercent ag e o f targ et d ep end ent st at ement s
Nu mb er o f t arget sy st ems
Software Engineering, 6th edition.

Slide 13

Requirements interaction

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
But, using low power chips may mean that more chips have
to be used
Which is the most critical requirement?
Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 14

Domain Requirement:
Train protection system
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.

Problems

Understandability
Requirements are expressed in the language of the application domain
This is often not understood by software engineers

Implicitness
Domain specialists understand the area so well that they do not think of
making the domain requirements explicit
Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 15

Requirements document requirements

Specify external system behaviour

Specify implementation constraints
Easy to change
Serve as reference tool for maintenance
Record forethought about the life cycle of the system

i.e. predict changes

Characterise responses to unexpected events

Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 16

Users of a
requirements
document

System customers

Specify the requirements and

read them to check that they
meet their needs. They
specify changes to the
requirements

Managers

Use the requirements

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

System engineers

Use the requirements to

understand what system is to
be developed

System test
engineers

Use the requirements to

develop validation tests for
the system

System
maintenance
engineers

Use the requirements to help

understand the system and
the relationships between its
parts

Requirements engineering process

Feasibility
study

Requirements
elicitation and
analysis

Requir ements
specification

Feasibility
report

Requirements
validation
System
models
User and system
requirements
Requirements
document

Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 18

Feasibility studies

A feasibility study decides whether or not the

proposed system is worthwhile
A short focused study that checks

If the system contributes to organisational objectives

If the system can be engineered using current technology and
within budget
If the system can be integrated with other systems that are
used

Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 19

Elicitation and analysis

Sometimes called requirements elicitation or

requirements discovery
Involves technical staff working with customers to
find out about

the application domain

the services that the system should provide
the systems operational constraints

May involve end-users, managers, engineers involved

in maintenance, domain experts, trade unions, etc.

These are called stakeholders

Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 20

Problems of requirements analysis

Stakeholders dont know what they really want

Stakeholders express requirements in their own terms
Different stakeholders may have conflicting
requirements
Organisational and political factors may influence the
system requirements
The requirements change during the analysis process

New stakeholders may emerge and the business environment

change

Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 21

System models

Different models may be produced during the

requirements analysis activity
Requirements analysis may involve three structuring
activities which result in these different models

Partitioning Identifies the structural (part-of) relationships between entities

Abstraction Identifies generalities among entities
Projection Identifies different ways of looking at a problem

System models will be covered on January 30

Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 22

Scenarios

Scenarios are descriptions of how a system is used in

practice
They are helpful in requirements elicitation as people
can relate to these more readily than abstract
statement of what they require from a system
Scenarios are particularly useful for adding detail to
an outline requirements description

Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 23

Requirements validation

Concerned with demonstrating that the requirements

define the system that the customer really wants
Requirements error costs are high so validation is very
important

Fixing a requirements error after delivery may cost up to 100 times the
cost of fixing an implementation error

Requirements checking

Validity
Consistency
Completeness
Realism
Verifiability

Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 24

Requirements validation techniques

Reviews

Prototyping

Using an executable model of the system to check requirements.

Test-case generation

Systematic manual analysis of the requirements

Developing tests for requirements to check testability

Automated consistency analysis

Checking the consistency of a structured requirements description

Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 25

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

The requirements engineering process includes a

feasibility study, requirements elicitation and analysis,
requirements specification and requirements
management
Requirements validation is concerned with checks for
validity, consistency, completeness, realism and
verifiability
Ian Sommerville 2000

Software Engineering, 6th edition.

Slide 26