Introduction to software engineering
Course Code: SE104
Target Group: Software Engineering
Instructor: Biniam Behailu
June, 2024
Chapter 4 Outline
Requirements
01 What is requirement?
02 Types of Requirements
03 Levels of Requirements
04 What is Requirement Engineering
05 Requirement Engineering Activities
What is requirement?
A function, constraint or other property that the system must provide
to fill the needs of the system’s intended user(s).
It is an important factor for the development of any project and it
defines what different stakeholders (users, customer,
manager and developer) need and how system will fulfil these needs.
They are generally expressed in natural language for the reason that
everyone can well understand it.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 3
What is requirement?
It helps the analyst to better understand which element and function
are necessary in the development of particular project.
Requirements are used as input in a design, implementation and
validation stage of product development.
A project can be succeed or failed at any time during project life cycle
because of poor requirement gathering and managing process.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 4
What is requirement?
It is about WHAT not HOW
Requirements are the descriptions of the services provided by a
system and its operational constraints
It may range from a high level abstract statement to a detailed
mathematical specification
A careful requirements process doesn’t mean there will be no
changes later
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 5
What is requirement?
If you are required to develop a library information software system,
what will you do firstly?
What is the scope and boundary of the software?
What functions that the system may have?
What performances that the system may have?
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 6
Types of Requirements
Software requirements are often classified as functional requirements,
non-functional requirements or domain requirements.
Functional Requirements
These are requirements that the end user specifically demands as basic
functionality that the system should offer.
All these functionalities need to be necessarily incorporated into the
system as a part of the contract.
Example:
What are the features that we need to design for this system?
What are the edge cases we need to consider, if any, in our design?
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 7
Types of Requirements
Non-Functional Requirements
These are the quality constraints that the system satisfy according to
the project contract.
The priority or extent to which these factors are implemented varies
from one project to another.
Portability
Security, Maintainability, Reliability, Scalability, Performance,
Reusability, Flexibility
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 8
Types of Requirements
Example
Each request should be processed with the minimum latency?
System should be highly valuable.
NFRs are not directly concerned with specific functions delivered by
the system.
However, non-functional requirements may be more critical than
functional requirements.
That is if they are not met, the system may be useless.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 9
Types of Requirements
Non-functional
requirements
Process Product requirements External
requirements requirements
Usability requirements
Delivery Legal
requirements Reliability requirements constraints
implementation Safety requirements Economic
requirements constraints
standards Efficiency requirements
Interoperability
requirements requirements
Performance requirements
Capacity requirements
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 10
Types of Requirements
Functional Requirements Non Functional Requirements
A functional requirement defines a system or its A non-functional requirement defines the quality
component. attribute of a software system.
It places constraints on “How should the
It specifies “What should the software system
software system fulfill the functional
do?”
requirements?”
Non-functional requirement is specified by
Functional requirement is specified by User. technical peoples e.g. Architect, Technical
leaders and software developers.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 11
Types of Requirements
It is mandatory. It is not mandatory.
It is captured in use case. It is captured as a quality attribute.
Defined at a component level. Applied to a system as a whole.
Helps you to verify the performance of the
Helps you verify the functionality of the software.
software.
Functional Testing like System, Integration, End to Non-Functional Testing like Performance, Stress,
End, API testing, etc are done. Usability, Security testing, etc are done.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 12
Types of Requirements
Usually easy to define. Usually more difficult to define.
Example Example
1) Authentication of user whenever he/she logs 1) Emails should be sent with a latency of no
into the system. greater than 12 hours from such an activity.
2) System shutdown in case of a cyber attack. 2) The processing of each request should be
3) A Verification email is sent to user whenever done within 10 seconds
he/she registers for the first time on some 3) The site should load in 3 seconds when the
software system. number of simultaneous users are > 10000
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 13
Types of Requirements
Domain requirements
Requirements that come from the application domain of the system
and that reflect characteristics of that domain.
They are not from specific needs of system users.
They usually include specialized terminologies or reference to
domain concept.
They can be functional or non-functional requirements.
Domains can be financial, healthcare, E-commerce …etc
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 14
Levels of Requirements
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 15
Levels of Requirements
Business requirements
These are used to state the high-level business objective of the
organization or customer requesting the system or product.
They are used to document main system features and functionalities
without going into their nitty-gritty details.
They are captured in a document describing the project vision and
scope.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 16
Levels of Requirements
User requirements
User requirements add further detail to the business requirements.
They are called user requirements because they are written from a
user’s perspective and the focus of user requirement describe tasks
the user must be able to accomplish in order to fulfill the above
stated business requirements.
They are captured in the requirement definition document.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 17
Levels of Requirements
System requirements
System requirements are expanded versions of the user
requirements that are used by software engineers as the starting
point for the system design.
They add detail and explain how the user requirements should be
provided by the system
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 18
What is Requirement Engineering?
To understand customers’ requirements about the software to be
developed is extremely important.
However,
Customers are unable to express requirements explicitly
o Typically, they can not tell you what they want clearly.
o The requirements that customers or end-users present are often:
incomplete, inaccurate, and inconsistent.
Stakeholders (business and technical groups) speak different languages.
Software requirements are often extremely complex and large scale.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 19
What is Requirement Engineering?
Requirement Engineering (RE) is the systematic process of eliciting,
analyzing, documenting, and managing the requirements for a
software system or product.
It covers all activities involved in discovering, documenting and
maintaining a set of requirements for a computer- based system.
It helps software engineers to better understand the problem they
will work to solve.
It can influence the development: cost, time, effort and quality.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 20
What is Requirement Engineering?
The goal of requirement engineering is to:
obtain and understand software requirements in a complete,
consistent and accurate way, and generate software requirement
specification (SRS) document.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 21
Requirement Engineering Activities
Software requirements engineering is made up of two major processes:
requirements development and requirements management.
Requirements development encompasses all of the activities involved in
eliciting, analyzing, specifying, and validating the requirements.
It occur during the early concept and requirements phases of the life cycle.
Requirements management is the process of understanding and
controlling changes to system requirements and maintaining links between
dependent requirements.
The activities used for requirement engineering vary widely depending on
the application domain, the people involved and the organization
developing the requirements.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 22
Requirement Engineering Activities
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 23
Feasibility study
A feasibility study decides whether or not the proposed system is
worthwhile.
A short focused study that checks if the system;
contributes to organizational objectives?
can be engineered using current technology and within budget?
can be integrated with other systems that are used?
Unless the answers for the above questions are affirmative it has no
real value to the business.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 24
Feasibility study
Feasibility study involves information assessment, information
collection and reporting.
Types of Feasibility Study
o Technical Feasibility
o Operational Feasibility
o Economic Feasibility
o Legal Feasibility
o Schedule Feasibility
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 25
Requirements elicitation & Analysis
Involves finding out the services that the system should provide and
the system’s operational constraints.
Is the most difficult, most critical, most error-prone, and most
communication-intensive aspect of software development.
Different models may be produced during the requirements analysis
activity.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 26
Requirements elicitation & Analysis
Why Requirements elicitation and analysis is a difficult process?
o Stakeholders often don’t really know what they want from the
computer system.
o Stakeholders naturally express requirements in their own terms.
o Different stakeholders have different requirements.
o Political factors may influence the requirements of the system.
o The requirements change during the analysis process. New
stakeholders may emerge and the business environment change
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 27
Requirements elicitation & Analysis
Requirements elicitation & analysis process activities involves
Domain understanding
Requirement collection
Classification (into coherent clusters)
Conflict resolution and identification of unpractical requirements
Prioritization
Requirement checking (e.g. Eliminate, combined and modified
requirements)
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 28
Requirements elicitation & Analysis
There are various requirement elicitation and analysis techniques.
Some of these are:
- Interview - Brainstorming
- Prototyping - Delphi Technique
- Ethnography - Viewpoints
- Scenarios - Use cases
- Session Videotaping
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 29
Requirements elicitation & Analysis
Interview
In formal or informal interviewing, the RE team puts questions to
stakeholders about the system that they use (if any) and the system to be
developed.
o Ask about specific details and about the stockholder's vision for the
future
o Ask if they have alternative ideas
o Ask for other sources of information
o Ask them to draw diagrams
There are two types of interview
Closed interviews where a pre-defined set of questions are answered.
Open interviews where there is no pre-defined agenda and a range of
issues are explored with stakeholders.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 30
Requirements elicitation & Analysis
Prototyping
Software customers and end users usually find it very difficult to
express their real requirements
Prototyping provide insight to the new functionalities by
demonstrating a new prototype
The simplest kind: paper prototype/ wireframes
The most common: a mock-up of the system’s UI
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 31
Requirements elicitation & Analysis
Delphi Technique
Is an iterative technique in which information is exchanged in a written
form until a consensus is reached.
For example
o participants may write down their requirements, sorted in order of
importance.
o The sets of requirements obtained are distributed to all participants,
who reflect on them to obtain a revised set of requirements.
o The procedure will be repeated several times until sufficient consensus
is reached.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 32
Requirements elicitation & Analysis
Ethnography
Ethnography is an observational technique that can be used to
understand Ethnography and Ethnography requirements.
A social scientists spends a considerable time observing and analyzing
how people actually work.
Ethnographic research allows requirements engineers to deeply
immerse themselves in the users' natural environment and observe
their behaviors, interactions, and the context in which they operate.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 33
Requirements elicitation & Analysis
Viewpoints
Viewpoints are a way of structuring the requirements to represent
the perspectives of different stakeholders.
Stakeholders may be classified under different viewpoints.
This multi-perspective analysis is important as there is no single
correct way to analyze system requirements of all stakeholders.
Advantage: Provides a framework for discovering conflicts in the
requirements proposed by different stakeholders.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 34
Requirements elicitation & Analysis
Scenarios
are descriptions of how a system is used in practice.
They are helpful in requirements elicitation as people can relate to these
more readily than abstract statement of what they require from a system.
Scenarios are particularly useful for adding detail to an outline
requirements description
Scenarios descriptions include
A description of the starting situation;
A description of the normal flow of events;
A description of what can go wrong;
Information about other concurrent activities;
A description of the state when the scenario finishes.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 35
Requirements elicitation & Analysis
Use cases
Use-cases are a scenario based technique in the unified modelling
language (UML) which identify the actors in an interaction and which
describe the interaction itself.
A set of use cases should describe all possible interactions with the
system.
Sequence diagrams may be used to add detail to use-cases by
showing the sequence of event processing in the system.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 36
Software Requirement Specification (SRS)
In this activity complete description of the behavior of the system is
developed.
The requirements specification document states in precise and
explicit language those functions and capabilities a software system
must provide, as well as stating any required constraints by which the
system must abide.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 37
Software Requirement Specification (writing requirements)
Natural language (informal requirements)
o Widely practiced: everybody can read them, finding a better notation is
hard
Structured natural language
o Forms/templates are used to bring some consistency to natural
language presentations
Graphical notations
o A graphical language, supplemented by text annotations is used to
define the functional requirements for the system.
Design Description Language
o uses a language like a programming language but with more abstract
features to specify the requirements by defining an operational model
of the system.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 38
Software Requirement Specification
Characteristics of requirements
Non-ambiguous - the requirement should be phrased so that there is one
and only one interpretation for it.
Correct – The information used to create it has to be correct and has to
reflect reality.
Necessary – If it wasn’t included, what’s the worst that could happen? If
you and the users are willing to accept those consequences, then it
probably isn’t really necessary.
Focus – Don’t write one requirement that specifies multiple needs –
instead, break it up into several requirements.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 39
Software Requirement Specification
Characteristics of requirements
Feasible – A requirement must be feasible/practical.
Verifiable – A requirement has to be testable/testable.
Precise - requirement should be evident and unambiguous
Clear – A requirement has to be clear and unambiguous.
Deal only with the problem - Requirements should state “what” is
required at the appropriate system level, not “how”
Not be gold platted
Example: TVRS(traffic violation report system) will play a piece of classical
music during initialization
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 40
Requirements validation
Requirements validation is a crucial step in the requirements
engineering process, where the defined requirements are verified to
ensure they accurately reflect the users' needs, are feasible, and can
be effectively implemented.
Concerned with demonstrating that the requirements define the
system that the customer really wants and they are error free.
Requirements error costs are high so validation is very important
Fixing a requirements error after delivery may cost up to 100 times
the cost of fixing an implementation error.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 41
Requirements validation
During the requirements validation process, different types of checks
should be carried out on the requirements in the requirement
document.
Some of the checks are
- Validity - Consistency
- Completeness - Realism
- Verifiability
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 42
Requirements validation
To validate requirements we may use the following requirement validation
techniques
Requirements reviews
o Systematic manual analysis of the requirements.
Prototyping
o Using an executable model of the system to check requirements.
Test-case generation
o Developing tests for requirements to check testability.
Automated consistency analysis
o Checking the consistency of a structured requirements description
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 43
Requirements management
Requirements management is the process of managing changing
requirements during the requirements engineering process and system
development.
Requirements change for the following reasons:
o The priority of requirements from different viewpoints changes during
the development process.
o System customers may specify requirements from a business
perspective that conflict with end-user requirements.
o The business and technical environment of the system changes during
its development.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 44
Requirements management
Principal stages to change management process are
o Problem analysis - Discuss requirements problem and propose
change;
o Change analysis and costing - Assess effects of change on other
requirements;
o Change implementation - Modify requirements document and
other documents to reflect change.
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 45
Requirements management
From an evolution perspective, requirements fall into two classes
Enduring requirements: Stable requirements derived from the core
activity of the customer organization. May be derived from domain
models
E.g. a hospital will always have doctors, nurses, etc.
Volatile requirements: Requirements which change during
development or when the system is in use.
In a hospital, requirements derived from health-care policy
Compiled by : Biniam Behailu & Yimer Amedie Introduction to Software Engineering 46
THANK YOU
?
"Unambiguous, testable requirements
are the bedrock of successful
projects."
Compiled by : Biniam Behailu Introduction to Software Engineering 47
