DMIoT, School of Computing

Software Engineering Academic Program

Fundamentals of Software Engineering

By
Yayehudar T.
 Chapter Four

Requirements Engineering
 Introduction
What are 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 :
• (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) A documented representation of a condition or capability as in
(1) or (2).’
 Cont’d…
• 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.
❑The software requirements are description of features and
functionalities of the target system.
• Requirements convey the expectations of users from the
software product.
 User and System Requirements
• Typically, requirements are presented into two levels of
detail; user and system requirements, where user need a high-
level statement of the requirements, while system developers
need a more detailed system specification.
• So, user and system requirements just refer to different levels
of detail.
• Having different levels of detail is useful because it
communicates information about the system being developed
for different types of readers.
 User Requirements
• It describes the services that the system should provide and
the constraints under which it must operate.
• We don’t expect to see any level of detail, or what exactly the
system will do, It’s more of generic requirements.
• It’s usually written in a natural language and supplied by
diagrams.
 System Requirements
• The system requirements mean a more detailed description of
the system services and the operational constraints such as
how the system will be used and development constraints
such as the programming languages.
• This level of detail is needed by those who are involved in
the system development, like engineers, system architects,
testers, etc.
 Functional & Non-Functional Requirements
• The software requirements are classified into functional
requirements and non-functional requirements.
Functional Requirements
• It covers the main functions that should be provided by the
system.
• When expressed as user requirements, they are usually
described in an abstract way.
• However, more specific functional system requirements
describe the system functions, its inputs, processing; how it’s
going to react to a particular input, and what’s the expected
output.
 Cont’d…
Non-Functional Requirements
• These are the constraints on the functions provided by the
system.
• The constraints, like how many processes the system can
handle (performance), what are the (security) issues the
system needs to take care of.
• The rate of failure (reliability), what are the languages and
tools that will be used (development), what are rules you
need to follow to ensure the system operates within the law
of the organization (legislative).
 Cont’d…
❑Non-functional requirements are often critical than
individual functional requirements.
• Users can usually find ways to work around a system
function that doesn’t really meet their needs.
• However, failing to meet a non-functional requirement can
mean that the whole system is unusable.
➢For example, if an aircraft doesn’t mean meet its reliability
requirements, it won’t be safe for operation, or if an
embedded control system fails to meet its performance
requirements, the control functions won’t operate correctly.
 What is Requirements Engineering (RE) ?

How the customer How the project How the System How the programmer How the business
explained it leader understood it Analyst designed it wrote it Consultant described it

How the project was What operations How the customer How it was supported What the customer
documented installed was billed really need
 Cont’d…
❑Requirements engineering is a process of gathering and
defining what services should be provided by the system.
▪ It focuses on assessing if the system is useful to the business
(feasibility study), discovering requirements (elicitation and
analysis), converting these requirements into some standard
format (specification), and checking that the requirements
define the system that the customer wants (validation).
❑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.
 Cont’d…
• In practice, requirements engineering isn’t sequential
process, it’s an iterative process in which activities are
interleaved.
• For example, you iterate first on the user requirements;
elicitation, specification, and validation, and repeat the same
steps for the system requirements.
❑Early in the process, most effort will be spent on
understanding high-level business and user requirements.
• Later in the process, more efforts will be spent on elicitation
and understanding detailed system requirements.
 Requirements Engineering Process

• It is a four-step process, which includes:

1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
Cont’d…
 Cont’d…
1. 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.

Types of Feasibility:
I. Technical Feasibility -it evaluates the current technologies, which are
needed to accomplish customer requirements within the time and budget.
II. Operational Feasibility - it assesses the range in which the required
software performs a series of levels to solve business problems and
customer requirements.
III. Economic Feasibility - it decides whether the necessary software can
generate financial profits for an organization.
 Cont’d…
2. Requirement Elicitation and Analysis
• The activity of generating the requirements of a system from
users, customers, and other stakeholders.
• 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.
 Cont’d…
Problems of Elicitation and Analysis
• Getting all, and only, the right people involved is difficult.
• Stakeholders often don't know what they want.
• Stakeholders express requirements in their own terms.
• Stakeholders may have conflicting requirements.
• Requirement may change during the analysis process.
• Organizational and political factors may influence system
requirements.
 Cont’d…
❑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, 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
arise from some conflicts.
 Cont’d…

Figure: processes of requirements elicitation and analysis

 Cont’d…
• It shows that it’s an iterative process with feedback from one 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.
 Cont’d…
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 exists).
• Techniques: interviews, scenarios, prototypes, etc.
❑Gathering and understanding the requirements is a difficult
process
• That’s because stakeholders may not know what exactly they want the
software to do, or they may give unrealistic requirements.
• They may give different requirements, which will result in conflict
between the requirements, so we have to discover and resolve these
conflicts.
• Also, there might be some factors that influence the stakeholder’s
decision, like, for example, managers at a company or professors at the
university want to take full control over the management system.
 Cont’d…
Requirements Classification & Organization
• 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.
 Cont’d…
Requirements Prioritization & Negotiation
• 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.
❑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.
Requirements Specification
• The requirements are then documented
 Cont’d…
3. 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), data dictionaries, etc.
 Cont’d…
Data Flow Diagrams (DFDs)
• 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.
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.
 Cont’d…
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.
 Cont’d…
