Lecture 9-I

Requirement Engineering

CS-321
Instructor: Naveed Anwer Butt
University Of Gujrat

1
 – Software Requirements –
Descriptions and specifications of a system

Objectives:
 To introduce the concepts of user and system requirements

 To describe functional / non-functional requirements

 To explain two techniques for describing system requirements

 To explain how software requirements may be organised in a

requirements document
2
 Overview
 What is it?
 Who does it?
 Why is it important?
 What are the tasks?

3
 Requirements engineering
Requirements engineering is the process of establishing
 the services that the customer requires from a system

 the constraints under which it operates and is developed

Requirements
The descriptions of the system
services and constraints
that are generated during the
requirements engineering
process

4
 What is it?
 Helps software engineer to better understand the
problem they will work to solve
 What the business impact of the software will be
 What the customer wants
 How end-user will interact with the software

5
 Who does it?
 Software engineers
 System engineers or analysts
 Project stakeholders
 Anyone who has a direct interest in or benefits from the system
that is to be developed
 Manages
 Customer
 End-users

6
 Role of a system analyst
 The following basic questions pertaining to the project should be clearly understood
by the analyst in order to obtain a good grasp of the problem:

 What is the problem?

 Why is it important to solve the problem?

 What are the possible solutions to the problem?

 What exactly are the data input to the system and what exactly are the
data output by the system?

 What are the likely complexities that might arise while solving the
problem?

 If there are external software or hardware with which the developed

software has to interface, then what exactly would the data interchange
formats with the external system be? 7
 Why is it important?
 Are you going to design and building an elegant software
that is not what the customer wants?
 It establishes a solid base for design and construction
 It is a bridge to design and construction

8
What is a Requirement

 A condition or capability needed by a user to solve problem or achieve an

objective [IEEE]
 Requirements are capabilities and conditions to which the system - and
more broadly the project must conform [JBR99]
 Software requirements express the needs and constraints that are placed
upon a software product that contribute to the satisfaction of some real
world application [Kot00].
 Requirements describe how a system should act, appear or perform

9
 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

10
Requirements vs. Requirement Engineering

The descriptions of the

services and constraints
are the requirements
for the system

The process of finding out,

analyzing, documenting
and checking these
services and constraints
is called
requirements engineering

11
 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

12
 Levels of Software Requirements
 Business Requirements
 State high level business objective or customer requesting the
system
 User Requirements
 Focus on user defined tasks in order to fulfill the business
requirements
 Functional Requirements
 Non-Functional Requirements

13
 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

14
 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.
 Describes the interaction of software with its environment and
specify the inputs, outputs, external interfaces, and the function that
should not be included.

View of a system performing a set of functions

15
 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.

16
 Contd……
 The user of the bank should be able to search the
desired services from the available ones.
 There should be appropriate documents for users to
read. This implies that when a user wants to open an
account in the bank, the forms must be available so that
the user can open an account.
 After registration, the user should be provided with
unique acknowledgement number so that he can later be
given an account number.
!... Functional requirements should be Complete and Consistence…!z

17
 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 very difficult or impossible to produce
a complete and consistent requirements document

18
 STEP 1
 Identifying functional requirements from a problem
description
 The high-level functional requirements often need to be identified
either from an informal problem description document or from a
conceptual understanding of the problem.
 Functional requirements actually describe a set of high-level
requirements
 Each high-level requirement might consist of several other
functions.

19
 STEP 2
 Documenting functional requirements
 Example: - Withdraw Cash from ATM
 R1: withdraw cash
 R1.1 select withdraw amount option
 Input: “withdraw amount” option
 Output: user prompted to enter the account type
 R1.2: select account type
 Input: user option
 Output: prompt to enter amount
 R1.3: get required amount
 Input: amount to be withdrawn in integer values greater than 100 and less
than 10,000 in multiples of 100.
 Output: The requested cash and printed transaction statement.
 Processing: the amount is debited from the user’s account if sufficient
balance is available, otherwise an error message displayed.

20
 Non-functional requirements
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

21
 Nonfunctional requirements
 Non functional requirements deal with the characteristics of the
system which can not be expressed as functions - such as the
maintainability of the system, portability of the system, usability of
the system, etc.
 constraints on the services or functions offered by the system such as
timing constraints, constraints on the development process,
standards, etc.
 Nonfunctional requirements may include:
 reliability issues
 accuracy of results
 human - computer interface issues
 constraints on the system implementation, etc.

22
 Domain requirements
 Derived from the application domain and describe system
characteristics and features that reflect the domain

 May be new functional requirements, constraints on existing

requirements or define specific computations
 If domain requirements are not satisfied, the system may be
unworkable
 Include any constraint present in the existing functional
requirements.
 It may contain a design constraint that describes the user interface.
 Copyright restrictions and security mechanism for the files and
documents used in system

23
Library system domain requirements
 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 user’s requirements, these
documents will either be printed locally on the system server for
manually forwarding to the user or routed to a network printer.

24
 Contd…..
 When domain requirements are not expresses clearly, it
can result in various difficulties such as:
 Problem of Understandability
 Difficult to understand when specified in the language of
application domain (Such as mathematical expressions)
 Problem of implicitness
 Due to incomplete information (not express clearly) creates
problem for development team

25
 User requirements

 Should describe functional and non-functional

requirements so that they are understandable by system
users who don’t have detailed technical knowledge

 User requirements are defined using natural

language, tables and diagrams

26
 Problems with natural language
 Lack of clarity
 Precision is difficult without making the document
difficult to read
 Requirements confusion
 Functional and non-functional requirements tend to
be mixed-up
 Requirements amalgamation
 Several different requirements may be expressed
together

27
Decision tree representation

28
Decision Table

29
 Guidelines for writing requirements

 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 let highlighting to identify key parts of the requirement

Avoid the use of computer jargon !!!

30