2 DFDS, LDSS AND ELHS
DFDS, LDSS AND ELHS.................................................................................................................... 2
Data Flow Diagrams .................................................................................................................... 2
DFD Notation ............................................................................................................................... 2
External Entity .............................................................................................................................. 2
Data Flow ..................................................................................................................................... 3
Process .......................................................................................................................................... 4
Data Store ..................................................................................................................................... 5
Data Flow Diagrams Aid Communication ................................................................................... 6
Decomposing Data Flow Diagrams ............................................................................................. 8
Context Diagram......................................................................................................................... 11
Developing Data Flow Diagrams ............................................................................................... 12
Direct data flow diagramming .................................................................................................... 13
Formal data flow diagramming .................................................................................................. 14
Document Flow Diagrams .......................................................................................................... 14
Resource Flow Diagram ............................................................................................................. 17
Organisation Chart ..................................................................................................................... 19
DFDs, LDSs and ELHs
SSADM builds a multiple, self checking, view of data oriented systems. It looks at
a system from the processing perspective and builds a processing model which
shows how information, in the form of distinct data items, is passed around. It
concurrently identifies the data contained within the system and builds a data
model which shows how the data should be grouped to support the processes.
When these models become stable, in the middle of Requirements Specification, a
third view that links the system‟s data with the processes performed on that data is
formed. The building blocks of these three complementary views of a system are
respectively the Data Flow Diagram (DFD), the Logical Data Structure (LDS) and
the Entity Life History (ELH).
In what follows, the basic concepts and notation used to draw these three
graphical representations of a system are presented. The manner in which they are
developed within an SSADM life-cycle will be shown in the following chapters
which display the method through its constituent techniques.
One of SSADM‟s underlying philosophies has always been not to use any
technique that has not already proved itself in practise. Thus the contents of this
chapter may be familiar to experienced system analysts who need only skim
through it to familiarise themselves with the notation or even skip it altogether.
Alternatively, the inexperienced analyst may wish to either start here or revisit this
chapter after gaining some understanding of the SSADM techniques and
framework as described in the following chapters. After all, SSADM, in common
with all other structured methods, can be viewed simply as a recommendation to
use certain techniques in a certain sequence.
Data Flow Diagrams
The Data Flow Diagram (DFD) is the visible part of the Data Flow Modelling
(DFM) technique. If used, the DFD is drawn at the very beginning of the analysis
where, in various guises, it helps define the context of the system under
consideration. It then becomes, with the LDS, the main place for recording the
analysts‟ understanding of the functioning of the current system. When a good
understanding of the data movements of the current system has been achieved, the
logic of the system is distilled from the DFD and a new „logical‟ DFD may be
produced. This DFD contains the essence of the system‟s functionality, free from
technical and physical constraints that may exist in the current system. With the
logical view of the system in hand, the analysts propose alternative options for a
new system. The users choose one of these options and a final DFD is drawn for
the, by now, „required‟ system.
The DFD is a diagram that consists principally of four symbols, namely the
external entity, the data flow, the process and the data store. Additionally, a
physical flow can be shown on the DFD of the current system.
An external entity is something outside the system that receives or sends
information to the system. It is sometimes known as an external source/recipient
and should not be confused with the notion of an Entity (not external) which is
used in SSADM to refer to collections of data that reside within the system!
The symbol used to represent an external entity on a DFD is an oval which
contains the name of the external entity and an unique identifier consisting of a
lower-case letter of the alphabet (see figure 2.1)
External Entity d
Dublicated External Entity Supplier Supplier
Decomposed External Entity Cosmetics Equipment
Figure 2.1 External entity notation
Sometimes, it is convenient to show an external entity in more than one place on a
DFD. When this happens, a stripe is used to indicate that an external entity is
repeated somewhere else in the same diagram. Also, it is possible that an external
entity can be decomposed when viewed from different angles (or levels) within
the system. In this case, a numeric suffix after the identifier will retain the fact that
this external entity is a more specific manifestation of an already defined external
Any information that exists within a system has to originate from an
external entity. The identification of external entities is relatively straightforward
and many analysts start drawing DFDs by firstly identifying as many external
entities as they can.
When there is doubt whether something is an external entity or an integral
part of a system, it helps to remember that external entities are the system‟s only
sources of original information.
A data flow represents a piece of information moving between two objects of a
DFD. The symbol for a data flow is an arrow with the name that uniquely
describes the contents of the flow next to it (see figure 2.2)
One way flow
Two way flow
Flow between two Goods
Physical flow Cosmetics
Figure 2.2 Types of Flow
In SSADM a two way arrow is also allowed, at least on the high level initial DFDs
of the current system. These should be used sparingly. Additionally, a flow
between two external entities can be shown using a dashed arrow. This flow is not
of importance to the system (since it is between two things which are outside its
area of concern) but it helps clarify some ambiguities that may arise when reading
a DFD. Also, it is sometimes convenient in the initial analysis to show the flow of
a physical resource between two objects in the DFD. When this is deemed
necessary, a broad arrow is usually used to depict it.
The drawing of DFDs is an iterative activity. However clear a completed
DFD looks, it should be appreciated that to draw one many passes have to be
made (with a lot of paper ending up in the waste-paper basket!). A DFD starts
taking its final shape when it is possible to produce a clear list of data items (or
attributes) for each and every one of its data flows.
A process shows an activity within a system that transforms data which either
already exists within the system, or has just been received from an external entity.
Processes represent data oriented activities performed within the organisation.
On a DFD a process is shown as a box partitioned into three, as in figure
2.3. The top left hand side contains a unique number that identifies the process
and its whereabouts within the diagram.
Figure 2.3 Process
The top right hand side contains the location where the process takes place. This
location may be an actual physical location, such as „store room‟ or „admin‟, or a
person who performs the process, such as „admin clerk‟ or „Sam‟. Identifying the
location of a process is optional. Indeed, the location is only indicated in the first
DFDs drawn for a system. As the analysis proceeds, the location is left blank since
it actually signifies a physical constraint that exists in the current system and does
not add anything to the functionality of the system. It may come as no surprise that
most non-SSADM DFD notation has no provision whatsoever for location.
The main body of the process box contains a descriptive name for the
process. This name should contain a strong active transitive verb which clearly
indicates what processing takes place on the data received by the process.
The process is the main building block of DFDs. Identifying processes is
not as straightforward as it seems and a certain knack is required.
For a process to be complete, it needs to have both an input and an output
(shown by data flows going into and coming out of it). If a process has no input
then it has generated data for itself, something that is not allowed. If a process has
no output then it has no use and exists only for itself. In well run organisations and
businesses this does not happen. A process that is such a black hole of information
may exist in extremely bureaucratic circumstances but is very rare. When such a
situation seems to arise, where the sole aim of an activity is to gather information
that is never used by anyone, then the novice system analyst is advised to look
again because the chances are that he or she has misunderstood the purpose of that
A data store shows where information is held within the system. Data stores are
shown on DFDs as open ended rectangles which contain an identifier and the data
store‟s name (see figure 2.4). In a system, data may be stored in an electronic
medium such as a computer or a till machine, in a non-electronic „manual‟ form
such as a filing cabinet or a drawer, or in a transient form where it has been
deposited awaiting collection such as an in-out tray. The data store identifier
caters for these three cases:
T1 Unpaid Invoices
D1 Orders D1 Orders
Figure 2.4 Data Stores: Digitised, Manual and Transient, and duplicated
For electronic data stores the letter D (for digitised) is used. Manual data stores are
identified by the use of the letter M and transients by the letter T. The letter C is
not used in SSADM as it may stand for both Computerised and Clerical!
As with external entities, many crossing flows may be avoided if we are
allowed to draw a data store twice on the same diagram. When this is done, an
extra vertical line is added on both data stores. Some further data store numbering
conventions will be presented after the notion of decomposing DFDs is introduced
later in this chapter.
Clearly, as with processes, data stores should both receive information for
storing and provide it for further processing. If a data store exists without a flow
from a process coming into it or a flow towards a process coming out of it then the
analyst should further investigate the system (by asking the user such questions as
“how does the information get here in the first place?” and “who uses this
information after it gets here?”).
Direct flows of information between two data stores are evidently not
possible. A data store is passive. It does not suddenly jump up and throw data to
another data store in the same way that the contents of a cabinet don‟t suddenly
materialise somewhere else, as if moved by a poltergeist. Some action has to take
place to pick things out of one data store and redistribute them to others. That
action is depicted by a process box which will need to intervene between the two
communicating data stores.
Data stores contain the data that exists inside a system. As such, data
stores belong to the system and no one outside the system should have access to
them. This means that an external entity cannot, under any circumstances, be
connected via a data flow directly to a data store. There should always be a
process in between an external entity and a data store to either retrieve the data
from the data store for sending to the external entity or to receive the data from an
external entity before putting it into the appropriate data store. Conversely, a
process that does neither take data from a data store nor puts data into one does
not belong to the system and its inclusion should be further investigated. The data
store is fundamental to an information system since it represents the location of
the information. Any process that does not communicate with the information in
the data stores is simply not a process of this information system.
Data Flow Diagrams Aid Communication
One of the reasons for drawing data flow diagrams is to aid communication
between the analyst and the user. A completed DFD does not use any technical
notation that cannot be understood immediately by the average person. The best
way to demonstrate this is to actually „walk through‟ one. See for example the
DFD displayed in figure 2.5 which depicts a small Stock Control system.
A simple reading through the aptly named processes shows that the main
activities of this system are to Order Stock, Receive Stock and Sell Stock. Further,
a reading of the data stores informs us that the system keeps information about the
stock it holds in a Stock File and about its orders in a Purchase Order Cabinet.
From the external entities it is clear that the system; provides Managers with stock
lists and matched order details; expects from Managers a purchase order detailing
the goods to be ordered; expects from Suppliers information about goods
delivered; and expects to be informed about what Customers have bought.
1 Stock Clerk
Stock List Stock
Order Stock List M2
Supplier Purchase Order
2 Stock Clerk
Receive Orders M1
Manager Delivered Goods
Sell Sold Goods M2 Stock
Figure 2.5 A Small Stock Control system. Observe the use of the convention which allows the
Stock File manual data store to appear twice on the diagram, as does the Manager external entity.
Also note that all processes make use of at least one data store.
Note that what information actually moves about is not clear from the
diagram alone. The diagram will only really become useful, in software
engineering terms, when the data content of each data flow is identified. For
example, what is the content of the Purchase Order data flow emanating from
Manager towards Order Stock? Is it the product name and the quantity ordered? Is
the supplier name and address included? Or is there just a supplier number that
distinguishes one supplier from another? Is the price of the product included in the
flow? If it is, which price is it? The one from a price list? The one the manager
may have just negotiated with the supplier before setting up the purchase order?
Or is it the highest price the manager expects to pay? Also, is the order date
included in the flow? Is there a date indicating the latest date beyond which the
goods will not be accepted? Are there any other conditions attached to the order,
such as a request not to deliver it in parts?
Only after careful investigation can the analyst answer these questions and
draw an effective diagram. In the case of the Small Stock Control system we are
considering for the moment, the obvious place to look for answers to the above
questions is a sample of an actual Purchase Order used by the business. Request a
copy of one and read off the data items it contains. Then check with the users
whether they want any additional information to be included. Specifically enquire
whether the information on the existing Purchase Order is sufficient to allow a
hassle-free match with the supplier‟s delivery note which will accompany the
stock when it arrives.
Asking these questions in order to fill-in the data content of each data flow
enhances the analysts‟ understanding of the situation and facilitates the task of
providing a computer information system that actually supports the business.
If we now study the whole of figure 2.5 again, we note that no mention has
been made about how the system has achieved what it has set out to achieve. The
only concern has been with what is achieved and what has been stored in order to
achieve it. In fact any system in general, and any process in particular, acts as a
black box into which information enters and from which information emanates.
The DFD does not show either how the input is turned into output nor where the
information is physically stored.
Decomposing Data Flow Diagrams
The closer look at process 1 also shows that it is logically consistent and does
indeed describe the activity of ordering stock. On the other hand, it does not
contain enough detail to understand exactly what happens when stock is ordered.
For example, is there any time lapse between the production of a stock list and a
firm order coming back? When does a check of the product files take place? Who
is responsible for choosing which supplier to use?
The DFD deals with these issues by allowing more detailed views of the
high level processes shown in figure 2.5. This is done by breaking up each process
into as many sub-processes as deemed necessary. Any process on a DFD may be
broken up into several sub-processes which, when viewed collectively, make up
that process. Thus for example we may break-up process 1 into that shown on
1 Order Stock
Stock List Purchase Order
Stock List Purchase Order
Stock Purchase Order
Figure 2.6 Level 2 of Order Stock
The decomposition of a DFD into lower level DFDs is known as levelling.
The DFD that shows the entire system is known as the „top level‟ or „level 1‟
DFD. The DFD of figure 2.6 plus all the DFDs that contain more detailed views of
the level 1 processes make up „level 2‟ DFDs. Any level 2 process that is further
decomposed gives rise to a level 3 DFD and so on. A process that is decomposed
is known as a „parent‟ whose „children‟ are the diagrams derived from it. Any
process that does not contain any further decomposition ( i.e. has no children) is
known as a „bottom level‟ or „elementary‟ process.
These elementary processes constitute the building blocks of the system
and as such need to be considered carefully. They will contain enough detail for a
program specification to be deducible from them at a later stage. As such, a clear
description of each one has to be produced at some time during the analysis. These
Elementary Process Descriptions (EPDs) are written in plain English, or in
pseudocode, depending on the project team. A sample EPD is shown in figure 2.7.
Elementary Process Description
System: Small Stock DFD Type: Current
Process Name: Record Purchase Order Process Id: 1.2
Managers give the stock clerk a ready made purchase order. The stock clerk places
this order in the Purchase Order Cabinet.
It is the managers‟ responsibility to send the order directly to the supplier they
have chosen. Each purchase order contains product information taken from the
supplier‟s price list. The date after which a delivery of goods will be unacceptable
is also included.
Figure 2.7 An Elementary Process Description for Record Purchase Order
When the analyst decides that a process is indeed an elementary one and no
further decomposition is necessary, the process box is annotated with a little
asterisk in its bottom right hand corner (see figure 2.8).
Figure 2.8 Elementary Process showing „asterisk‟.
Note that figures 2.5 and 2.6 are consistent in that whatever lies in the immediate
vicinity of process 1 in figure 2.5 does indeed communicate directly with it when
viewed through figure 2.6. If there is a flow on a level 2 diagram that does not
correspond to one on its parent diagram then something is wrong. In this case
either the top level or the lower level diagram needs updating, depending on
further analysis. Lower level diagrams show a view of the system that is from the
bottom upwards while top level diagrams show more conceptual overviews.
Sometimes a flow of information is missed on the top level DFDs only to be
discovered when the nitty gritty of the lower level DFDs is considered. In other
cases the careful attention to detail required for a lower level DFD leads to the
missing of a flow that is clearly visible from the higher level DFD. A continuous
bouncing from high to low and back to high level takes place, each time yielding a
new aspect of the system under consideration. This leads to a better, deeper,
understanding of the system after each bounce is completed. The novice analyst
only has to attempt a DFD of a real situation to come to appreciate this point.
The analogy here is that of a map. In order to drive to a town a „high level‟
map of the whole region is used. When the town is reached a new map is required
showing the roads of the town in more detail. Each map serves a different purpose
and neither is enough to complete a journey into a town. Further, the roads shown
on the parent map going in (and out of) a town correspond directly with roads
shown on the more detailed maps. The analogy can be further expanded if we
imagine that we are trying to plan (i.e. design) routes into and out of towns. In this
case the high level map will be useful in indicating the possible approaches. When
these are decided upon, the detailed maps have to be looked at to check whether
the suggested approaches are indeed possible and traffic jams avoidable. This
detailed look may lead to further suggestions which have to be referred back to the
top level map to check if these suggestions are indeed useful (it is no good looking
at a detailed map and suggesting that the best way to get into town is from an
eastward approach when you are driving in from the west - and there is no ring
road circling the town). Thus town planners have to continuously skip from high
to low and back to high level maps. Of course, the number of levels they will have
to dip into depends on the size of the town, in the same way that the number of
levels on a DFD depends on the size of the system under consideration.
Note also that the level 2 DFD of process 1 has all its processes numbered
1.n. The convention is that the number of a child process is prefixed with the
number of its parent process. With this convention it is immediately clear that
process 2.3.1, say, is a child of process 2.3 which itself is a child of process 2 (see
Figure 2.9 Conceptual view of DFD levels
Similarly, a data store that lies solely inside a process is numbered in a
manner to indicate this. Thus data store D4 is a data store shared on a level 1 DFD
while data store D4/3 is one of three level 2 data stores that resides solely in
There are no rules suggesting how many processes should be placed on
each DFD level. Since the DFD is also a means of communicating with other
human beings, anything between six and nine or even fifteen processes per level
have been suggested. It is up to the individual analyst to decide how many
processes will retain the comprehensibility of each DFD and it will be the analyst
who will be blamed if the diagram is too cluttered.
Figure 2.5 represents the top level or level 1 DFD of a Small Stock Control
system. A level higher than that, showing the whole system as a single process
with external entities around it, is also possible. This diagram places the whole
system into context vis a vis its communication with the outside world as seen
through its own eyes (see figure 2.10)
Stock List Purchase Order
Figure 2.10 Context diagram of Small Stock System
Not surprisingly this diagram is known as the Context Diagram or the level 0
(zero) diagram. Viewed in this manner, level 2 diagrams are a decomposition of a
level 1 diagram which in turn is a decomposition of a level 0 diagram.
All the rules mentioned above about DFDs apply here; all the incoming
and outgoing flows to and from the context diagram should correspond directly
with the flows seen flowing between all level 1 processes and the external entities
they interact with. Further, since each lower level DFD is consistent with its
parent diagram, it will be possible to trace each flow seen in the context diagram
down to the elementary process that either generates that flow or receives it. The
flows shown on the Context Diagram are of vital importance since it is for these
interactions with the outside world that the system exists and through which it will
be judged as a good or a bad system. For this reason SSADM makes sure that we
are 100% confident with the content of each input to or output from the system by
necessitating the completion of a document that traces each external flow down to
an elementary process. This document is called an I/O Description, a sample of
which can be seen in figure 2.11
Data Flow Data Item Remarks
Stock List product name
quantity in stock
Purchase Order supplier name Purchase order contains
supplier address one „supplier name‟ but
supplier‟s product code many „product name‟
purchase order date
latest acceptable delivery date
Matched Orders supplier name
supplier‟s product code
purchase order date
latest acceptable delivery date
Delivery supplier name
supplier‟s product code
purchase order date
Bought Goods product name Customers name is not
quantity sold taken.
Figure 2.11 I/O Description of the Stock System depicted in figure 2.10
Developing Data Flow Diagrams
There are no fixed rules about how to draw a DFD. In what follows suggestions
about tackling different situations are given. Usually, in each situation one of these
suggestions is more useful than the others. Having said that, each analyst develops
his or her individual style which is more often than not a hybrid of these
suggestions. Matters are further complicated for the novice system analyst by the
fact that there is no one DFD for each situation. Indeed, if the DFDs of two
individuals are identical then some replication has taken place along the line. A
DFD set is complete only when it feels right. For this reason most real life DFDs
have to be shown to colleagues who will be able to pass judgement on whether the
DFD is finalised or whether another stab at it is needed.
The fact that no two DFDs of the same situation „look‟ alike does not
mean that two analysts working independently should not identify the same
external entities, the same data stores and the same data items entering the system.
It is the „presentation‟, and thus the appearance, of this understanding of the
system under investigation that will differentiate each person‟s DFD.
The situation becomes more unnerving when it is realised that it is not
always the case that the drawing starts from the higher level downwards. The
other way round is sometimes more productive, depending on the situation. In fact
we find that we work like a yo-yo continually tweaking the diagrams until we are
satisfied that the diagram has served its purpose. It should always be remembered
that the DFD is meant to produce enough information for a clear program
specification to be extracted from it. Only by completing an SSADM cycle will
the novice analyst realise what level of detail the diagram is meant to arrive at.
Nevertheless, the following suggestions are useful.
Direct data flow diagramming
This method is the one favoured by experienced analysts. Unfortunately it does
not seem to use rules and the diagrams seem to take shape through the gut and not
through the head.
It has been indicated above that identifying external entities and data stores
seems more straightforward than identifying processes and data flows.
Starting from data stores alone is not enough since they are quite static.
What we are aiming for is to identify the data store in order to identify its data
contents in order to detect the processes which either provide values for them or
use them to provide the business with information it requires. It is one matter
identifying data stores and another matter entirely identifying their contents
Starting from external entities alone does give an indication of information
flowing to and fro since an external entity does not exist if it neither sends nor
receives information from the system. Unfortunately the problem with external
entities is that in the beginning it is not clear what lies inside and what lies outside
the system. Indeed, part of the DFD‟s task is to identify the system‟s boundary in
the first place. When the boundary starts taking shape a minor breakthrough has
One way of starting is to take a large piece of paper and start scattering
round its edges the little named ovals that denote the external entities being
identified, while at the same time placing the little open ended rectangles that
denote the newly discovered data stores somewhere in the middle. Since data
stores and external entities are not allowed to communicate directly with each
other, a blank space exists in between. The next move is to try and identify a few
high level processes which should be immediately scribbled down. With a few
processes, data stores and external entities present, flows to and from these
processes start taking shape. These flows link, via appropriate processes, the
information we know moves to and from the external entities with the information
we know resides in the data stores. As more processes and data flows are
discovered the piece of paper begins to contain many crossing lines. It soon
becomes positively messy and ready to end up in the waste-paper basket. A fresh
sheet of paper is then obtained on which the contents of the first sheet are placed
in some rearranged manner and the whole activity starts again until such time that
it is deemed that enough is enough.
Reaching a state of understanding which leads to the identification of the
first processes of a system is another little minor breakthrough in itself. What we
are trying to do here is to create a model that will give us both an overview and a
detailed breakdown of a system at the same time. It seems that we need the whole
picture to start detecting the system‟s detail and that we need the system‟s detail to
appreciate the whole. This is why things look tricky to start with. Only after
something is jotted down on a piece of paper, be it a list of possible data stores, a
list of system outputs, a list of external entities, or indeed a mix of any of the
above, do fresh ideas about the nature of the system start manifesting themselves.
Formal data flow diagramming
The above „natural‟ method is of course not very helpful for the novice who needs
something tangible to hold on to. Looking at any organisation or business there are
three things that are clearly visible. They are a) documents that seem to fly around,
b) products and resources moving to and fro, and c) the place where certain things
happen, for which certain people in the organisation‟s hierarchy are responsible.
Depending on the type of organisation, any one of the above will be predominant
and therefore easier to start with. In what follows, the documents, the resources,
and the structure of the organisation under analysis will each be used to draw a
diagram which will in turn be helpful in drawing the DFD. None of these
diagrams, the Document Flow Diagram, the Resource Flow Diagram or the
Organisation Chart are official SSADM products. They are products of
conventional system analysis which can be used in SSADM if it is thought (by the
project team) that they will lead to better DFDs. In short, they are mere working
Each one of these diagrams has the advantage of identifying the system‟s
boundary slightly more clearly than the direct method. Since the final aim is to
produce a DFD, it should not be forgotten that it is data flows (and hence
information in the form of data items) that need identifying. Thus, when a
document or a resource is traced through a system, it is not that specific document
or resource that is of interest. Instead it is the actual information on that document
that is important. When the document is entering the system, it gives a clue to the
data which the future (computer) system will have to anticipate. When the
document is emanating from the organisation, it contains the data the future
system must be able to output on request. These documents therefore act as a
trigger for the analyst to identify the (data) inputs and outputs of the future system.
Of course, what is really needed is to then identify the processes which will
perform these inputs and outputs and the data stores which will be used by these
Document Flow Diagrams
Most business environments generate a lot of paper. If they don‟t they are too
small, and hence not suitable for the elaborate analysis and design recommended
by a full blown application of SSADM. Consider, for example, the hairdressing
Salon of the case study used in these notes. This Salon is informal in the sense that
the proprietor currently deals with most situations single-handedly. On the other
hand it is clear that she will need to organise herself and her paperwork
considerably if she wishes to expand her business from the two shops she now
owns to the chain of salons she strives for. It is this potential expansion, where
salon managers across a wide geographic area will have to communicate with each
other, that merits the effort required by the method.
In drawing document flow diagrams, the trick is to identify as many
documents as possible and, for each, its source and its recipient. A document flow
diagram simply consists of ovals representing sources or recipients of documents
connected by arrows containing the name of the document flowing from one to the
other. Standard systems analysis investigation, such as, in our example, direct
observation of the daily workings of the salon, reveals the following documents
flying about: Invoices and Delivery Notes from Suppliers to the Stock Clerk,
Adverts from Marketing to Magazines, Daily Training Records from the
Appointments section to Personnel, Monthly Training Records from Personnel to
Training Agencies, Payments from Accounts to Suppliers, and a few others as
shown in figure 2.12:
Payments Delivery Marketing
Accounts Invoices Control
Figure 2.12 Initial Salon Document Flow Diagram
The next thing to do is to have a first crack at deciding what will lie inside and
what outside the system under investigation. The decision, which is taken in
consultation with the users, leads to the diagram being annotated with a line which
shows what lies inside the system and what outside. The setting of this boundary
is by no means as straightforward as it may appear here, where we have
conveniently separated many sources and recipients in a way that simplifies the
real case significantly. Even so, the boundary is still a bit arbitrary. In practice,
where the distinction between business and system objectives is not clear cut, the
boundary should be treated as a „first shot‟ at scoping the problem. (An alternative
way of scoping a situation will be shown when the Business Activity Modelling
technique is introduced.) For the Salon, the Supplier, the Magazines and the
Training Agency are clearly outside the business‟s sphere of influence, while the
proprietor decides that Accounting and Marketing will also lie outside the
computer‟s realm. The system‟s boundary is shown in figure 2.13.
Note that there are some documents that are clearly missing from the
scenario (or alternatively there is a lot of information flowing about which does
not have an accompanying document). For example, while the scenario states that
orders are made, they seem to be made through the telephone and no document
raised to be sent to the supplier (though a note of items ordered may be jotted
down for later checking). Similarly, no documents seem to flow about indicating
whether an Appointment has been made with a Customer. In fact, the documents
of the salon, as we have defined them here, fail to contribute anything to our
understanding of the appointments side of the business, since each appointment
request is currently dealt with informally over the phone and logged in an
Appointments Book (which we have not considered to be a „moving‟ document).
Payments Delivery Marketing
Accounts Invoices Control
Figure 2.13 Salon Document Flow Diagram with system boundary.
The document flow diagram uses informal rules and cannot be checked as
rigorously as a Data Flow Diagram. For this reason it is only a supporting product
for SSADM, expected to be raised, if at all, sometime during the Feasibility Study
(Stage 0) or the beginning of Requirements Analysis (Stage 1).
If a document flow diagram is used to produce a DFD, then the
sources/recipients lying outside the boundary become external entities while the
ones inside give rise to processes and/or data stores. Figures 2.14 and 2.15 show
the context diagram and a level 1 DFD that could be derived from the document
flow diagram of figure 2.13. The DFD of figure 2.15 is deliberately left
inconsistent to indicate precisely what emanates from the document flow diagram
used to create it. When the reader perfects his or her understanding of Data Flow
Modelling, it may be interesting to study it to find its shortcomings.
Checked Invoice P45
Figure 2.14 Salon Context diagram derived from the document flow diagram of figure 2.13.
Checked Invoice Employment
Train Records Agency
Figure 2.15 Salon level 1 Current System Data Flow Diagram derived from document flow
diagram of figure 2.13. Note how the incomplete DFD leads to further questions that need to be
However naive figures 2.12-2.15 appear to be they are still informative. For
example, figure 2.13 gives a glimpse of the salon set-up where three distinct
subsystems seem to co-exist: one for controlling stock, one for dealing with
personnel and one to fulfil customer appointments. Furthermore, the gaps
appearing in figure 2.15 help the analyst ask more pertinent questions about the
Resource Flow Diagram
The resource flow diagram uses similar conventions to its document flow cousin.
As in the case of the document flow diagram, the interest here is to follow the
resource in such a manner that the information travelling with it can be educed
when drawing the DFD.
The Salon under consideration does not have many resources. A library, an
airline, a stock depot, a leasing company, a vehicle renting business, and others,
are examples of organisations in which the tracking of resources gives a good
indication of the information necessary for the proper functioning of that
organisation. The salon has two types of resources, its stock and its employees.
These give rise to the resource flow diagrams of figure 2.16.
Use Remove Store
Stock Stock Stock
Register Participate in
Figure 2.16 Resource flow diagram for a) stock item, and b) employee or trainee.
The resource flow diagrams of figure 2.16 lead to the Data Flow Diagram of
figure 2.17. Notice the inconsistent level of detail in each process. By the time the
final DFD for the current system is produced, processes that seem to be high level
here may end up at lower levels later on. Notice also the implicit decision of
choosing the external entities, which seem to appear from nowhere.
d 1 3
Supplier Buy Consider Employee
* * Termination
Customer Bill Participate in Agency
Fig 2.17 Salon level 1 Current System Data Flow Diagram derived from resource flow diagrams of
figure 2.16. Note again that as far as DFDs are concerned, this one is a long way from being
complete. Nevertheless, it still manages to give a glimpse of what is going on in the Salon and
helps us focus on different parts of the whole system.
In well structured organisations, of which the Salon under consideration is not a
member (yet), a hierarchical organisation chart either exists or can be easily and
unambiguously produced. By identifying activities taking place within the salon
the chart of figure 2.18 can be drawn.
Manager (1) order stock
Receptionist Stylist Trainee
(1+1) (4+3) (3+3)
set-up appointments participate in appointments
monitor training use stock
Figure 2.18 Organisation Chart of Salon
The organisation chart essentially consists of activities taking place within the
organisation. As such it has the ability to identify major system processes as seen
through the eyes of the people performing them. (After all it is people the analyst
interviews to get an understanding of a system under consideration). These
processes can now be jotted down, giving rise to a DFD in the making (see figure
a 1 Reception 4 Manager
Customer Request Set Up Order
2 Stylist M2
Reference Employee Delivery Note
Employee Details Employ
Fig 2.19 Infant current system DFD derived from the Salon organisation chart of figure 2.18.
What is missing from this infant DFD are the actual flows of information running
about between these processes. This is in direct contrast to the DFD constructs of
the preceding sections in which the flows, document or resource, were the driving
force of the diagrams.
This diagram is „filled in‟ by turning back and rereading the scenario, and
adding the information flows as they are identified. Alternatively, most flows can
be simply picked up from a document or a resource flow diagram using the ideas
One thing is for sure: drawing a DFD is a recursive process which requires
a bit of imagination to find the best way to proceed. Some more clues of what to
do will become apparent when we find out, in the next chapter, how to arrange the
data once it is captured by one of the processes of our DFDs.