STRUCTURED ANALYSIS APPROACH

(DATA FLOW DIAGRAM)

ISS2201-ANALISIS KEBUTUHAN SISTEM
09 MARET 2018
PRESENTED BY: RINI JULIANA SIPAHUTAR
LEARNING OUTCOMES

▰ Explain what is structure analysis

▰ Describe the use of data flow diagrams
▰ Produce a data flow diagram from a given
case study including different levels
▰ Distinguish between the different categories
of data flow diagrams

2
MODEL: LOGICAL AND PHYSICAL

Model – a pictorial representation of reality.

Just as a picture is worth a thousand words, most
models are pictorial representations of reality.

Logical model – a nontechnical Physical model – a technical

pictorial representation that pictorial representation that depicts
depicts what a system is or does. what a system is or does and how
the system is implemented.
Synonyms or essential model, Synonyms are implementation
conceptual model, and business model and technical model.
model.
3
 MODEL IN ANALYSIS PHASE

▰ Analysis phase , SA create model that define in great detail what is required
using logical model
▰ Logical models remove biases that are the result of the way the system is
currently implemented, or the way that any one person thinks the system might
be implemented.
▰ Logical models reduce the risk of missing business requirements because we
are too preoccupied with technical results.
▰ Logical models allow us to communicate with end-users in nontechnical or
less technical languages.
▰ In general is devided into :
▻ Structured Model
▻ Object Oriented Model 4
STRUCTURED VS OO MODELLING

5
WHAT IS STRUCTURED ANALYSIS MODEL?

▰ It focuses on specifying what the system or application is

required to do by following approach:
▻ View a system as collection of process
▻ Contain instruction that execute a sequence
▻ Processes accept inputs and produce outputs
▰ Elements of structured analysis model
▻ Entity Relationship Diagram
▻ Data Flow Diagrams
▻ Data Dictionary: definitions of elements in the system
6
DATA FLOW DIAGRAM

7
 OVERVIEW

▰ Data flow diagram (DFD) – a process model used to depict the flow of
data through a system and the work or processing performed by the
system.
▰ Data Flow Diagrams are usually produced using a CASE (Computer Aided
Software Engineering) tool.
▰ Using a CASE tool for construction of the DFDs has many advantages:
▻ Not Allow a non-standard use of notation for all the items in the
diagrams.
▻ Applies some rules so that designing the diagrams prevents the
users from making connections between the different items that
should not be allowed 8
 DEVELOPMENT AND PURPOSE OF DFD (1)

▰ When all the information about the current system is gather it

should be possible to construct the DFDs to show:
▻ the information that enters and leaves the system
▻ the people/roles/other systems who generate and/or receive
that information
▻ the processes that occur in the system to manipulate the
information
▻ the information that is stored in the system
▻ the boundary of the system indicating what is (and what is
not) included 9
 DEVELOPMENT AND PURPOSE OF DFD (2)

▰ The DFDs are used to:

▻ discuss with the user a diagrammatic interpretation of the
processes in the system and clarify what is currently being
performed (as is system)
▻ determine what the new system should be able to do and
what information is required for each different process that
should be carried out
▻ check that the completed system confirms to its intended
design 10
 COMPONENTS

▰ There are four symbols that are normally used on a DFD:

1. External entities
2. Processes
3. Data stores
4. Data flows

11
 EXTERNAL ENTITIES

▰ Things that are identified as needing to interact with the system

▰ External Entities define the “boundary” or
scope of a system being modeled. Customer
▰ Almost always one of the following:
▻ Office, department, division.
▻ An external organization or agency. Manager
▻ Another business or another
information system.
▻ One of system’s end-users or managers Payroll system
▰ Named with descriptive, singular noun
12
DATA STORES

Data store – stored data intended for later use.

Synonyms are file and database.
▻ Frequently implemented as a file or database.
▻ A data store is “data at rest” compared to a data
flow that is “data in motion.” Gane and Sarson shape
▻ Almost always one of the following:
▻ Persons (or groups of persons)
▻ Places
▻ Objects
▻ Events (about which data is captured)
▻ Concepts (about which data is important)
▻ Data stores depicted on a DFD store DeMarco/Yourdon shape
all instances of data entities
(depicted on an ERD)
▻ Named with plural noun 13
 PROCESS CONCEPTS

