Spring 2022

Instructor: Dr. Ali Arshad

1. Understand of the importance of requirements
engineering process

2. Effectively gather and analyze software

requirements for the development of cost-
effective and efficient technical solutions

3. Use system modeling techniques for

requirements analysis and requirements
presentation
 Textbook
 Roger S. Pressman, Bruce R. Maxim, “Software
Engineering: A Practitioner’s Approach”, 8th Ed,
McGraw-Hill Education, 2015.

 References Material:
 Elizabeth Hull, Ken Jackson and Jeremy Dick.
“Requirements Engineering”, 3rd Ed, Springer-
Verlag London Limited, 2011.
 Your grade will be evaluated based on your
individual assignments, quizzes, midterms
and final exams.
▪ Quizzes 10%
▪ Assignment 05%
▪ Midterm 25%
▪ Final Exam 50%
▪ PBL 10%
 Software Engineering vs Other Engineering
 Ad hoc Software Development
 Software Process Model
• Waterfall model.
• Prototype Model
• Component-Based development model (CBSE).
• Agile Models.
 7

Waterfall Model
Requirements

Design

Code & Unit

Test
Test &
Integration
Operations &
Maintenance
 Requirements form the basis for all software
products.
 Requirements are the base of the product
 Requirements should be gather critically
 All product quality lies on the requirements
 RE is the process which enables us to systematically
determine the requirements for a software product.
 RE is a process in which we do the gathering of requirements in
structure way.
 A complete description of what the software
system will do without describing how it will
do it is represented by Software requirements
 Software Requirement Engineering gives set of rules
for gathering the requirements

 Software requirements are the complete

specification of the desired external behavior of
the software system to be built
 In requirement engineering we have to give
complete picture of software, when it is
developed what it will do
 RE does not tell how the software will work
 Requirements should be written in such a way
that the reader can understand what Software will
do.
 RE does not tell how the software will be build.
 A condition or capability that must be met or
possessed by a system ….to satisfy a
contract, standard, specification, or other
formally imposed document.
IEEE std 729
 Stakeholders
 People who are going to use the software
 Documents
 Existing Systems
 Domain/Business area
 Suppose we are going to build the software for
shop, keeping the record of all entries of sale and
day end calculate the profit and maintain the
ledger
 The hardest single part of building a software
system is deciding what to build ….no other
part of the work so cripples the resulting
system if done wrong. No other part is
difficult to rectify later.
[Fred Brooks]
 The system shall maintain records of all
payments made to employees on accounts
of salaries, bonuses, travel/daily allowances,
medical allowances etc.
 The system shall maintain records of all
library materials including books, serials,
newspapers, and magazines, video and audio
tapes, DVDs etc.
 The System shall allow the user s to search
for an item by title, author, or by international
standard book number
 The system should support at least twenty
transactions per second
 The system facilities which are available to
public users shall be demonstrable in ten
minutes or less
 A software requirement can be of 3 types

1. Functional requirements.
2. Non-functional requirements.
3. Domain requirements.
 21

1. Functional Requirements
 What requirements (What the product must do).

 Describe functionality or system services (what are the inputs, the

outputs and expectations).

 Depend on the type of software, expected users and the type of

organization where the system is developed.
 22

1. Functional Requirements

 Functional requirements can be:

 User requirements are high-level statements of what the system should do.

 System requirements should describe the system services in detail.

 23

The LIBSYS Case Study

 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.
 24

Example 1:

The user shall be able to search either

all of the initial set of databases
or select a subset from it.
 25

Example 2:

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.
 Example 3:
• The system shall solve the quadratic equation
using the following formula:
x=(-b+sqrt(b2-4*a*c))/2*a
 Example 4 :
• The user shall be able to search either the
entire database of patients or select a subset
from it (admitted patients, or asthma patients
etc.)
 Example 5:
• The system shall provide appropriate viewers
for the user to read documents in the
document store
 Example 6:
