Jimma University

Jimma Institute of Technology

Software Engineering Program

Fundentals of Software Engineering

Chapter 3: Requirements Engineering

October, 2025
Outlines
 What is requirements Engineering?
 Software Requirements
 Requirement Engineering Process
 System Models
What is requirements Engineering?
 Requirements engineering (RE) refers to the process of defining, documenting,
and maintaining requirements in the engineering design process.
 Requirements Engineering (RE) is a set of activities concerned with identifying
and communicating the purpose of a software-intensive system, and the contexts
in which it will be used.
 Requirement engineering is the process of establishing the services that the
customer requires from a system and the constraints under which it operates
and is developed.
 Requirement engineering is the process of collecting, validating and
managing the requirements essential for the development of the software,
specified by the clients or the end-users.
 Requirements engineering is the process of conforming engineering designs
to a set of core software requirements.
 Requirement engineering provides the appropriate mechanism to understand
what the customer desires, analyzing the need, and assessing feasibility,
negotiating a reasonable solution, specifying the solution clearly, validating
the specifications and managing the requirements as they are transformed
into a working system.
What is requirements Engineering? …
 Thus, requirement engineering is the disciplined application of proven
principles, methods, tools, and notation to describe a proposed system's
intended behavior and its associated constraints.
 Hence, RE acts as the bridge between the real-world needs of users,
customers, and other constituencies affected by a software system, and the
capabilities and opportunities afforded by software-intensive technologies.
 This is critically important for creating accurate results in software
engineering.
 Requirements engineering is also known as requirements analysis.
 The requirements themselves are the descriptions of the system services
and constraints that are generated during the requirements engineering
process.
 This task is performed at the initial stages of software development.
 Requirement engineering provides the basic idea to the software developer
of what the client or the end-user wants the software to do.
 The requirement engineering process involves a team of software
developers or engineers, business analysts, customers and end-users.
Software Requirements
 Requirement is a condition or capability possessed by the software or
system component in order to solve a real-world problem.
 The problems can be to automate a part of a system, to correct
shortcomings of an existing system, to control a device, and so on.
 IEEE defines requirement as:
 A condition or capability needed by a user to solve a
problem or achieve an objective.
 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.
 Requirements describe how a system should act, appear or perform.
 For this, when users request for software, they provide an approximation of
what the new system should be capable of doing.
 Requirements differ from one user to another and from one business process
to another.
Guidelines for Expressing Requirements
 The purpose of the requirements document is to provide a basis for the
mutual understanding between the users and the designers of the initial
definition of the software development life cycle (SDLC) including the
requirements, operating environment and development plan.
 The requirements document should include the overview, the proposed
methods and procedures, a summary of improvements, a summary of
impacts, security, privacy, internal control considerations, cost
considerations, and alternatives.
 The requirements section should state the functions required in the software
in quantitative and qualitative terms and how these functions will satisfy the
performance objectives.
 The requirements document should also specify the performance
requirements such as accuracy, validation, timing, and flexibility.
 Inputs, outputs, and data characteristics need to be explained.
 Finally, the requirements document needs to describe the operating
environment and provide (or make reference to) a development plan.
Guidelines for Expressing Requirements …
 There is no standard method to express and document requirements.
 Requirements can be stated efficiently by the experience of knowledgeable
individuals, observing past requirements, and by following guidelines.
 Guidelines act as an efficient method of expressing requirements, which
also provide a basis for software development, system testing, and user
satisfaction.
 The guidelines that are commonly followed to document requirements are
listed below:
 Sentences and paragraphs should be short and written in active
voice. Also, proper grammar, spelling, and punctuation should be
used.
 Conjunctions such as ‘and’ and ‘or’ should be avoided as they
indicate the combination of several requirements in one
requirement.
 Each requirement should be stated only once so that it does not
create redundancy in the requirements specification document.
Types of Requirements
 Requirements help to understand the behavior of a system, which is