Process – work performed by a system in response to

incoming data flows or conditions. A synonym is
transform.
▻All information systems include Gane and Sarson shape
processes - usually many of them
▻Processes respond to business
events and conditions and transform Process
data into useful information Name
▻Modeling processes helps us to understand the
interactions with the system's environment, other DeMarco/Yourdon shape
systems, and other processes.
▻Named with a strong action verb followed by object
clause describing what the work is performed on/for . 14
 PROCESS

▰ Example:
1. Enter customer details
2. Register new students
3. Validate sales orders

15
 DATA FLOWS

▰ Represent the flow of data to or from a process.

▰ The symbol is an arrow and next to it a brief description of the data that is represented.
▰ There are some interconnections, though, that are not allowed:
▻ Between a data store and another data store
▻ This would imply that one data store could independently decide to send some of
information to another data store. In practice this must involve a process.
▻ Between an external entity and a data store
▻ This would mean that an external entity could read or write to the data stores having direct
access. Again in practice this must involve a process.
▻ Between an external entity and an external entity
▻ We are not normally concerned with information exchanges between two external entities
as they are outside our system
▰ Example:
Applicant’s name Payment 16
 DATA FLOWS PACKET CONCEPT

▰ Data that should travel together should be shown as a single

data flow, no matter how many physical documents might be
included.

17
DATA FLOWS TO AND FROM DATA STORES

18
 RULES FOR DATA FLOWS

▰ A data flow should never go

unnamed.
▰ In logical modeling, data
flow names should
describe the data flow
without describing the
implementation
▰ All data flows must begin
and/or end at a process.

19
THE SYSTEM IS ITSELF A PROCESS

20
PROCESS DECOMPOSITION

▰ Decomposition – the act of breaking a system into sub-components.

Each level of abstraction reveals more or less detail.

21
 DECOMPOSITION DIAGRAMS

Decomposition
diagram – a tool used
to depict the
decomposition of a
system. Also called
hierarchy chart.

22
COMMON PROCESS ERRORS ON DFDs

23
 KEY POINTS THAT APPLY TO ALL DFDs

▰ All the data flows are labelled and describe the information that is being carried.
▰ It tends to make the diagram easier to read if the processes are kept to the middle, the
external entities to the left and the data stores appear on the right hand side of the diagram.
▰ Each process should have an output. If there is no output then there is no point in having that
process. A corollary of this is that there must be at least one input to a process as it cannot
produce data but can only convert it form one form to another.
▰ Data stores should have at least one data flow reading from them and one data flow writing to
them. If the data is never accessed there is a question as to whether it should be stored. In
addition, there must be some way of accumulating data in the data store in the first place so it
is unlikely there will be no writing to the data store.
▰ Data may flow from
▻ External entity to process and vice-versa
▻ Process to process
▻ Process to data store and vice-versa
▰ No logical order is implied by the choice of id for the process. 24
 DEVELOPING DFD

▰ Diagrams move from general to specific

▰ Similar to levels in a menu-driven system; top-level node is analogous to the
main menu
▰ DFD Consists of different level
1. Context Diagram (Level 0 DFD) : no process or data stores shown.
2. Level 1 DFD : is developed which shows the processes taking place to
convert the inputs shown in the context diagram to the outputs.
 detail is given to show which processes are responsible for accepting
the different inputs and producing the different outputs.
3. Any process shown that is complicated by a number of data flows and
requires further refinement is shown on another diagram (level 2 DFD)
25
 CONTEXT DATA FLOW DIAGRAM

▰ Context data flow diagram - a process model used to document the scope
for a system. Also called the environmental model.

1. Think of the system as a "black box."

2. Ask users what business transactions the system must respond to.
These are inputs, and the sources are external agents.
3. Ask users what responses must be produced by the system. These are
outputs, and the destinations are external agents.
4. Identify any external data stores, if any.
5. Draw a context diagram. 26
EXAMPLE: CONTEXT DIAGRAM