• Every order shall be with a unique identifier
which the user shall use to access the order
 Example 7:
• The system shall allow customers to return
non-perishable items within fifteen days of
purchase. The customer must present the
original sale receipt to return the order
 Functional Requirements
• Incomplete and ambiguous requirements are
open to multiple interpretations and
assumptions
• This can lead to the development of poor
quality or faulty, software products
• The level of details are different in all
requirements
 Problems:
• What if a=0 ?
• Graceful degradation
• Two ways:
– Throw an error message
– Ask for an alternate

Requirements have ambiguities

 33

Problems with Requirements

 Problems arise when requirements are not precisely stated

(Ambiguous).

 Ambiguous requirements may be interpreted in different ways by

developers and users.

 Should be complete and consistent.

 34

2. Non-Functional Requirements

System Properties

• Reliability, Response time, Maintainability, Storage requirements.

Constraints

• I/O device capability, Data representations.

Process Requirements

• Mandating a particular CASE system, Programming language or

Development method.
 Non-Functional Requirements:
• Why they are important if they are :Non
Functional
• Have no direct relation with the product’s
functionality but they are important
• Equivalent important as Functional
Requirements
• Quality attributes
• Not the part of software but Software can fail
without them
 36

Types of Non-Functional Requirements

 37

Examples of Non-Functional Requirements

 Product Requirement:
 Requirements which specify that the delivered product must behave in a
particular way e.g. execution speed, reliability, etc

 Organisational Requirement:
 Requirements which are a consequence of organizational policies and
procedures e.g. process standards used, implementation requirements, etc.

 External Requirement:
 Requirements which are a consequence of organizational policies and
procedures e.g. process standards used, implementation requirements, etc.
 38

Question:

Which do you think is more critical,

A functional or non-functional
requirement? Why?
 39

Verifiable Non-Functional Requirements

 Non-functional requirements may be very difficult to state precisely.

 Imprecise requirements may be difficult to verify.

 Therefore we need a statement using some measure that can be

objectively tested.
 40

Verifiable Non-Functional Requirements

 Example: The system shall be easy to use.

 Better expressed as:

Experienced users shall be able to use all the system functions after a
total of two hours training. After this training, the average number of
errors made by experienced users shall not exceed two per day.
 Functional Vs Non Functional
Requirements:
• Functional requirements explain how the
system must work, while non functional
requirements explain how the system should
perform.
 42

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

 Avoid the use of computer jargon.

 43

Why is it important to get it right?

If you don’t do it right you will build a very elegant software solution that
solves the wrong problem.

 the result is project failure, wasted time and money, personnel

frustration, and customer dissatisfaction.
• Requirements that come from the application domain
and reflect fundamental characteristics of that
application domain
▫ These can be both the functional or non-functional
requirements
 These requirements, sometimes, are not explicitly mentioned
 Domain experts find it difficult to convey domain requirements

▫ Their absence can cause significant dissatisfaction

▫ Domain-specific terminology can also cause confusion

• Banking domain has its own specific constraints,

▫ for example, most banks do not allow over-draw on most
accounts, however, most banks allow some accounts to be
over-drawn

44
 Following are some characteristics of domain
requirements:
1. They may be functional or non functional
2. Reflect the characteristics and come from
respective domain
3. Sometimes not explicitly mentioned
4. Absence of these can cause significant
dissatisfaction
5. Sometimes pose strict constraint on system.
• They explain what the system shall not do.
▫ Many people find it convenient to describe their
needs in this manner
• These requirements indicate the indecisive
nature of customers about certain aspects of
a new software product
▫ Example:
 The system shall not use red color in the user interface,
whenever it is asking for inputs from the end-user

46
• They are development guidelines within
which the designer must work
▫ These requirements can seriously limit design and
implementation options
 Can also have impact on human resources
▫ Example
 The system shall be developed using the Microsoft .Net
platform
 The system shall be developed using open source tools
