Lecture 1

Software Requirements

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1

Objectives
 To introduce the concepts of user and system
requirements
 To describe functional and non-functional
requirements
 To explain two techniques for describing system
requirements
 To explain how software requirements may be
organised in a requirements document

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 2

Topics covered
 Functional and non-functional requirements
 User requirements
 System requirements
 The software requirements document

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 3

Requirements engineering
 Software Requirements: Descriptions and
specifications of a system
 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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 4

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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 5

Requirements abstraction (Davis)

“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 organisation’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.”

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 6

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
services. Written as a contract between client and contractor
 Software specification
• A detailed software description which can serve as a basis for a
design or implementation. Written for developers

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 7

Definitions and specifications
Requirements definition

1. The software must provide a means of repr esenting and

1. accessing external files created by other tools.

Requirements specification

1.1 The user should be provided with facilities to define the type of
1.2 external files.
1.2 Each external file type may have an associated tool which may be
1.2 applied to the file.
1.3 Each external file type may be represented as a specific icon on
1.2 the user’s display.
1.4 Facilities should be provided for the icon repr esenting an
1.2 external file type to be defined by the user.
1.5 When a user selects an icon repr esenting an external 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.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 8

Requirements readers
Client managers
System end-users
User requirements Client engineers
Contractor managers
System architects

System end-users
Client engineers
System requirements
System architects
Software developers

Client engineers (perhaps)

Software design
System architects
specification
Software developers

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 9

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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 10

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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 11

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.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 12

Requirements imprecision
 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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 13

Requirements completeness and consistency

 In principle requirements should be both complete

and consistent
 Complete
• They should include descriptions of all facilities required
 Consistent
• 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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 14