|| Jai Sri Gurudev ||

SJB Institute of Technology

Department of Information Science & Engineering

With the Blessings of

His Divine Soul Jagadguru Padmabushana His Holiness Jagadguru

Sri Sri Sri Dr. Balagangadharanatha
Revered
Sri Sri Sri Dr. Nirmalanandanatha
Maha Swamiji, Maha Swamiji, Sri Sri Dr. Prakashanath Swamiji,
Founder President, President, Chief Pontiff Managing Director,
Sri Adichunchanagiri Shikshana Trust ® Sri Adichunchanagiri Shikshana Trust ® SJB and BGS Group of Institutions

2
Program: B.E. ISE
Course name: SOFTWARE ENGG.
and
PROJECT
MANAGEMENT
Course code: 21CS61
VI semester, MODULE -2
Faculty: DR.ABHILASH C N
Professor, Dept.of ISE, SJBIT
Syllabus overview
Contd…
 Requirements Engineering
1. The broad spectrum of tasks and techniques
that lead to an understanding of
requirements is called requirements
engineering.
2. It is a major software engineering action that
begins during the communication activity and
continues into the modeling activity. It acts as
a bridge between the Design & Construction.
Definition: SE is a set of practices & guidelines to
execute a PROJECT
 A process is a sequence of steps with user
needs to an end product that are repeated to
 Elements of Requirements Model
 There are many different ways to look at
the requirements for a computer-based
system.
 Different modes of representation force you
