Structured analysis

Structured analysis is widely used system modeling technique for understanding real world system
before they are built. It is based on functional decomposition of the problem domain. However, its
inherent weakness is in identification and partitioning of a system‟s functionality.
Structured analysis is a set of techniques and graphical tools that allow analysis to develop new
kind of system specification that are easily understandable to the user. Most of them have now tools.
The traditional approach focuses on cost/benefit and feasibility analysis, project management,
hardware and software selection and personnel consideration. In contrast, structured analysis
considers new goals and structured tools for analysis. The new goals specify the following.
 Graphics should be used wherever possible to help communicate better with the user
 Logical and physical system should be differentiated,
 A logical system model to familiarize the user with system characteristics and interrelationship
before implementation should be built.
The structured tools focus on the data flow diagrams, data dictionary, structured English, decision
trees and decision tables. The objective is to built a new document called system specification
document. This document provides the basis for design and implementation.
Structured analysis has the following attributes.
1. It is graphic. The DFD for example present a picture of what is being specified and is conceptually
easy to understand the presentation of the application.
2. The process is partitioned so that one has clear picture of the progression from general to specific
in the system flow.
3. It is logical rather than physical. The elements of system do not depend on vendor or hardware.
They specify in a precise, concise and highly readable manner the working of the system and its
implementation.

Data Flow Diagram

Data Flow Diagram (DFD) is a structured, diagrammatic technique showing for showing the
functions performed by a system and the data flowing into, out of and whining it. It was first developed
by Larry Constantine. DFDs show the flow of data from external body into the system. It shows the
movement of data from one process to another and also its logical storage. It consists of data flows,
processes, sources, destinations and stores. DFDs describe the information flows within a system.
Data flow diagrams ate of two types.
 Physical Data Flow Diagrams
 Logical Data Flow Diagram.
Physical data flow diagrams are implementation dependent. They show the actual devices,
department, and people etc., involved in the current system. They can be verified by the users. A
physical DFD is a good starting point in developing a logical DFD.
 Logical data flow diagrams in contrast, describe the system independently of how it is actually
implemented. They shows what takes place rather than how an activity is accomplished.
Both types of data flow diagrams support a top down approach to systems analysis, whereby
begin by developing a general understanding of the system and gradually explode components in
greater detail.
DFD show the following:
(a)The processes within the system.
(b) The data stores (files) supporting the system operation.
(c) The information flows within the system.
(d) The system boundary
(e) Interactions with external entities.

A DFD is also known as a “bubble chart”. It clarifies the system requirements and identifying major
transformations that will become programme in system design. So DFD is the starting point of the
design that functionally decomposes the requirements, specifications down to the lowest level of
detail. DFD consists of series of bubbles joined by lines. The bubbles represent data transformations
and the lines represent data flows in the system.

DFD Principles
Following are the principles of DFDs:
1. The general principle in DFDs is that a system can be decomposed into subsystems and
subsystems can be decomposed into lower level subsystems and so on.
2. Each subsystem represents a process or activity in which data is processed. At the lower level
processes can no longer be decomposed.
3. Each „process‟ i.e. a subsystem and an activity in a DFD has the characteristics of a system .all
processes must have at least one data flow in and one data flow out. All processes should modify
the incoming data, producing new forms of outgoing data. A data flow must be attached to at least
one process.
4. Just as an operational system must have input and output, a process must also have an input and
output.
5. Data enters the system from the environment; data flows between processes within the system
and is produced as output from the system. Each data store must be involved with at least one
data flow. Each external entity must be involved with at least one data flow.

Data Flow Diagram Notations:

There are four symbols used in data flow diagrams;
1. Squares representing external entities, which are sources or destinations of data: External
Entities, also known as External sources/ recipients, are things (For example, people, machines,
organizations etc.) which contribute data or information to the system or which receive data /
 information from it. External entities are represented by rectangles and are outside the system
