Software Engineering

Practices

Symbiosis International (Deemed University)

1
Unit 3: Requirements Modeling

Dr. Pallawi Bulakh

M.Sc. M.Phil.Ph.D. NET with JRF
(Computer Science and Applications)

2
Requirement modelling
• 3.1 Requirements Modeling

• 3.2 Use of Structural approach and object-oriented

approaches,

• 3.3 Data and process modeling

3
Requirement modeling:
• Requirement modeling is a Strategy in project
management where the requirements keep on emerging
throughout the project.

• It is the process of documenting, analyzing, and

managing the requirements.

4
Requirement modeling process
1.Analyzing the requirements: In this activity the
requirements are thoroughly checked if they are
complete, concise, correct, and clear.

2.Documenting the requirements.: Once the requirements

are analysed, they are documented in a specific format.
This documentation is necessarily understandable by the
5
team members working on the project.
Requirement modeling process
• Managing the requirements: Once the requirements are
collected and documented, they must be tracked and
managed throughout the project.

• Also, the changes in the requirement are accommodated

as per the feasibility.

6
Use Of Approaches For Requirement
Modeling:
• The requirement modeling can be done using two
main approaches.

• Structural approach and Object-Oriented Approach

• These two approaches are effective methods to

develop and design the requirement and in turn the
software systems.
7
Structural Approach
● The main focus is on processes
● it uses SDLC methodology for requirement modeling
● It is useful when the requirements of the customer are
stable and clear
● Structural approach for requirement modeling uses Data
flow diagram Entity relationship diagram, control flow
diagram, State transition diagram.

8
Object Oriented Approach
● The main focus in the object-oriented approach for
requirement modeling is on Real world objects.
● It uses an incremental or iterative approach for
requirement refining.
● It's mainly used for large projects with variable
requirements.
● It uses use case models, object models, state transition
diagrams and deployment diagrams.
9
Data and process modeling
• Everything revolves around the data
• data is the most important and eminent part of the
software development process
• All the strategic decisions are based on the data in hand
and the predictions related to the data.
• Therefore, there is a need to systematically organize the
data and also to model the relationship in between the
data

10
Data Modelling
• Data Modelling in software engineering is simplifying a
software system's diagram or data model by applying
certain formal techniques.
• It involves expressing data and information through text
and symbols.
• Data modeling represents the data with diagrams,
symbols, and text so as to have visibility about the data,
data items, and relationships among them.

11
Data Modelling
• Data modelling creates a conceptual representation of
data objects and their relationship
• The process of data modeling has the following steps:
a.requirement gathering
b.conceptual design
c.logical design
d.physical design
e.implementation
12
Data Abstraction
a.Logical: In the logical level, the constraints between the
relationships and the data objects are defined using ER
diagrams or SQL.
b.physical: Physical level deals with the actual storage of
the data, its type, and indexes.
c.conceptual: in this level high-level entities and their
relationships are defined using diagrams.

13
Data modelling Methods
• Entity- Relationship Diagram
• Hierarchical model
• Network model
• Relational model
• Object oriented model

14
Process modelling
• Process modelling is the activity of
representing the processes in a
graphical manner or workflows
• Process models help to visualize
the processes at glance which
helps the team members to
thoroughly understand the entire
procedure
• This makes a complete and
comprehensive view of the
process.
16
Why Process Modelling?
• Process modelling improves efficiency
• Saves time
• Increases productivity
• Provides a transparent overview of the
process clearly depicting the start and
end point of the processes.
• Ensures consistency and
standardization across the organization.
• Process models use standard notations
• Standard notations allow the process to
get easily understood and read by
anyone.
17
Standard process modeling notations
● Sequence flows are represented by arrows.
● Diamonds represent decision points or
gateways
● Beginnings and endpoints of processes are
represented by ovals.
● Rectangles are used to represent activities
within a workflow
● Swim lanes are used to identify who owns
which components of a process.
18
Process Modeling Techniques
• Gantt chart
• Created by henry gantt
• Project management tool in the form of a chart
• Shows the progress of a project along with its timeline.
• It has two main parts, a task list on the left side and a
bar chart timeline on the right.
• This allows us to create a schedule of the project
activities

19
Gantt Chart

20
Gantt Chart Example

21
Flow Chart
• Flow chart is a pictorial
representation of an algorithm.
• flow chart makes it easy to
understand the complex program and
its logic
• It’s a standardized way of project flow
communication among the project
stakeholders.
• Flow charts use standard notations to
represent any activity
23
Flow Chart
Notations

24
Example
Flow
Chart