to consider requirements from different
viewpoints.
1. Scenario-based elements. The system is
described from the user’s point of view using a
scenario-based approach.
 Actors are the different people (or devices)
 Actors represent the roles that people (or
 Elements of Requirements Model -
Example
 Recalling basic SafeHome requirements,
we define four actors:
 homeowner (a user),
 setup manager (likely the same person
as homeowner, but playing a different
role),
 sensors (devices attached to the
system), and the monitoring and
 response subsystem (the central station
that monitors the SafeHome home
 Elements of Requirements Model
2. Class-based elements. Each usage scenario
implies a set of objects that are manipulated as
an actor interacts with the system.
 These objects are categorized into classes—a
collection of things that have similar
attributes and common behaviors.
3. Behavioral elements. The behavior of a
computer-based system can have a deep effect
on the design that is chosen and the
implementation approach that is applied.
The unified
modeling
language (UML) is
a general-purpose
visual modeling
language that is
intended to
provide a
standard way to
The diagram lists the
attributes of sensors
(e.g., name, type) and
the operations (e.g.,
identify, enable)
 Elements of Requirements Model
 The State diagram is one method for
representing the behavior of a system by
depicting its states and the events that cause
the system to change state.
 Stakeholders from the business community
(e.g., business managers, marketing people,
product managers)
 Requirements Analysis
 Requirements analysis results in the
specification of software’s operational
characteristics, indicates software’s interface
with other system elements, and establishes
constraints that software must meet.
 The requirements modeling action results in
one or more of the following types of models:
 Scenario-based models of requirements
from the point of view of various system
“actors” Ex: Use Case
 Data models that depict the information
 Requirements Analysis

 Class-oriented models that represent object-oriented

classes (attributes and operations) and the manner in
which classes collaborate to achieve system
requirements. Ex: Class diagrams
 Flow-oriented models that represent the functional
elements of the system and how they transform data
as it moves through the system. Ex: Dataflow diagram
 Behavioral models that depict how the software
behaves as a consequence of external “events”
Ex: Sequence diagram
 Elements of Requirements Analysis
 Pictorial Representation of all the models
A domain in SE:
attempting to solve a
problem using software.

Ex: Insurance, E-
commerce, Bank,
Agriculture, Finance,
Embedded system, Data
science, Military,
Healthcare etc.
 Elements of Requirements Analysis
1. Scenario-based models of requirements from the
point of view of various system “actors”
2. Data models that depict the information domain for
the problem.
3. Class-oriented models that represent object-oriented
classes (attributes and operations) and the manner
in which classes collaborate to achieve system
requirements
4. Flow-oriented models that represent the functional
elements of the system and how they transform data
as it moves through the system
 Requirements Engineering – 7 distinct tasks

1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation and
7. Requirements Management
 Requirements Engineering – 7 distinct tasks
1. Inception: most projects begin when a
business need is identified or a potential new
market or service is discovered.
 We establish a basic understanding of the
problem, the people who want a solution, the
nature of the solution that is desired, and the
effectiveness of preliminary communication
and collaboration between the other
stakeholders and the software team.
2. Elicitation:—ask the customer, the users, and
others what the objectives for the system or product
are, what is to be accomplished.
 Requirements Engineering – 7 distinct tasks
3. Elaboration: The information obtained from the
customer during the above two tasks is expanded and
refined.
 It describes how the end user (and other
actors) will interact with the system. The
attributes for each class, relationship and
collaborations between those classes are
defined.
4. Negotiation: customers and users to ask for more
than can be achieved, given limited business
resources. We need to reconcile these conflicts
through a process of negotiation.
 Requirements Engineering – 7 distinct tasks
5. Specification: A specification can be a written
document, a set of graphical models, a formal
mathematical model, a collection of usage scenarios,
a prototype, or any combination.
6. Validation: The work products produced as a
consequence of requirements engineering are
assessed for quality.
 Requirements validation examines the specification
to ensure that all software requirements have been
stated.
 Also checks the inconsistencies, omissions,
and errors have been detected and corrected;
 Requirements Engineering – 7 distinct tasks
7. Requirements Management: these are a set of
activities that help the project team identify, control,
track requirements and changes to requirements at
any time as the project proceeds.
 Collaborative Requirements Gathering
Basic Guidelines to be followed during Req.
Gathering:
 Meetings are conducted and attended by both
software engineers and other stakeholders.
 Rules for preparation and participation are
established.
 An agenda is suggested that is formal enough to
cover all important points but informal enough to
encourage the free flow of ideas.
 A “facilitator” (can be a customer, a developer,
or an outsider) controls the meeting.
 A “definition mechanism” (can be work sheets,
 Domain Analysis
 Doing any kind of analysis improves time-to-market &
reduces development costs. So, Who is going to decide,
categorize, prepare them?
 Software domain analysis is the identification, analysis, and
specification of common requirements from a specific
application domain.
 The “specific application domain” can range from avionics
to banking, from multimedia video games to software
embedded within medical devices.
 The goal of domain analysis is straightforward: to find or
create those analysis classes and/or analysis patterns that
are broadly applicable so that they may be reused.
INPUT OUTPUT
 Swimlane diagram - Importance
 The UML swimlane diagram is a useful variation of
the activity diagram.
 It allows to represent the flow of activities described
by the use case and at the same time indicate which
actor has responsibility for the action described by an
activity rectangle.
 Responsibilities are represented as parallel segments
that divide the diagram vertically, like the lanes in a
swimming pool.
 Three analysis classes—Homeowner, Camera,and
Interface—have direct or indirect responsibilities.
 Data Object - Automobile
A data object is a representation of composite information.
external entity (e.g., anything that produces or consumes
information), a thing (e.g., a report or a display), an
occurrence (e.g., a telephone call) or event (e.g., an alarm),
a role (e.g., salesperson), an organizational unit (e.g.,
accounting department), a place (e.g., a warehouse), or a
structure (e.g., a file)
 Data Attributes
 Data attributes define the properties of a data object
and take on one of three different characteristics.
 They can be used to
(1) name an instance of the data object,
(2) describe the instance, or
(3) make reference to another instance in another
table.
 Relationships
 Data objects are connected to one another in
different ways. Consider the two data objects, person
and car.
 Other two types of Modeling – Flow & Behavioral
 Flow-oriented modeling provides an indication of how
data objects are transformed by processing functions.
 Behavioral modeling depicts the states of the system and
its classes and the impact of events on these states.
 Ex: The Dataflow diagram (DFD) takes an input-process-
output view of a system. The data objects flow into the
software, are transformed by processing elements, and
resultant data objects flow out of the software.
 Data objects are represented by labeled arrows, and
transformations are represented by circles (also called
bubbles).
 Example for – Flow Modeling
 Data objects are represented by labeled arrows, and
transformations are represented by circles (also
called bubbles).
 The DFD is presented in a hierarchical fashion, where
Level-0 represents the system as a whole.
Subsequent data flow diagrams refine the context
diagram, providing increasing detail with each
subsequent level.
 Level 1 Data flow Diagram
 The data flow diagram enables you to develop models
of the information and functional domain.
 Level 2 Data flow Diagram
 The data flow diagram enables you to develop models
of the information and functional domain.
 Other two types of Modeling – Flow & Behavioral
 Behavioral modeling depicts the states of the system and
its classes and the impact of events on these states. The
behavioral model indicates how software will respond to
external events with the following steps:
1. Evaluate all the use cases to understand the sequence of
interaction within the system.
2. Identify events that drive the interaction sequence and
understand how it relates to specific objects.
3. Create a sequence for each use case.
4. Build a state diagram for the system.
5. Review the behavioral model to verify accuracy and
consistency.
 Example for Behavioral Modeling – State Diagram
 SafeHome Security Surveillance System:
 Example for Behavioral Modeling – Sequence Diagram
 SafeHome Security Surveillance System:
DFD Diagram & State Diagram
THANK YOU
HAPPY LEARNING, WRITE AND
PRACTICE TO GET BETTER OUTCOME