Chapter 3

Software requirement engineering

Outlines

 Functional and non-functional requirements

 User requirements
 System requirements
 Interface specification
 The software requirements document
Requirements engineering

 The process of formulating, documenting and maintaining

software requirements
 Requirement engineering activities: -
 Requirement inception/requirement elicitation
 Requirement identification (practice to collect info)
 Requirement analysis & negotiation
 System modelling (e.g. UML)
 Requirement validation
 Requirement management (e.g. managing changes)
What is a requirement?

 Requirement are descriptions of the services that a software system must

provide and the constraints under which it must operate
 Requirements may serve a dual function
 Basis of a bid for a contract
 Basis for the contract itself
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 & contractor
Types of requirement

 Software specification
 A detailed software description which can serve as a basis for a
design or implementation
 Written for developers.
Example of definitions and specifications

User requirement definition

 The software must provide means of representing and accessing external files created by
other tools

System requirements specification

 The users should be provided with facilities to define the type of external files
 Each external type may have an associated tool which may be applied to the file
 Each external file type may be represented as a specification on the user’s display
 Facilities should be provided for the icon representing an external file to be defined by the
user
 When a user selects an icon representing an external file, the effect of that selection is to
apply to the associated with the type of the external file to the file represented by the
selected icon
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.
Functional and non-functional
requirements
 Domain requirements
 Requirements that come from the application domain of the
system and that reflect characteristics of that domain.
 May be functional or non-functional
 Example: The requirement of insulin pump system that delivers
insulin on demand include the following domain requirement:-
 The system safety shall assured according to standard IEC 60601
Examples of functional requirements :
ATM system
 The system should allow the user to check for his or her bank account balance
 The user will be able to withdraw money from his or her bank account,
 In case of an invalid ATM card, the system should eject the card and show an
error message to the user.
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.
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.

 Non-functional requirements may be more critical than functional

requirements. If these are not met, the system is useless.
Non-functional requirements examples

 Product requirement
 The user interface for LIBSYS shall be implemented as simple
HTML without frames or Java applets.
 Organisational requirement
 The system development process and deliverable documents shall
conform to the process and deliverables defined in XYZCo-SP-
STAN-95.
Non-functional requirements examples

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

 Describe system characteristics and features that reflect the domain

 May be new functional requirements, constraints on existing requirements or
maybe define specific computations
 If domain requirements are not satisfied, the system may be unworkable
Example: Library System
Property Measure
Speed Processed transactions/s
User/event response time
Screen refresh time
Size Kbytes
Number of RAM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness % events causing failure
Time to restart after failure
Probability of data corruption on failure

Portability % target system dependent statement

Number of target systems
Domain requirement issues

 Understandability
 Requirement are expressed in language of the application domain
 Often not understand by software engineers developing the system
 Implicitness
 Domain specialists understand the are so well they do not think of
making the domain requirement explicit
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.
User Requirements

 Should describe functional & non-functional requirements so that they are

understandable by system users don’t have detailed technical knowledge
 User requirements are defined using NL, table & diagram
Problems with natural language

 Ambiguity
 Readers & writers may not interpret words in the same way
 Over flexibility
 The same thing may be expressed in a number of different ways
 Requirements amalgamation & confusion
 Several different requirements may be expressed together;
functional and non-functional requirements may be mixed
together
Problems with natural language

 Lack of modularisation
 NL structures are inadequate to structure system requirements
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.
Graphical models

 Graphical models are most useful when you need to show how state changes
or where you need to describe a sequence of actions.
Sequence diagrams

 These show the sequence of events that take place during some user
interaction with a system.
 You read them from top to bottom to see the order of the actions that take
place.
 Cash withdrawal from an ATM
 Validate card;
 Handle request;
 Complete transaction.
 Sequence diagram of ATM
withdrawal ATM Database

Card
Card number

Card OK
PIN request
PIN
Option menu Validate card

<<exception>>
invalid card

Withdraw request Balance request

Balance
Amount request
Handle request
Amount
Debit (amount)
Fig. 3.1: Sequence diagram <<exception>> Debit response
for ATM withdrawal insufficient cash

Card
Card removed
Complete
Cash transaction

Cash removed
Receipt
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
Users of a requirements document
Specify the requirement and read them to
System customer check that they meet their needs. They
specify changes to the requirements

Use the requirements document to plan a bid

Managers for the system and to plan the system
development process

Use the requirement to understand what

System engineers
system is to be developed

Use the requirement to develop validation test

System test engineers
for the system

System maintenance Use the requirement to help understand the

engineers system and the relationship between its parts
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.
Requirements document structure

 Preface
 Introduction
 Glossary
 User requirements definition
 System architecture
 System requirements specification
 System models
 System evolution
 Appendices
 Index