Wollo University

College Informatics
Department of Computer Science
Fundamentals of Software Engineering
Course Code: CoSc3061

1 07/02/2022
 Chapter- 3
Requirement Engineering

07/02/2022 2
 Why RE in Sys Eng?
System Engineering = Engineering System

 A system is a set of interacting or

interdependent components forming an
integrated whole.
 A system is a set of elements (often called
‘components’ instead) and relationships which
are different from relationships of the set or
its elements to other elements or sets.

07/02/2022 3
 Why RE in SysEng?
 The term system may also refer to a set of
rules that governs structure and/or behavior.

 Engineering is the discipline, art, skill and

profession of acquiring and applying
scientific, mathematical, economic, social, and
practical knowledge, in order to design and
build structures, machines, devices, systems,
materials and processes.
07/02/2022 4
 Why RE in SysEng?
Requirements Engineering is raising and
answering questions:
 Why do we need a System?
 What should a System be like?
 How do we go about building a System?
A variety of RE: RE for software system, RE for
hardware, RE for enterprise, …

07/02/2022
 Why RE?
Software Lifecycle Revisited
Project Planning
Systems Engineering and Mgmt

Requirements Analysis Software Process

Forward
Engineering Software Architecture and Design

Configuration
Implementation
Management
Reverse
Engineering Testing
Evolution and
SQA and Metrics Re-engineering

Maintenance
07/02/2022 6
 Cont’d

• Requirements form the basis for all software products.

• It is a feature that the system must have or a
constraint that it must satisfy to be accepted by the
customer.
• Requirements engineering is the process, which
enables us to systematically determine the
requirements for a software product.

07/02/2022 7
 Requirement
• Something required, something wanted or
needed.
– Webster’s dictionary
• There is a huge difference between wanted
and needed and it should be kept in mind all
the time.

07/02/2022 8
 Software Requirements
• A complete description of what the software
system will do without describing how it will do.
• Software requirements are complete
specification of the desired external behavior
of the software system to be built.
• They also represent External behavior of the
system.

07/02/2022 9
 Software Requirements Cont…

• Software requirements may be:

– Abstract statements of services and/ constraints.
– Complete mathematical functions.
– Part of the proposal of contract.
– The contract itself.
– Part of the technical document, which describes a
product.

07/02/2022 10
 IEEE Definition of Requirement
IEEE Standard Glossary of Software Engineering
Technology:

A requirement is:
1. A condition or capability needed by a user to solve
a problem or achieve an objective.

2. A condition or capability that must be met or

possessed by a system or system component to
satisfy a contract, standard, specification, or
other formally imposed document.

3. A documented representation of a condition of

capability as in 1 or 2.
07/02/2022 11
 Requirement Bridge
System
Business
development
domain
domain

 Customers understand the business domain.

 Developers understand the systems development domain.
 Requirements are try to bridge the Gap.

07/02/2022 12
 Example1
Course Example

“Write a program that will read in a list of 200 positive

integers, sort them in ascending order, display the
sorted list and display the average of the numbers”

Requirements
 Read in a list of 200 positive integers
 Sort the list of integers in ascending order
 Display the average of the numbers

07/02/2022 13
 Sources of Requirements
• Stakeholders
– People affected in some way by the system

• Documents
• Existing system

• Domain/business area

07/02/2022 14
 Kinds of Software Requirements
• Functional requirements
• Non-functional requirements
• Domain requirements
• Inverse requirements
• Design and implementation constraints

07/02/2022 15
 Functional Requirements
• Statements describing what the system does.
• Functionality of the system.
• Statements of services the system should
provide:
– Response/reaction to particular inputs.

– Behavior in particular situation.

07/02/2022 16
 Functional Requirements Cont…

• Functional requirements should be complete and

consistent.
• Customers and developers usually focus all their
attention on functional requirements.
• Example:
• The system shall solve a quadratic equation
using the following formula:
x = (-b+sqrt(b2 – 4*a*c))/2*a

17
07/02/2022
 Comments on Examples
• Notice the ambiguity in the requirement for solving the
quadratic equation.
• The requirement does not speak about the possibility
when the value of ‘a’ is zero.
x = (-b+sqrt(b2 – 4*a*c))/2*a

