Following is a diagrammatic representation of different phases of

waterfall model.

The sequential phases in Waterfall model are:

 Requirement Gathering and analysis: All possible
requirements of the system to be developed are captured in this phase
and documented in a requirement specification doc.
 System Design: The requirement specifications from first
phase are studied in this phase and system design is prepared. System
Design helps in specifying hardware and system requirements and also
helps in defining overall system architecture.
 Implementation: With inputs from system design, the system
is first developed in small programs called units, which are integrated in
the next phase. Each unit is developed and tested for its functionality
which is referred to as Unit Testing.
Integration and Testing: All the units developed in the
implementation phase are integrated into a system after
testing of each unit. Post integration the entire system is
tested for any faults and failures.
 Deployment of system: Once the functional and non functional
testing is done, the product is deployed in the customer environment or
released into the market.
 Maintenance: There are some issues which come up in the
client environment. To fix those issues patches are released. Also to
enhance the product some better versions are released. Maintenance is
done to deliver these changes in the customer environment.
All these phases are cascaded to each other in which progress is
seen as flowing steadily downwards (like a waterfall) through the
phases. The next phase is started only after the defined set of goals
are achieved for previous phase and it is signed off, so the name
"Waterfall Model". In this model phases do not overlap.
 Waterfall Model Application
Every software developed is different and requires a suitable SDLC
approach to be followed based on the internal and external factors.
Some situations where the use of Waterfall model is most
appropriate are:
 Requirements are very well documented, clear and fixed.
 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to
support the product.
 The project is short.
 The advantage of waterfall development is that it allows for
departmentalization and control. A schedule can be set with deadlines
for each stage of development and a product can proceed through the
development process model phases one by one.
 Development moves from concept, through design, implementation,
testing, installation, troubleshooting, and ends up at operation and
maintenance. Each phase of development proceeds in strict order.
 DATA FLOW DIAGRAM

A data flow diagram (DFD) is a graphical representation of the "flow" of data through an
information system, modelling its process aspects. A DFD is often used as a preliminary step
to create an overview of the system, which can later be elaborated.
DFDs can also be used for the visualization of data processing (structured design).
A DFD shows what kind of information will be input to and output from the system, where
the data will come from and go to, and where the data will be stored. It does not show
information about the timing of process or information about whether processes will operate
in sequence or in parallel (which is shown on a flowchart).
This context-level DFD is next "exploded", to produce a Level 1 DFD that shows some of the
detail of the system being modeled. The Level 1 DFD shows how the system is divided into
sub-systems (processes), each of whi1ch 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.
Data flow diagrams are one of the three essential perspectives of the structured-systems
analysis and design method SSADM. The sponsor of a project and the end users will need to
be briefed and consulted throughout all stages of a system's evolution. With a data flow
diagram, users are able to visualize how the system will operate, what the system will
accomplish, and how the system will be implemented. The old system's dataflow diagrams
can be drawn up and compared with the new system's data flow diagrams to draw
comparisons to implement a more efficient system. Data flow diagrams can be used to
provide the end user with a physical idea of where the data they input ultimately has an effect
upon the structure of the whole system from order to dispatch to report.
How any system is developed can be determined through a data flow diagram model.
In the course of developing a set of leveled data flow diagrams the analyst/designer is forced
to address how the system may be decomposed into component sub-systems, and to identify
the transaction data in the data model.
Data flow diagrams can be used in both Analysis and Design phase of the SDLC.
There are different notations to draw data flow diagrams. defining different visual
representations for processes, data stores, data flow, and external entities.
DFD NOTATION

DFD EXAMPLE

Steps to Construct Data Flow Diagram:-