described by various tasks of the system.
 For example, some of the tasks of a system are to provide a response to
input values, determine the state of data objects, and so on.
 Note that requirements are considered prior to the development of the
software.
 The requirements, which are commonly considered, are classified into
three categories, namely, functional requirements, non-functional
requirements, and domain requirements.
 IEEE defines functional requirements as ‘a function that a system or
component must be able to perform.’
 These requirements describe the interaction of software with its
environment and specify the inputs, outputs, external interfaces, and the
functions that should be included in the software.
 Also, the services provided by functional requirements specify the
procedure by which the software should react to particular inputs or behave
in particular situations.
Types of Requirements …
 To understand functional requirements properly, let us consider the
following example of an online banking system.
 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 a unique
acknowledgement number so that he can later be given an
account number.
Types of Requirements …
 The functional requirements should be complete and consistent.
Completeness implies that all the user requirements are defined.
 Consistency implies that all requirements are specified clearly without any
contradictory definition.
 Generally, it is observed that completeness and consistency cannot be
achieved in large software or in a complex system due to the problems that
arise while defining the functional requirements of these systems.
 The different needs of stakeholders also prevent the achievement of
completeness and consistency.
 Due to these reasons, requirements may not be obvious when they are, ‘first
specified and may further lead to inconsistencies in the requirements
specification.
Types of Requirements …
 The non-functional requirements (also known as quality requirements) are
related to system attributes such as reliability and response time.
 Non-functional requirements arise due to user requirements, budget
constraints, organizational policies, and so on.
 These requirements are not related directly to any particular function
provided by the system.
 Non-functional requirements should be accomplished in software to make it
perform efficiently.
Types of Requirements …
 The description of different types of non-functional requirements is listed
below:
 Product requirements: These requirements specify how software product performs.
Product requirements comprise the following.
 Efficiency requirements: Describe the extent to which the software makes optimal
use of resources, the speed with which the system executes, and the memory it
consumes for its operation. For example, the system should be able to operate at
least three times faster than the existing system.
 Reliability requirements: Describe the acceptable failure rate of the software. For
example, the software should be able to operate even if a hazard occurs.
 Portability requirements: Describe the ease with which the software can be
transferred from one platform to another. For example, it should be easy to port the
software to a different operating system without the need to redesign the entire
software.
 Usability requirements: Describe the ease with which users are able to operate the
software. For example, the software should be able to provide access to functionality
with fewer keystrokes and mouse clicks.
 Organizational requirements: These requirements are derived from the policies and
procedures of an organization. Organizational requirements comprise the following.
Types of Requirements …
 Delivery requirements: Specify when the software and
its documentation are to be delivered to the user.
 Implementation requirements: Describe requirements
such as programming language and design method.
 Standards requirements: Describe the process standards
to be used during software development. For example,
the software should be developed using standards
specified by the ISO and IEEE standards.
 External requirements: These requirements include all
the requirements that affect the software or its
development process externally. External requirements
comprise the following.
Types of Requirements …
 Interoperability requirements: Define the way in which different
computer-based systems will 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 the software operates
within the legal jurisdiction. For example, pirated software
should not be sold.
 Non-functional requirements are difficult to verify. Hence, it is essential to
write non-functional requirements quantitatively, so that they can be
tested. For this, non-functional requirements metrics are used. These
metrics are listed in Table.
Types of Requirements …

Features Measures

Speed  Processed transaction/ second

 User/event response time
 Screen refresh rate

Size  Amount of memory (KB)

 Number of RAM chips.

Ease of use  Training time

 Number of help windows
Types of Requirements …
Types of Requirements …
 Requirements which are derived from the application domain of the system
instead from the needs of the users are known as domain requirements.
 These requirements may be new functional requirements or specify a method to
perform some particular computations.
 In addition, these requirements include any constraint that may be present in the
