Terna Engineering College

Computer Engineering Department

Program: Sem V

Course: Software Engineering

LAB Manual
PART A
Experiment No.03

A.1 Aim:
Draw Data Flow Diagram for your selected Mini-Project

A.2 Prerequisite:
Knowledge about requirement engineering processes of SDLC and requirement modelling.

A.3 Outcome:
After successful completion of this experiment students will be able to

Model requirements of project (software) using Data Flow Diagram (DFD)

A.4 Theory:

1. DATA FLOW DIAGRAM (DFD):

● Data flow diagram is a graphical model of system, which shows what are the various
functions (activities) performed by the system and how data flows among various functions.
● Each function is considered as a separate process.

● A data flow diagram (DFD) is a graphical representation of the "flow" of data through an
information system. DFDs can also be used for the visualization of data processing
(structured design).

● On a DFD, data items flow from an external data source or an internal data store to an
internal data store or an external data sink, via an internal process.

● A DFD provides no information about the timing of processes, or about whether processes
will operate in sequence or in parallel.

● It is therefore quite different from a flowchart, which shows the flow of control through an
algorithm, allowing a reader to determine what operations will be performed, in what
order, and under what circumstances, but not what kinds of data will be input to and output
from the system, nor where the data will come from and go to, nor where the data will be
stored (all of which are shown on a DFD).

● Data Flow diagrams (DFD) that help you model data flows and functional requirements for
a designed system.

● Elements of Data Flow Diagram

●
1. DATA STORE:-A data store is a holding place for information within the system
2. PROCESS:-A process performs transformation or manipulation on input data and produces
output data.
3. ENTITY:-An entity is anything that interact with system and is a source or destination of a
data.
4. DATA FLOW:-A data flow shows the flow of information from its source to its destination.

Data flow diagram Example

■ DFD-LEVELS

■ Level-0-DFD(Context Level DFD) :-

● It is common practice to draw a context-level data flow diagram first, which shows
the interaction between the system and external agents which act as data sources and
data sinks.
● On the context diagram (also known as the 'Level 0 DFD') the system's interactions
with the outside world are modelled purely in terms of data flows across the system
boundary. The context diagram shows the entire system as a single process, and
gives no clues as to its internal organization.
■ Level-1-DFD :-

● A Level 1 DFD that shows some of the detail of the system being modelled.
● The Level 1 DFD shows how the system is divided into sub-systems (processes), each
of which deals with one or more of the data flows to or from an external agent, and
which together provide all of the functionality of the system as a whole.
● It also identifies internal data stores that must be present in order for the system to
do its job, and shows the flow of data between the various parts of the system.

■ Level-2-DFD:-

● This level is a decomposition of a process shown in a level-1 diagram. There should

be a level-2 diagram for each and every process shown in a level-1 diagram. i.e. it is
breakdown of level-1-DFD.

■ Level-3-DFD:-
● Level 3 DFD is a breakdown of Level 2 DFD.

Example:
Level 0 DFD or Context level DFD

Level 1 DFD
Level 2 DFD for verification Process of level 1 DFD
Level 2 DFD for Processing Process of level 1 DFD
 PART B
(PART B : TO BE COMPLETED BY STUDENTS)

(Students must submit the soft copy as per following segments within two hours of the practical.
The soft copy must be uploaded on the Blackboard or emailed to the concerned lab in charge
faculties at the end of the practical in case the there is no Black board access available)

Roll No. 23 Name: Riddhi Javkar

Class : COMPUTER C Batch : C2
Date of Experiment: Date of Submission
Grade :

B.1 Draw DFD of selected mini project up to level 2

DFD : Level 0
DFD : Level 1

DFD : Level 2
B.2 Conclusion:
(Students must write the conclusion)

B.3 Question of Curiosity

Q1: What do you mean by requirement modelling? Why it is required?

Requirements modeling is an approach used in projects where the requirements keep on evolving
throughout the project. In any IT project, there is always a possibility that developers could
misinterpret software requirements. Most commonly, this will be due to a lack of effective
communication and briefing.

Q2: List of various requirement gathering techniques

Brainstorming

Brainstorming is used in requirement gathering to get as many ideas as possible from group
of people. Generally used to identify possible solutions to problems, and clarify details of
opportunities.

Document Analysis

Reviewing the documentation of an existing system can help when creating AS–IS process
document, as well as driving gap analysis for scoping of migration projects. In an ideal world,
we would even be reviewing the requirements that drove creation of the existing system – a
starting point for documenting current requirements. Nuggets of information are often buried
in existing documents that help us ask questions as part of validating requirement
completeness.

Focus Group

A focus group is a gathering of people who are representative of the users or customers of a
product to get feedback. The feedback can be gathered about needs/opportunities/ problems
to identify requirements, or can be gathered to validate and refine already elicited
requirements. This form of market research is distinct from brainstorming in that it is a
managed process with specific participants.

Interface analysis

Interfaces for a software product can be human or machine. Integration with external systems
and devices is just another interface. User centric design approaches are very effective at
making sure that we create usable software. Interface analysis – reviewing the touch points
with other external systems is important to make sure we don’t overlook requirements that
aren’t immediately visible to users.

Interview

Interviews of stakeholders and users are critical to creating the great software. Without
understanding the goals and expectations of the users and stakeholders, we are very unlikely
to satisfy them. We also have to recognize the perspective of each interviewee, so that, we can
properly weigh and address their inputs. Listening is the skill that helps a great analyst to get
more value from an interview than an average analyst.

Observation

By observing users, an analyst can identify a process flow, steps, pain points and
opportunities for improvement. Observations can be passive or active (asking questions while
observing). Passive observation is better for getting feedback on a prototype (to refine
requirements), where active observation is more effective at getting an understanding of an
existing business process. Either approach can be used.

Prototyping

Prototyping is a relatively modern technique for gathering requirements. In this approach,

you gather preliminary requirements that you use to build an initial version of the solution - a
prototype. You show this to the client, who then gives you additional requirements. You
change the application and cycle around with the client again. This repetitive process
continues until the product meets the critical mass of business needs or for an agreed number
of iterations.

Requirement Workshops

Workshops can be very effective for gathering requirements. More structured than a
brainstorming session, involved parties collaborate to document requirements. One way to
capture the collaboration is with creation of domain-model artifacts (like static diagrams,
activity diagrams). A workshop will be more effective with two analysts than with one.

Reverse Engineering

When a migration project does not have access to sufficient documentation of the existing
system, reverse engineering will identify what the system does. It will not identify what the
system should do, and will not identify when the system does the wrong thing.

Survey/Questionnaire

When collecting information from many people – too many to interview with budget and time
constraints – a survey or questionnaire can be used. The survey can force users to select from
choices, rate something (“Agree Strongly, agree…”), or have open ended questions allowing
free-form responses. Survey design is hard – questions can bias the respondents.

************************