Four Steps are generally used to construct a DFD.
Process should be named and referred for easy reference. Each name should be representative
of the reference.
The destination of flow is from top to bottom and from left to right.
When a process is distributed into lower level details they are numbered.
The names of data stores, sources and destinations are written in capital letters.
Rules for constructing a Data Flow Diagram:-
Arrows should not cross each other.
Squares, Circles, Files must bear a name.
Decomposed data flow squares and circles can have same names.
Draw all data flow around the outside of the diagram.
LEVEL-1 DFD DIAGRAM

SEQUENCE DIAGRAM

A Sequence diagram is an interaction diagram that shows how processes operate with one
another and what is their order. It is a construct of a Message Sequence Chart. A sequence
diagram shows object interactions arranged in time sequence. It depicts the objects and
classes involved in the scenario and the sequence of messages exchanged between the objects
needed to carry out the functionality of the scenario. Sequence diagrams are typically
associated with use case realizations in the Logical View of the system under development.
Sequence diagrams are sometimes called event diagrams or event scenarios.
A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects
that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in
the order in which they occur. This allows the specification of simple runtime scenarios in a
graphical manner.
Sequence diagram is the most common kind of interaction diagram, which focuses on
the message interchange between a number of lifelines.
Sequence diagram describes an interaction by focusing on the sequence of messages that are
exchanged, along with their corresponding occurrence specifications on the lifelines.
The following nodes and edges are typically drawn in a UML sequence diagram: lifeline,
execution-specification, message, fragment, interaction, state invariant, continuation,
destruction occurrence.
ER-DIAGRAM
 USE CASE DIAGRAM

A use case diagram at its simplest is a representation of a user's interaction with the system
that shows the relationship between the user and the different use cases in which the user is
involved. A use case diagram can identify the different types of users of a system and the
different use cases and will often be accompanied by other types of diagrams as well.
So only static behavior is not sufficient to model a system rather dynamic behavior is more
important than static behavior. In UML there are five diagrams available to model dynamic
nature and use case diagram is one of them. Now as we have to discuss that the use case
diagram is dynamic in nature there should be some internal or external factors for making the
interaction.
These internal and external agents are known as actors. So use case diagrams are consists of
actors, use cases and their relationships. The diagram is used to model the system/subsystem
of an application. A single use case diagram captures a particular functionality of a system.
So to model the entire system numbers of use case diagrams are used.
The purpose of use case diagram is to capture the dynamic aspect of a system. But this
definition is too generic to describe the purpose.

Because other four diagrams (activity, sequence, collaboration and State chart) are also
having the same purpose. So we will look into some specific purpose which will distinguish it
from other four diagrams.
Use case diagrams are used to gather the requirements of a system including internal and
external influences. These requirements are mostly design requirements. So when a system is
analyzed to gather its functionalities use cases are prepared and actors are identified.
Now when the initial task is complete use case diagrams are modelled to present the outside
view.
So in brief, the purposes of use case diagrams can be as follows:
Used to gather requirements of a system.
Used to get an outside view of a system.
Identify external and internal factors influencing the system.
Show the interacting among the requirements are actors. How to draw Use Case Diagram?
Use case diagrams are considered for high level requirement analysis of a system. So when
the requirements of a system are analyzed the functionalities are captured in use cases.
So we can say that uses cases are nothing but the system functionalities written in an
organized manner. Now the second things which are relevant to the use cases are the actors.
Actors can be defined as something that interacts with the system.
The actors can be human user, some internal applications or may be some external
applications. So in a brief when we are planning

to draw a use case diagram we should have the following items identified.
Functionalities to be represented as an use case
Actors
Relationships among the use cases and actors.
Use case diagrams are drawn to capture the functional requirements of a system. So after
identifying the above items we have to follow the following guidelines to draw an efficient
use case diagram.
The name of a use case is very important. So the name should be chosen in such a way so that
it can identify the functionalities performed.
Give a suitable name for actors.
Show relationships and dependencies clearly in the diagram.
Do not try to include all types of relationships. Because the main purpose of the diagram is to
identify requirements.
Use note whenever required to clarify some important points.

USE CASE DIAGRAM