27
 PROCESS DECOMPOSITION DIAGRAM

▰ Break system into sub-

components to reveal more
detail.
▰ Every process to be
factored should be
factored into at least two
child processes.
▰ Larger systems might be
factored into subsystems
and functions.
28
 DFD LEVEL 1

▰ contains all the options on the main menu

▰ a leveled set of DFDs has a 1-to-1 correspondence
with the levels on the hierarchy chart
▰ each process numbered with an integer
▰ includes major data stores and all external entities

29
 CREATING CHILD DIAGRAM (1)

▰ Each process on Context Diagram (DFD Level 1) can be

exploded to create a more detailed child diagram (see
functional decomposition diagram)
▰ Parent - process on diagram level 1
▰ Child - resulting diagram that is exploded from Parent
▰ Vertical balancing - a child diagram cannot produce output
or receive input that the parent process does not also
produce or receive
30
 CREATING CHILD DIAGRAM (2)

▰ All data flow in or out of the parent process must be shown flowing in
or out of the child diagram
▰ Processes on the child diagram are numbered using the parent
process number, a decimal point, and a unique number for each child
process (e.g., if process 3 would be exploded to level 2 then its
number become 3.1 to … 3.n)
▰ Child diagram may include data stores not shown on the parent
process
▰ Processes may or may not be exploded, depending on level of
complexity 31
 CHECK LIST

There are many errors that may occur when drawing data flow diagrams. Here is a check list to help you
avoid some of the major difficulties.
1. External entities must be people or systems that send information to or accept information form
the system to be engineered.
2. Data flows must always be labelled with the data they contain. Do not put verbs in the data flow
description as this implies a process.
3. Parent and child diagrams should be consistent. Each child diagram should have the same input
and output data flow as the parent process. Do not show a data flow coming from or to an
external entity on a level 1 DFD that isn’t shown on the context diagram (and vice versa).
4. Check the direction of data flows to and from data stores.
5. Make sure each process has at least one input and one output.
6. Each data store should have at least one input and one output on the DFDs somewhere.
7. Each process name should start with a verb.
8. Where a process has only two data flows (one input and one output) then check it. Usually a data
flow has been omitted. 32
 PROCESS MODELLING AND DFDs

▰ The DFD on their own are insufficient to describe the processes.

▰ Behind the diagrams should be a textual description showing detail of all the
elements that appear on the diagrams.
▰ These are logged into what is known as a data dictionary.
▰ The DFD’s together with the data dictionary definitions are known as a process
model.
▰ Any proprietary CASE tool will have the facility to record these items in a data
dictionary.
Process modeling – a technique used to organize and document a system’s
processes.
▻ Flow of data through processes
▻ Logic
▻ Policies 33
▻ Procedures
 STRUCTURED TERMS – DATA DICTIONARY

▰ data dictionary - document containing definitions of all system data;

includes data elements, data structures, data stores, data flows, and
process specifications
▻ data elements - lowest level of information on which a process can act
▻ i.e. DB attributes/record fields - e.g. unit price
▻ data stores - places where data are stored; e.g. files; microfiche, filing
cabinets
▻ data flows - represent movement of data in a system; consist of data
input and data output e.g. forms, reports, invoices, letters
▻ process specifications - definitions of how processes work 34
 PROCESS MODEL

▰ Here are examples of some definitions of a data flow, an external

entity and a process.

35
 CASE STUDY

▰ Buatlah DFD untuk sistem perpustakaan Del. Mulai dengan:

▻ Daftarkan external entity
▻ Identifikasi proses apa saja yang ada
▻ Identifikasi minimal satu aliran data input dan output dari
setiap proses
▰ Setelah itu kelompokkan mana proses yang saling berhubungan.
Gunakan diagram process decomposition untuk memudahkan anda
mengelompokkan proses-proses tersebut.
▰ Setelah itu gambarkan Context Diagram dan Diagram Level 1 dan
seterusnya… 36
THANKS!
Any questions?
You can find me at
rini.sipahutar@del.ac.id

37