HARAMAYA UNIVERSITY

College of Computing and Informatics

Department of Software Engineering

Target Group:- 3rd Year Software Engineering Students

Course Name:- Requirements Engineerin1 g

3/8/2024
Compiled By: Shambel Adugna
REQUIREMENTS ENGINEERING

Compiled By:Shambel Adugna

 CHAPTER -1
BASICS OF SOFTWARE
REQUIREMENTS ENGINEERING

3/8/2024
 INTRODUCTION

▪ The development of computer-based systems has been facing

problems like
• Late delivery
• Over budget
• They don’t do what the users really want and
• They are often never used to their full effectiveness by the people who
have paid for them.

3/8/2024
• The most common reasons for project failures are not technical and
Table 1.1 identifies the main reasons why projects fail.
• The data is drawn from surveys conducted by the Standish Group
in 1995 and 1996, and shows the percentage of projects that stated
various reasons for project failure.
• The problems fall into three main categories:
➢Requirements – either poorly organized, poorly
expressed, weakly related to stakeholders, changing
too rapidly, or unnecessary; unrealistic expectations
➢Management problems of resources – failure to have
enough money, and lack of support, or failure to
impose proper discipline and planning, many of these
arise from poor requirements control
➢ Politics – which contributes to the first two problems
3/8/2024
3/8/2024
3/8/2024
• Because there are so many different types of requirements, it
isn’t possible to describe a standard way of writing
requirements or to define the ‘best’ way to specify
requirements.

• It depends on:-
• who is writing the requirements,
• who is likely to read them,
• the general practices of the organization
developing the requirements, and
• the application domain of the system.
3/8/2024
• The problem of writing requirements are universal and there
is no complete solution for these problems.
• But Good Requirements engineering
practices can reduce the number of problems and
minimize their impact on the final system.

3/8/2024
 Requirements Definition