25
Example
Flow
Chart

26
ER Diagram
• ER diagram is again a process model that depicts the
entities and their relationships in a database

• used to show real-world objects like people,

departments, and their relationship with each other.

• Mostly used in database systems.

27
ER diagram
Notations

28
ER Diagram Example

29
ER
Diagram
Example

30
Data Flow Diagram
• Data Flow diagrams of DFDs are the visual
representation of the processes and their flow within
a system
• DFDs depict the requirements for the system
• The main intention of DFD is to show the boundaries
and scope of the system
• It's a collection of standard symbols to represent the
processes and flow
31
DFD Notations

32
DFD
• DFDs operate in levels to implement data abstraction.
• The levels are named as zero, first, and so on.
• 0-level DFD, also known as context level DFD is the basic
DFD that shows only the input and output of the system
• In level-1 DFD, the main objectives or functionalities of
the system are represented.
• Level-2 DFD goes deeper into the functionalities.

33
0-level DFD

34
Level-1 DFD

35
Level-2 DFD

36
UML
diagrams

37
Structural Diagrams
• Structural Diagrams Represent A Static View Or Structure
Of A System
• It Consists Of
• Class Diagrams,
• Composite Structure Diagrams,
• Component Diagrams,
• Deployment Diagrams,
• Object Diagrams, And
• Package Diagrams.
38
Class Diagram
• Class diagrams are the most important UML diagrams.
• They depict the object-oriented structure of the software
systems.
• It shows the behavior of the different software system
classes.
• The class diagram consists of class attributes and the
operation that is performed by them.
• It also shows the relationship between two or more
classes.
39
40
Class Diagram Example

41
Composite structure diagram
• The composite structure diagram is used to represent the
parts within the class.
• It provides a logical overview of all parts of the system.
• It consists of parts, ports, and connectors.
• It's a static kind of diagram.

42
Composite structure diagram

43
Object diagram
• Object diagram is a structural diagram of UML which
represents the scenario of a system at a particular
instance of time.
• Object diagram consists of the objects, the data and its
value.
• Object diagram also shows the relationship between the
objects at that particular instance of the time.
• The Class diagram depicts the actual classes but the
object diagram shows the same classes at a point of time
with its values
44
Difference between Class Diagram and Object Diagram

45
Component diagram:
• Component diagram is a static UML diagram showing the
wiring between a system's different components.
• Similar to the class diagram.
• It also represents the structure and relationship between
the elements of the software system.
• It also looks after whether the functional requirements
are properly planned and developed.

46
Component diagram:

47
Deployment diagram
• The deployment diagram represents the physical
components of a software system which includes
hardware and software.
• It also gives information about the system software.
• It deals with the physical components of the software
system.
• This helps to understand the implementation of the
system.

48
Deployment Diagram

49
Package diagram:
• Package diagram is a structural diagram that is used to
represent a group of classes into packages.
• A package can be defined as a group of logically similar
elements.

50
Package Diagram

51
Use case diagrams
• Use case diagrams to describe the functions of a
software system along with its boundaries.
• Use case diagrams also show the relationships between
the systems and their actors.
• The main components of use case diagrams are use
cases, actors, systems, and their relationships.

52
53
Behavioural diagram
• Behavioural diagrams depict the dynamic aspect of a
software system.
• There are different UML diagrams to show the different
aspects of the system.
• The changing state of the object is represented using
behavioural diagrams.
State Machine Diagram
• This diagram presents the system's behavior using finite
state transitions.
• This is also known as the state-chart diagram.
• The dynamic aspect of the system is represented as a
response to the external agent.
• It is also known as the State-charts diagram.
State Machine Diagram
Activity Diagram
• Activity diagram shows the flow of control from one
activity to another activity.
• The sequence of the activities as it occurs can be
modelled using an activity diagram.
• The various components of the activity diagram are
activities, actions, control flow, start and end nodes,
and swim lanes.
• Activity diagram also shows the association, control
flow, and constraints on the activities.
Activity
diagram
Use Case Diagram
• It represents the functionality of a system by utilizing
actors and “Use Cases”.
• It encapsulates the functional requirement of a system
and its association with actors.
• It portrays the use case view of a system.
Use Case
Diagram
Interaction diagram
• Interaction diagram is used to show the interactive
behaviour among the entities of the system.
• They capture the dynamic behavior of the system with
the control flow of the activities.
• The components that participate in interaction
diagrams are objects, message flow, sequence of the
activities/message, and timeline.
• Also known as Sequence Diagram.
Interaction
Diagram or
Sequence
diagram