existing functional requirements.
 As domain requirements reflect the fundamentals of the application domain, it is
important to understand these requirements.
 Also, if these requirements are not fulfilled, it may be difficult to make the
system work as desired.
 A system can include a number of domain requirements.
 For example, it may comprise a design constraint that describes the user
interface, which is capable of accessing all the databases used in a system.
 It is important for a development team to create databases and interface designs
as per established standards.
Types of Requirements …
 Similarly, the requirements of the user such as copyright restrictions and
security mechanism for the files and documents used in the system are also
domain requirements.
 When domain requirements are not expressed clearly, it can result in the
following difficulties.
 Problem of understandability: When domain requirements are specified in
the language of application domain (such as mathematical expressions), it
becomes difficult for software engineers to understand them.
 Problem of implicitness: When domain experts understand the domain
requirements but do not express these requirements clearly, it may create a
problem (due to incomplete information) for the development team to
understand and implement the requirements in the system.
Requirement Engineering Process
 This process is a series of activities that are performed in the requirements
phase to express requirements in the Software Requirements Specification
(SRS)document.
 It focuses on understanding the requirements and its type so that an
appropriate technique is determined to carry out the Requirements
Engineering (RE) process.
 The new software developed after collecting requirements either replaces
the existing software or enhances its features and functionality.
 For example, the payment mode of the existing software can be changed
from payment through hand-written cheques to electronic payment of bills.
 Requirement engineering processes includes:
 Feasibility Study
 Requirement Elicitation and Analysis
 Software Requirement Specification
 Software Requirement Validation
 Software Requirement Management
Requirement Engineering Process …
Feasibility Study
 The objective behind the feasibility study is to create the reasons for
developing the software that is acceptable to users, flexible to change and
conformable to established standards.
 Technical Feasibility: Technical feasibility evaluates the current
technologies, which are needed to accomplish customer requirements within
the time and budget.
 Operational Feasibility: Operational feasibility assesses the range in which
the required software performs a series of levels to solve business problems
and customer requirements.
 Economic Feasibility: Economic feasibility decides whether the necessary
software can generate financial profits for an organization
Requirement Elicitation and Analysis
 It’s a process of interacting with customers and end-users to find out about the
domain requirements, what services the system should provide, and the other
constrains.
 It may also involve a different kinds of stockholders; end-users, managers,
system engineers, test engineers, maintenance engineers, etc.
 This is also known as the gathering of requirements.
 Here, requirements are identified with the help of customers and existing
systems processes, if available.
 Analysis of requirements starts with requirement elicitation.
 The requirements are analyzed to identify inconsistencies, defects, omission, etc.
 We describe requirements in terms of relationships and also resolve conflicts if
any.
Requirement Elicitation and Analysis…
 Effective software development begins with a clear understanding of what
the end-users and stakeholders need.
 Requirement elicitation is the process of gathering, analysing, and
clarifying those needs to ensure the final product aligns with expectations.
It involves engaging with stakeholders, uncovering hidden requirements,
and addressing potential conflicts early in the project life cycle.
 This crucial phase lays the foundation for building a solution that meets
both business goals and user expectations.
 Requirement elicitation goes beyond simply collecting information—it
involves collaboration, communication, and critical thinking.
 Techniques such as interviews, workshops, surveys, and observation are
used to extract both explicit and implicit requirements.
Requirement Elicitation and Analysis…
 The requirements elicitation and analysis has 4 main process

 We typically start by gathering the requirements, this could be done through

a general discussion or interviews with your stakeholders, and also it may
involve some graphical notation.

 Then you organize the related requirements into sub components and
prioritize them, and finally, you refine them by removing any ambiguous
requirements that may rise from some conflicts.
 Here are the 4 main processes of requirements elicitation and analysis.
 It shows that it’s an iterative process with a feedback from each activity to