such as vendors or customers with whom the system interacts. When modeling complex systems,
each external entity in a DFD will be given a unique identifier. It is common practice to have
duplicated of external entities in order to avoid crossing lines, or just to make a diagram more
readable.
2. Rounded rectangles/ circles representing processes, which take data as input, do
something to it and output it: A process represents activities in which data is manipulated by
being stored or retrieved or transferred in some way. In other words we can say that processes
transform the input data into output data. Circles stand for a process that converts data into
information. Processes can be represented either by circles or by rounded rectangles.
3. Arrows representing the data flows, which can either be electronic data or physical items: Data
flows are represented by a line with an arrow, The arrow shows the direction of flow of data. It
depicts data/ information flowing to or from a process. The arrows must either start and /or end at a
process box. It is impossible for data to flow from data store to data store except via a process,
and external entities are not allowed to access data stores directly. Arrows must be named. Double
ended arrows may be used with care.
4. Open-ended rectangles representing data stores-
These also include electronic stores such as database and physical stores such as filing cabinets
or stacks of paper a data store is depicted by two parallel lines or open ended rectangles. Here
data to be stored or referenced by a process in the system. The data store may represent
computerized or non-computerized devices
Constructing a DFD:
• Processes should be named and numbered for easy reference. Each name should be
representative of process.
• The direction of flow is from top to bottom and from left to right. Data flows from the source (upper
left corner) to the destination (lower right corner). One way to indicate this is to draw along flow line
back to the source. Since source symbol is repeated it is marked with a short diagonal in the lower
right corner.
• When a process is exploded into lower level details they are numbered; i.e. process can be
exploded into sub processes
• The names of data stores, sources and destinations are written in capital letters. Process and data
flow names have the first letters of each word capitalized.

Data flow diagram layers

DFDs can be drawn in several nested layers. A single process node on a high level diagram
can be expanded to show a more detailed data flow diagrams. The context diagram is drawn first
followed by various layers of data flow diagrams
Level 0: Context Diagram
This DFD level focuses on high-level system processes or functions and the data sources that flow to
or from them. Level 0 diagrams are designed to be simple, straightforward overviews of a process or
system.
Level 1: Process Decomposition
While level 1 DFDs are still broad overviews of a system or process, they‟re also more detailed — they
break down the system‟s single process node into sub processes.
Level 2: Deeper Dives
The next level of DFDs dive even deeper into detail by breaking down each level 1 process into
granular sub processes.
Level3: Increasing Complexity
Level 3 and higher-numbered DFDs are uncommon. This is largely due to the amount of detail
required, which defeats its original purpose of being easy to understand.

e.g. students use an enrolment form to enroll in the program, when the form is received, an
acceptance of enrolment is sent to students. Later faculties receive class list of enrolled students for
each subject, they teach. At the end of term, the faculties returned these list with marks of each
student, exam result. From all sheets exam result is done.
Context DFD (level 0)

Data Dictionary:
• In data flow diagrams names are given to data flows, processes and data stores. Although the
names are descriptive they do not give details. So a data dictionary is builded to keep details of
data flows, processes and data store. It is a set of rigorous definitions of all DFD data elements
and data structures.
• A data dictionary has many advantages. Since documentation is valuable in any organisation. It
improves user‟s communication by establishing constant definitions of various elements, terms and
procedures.
• It serves as a common base for programmers working on the system and compares their data
descriptions. It also controls the information contained for each data element. For e.g. programmes
that use a given data element are cross referenced in the data dictionary, which makes easy to
identify them and make any necessary changes. Most data base management systems have a
data dictionary standard feature. Data has been described in different ways
There are three classes of items defined;
• Data element: The smallest unit of data that provides no further decomposition. For e.g. “date”
consists of day, month, and year.
• Data structure: It means a group of data elements. For e.g. “phone” It consists of four data
elements, Area code, exchange, number, extension. Book details consist of author name, title,
ISBN (International Standard Book Number), LOCN (Library of Congress Number), publisher name
and quantity
• Data flows and data stores: Data flows are data structures in motion, whereas data stores are data
structures at rest. A data store is a location, whereas data structures are temporarily located.