• Incomplete and ambiguous requirements are open to

multiple interpretations and assumptions.
• This can lead to the development of poor quality, or
faulty, software products.
07/02/2022 18
 Non-Functional Requirements
• Most non-functional requirements relate to the system as a
whole.
• They include constraints on timing, performance, reliability,
security, maintainability, accuracy, the development process,
standards, etc.

07/02/2022 19
 Non-Functional Requirements
• They are often more critical than individual
functional requirements.
• Capture the emergent behavior of the system,
that is they relate to system as a whole.
• Must be built into the framework of the
software product.
• Failure to meet a non-functional system
requirement may make the whole system
unusable.

07/02/2022 20
 Non-Functional Requirements

• For example, if an aircraft system does not

meet reliability requirements, it will not be
certified as ‘safe’.
• If a real-time control system fails to meet its
performance requirements, the control functions
will not operate correctly.

07/02/2022 21
 Non-Functional Requirements
From where we get NFR?
• Non-functional requirements arise through user
needs, because of budget constraints, because of
organizational policies, because of the need of
interoperability with other software and hardware
systems, or because of external factors such as
safety regulations, privacy legislation, etc.

07/02/2022 22
 Non-Functional Requirements

Non-Functional
requirements

Product Organizational External

requirements requirements requirements

07/02/2022 23
 Non-Functional Requirements
Product Requirements:

Product
requirements

Usability Efficiency Reliability Portability

requirements requirements requirements requirements

Performance Space
requirements requirements

07/02/2022 24
 Non-Functional Requirements
Organizational Requirements:

Organizational
requirements

Standards Implementation Delivery

requirements requirements requirements

07/02/2022 25
 Non-Functional Requirements
External Requirements:

External
requirements

Interoperability Ethical Legislative

requirements requirements requirements

Privacy Safety
requirements requirements

07/02/2022 26
 Non-Functional Requirements
Observations on NFR (Cont…):

• Non-functional requirements should be written in a

quantitative manner as much as possible, which is not
always easy for customers.
• For some goals, there are no quantitative measures,
e.g., maintainability.
• Goals can be useful to designers and developers, as
they give clues to them about priorities of the
customers.

07/02/2022 27
 Non-Functional Requirements
Observations on NFR (Cont…):

• Chances of conflicts within non-functional requirements

are fairly high, because information is coming from
different stakeholders.
• For example, different stakeholders can give different
response times or failure tolerance levels, etc.
• Some negotiations must be done among different
stakeholders, to achieve an agreement in these
situations
07/02/2022 28
 Non-Functional Requirements
Observations on NFR (Cont…)

• Non-functional requirements should be

highlighted in the requirements document, so
that they can be used to build the architecture
of the software product.
• NFRs are very important to capture the
emergent behavior of the system in these
there major dimensions.
07/02/2022 29
 Metrics for NFRs Cont…

Property Measure
Ease of use 1. Training time
2. Number of help frame

Requirements related to “Ease of use” can use different

measures to quantify the goal.
Property Measure
Reliability 1. Mean time to failure
2. Probability of unavailability
3. Rate of failure occurrence
4. Availability

Requirements related to “Reliability” can use different measures to

quantify the goal.
07/02/2022 31
 Metrics for NFRs Cont…

Property Measure
Robustness 1. Time to restart after failure
2. Percentage of events causing failure
3. Probability of data corruption on failure

Requirements related to “Robustness” can use different measures to

quantify the goal.

Property Measure
Portability 1. Percentage of target-dependent statements.
2. Number of target systems.

Requirements related to “Portability” can use different measures to quantify

the goal.
07/02/2022 32
 Domain Requirements
• 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 express domain
requirements.

07/02/2022 33
 Domain Requirements Cont…
• Their absence can cause significant dissatisfaction.

• They can be impose strict constraints on solutions.

• This is particularly true for scientific and engineering domains.

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

07/02/2022 34
 Inverse Requirements
• They explain what the system shall not do.
• Many people find it convenient to describe their needs in
this manner.
• These requirements indicate unconfident 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.

07/02/2022 35
 Design and Implementation Constraints

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

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

07/02/2022 36