4. 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 checked against the following conditions.
✓If they can be practically implemented
✓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 be demonstrated
 Cont’d…
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.
 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.
• System modeling has generally come to mean representing the system
using some kind of graphical notation, which is now almost always
based on notations in the Unified Modeling Language (UML).
• System modelling helps the analyst to understand the functionality of
the system and models are used to communicate with customers
❑Models are used:
• during the requirements engineering process to help derive the
requirements for a system,
• during the design process to describe the system to engineers
implementing the system and
• after implementation to document the system’s structure and operation.
 Cont’d…
❑You may develop models of both the existing system and
the system to be developed:
➢Models of the existing system are used during requirements
engineering.
✓They 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.
 Cont’d…
➢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.
❑Different models present the system from different perspectives
• External perspective showing the system’s context or environment
• Behavioural perspective showing the behaviour of the system
• Structural perspective showing the system or data architecture
• Interaction perspective where you model the interactions between a
system and its environment or between the components of a
system.
 Context models
• Context models are used to illustrate the operational context of a
system - they show what lies outside the system boundaries.
• The context of an ATM system
 Data Flow Diagrams
▪ It is a graphical representation of the flow of data.
▪ Data flow diagrams show:
• Data flowing through a system to or from external
entities.
• The processes that transform the data.
• How the data flow from one process to other step by
step
• The data stores that hold the data.
 Why we should Use DFD?
• In describing the boundaries of the system.
• For communicating existing system knowledge to the users.
• A straightforward graphical technique which is easy to
recognize.
• To understand detailed representation of system
components.
• Used as the part of system documentation file.
• Easier to understand by technical and nontechnical
audiences
• Finding out the logic behind the data flow within the
system.
 Components of DFD
• DFD consists principally of four symbols, namely the:
 Process

• Work or actions performed on data (inside the system)

• Labels should be verb phrases
• Receives input data and produces output
 Rule 1: Process
• Can have more than one outgoing data flow or more than one
incoming data flow
 Rule 2: Process
• Can connect to any other symbol (including another process symbol)
Process: Correct/Incorrect?
 Data Flow

• Is a path for data to move from one part of the IS to another

• Arrows indicating movement of data
• Can represent flow between process and data store by two separate
arrows
 Data Store
• Is used in a DFD to represent data that the system stores
• Labels should be noun phrases
 Rule: Data Store
• Must have at least one incoming and one outgoing data flow
 External Entity
• It is origin or destination of data (outside the system)
• Labels should be noun phrases
Rules for Using DFD Symbols
 Levels of DFD
Level 0 Diagram:
• Shows all the processes of the overall system
Level 1 Diagrams
• Shows single process on the level 0 diagram
• Shows how information moves from and to each of these processes.
• Shows in more detail the content of higher level process.
• Level 1 diagrams may not be needed for all level 0 processes.
• Then it may be Level-2 or 3 and so on ..(if required)
 Example
A short brief about the proposed system
• Here we are going to create a DFD for SMS Mela.
➢ The core task of the proposed system that the system will be used to:
• register customer and store customer data
• buy and sell SMS packages.
• create user, packages, categories.
• send SMS via customer.
• manage user and customer.
• store SMS log and data.
• As it is possible to produce a several no of DFD from the above
scenario, here we only represent the DFD which describes user core
tasks with the system.
 Context Diagram of SMS mela API

Registration

Bus SMS
Package
SMS Mela Send SMS

Check
Balance
Level-0 Diagram of SMS mela API
Level-1 Diagram (Buy/add SMS)
 Data Dictionary
• Data dictionary is the centralized collection of information about data.
• It stores meaning and origin of data, its relationship with other data,
data format for usage, etc.
• The data is referenced via data dictionary while designing and
implementing software.
• Data dictionary removes any chances of ambiguity.
 Cont’d...

▪ Data dictionary should contain information about the following:

• Data Flow

• Data Structure

• Data Elements

• Data Stores

• Data Processing

53
Cont’d...
 Example
• Address = House No + (Street / Area) + City + State
• Course ID = Course Number + Course Name + Course Level +
Course Grades

55
 ERD
• Known as Entity Relationship Diagram

• An entity relationship diagram (ERD) shows the relationships of

entity sets stored in a database.

• ER diagrams illustrate the logical structure of databases

• ER-modeling is a data modeling technique used in software

engineering to produce a conceptual data model of a information
system.

• Diagrams created using this ER-modeling technique are called Entity-

Relationship Diagrams, or ER diagrams or ERDs.
 ERD Notations
• To design database there are several important components
which are focused i.e.

• Entity

• Relationship

• Attributes
 ERD Example

ER diagram for Library Management System

 Exercise
1. Precision Tools sells a line of high-quality woodworking
tools. When customers place orders on the company’s Web
site, the system checks to see if the items are in stock, issues a
status message to the customer, and generates a shipping
order to the warehouse, which fills the order. When the order
is shipped, the customer is billed. The system also produces
various reports.
• Draw a context diagram for the order system
• Draw DFD diagram 0 for the order system
59
 Cont’d...
2. Make DFD, ERD for the following
• Hotel Management System
• Inventory Management System
• Hospital Management System
• Railway Reservation System
• Automatic Teller Machine System

60
Thank you !
?