• Requirements are :-
• description of the services provided by the system and its
operational constraints reflecting needs of the customer that
helps to solve their problem.
• condition or a capability possessed by software or system
component in order to solve a real world problem.
• a statement that identifies a product or process operational,
functional, or design characteristic or constraint, which is
unambiguous, testable or measurable, and necessary for
product or process acceptability (by consumers or internal
quality assurance guidelines).
3/8/2024
• IEEE definition
(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 documents.

3/8/2024
 Requirements Engineering
• Requirements Engineering
• is the process of finding out, analyzing,
documenting, and checking services and operational
constraints called requirements for a computer-
based system.
• The Requirements Engineering phase is the first software
engineering activity, which translates the ideas or views into a
requirements document.

3/8/2024
Requirements Engineering Vs Systems
Engineering
• Requirements Engineering the subset of systems
engineering concerned with discovering, developing, tracing,
analyzing, qualifying, communicating and managing
requirements that define the system at successive levels of
abstraction.

• Systems engineering is concerned with systems as a whole

including hardware, software and operational processes.

3/8/2024
 The Systems Engineering Process

System System
requirements validation
engineering

Architectural System
design integration

Requirements Sub-system
partitioning development

Software
requirements
engineering

3/8/2024
 System Engineering Activities
• System requirements engineering
• The requirements for the system as a whole are established and written to be
understandable to all stakeholders
• Architectural design
• The system is decomposed into sub-systems
• Requirements partitioning
• Requirements are allocated to these sub-systems
• Software requirements engineering
• More detailed system requirements are derived for the system software
• Sub-system development
• The hardware and software sub-systems are designed and implemented in parallel.
• System integration
• The hardware and software sub-systems are put together to make up the system.
• System validation
• The system is validated against its
Compiled By:Shambel Adugna
3/8/2024 15
requirements.
 Types of Requirements

Compiled By:Shambel Adugna 16

3/8/2024
• Requirements commonly considered are
classified into two categories

1. Functional requirements
2. Nonfunctional requirements

3/8/2024
1. Functional Requirements
(Behavioral requirements)

• Describe
➢ The functionality or services that software should provide.

➢ The interaction of software with its environment

➢ Functions that should and should not be included in the software.

3/8/2024
• IEEE definition
➢ “a function that a system or component must be able
to perform.”
➢ Should be complete and consistent.
➢ Completeness
✓ all the Functional requirements should defined.
➢ Consistency
✓ all the Functional requirements should be specified
clearly without any contradictory definition.
3/8/2024
2. Non-functional Requirements
(Quality Attributes)
• Related to system attributes, such as reliability and response
time which makes the software to perform efficiently.
• Are not directly related to functions provided by the system
• Arise due to
➢ User requirements
➢ Budget constraints
➢ Organizational policies

3/8/2024
 Classifications of NFR

3/8/2024
3/8/2024
1. Product requirements
• Specify how software product performs.
• comprises
• Efficiency requirements
• the extent of optimal use of resources
• the speed with which system executes and
• the memory consumptions for its operation.
• E.g. The system should be able to operate at
least three times faster than the existing system.
3/8/2024
• Reliability requirements
• acceptable failure rate of the software.
• E.g. The software should be able to operate even if a hazard occurs.
• Portability requirements
• the ease with which software can be transferred
from one platform to another.
• E.g. It should be easy to port software to different operating system
without the need to redesign the entire software.
• Usability requirements:
• the ease with which users are able to learn to operate the
software.
• E.g. The software should be able to provide access to functionality with
fewer keystrokes and mouse clicks.

3/8/2024
2. Organizational requirements

• Derived from the policies and procedures of an organization.

• comprise of the following
• Delivery requirements
• Specify when software and its documentation are to be delivered to the user

• Implementation requirements
• Describe requirements, such as programming language and design method.

• Standards requirements:
• the process standards to be used during software development.

• E.g. The software should be developed using standards specified by ISO (International
Organization for Standardization) and IEEE standards.

3/8/2024
3. External requirements:
• include all the requirements that affect the software or its
development process externally.
• comprise of the following
• Interoperability requirements
• Define the way in which different computer-based systems interact with each
other in one or more organizations.
• Ethical requirements:
• Specify the rules and regulations of the software so that they are acceptable to
users.
• Legislative requirements:
• Ensure that software operates within the legal jurisdiction.
• E.g. Web pages developed for the federal government must comply with the
law for equality of treatment of people with disabilities (obstacle free
Internet, from 1/1/2006)
3/8/2024
Non-functional requirements examples
• Product requirement
• The user interface for LIBSYS shall be implemented as simple HTML
without frames or Java applets.
• Organizational requirement
• The system development process and deliverable documents shall
conform to the process and deliverables defined in XYZCo.
• 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.

3/8/2024
Non-functional requirements (NFR)

• Non-functional requirements define the overall qualities or

attributes of the resulting system.

• Non-functional requirements place restrictions on the product

being developed, the development process, and specify
external constraints that the product must meet.

• Examples of NFR include safety, security, usability, reliability

and performance requirements.
Compiled By:Shambel A.
 NFRs as Goals

• Non-functional requirements are sometimes written as

general goals, which are difficult to verify

• They should be expressed quantitatively using metrics

(measures) that can be objectively tested

Compiled By:Shambel A.
 Metrics for NFRs - 1

Property Measure
Speed 1. Processed
transactions/second
2. Response time
3. Screen refresh time

Requirements related to “Speed” can use different

measures to quantify the goal
Compiled By:Shambel A.
 Metrics for NFRs - 2
Property Measure
Size 1. K bytes
2. Number of function points

Requirements related to “Size” can use different measures

to quantify the goal

Compiled By:Shambel A.
 Metrics for NFRs - 3

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

Requirements related to “Ease of use” can use different

measures to quantify the goal

Compiled By:Shambel A.
 Metrics for NFRs - 4
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.
Compiled By:Shambel A.
 Metrics for NFRs - 5
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.
Compiled By:Shambel A.
 Metrics for NFRs - 6
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

Compiled By:Shambel A.
 Domain Requirement
• Requirement (either functional or non-functional) that come from
the application domain of the system, reflecting characteristics of
the domain. (e.g. physical laws, regulatory standards)

• Domain requirements reflect the environment in which the system

operates.

• Domain requirements may be expressed using specialized domain

terminology or reference to domain concepts.

• Domain requirements are important because they often reflect

fundamentals of the application domain.
Compiled By:Shambel A.
 Examples of Domain requirement

• The hospital management system should support the check-in

and check out for IPD (In Patient) and oPD Out patient
Department
• The GL(general leader) system should have the ability to post
Double entries
• The GL system should have the provision of maintaining chart of
accounts
• System will keep claim records & losses reserves, Financial
Transactions and Claim expense records
• Supporting associate agents at the policy level setup commission
due based on written premium, on invoicing or on premium
payments and generating agent statements
Compiled By:Shambel A.
 Inverse Requirement

• It describes the constraints on allowable behavior.

• In many cases, it is easier to state that certain behavior must
never occur than to state requirements guaranteeing acceptable
behavior in all circumstances.

• In simply which states that something should not be done.

Compiled By:Shambel A.
 Examples of Inverse Requirements

• User ID should only contain digits.

• The system should not use red color in the user
interface, whenever it asking for a input from the user.

Compiled By:Shambel A.
 Quality attributes
• quality attributes can be categorizes in four specific areas linked to
design, runtime, system, and user qualities.

I, Design Qualities

a, Conceptual Integrity: Conceptual integrity defines the consistency and

coherence of the overall design.

b, Maintainability: is the ability of the system to undergo changes.

c, Reusability: Reusability defines the capability for components and
subsystems to be suitable for use in other applications and in other
scenarios.

Compiled By:Shambel A.
 Quality Attributes
II. Run-time Qualities

i,Availability:defines the proportion of time that the system is functional

and working.

ii, Interoperability: is the ability of a system or different systems to

operate successfully by communicating and exchanging information
with other external systems written and run by external parties.

iii, Manageability: defines how easy it is for system administrators to

manage the application.

Compiled By:Shambel A.
 Cont…
Iv, Performance: is an indication of the responsiveness of a system to execute any
action within a given time interval. It can be measured in terms of latency or
throughput.

V, Reliability: is the ability of a system to remain operational over time.

Vi, Scalability: is ability of a system to either handle increases in load without impact
on the performance of the system.

Vii, Security: is the capability of a system to prevent malicious or accidental actions

outside of the designed usage, and to prevent disclosure or loss of information.

Compiled By:Shambel A.
 Cont…

III. System Qualities

i,Supportability: is the ability of the system to provide information helpful

for identifying and resolving issues when it fails to work correctly.

ii,Testability: is a measure of how easy it is to create test criteria for the

system and its components, and to execute these tests in order to
determine if the criteria are met.

Compiled By:Shambel A. 2/19/2022

 Cont…

VI. User Qualities

a, Usability: defines how well the application meets the requirements

of the user and consumer by being intuitive, easy to localize and
globalize, providing good access for disabled users, and resulting in
a good overall user experience.

Compiled By:Shambel A.
 Requirements for Critical Systems
• Critical systems
➢ Systems whose ‘failure’ causes significant economic, physical or human
damage to organizations or people.

➢ There are three principal types of critical system:

➢◻
Business critical systems
- Failure of the system leads to significant economic damage to business

➢ Mission critical systems

- Failure leads to the abortion of a mission

➢◻
Safety critical systems
- Failure endangers human life and causes significant envir2o/1n9/m
Compiled By:Shambel Adugna
3/8/2024 202e
2ntal 2d
8 amage.
• The cost of failure in CS is likely to exceed the cost of the
system itself.
• Examples of CS
• Communication systems such as aircraft radio systems
• Embedded control systems such as air-traffic control systems
• Financial systems such as banking systems
• Criticality attributes
• Reliability
• Availability
• Maintainability
• Safety
• Security
3/8/2024
▪ Reliability
• Number of times a system fails to deliver the specified
services expected by end-users.
• Metrics used
• MTTF – Mean Time To Failure
• time between observed system failures
• Rate of occurrence of Failure – number of failures in a given
time period
▪ Availability (esp. for nonstop systems)
• Determine how likely the system is available to meet a
demand for service when requested by end-users.
• Metrics used
• POFOD – Probability Of Failure On Demand
3/8/2024
▪ Performance
• Constrain the speed of operation of a system.
• Response requirements
• Specify the acceptable response of the system to end-users input.
• E.g. The system should respond to user request for service within 2 seconds.
• Throughput requirements
• Specify the amount of data which must be processed in a given time
• E.g. The system should process at least 10 transactions per second.
▪ Security
• To ensure unauthorized access to the system and its data is not allowed and
ensure the integrity of the system from accidental or malicious damage.
• E.g.
1. The access permissions for system data may only be changed by the
system’s data administrator.
2. 3/8/2024
All external communications between the system’s data server and clients
Compiled By:Shambel Adugna
must be encrypted
• Safety
• Ability to deliver its services in such away the human life and its
environment will not be damaged by the system.
• E.g. The system shall not operate if the external temperature is below
4 degree Celsius.

Compiled By:Shambel Adugna

3/8/2024 32
 Characteristics of Good Requirements
• Complete
◻ Functionality is described completely
• Correct
• According to stakeholders‘ intentions
• Consistent
• There are no two requirements that can not be reached in
one single system
• Testable
• Requirements can be used to generate tests on the final
software.
• Comprehensible
• ◻
Requirements are to be understood by all stakeholders
• Necessary
• Requirement should be needed by customer and user
• Traceable
• Well-Defined
• Requirement can only be understood in one single way
• ◻
Leaves no space for interpretation

3/8/2024
• Maintenance and Service staff: Although their prime responsibility is to
keep the system running once it has been delivered, they do have important
requirements that the system must address in order to help them do their job.

• Product disposers: This is an increasingly important role as environmental

protection legislation develops. Requirements from this source can have a
massive impact on design especially with respect to the materials employed.

• Training personnel: Like the maintenance staff, these people have a vested
interest in making the system easy to use and consequently easy to train people
to use. These people may also require the system to be able to work
simultaneously in a mode where live data and training data can be mixed
without interfering with the safe operation of the system.

3/8/2024
• System buyers: For public services and other large systems, the
person who buys the system may not be involved directly with its
development or operation. They will, though, have an important role
to play in scoping the system from the point of view of cost versus
perceived benefit. For product-based developments, the buyer may be
the actual user, e.g. mobile phone user, car driver etc.

• Sales and marketing: These people have a vital role to play in

formulating the capabilities for new systems, especially for product
based developments, because, for mass produced consumer products,
it is not possible to have access to all potential users.
3/8/2024
• Usability and efficiency experts: These people have a view on
how the system can be optimized to make it efficient in use. These
factors include ergonomics, ease of learning and, where relevant,
ability to be used reliably under pressure (e.g. in air traffic control).

• Operational environment experts: Usually a new system is not

created to work in a “green fields” situation; it will have to inter-
operate with existing systems. There may also be other
environmental aspects such as emission control where the system
must not pollute the environment, and conversely, aspects where the
system must be able to tolerate the environment in which it is placed
(e.g. in extreme weather conditions, submersed in water etc.)
3/8/2024
• Government: Rules, regulations and laws determine and influence
what a system may or may not do.
• Standards bodies: Existing and future standards can affect the
goals of a proposed system. These may be international such as
the GSM mobile phone standards, national standards or internal
company standards.
• Regulatory authorities: These organizations may require that
certain evidence be collected as part of a certification or
authorization process. Examples include the Rail Regulator in the
UK and the Food and Drug Administration (FDA) in the USA.

3/8/2024
Role Description
Domain expert Responsible for providing information about the
application domain and the specific problem in that
domain which is to be solved.
System end-user Responsible for using the system after delivery
Requirements engineer Responsible for eliciting and specifying the system
requirements
Software engineer Responsible for developing the prototype software
system
Project manager Responsible for planning and estimating the
prototyping project

3/8/2024
 Cont…
• The Generic activities common to all processes
• Feasibility Study

• Requirements Elicitation

• Requirements Analysis

• Requirements Specification

• Requirements Validation

• Requirements Management

3/8/2024