another. The process cycle starts with requirements discovery and ends with
the requirements document. The cycle ends when the requirements
document is complete.
Requirement Elicitation and Analysis…
Requirement Elicitation and Analysis…
 1. Requirements Discovery
 It’s the process of interacting with, and gathering the requirements from, the
stakeholders about the required system and the existing system (if exist).

 It can be done using some techniques, like interviews, scenarios, prototypes,

etc, which help the stockholders to understand what the system will be like.
 2. Requirements Classification and Organization
 It’s very important to organize the overall structure of the system.
 Putting related requirements together, and decomposing the system into sub
components of related requirements. Then, we define the relationship
between these components.
 What we do here will help us in the decision of identifying the most suitable
architectural design patterns.
Requirement Elicitation and Analysis…
 3. Requirements Prioritization and Negotiation
 We previously explained why eliciting and understanding the requirements
is not an easy process.
 One of the reasons is the conflicts that may arise as a result of having
different stakeholders involved. Why? because it’s hard to satisfy all
parties, if it’s not impossible.
 This activity is concerned with prioritizing requirements and finding and
resolving requirements conflicts through negotiations until you reach a
situation where some of the stakeholders can compromise.
 We shouldn’t reach a situation where a stakeholder is not satisfied because
his requirements is not taken into consideration.

 Prioritizing your requirements will help you later to focus on the essentials
and core features of the system, so you can meet the user expectations. It
can be achieved by giving every piece of function a priority level. So,
functions with higher priorities need higher attention and focus.
 4. Requirements Specification
 The requirements are then documented.
Requirement Elicitation and Analysis …
 Problems of Elicitation and Analysis
 Getting all, and only, the right people involved.
 Stakeholders often don't know what they want
 Stakeholders express requirements in their terms.
 Stakeholders may have conflicting requirements.
 Requirement change during the analysis process.
 Organizational and political factors may influence system
requirements.
Software Requirement Specification
 Software requirement specification is a kind of document which is created
by a software analyst after the requirements collected from the various
sources - the requirement received by the customer written in ordinary
language.
 It is the job of the analyst to write the requirement in technical language so
that they can be understood and beneficial by the development team.
 The models used at this stage include ER diagrams, data flow diagrams
(DFDs), function decomposition diagrams (FDDs), data dictionaries, etc.
 Data Flow Diagrams:
 Data Flow Diagrams (DFDs) are used widely for modeling the
requirements. DFD shows the flow of data through a system.
 The system may be a company, an organization, a set of
procedures, a computer hardware system, a software system, or
any combination of the preceding.
 The DFD is also known as a data flow graph or bubble chart.
Software Requirement Specification…
 Data Dictionaries:
 Data Dictionaries are simply repositories to store information
about all data items defined in DFDs.
 At the requirements stage, the data dictionary should at least
define customer data items, to ensure that the customer and
developers use the same definition and terminologies.
 Entity-Relationship Diagrams: Another tool for requirement specification is
the entity-relationship diagram, often called an "E-R diagram." It is a detailed
logical representation of the data for the organization and uses three main
constructs i.e. data entities, relationships, and their associated attributes.
Software Requirement Validation
 After requirement specifications developed, the requirements discussed in
this document are validated.
 The user might demand illegal, impossible solution or experts may
misinterpret the needs. Requirements can be the check against the following
conditions:
 If they can practically implement
 If they are correct and as per the functionality and specially of
software
 If there are any ambiguities
 If they are full
 If they can describe
Software Requirement Validation …
 Requirements Validation Techniques
 Requirements reviews/inspections: systematic manual analysis of
the requirements.
 Prototyping: Using an executable model of the system to check
requirements.
 Test-case generation: Developing tests for requirements to check
testability.
 Automated consistency analysis: checking for the consistency of
structured requirements descriptions.
Software Requirement Management
 Requirement management is the process of managing changing
requirements during the requirements engineering process and system
development.
 New requirements emerge during the process as business needs a change,