and shall run on Linux operating system
47
 The requirements don’t reflect the real needs of the
customer for the system.
 Requirements are inconsistent and/or incomplete
 It is expensive to make changes to requirements after they
have been agreed upon.
 There are misunderstandings between customers, those
developing the system requirements, and software
engineers developing or maintaining the system

48
• Requirement specification in natural language
pose some problems which include
▫ Lack of clarity
▫ Requirements confusion
▫ Requirements amalgamation
• Natural language understanding relies on the
specification readers and writers using the same
words for same concept
▫ A natural language requirements specification is over-
flexible.
“You can say the same thing in completely
different ways”
49
• When the requirements are wrong, system
are late, unreliable and don't meets the
customer need.

• This results enormous loss of time, revenue,

market share and trust of the customer

50
 51

Structure of the SRS document

 Preface.
 Introduction.
 Glossary.
 User requirements definition.
 System requirements specification.
 System models.
 Appendices.
 Index.
 a) Correct = correct if, and only if, every requirement stated there in is one that the software shall meet.
 b) Unambiguous; = every requirement stated therein has only one interpretation
 c) Complete;= All significant requirements, whether relating to functionality, performance, design
constraints. Definition of the responses of the software to all classes of input data in all possibilities of situations,
attributes, or external interfaces. Full labels and references to all figures, tables, and diagrams.
 d) Consistent;= Consistency refers to internal consistency. If an SRS does not agree with some higher-level
document, such as a system requirements specification, then it is not correct
 e) Prioritize;= if each requirement in it has an identifier to indicate either the importance or stability of that
particular requirement.
 f) Verifiable;= requirement is verifiable if, and only if, there exists some finite cost-effective process with
which a person can check that the software product meets the requirement
 g) Modifiable;= any changes to the requirements can be made easily, completely, and consistently while
retaining the structure
 h) Traceable;= if the origin of each of its requirements is clear and if it facilitates the referencing of each
requirement in future development or enhancement documentation

52
Requirements Of Parking System:
Req-1: Log on to the parking system.
Req-2: Enter vehicle number and Identify row number.
Req-3: Issue ticket.
Req-4: Identify person for log out to system.
Req-5: Check ticket.
Req-6: Identify payment method.
Req-7: Check vehicle number.
Req-8: Log out to system.

53
 Issue ticket to vehicle user when he requests.

I. Issue Ticket .
Log on to the library system by entering your
II. Log on to library system. username and password on login screen.

III. Check ticket. Who is checking ticket.?? Guard or software or by

what method this checking is done?? And at what
time this checking is done..? before leaving or
IV. Match the vehicle number. what?

V. Update library record after new entry. Tickets are checked by the parking guard before
the vehicle leaves the parking. Ticket holder and
vehicle number is validated by matching the id
VI. Entrance of vehicle and record its number in the list . card number and vehicle registration number.

VII. Search catalog . When we are checking the vehicle number ? Either
before entering the parking or at time of leaving the
VIII. Id of student is matched & book is issued to student. parking..? or this process is being followed at both
times? Specify that ..

IX. Issue book and update record . You are merging two requirements either state
them separately or identify them by using sub
X. Log out from the system. heading/sub bullets. Like;

Req-1. Allow entrance to vehicles which have

verified tickets by opening the parking gate.

Req1.1. record the number of entered vehicles in

Search on what basis..???? the database/record.
54
 55

Requirements Engineering Process

 “The process of establishing the services that the customer requires

from a system and the constraints under which it operates and is
developed.”

 The result is a specification: “representing the requirements in a

manner that ultimately leads to successful software implementation.”
 56

Requirements Engineering Process

Requirements
Feasibility elicitation and
study analysis
Requirements
specification
Feasibility Requirements
report validation

System
models

User and system

requirements

Requirements
document

Requirements Management
 57

Requirements Engineering Process

1. Feasibility Study

 A feasibility study decides whether or not the proposed system is useful.

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