Decision Trees.
 A decision tree is a diagram that presents conditions, and actions sequentially , shows which
conditions to consider first, which second and so on.
 It is the method of showing the relationship of each condition.
 Decision trees are a graphical representation of decision tables. Their purpose is to aid the
construction of decision tables.
 In fact decision tables and decision trees are means of expressing process logic.
 They may therefore, be used in conjunction with or in place of flow charts or pseudo code.
E.g.
• A Co-operative bank XYZ will grant loans under the following conditions
• If a customer has an account with the bank and has no loan outstanding, loan will be granted.
• If a customer has an account with the bank but some amount is outstanding from previous
loans, then loan will be granted if special management approval is obtained.
• Reject loan applications in all other cases.
A Decision Table (DT)
• It is matrix of rows and columns, that shows conditions and actions.
• Decision rules, in decision table, state what procedure to follows when certain conditions exist
• Condition statements identifies the relevant conditions.
• Condition entries tell which values, applies for particular condition
• Action statement list set of all steps taken during certain condition occur.
• Action entries show what specific actions when conditions are true

Conditions Decision Rules

Condition Statements Condition entries
Action Statements Action Entries

Conditions Decision Rules

1 2 3 4
C1 Patient has basic health insurance Y N Y N
C2 Patient has Social health insurance N Y Y N
Action Statements

Difference between Decision Table and Decision Tree :

No. Decision Table Decision Tree

1. Decision Tables are tabular representation Decision Trees are graphical representation of
of conditions and actions. every possible outcome of a decision.

2. We can derive decision table from decision We can not derive decision tree from decision
tree. table.
3. It helps to clarify the criteria. It helps to take into account the possible relevant
outcomes of decision.
4. In Decision Tables, we can include more In Decision Trees, we can not include more than
than one „or‟ condition. one „or‟ condition.
5. It is used when there are small number of It is used when there are more number of
properties. properties.

6. It is used for simple logic only. It can be used for complex logic as well.

7. It is constructed of rows and tables. It is constructed of branches and nodes.

Entity Relationship Diagrams
Entity relationship (E-R) model is a conceptual data model that views the real world entities and
relationships. The E-R diagram is a model of entities in the business environment, the relationships
among the entities, and the attributes or properties of both the entities and their relationships. A basic
component of the model is the entity relationship diagram which is used to visually represent data
objects.
The overall logical structure of a database can be expressed graphically by an E-R diagram.
Rectangles : Represent entity sets
Ellipses : Represent attributes
Diamonds : Represent relationship sets among entity sets
Lines : Link attributes to entity sets and entity sets to relationship sets
Double ellipse: Represent multivalved attributes
Dashed Lines : Indicate total participation of an entity in a relationship
Double rectangle : Represent weak entity sets

The basic symbols used in E-R diagram are

Entity Relationship Identifier Attribute Maultivalues Associative

Attribute entity
The following relationship symbols are used in E-R diagram

Unary Binary Ternary

An entity is anything that can be distinguished from any other thing. An entity is an abstract or
concrete thing in the real world that we want to model in a database. It is described using a set of
attributes. Every attribute is connected to one and only one entity. To identify an entity the best
approach is defining a noun from the list of attributes. E.g. in Customer Name, Customer is the entity
and in payment mode, payment is entity
Entity type is a collection is a collection of entities that share common properties or characteristic. An
entity instance is a single occurrence of an entity type. An entity type is described just once in a data
model, whereas many instances of that entity type may be represented by data stored in the database.
Attribute is named property of an entity that is of interest to the organisation. E.g. when Student is an
entity, student-id, student-name, and student-address will be the attributes of the student entity.