and a better understanding of the system is developed.
 The priority of requirements from different viewpoints changes during
development process.
 The business and technical environment of the system changes during the
development.
 Collection of software requirements is the basis of the entire software
development project.
 Hence, they should be clear, correct, and well-defined.
 A complete Software Requirement Specifications should be:
 Clear
 Correct
 Consistent
 Coherent
 Comprehensible
Software Requirement Management…
 Verifiable
 Prioritized
 Unambiguous
 Traceable
 Credible source
 Software Requirements: Largely software requirements must be categorized
into two categories:
 Functional Requirements: Functional requirements define a
function that a system or system element must be qualified to
perform and must be documented in different forms. The
functional requirements are describing the behavior of the system
as it correlates to the system's functionality.
Software Requirement Management …
 Non-functional Requirements: This can be the necessities that specify the
criteria that can be used to decide the operation instead of specific behaviors
of the system.
 Non-functional requirements are divided into two main categories:
 Execution qualities like security and usability, which are
observable at run time.
 Evolution qualities like testability, maintainability, extensibility,
and scalability that embodied in the static structure of the software
system.
System Models
 System modeling is the process of developing abstract models of a
system, with each model presenting a different view or perspective of that
system.
 It is about representing a system using some kind of graphical notation,
which is now almost always based on notations in the Unified Modeling
Language (UML).
 Models help the analyst to understand the functionality of the system; they
are used to communicate with customers.
 Models can explain the system from different perspectives:
 An external perspective, where you model the context or
environment of the system.
 An interaction perspective, where you model the interactions
between a system and its environment, or between the
components of a system.
 A structural perspective, where you model the organization of a
system or the structure of the data that is processed by the system.
 A behavioral perspective, where you model the dynamic behavior
of the system and how it responds to events.
System Models…
 Activity diagrams, which show the activities involved in
a process or in data processing.
 Use case diagrams, which show the interactions between
a system and its environment.
 Sequence diagrams, which show interactions between
actors and the system and between system components.
 Class diagrams, which show the object classes in the
system and the associations between these classes.
 State diagrams, which show how the system reacts to
internal and external events.
System Models…
 Models of both new and existing system are used during requirements
engineering.
 Models of the existing systems help clarify what the existing system does
and can be used as a basis for discussing its strengths and weaknesses.
 These then lead to requirements for the new system.
 Models of the new system are used during requirements engineering to help
explain the proposed requirements to other system stakeholders.
 Engineers use these models to discuss design proposals and to document the
system for implementation.
Context and process models
 Context models are used to illustrate the operational context of a system -
they show what lies outside the system boundaries.
 Social and organizational concerns may affect the decision on where to
position system boundaries.
 Architectural models show the system and its relationship with other
systems.
 System boundaries are established to define what is inside and what is
outside the system.
 They show other systems that are used or depend on the system being
developed.
 The position of the system boundary has a profound effect on the system
requirements.
 Defining a system boundary is a political judgment since there may be
pressures to develop system boundaries that increase/decrease the influence
or workload of different parts of an organization.
Context and process models …
 Context models simply show the other systems in the environment, not how
the system being developed is used in that environment.
 Process models reveal how the system being developed is used in broader
business processes.
 UML activity diagrams may be used to define business process models.
 The example below shows a UML activity diagram describing the process
of involuntary detention and the role of MHC-PMS (mental healthcare
patient management system) in it.
Context and process models …
Interaction models
 Types of interactions that can be represented in a model:
 Modeling user interaction is important as it helps to identify user
requirements.
 Modeling system-to-system interaction highlights the
communication problems that may arise.
 Modeling component interaction helps us understand if a
proposed system structure is likely to deliver the required system
performance and dependability.
 Use cases were developed originally to support requirements elicitation and
now incorporated into the UML.
Interaction models…
 Each use case represents a discrete task that involves external interaction
with a system.
 Actors in a use case may be people or other systems.
 Use cases can be represented using a UML use case diagram and in a more
detailed textual/tabular format.
Interaction models …

Use case title Transfer data

A receptionist may transfer data from the MHC-PMS to a general patient

record database that is maintained by a health authority. The information
Description
transferred may either be updated personal information (address, phone
number, etc.) or a summary of the patient's diagnosis and treatment.

Actor(s) Medical receptionist, patient records system (PRS)

Interaction models …

Patient data has been collected (personal information, treatment

summary);
Preconditions
The receptionist must have appropriate security permissions to access the
patient information and the PRS.

Postconditions PRS has been updated

1. Receptionist selects the "Transfer data" option from the menu.

Main success 2. PRS verifies the security credentials of the receptionist.
scenario 3. Data is transferred.
4. PRS has been updated.
Interaction models …

2a. The receptionist does not have the necessary security

credentials.
Extensions
2a.1. An error message is displayed.
2a.2. The receptionist backs out of the use case.
Interaction models …
 UML sequence diagrams are used to model the interactions between the
actors and the objects within a system.
 A sequence diagram shows the sequence of interactions that take place
during a particular use case or use case instance.
 The objects and actors involved are listed along the top of the diagram, with
a dotted line drawn vertically from these.
 Interactions between objects are indicated by annotated arrows.
Interaction models …
Structural models
 Structural models of software display the organization of a system in terms
of the components that make up that system and their relationships.
 Structural models may be static models, which show the structure of the
system design, or dynamic models, which show the organization of the
system when it is executing.
 You create structural models of a system when you are discussing and
designing the system architecture.
 UML class diagrams are used when developing an object-oriented system
model to show the classes in a system and the associations between these
classes.
 An object class can be thought of as a general definition of one kind of
system object.
 An association is a link between classes that indicates that there is some
relationship between these classes.
 When you are developing models during the early stages of the software
engineering process, objects represent something in the real world, such as
a patient, a prescription, doctor, etc.
Structural models …
 Generalization is an everyday technique that we use to manage complexity.
 In modeling systems, it is often useful to examine the classes in a system to
see if there is scope for generalization.
 In object-oriented languages, such as Java, generalization is implemented
using the class inheritance mechanisms built into the language.
 In a generalization, the attributes and operations associated with higher-level
classes are also associated with the lower-level classes.
 The lower-level classes are subclasses inherit the attributes and operations
from their super-classes.
 These lower-level classes then add more specific attributes and operations.
 An aggregation model shows how classes that are collections are composed
of other classes.
 Aggregation models are similar to the part-of relationship in semantic data
models.
Structural models …
Structural models …
Structural models …
Aggregation class
Behavioral models
 Behavioral models are models of the dynamic behavior of a system as it is
executing.
 They show what happens or what is supposed to happen when a system
responds to a stimulus from its environment.
 Two types of stimuli:
 Some data arrives that has to be processed by the system.
 Some event happens that triggers system processing. Events may
have associated data, although this is not always the case.
 Many business systems are data-processing systems that are primarily
driven by data.
 They are controlled by the data input to the system, with relatively little
external event processing.
 Data-driven models show the sequence of actions involved in processing
input data and generating an associated output.
 They are particularly useful during the analysis of requirements as they can
be used to show end-to-end processing in a system.
 Data-driven models can be created using UML activity diagrams:
Behavioral models …

Activity diagram
 Data-driven models can also be created using UML sequence diagrams:
Behavioral models …
 Real-time systems are often event-driven, with minimal data processing.
 For example, a landline phone switching system responds to events such
as 'receiver off hook' by generating a dial tone.
 Event-driven models shows how a system responds to external and
internal events.
 It is based on the assumption that a system has a finite number of states
and that events (stimuli) may cause a transition from one state to another.
 Event-driven models can be created using UML state diagrams:
Thank you!
Any questions?

Good day!