Systems Analysis & Design
Structured Analysis
Structured analysis is a development method for the analysis of existing manual or
automated systems, leading to the development of specifications for a new or
modified system. The underlying objective in structured analysis is to organise the
tasks associated with requirements determination to provide an accurate and complete
understanding of a current situation.
The word structure in structured analysis means:
1. the method attempts to structure the requirements determination process,
beginning with documentation of the existing system.
2. the process is organised in such a way that it attempts to include all relevant
details that describe the current system.
3. it is easy to verify when relevant details have been omitted.
4. the identification of requirements will be similar among individual analysts and
will include the best solutions and strategies for systems development
opportunities.
5. the working papers produced to document the existing and proposed systems are
effective communication devices.
This method of analysis has become synonymous with data flow analysis which
provides a tool for documenting an existing system and determining information
requirements in a structured manner.
Data Flow Analysis
Data analysis attempts to answer four specific questions:




What processes make up a system?
What data are used in each process?
What data are stored?
What data enter and leave the system?
Data drive business activities and can trigger events (e.g. new sales order data) or be
processed to provide information about the activity. Data flow analysis, as the name
suggests, follows the flow of data through business processes and determines how
organisation objectives are accomplished. In the course of handling transactions and
completing tasks, data are input, processed, stored, retrieved, used, changed and
output. Data flow analysis studies the use of data in each activity and documents the
findings in data flow diagrams, graphically showing the relation between processes
and data.
SAD4.DOC
CMSCS201
1
Systems Analysis & Design
Data flow diagrams are used in a number of methodologies (SSADM and I.E.) to
name two) and have the advantage of being able to be used in a number of contexts
within the analysis and development framework, representing models of the system
during its various stages of refinement. i.e.:
Current physical
Current logical
Required logical
Required physical
How the existing system works
What the current system accomplishes
What the new system is required to accomplish
How the required system will be implemented
Physical and Logical DFDs
There are two types of data flow diagrams, namely physical data flow diagrams and
logical data flow diagrams and it is important to distinguish clearly between the two:
Physical Data Flow Diagrams
An implementation-dependent view of the current system, showing what tasks are
carried out and how they are performed. Physical characteristics can include:
Names of people
Form and document names or numbers
Names of departments
Master and transaction files
Equipment and devices used
Locations
Names of procedures
Logical Data Flow Diagrams
An implementation-independent view of the a system, focusing on the flow of data
between processes without regard for the specific devices, storage locations or people
in the system. The physical characteristics listed above for physical data flow
diagrams will not be specified.
Data Flow Notation
Although the use of data flow diagrams is common to a number of analysis and design
methodologies the notation used in each instance varies slightly. The notation in use
here is drawn from SSADM and is recommended for use on this course.
There are generally five symbols used to construct data flow diagrams:
1. Data Flow. Data move in a specific direction from an origin to a destination in the
form of a document, letter, telephone call or virtually any medium. The data flow
can be thought of as a 'packet' of data.
SAD4.DOC
CMSCS201
2
Systems Analysis & Design
sales order
At the highest level DFD, one arrow may represent several data flows, which may
be decomposed into individual flows at the lower levels.
There are some validation rules about where data flows may or may not travel.



Data stores may not be linked by data flows: flows must travel from one to
another via a process.
External entities may not send or receive data flows directly to or from a data
store: they must communicate via a process.
Data cannot be generated by a process, or be swallowed by a process;
documents may be swallowed or generated, but there must be an output that is
related directly to all inputs to the process.
2. Physical flow. Used to represent the flow of physical items in the system.
Goods
3. External Entities. External sources or destinations of data, which may be people,
programs, organisations or other entities which interact with the system but are
outside its boundary. They may be external to the whole company, such as
customers, Inland Revenue etc. or just external to the application area. Thus if we
are modelling a Sales Office system, Accounts & Despatch areas would be shown
as external entities. Each external entity communicates in some way with the
system, so there is always a flow of data shown between a process in the system
and an external entity.
Supplier
Supplier
It may be desirable for the sake of clarity to duplicate an external entity on the
diagram, rather than have arrows from all points converging on one entity. If that
is the case, put a small line along the top of the entity.
4. Data Store. Here data are stored or referenced by a process in the system. The data
store may represent computerised or non computerised devices. It may be a filing
cabinet, an in-tray, a card index, a reference book or a computer file. Anywhere
that data is stored and retrieved is a data-store.
The notation is simple: a long, open-ended rectangle. with a box at the left end.
The box is labelled with an alpha pre-fix and a number. The alpha is either D (for
an automated data store) or M (for a manual/card data store). The number has no
significance; it is purely a reference. The rectangle is labelled with a description of
the contents of the data store.
SAD4.DOC
CMSCS201
3
Systems Analysis & Design
D1
Stock file
D1
Stock File
Again, for the sake of tidiness, you wish to show the data store in more than one
part of the diagram, add a bar o the left hand box. Each occurrence of the box
should display the additional bar.
5. Process. A process is an activity that receives data and carries out some form of
transformation or manipulation before outputting it again. The activity may be
carrying out calculations , creating a new document from information that
triggered the process, or amending the document . It is depicted by a box divided
into three parts: the upper left position is given a number. This has no significance
other than as a reference number; it does not imply priority or sequence. The
longer top rectangle beside it names the location where the processing takes place;
this may on an overview DFD, be a broad term, Sales Accounts etc. As the DFDs
become more detailed so do these descriptions.
The rest of the box describes what is happening in the process. The rule here is to
keep the description as concise and meaningful as possible. Use an imperative
verb with an object, but make the verb specific. 'Process...' and 'Update...' are too
vague and give little clue as to what is meant. 'Calculate...', 'Add...' or 'Validate...'
give a clearer picture of what is happening.
6
Sales
Calculate VAT
Developing Data Flow Diagrams
The most comprehensive and useful approach to developing an accurate and complete
description of the current system begins with the development of a physical data flow
diagram. The use of physical data flow diagrams is desirable for three reasons:
1. Analysts initially find it easier to describe the interaction between physical
components than to understand the policies used to manage the application.
Identifying people, what they do, which documents and forms trigger which
activities and what equipment is used in the processing. The movement of people,
documents and information between departments and locations is also identified.
2. Physical data flow diagrams are useful for communicating with users. Users relate
easily to people, locations and documents as they work with these each day. Users
may consider logical DFDs abstract as they do not contain these familiar
SAD4.DOC
CMSCS201
4
Systems Analysis & Design
components, however, with physical DFDs users can quickly identify incorrect or
missing steps.
3. Physical DFDs provide a way to validate or verify the user's current view of the
system with the way it is actually operating. If there are differences, they will be
noted and discussed. It is not unusual to find that what a users thinks is happening
differs in an important way from what actually occurs.
Drawing a Context Diagram
The first diagram developed is the context diagram (Level 0). It contains a single
process and plays an important role in studying the current system in that it defines the
system under investigation by determining the boundaries of the system. So anything
that is not inside the process identified will not be part of the systems study. The
manner in which other organisation or external elements function is out of our control
and so are not studied in detail.
An example context diagram.
Supplier
P ay
sO
od
o
G
r
rde
plier
S up
me n
t
e
.N
voic
G.R
r In
plie
Sup
Disp
atch
Sales System
Note
Customer
er
Custo mer Ord
Returned
G oods No
te
The Level 0 (Context Diagram) can be drawn by following three steps:Step 1 - List the documents used in the system.
Step 2 - List all the sources & recipients
Step 3 - Draw a box representing the system and show the flow of documents from
these sources and recipients. Those areas which are known to be inside the system are
hidden within the box.
Exploding the Process to produce a Top-level (1) DFD
In order to extend the study it is necessary to ‘explode’ the context diagram to show
the processes which achieve the transformation of the entire system. Initially we must
SAD4.DOC
CMSCS201
5
Systems Analysis & Design
identify the major functional areas within the system, transform those entities into
processes and label them accordingly.
E.g.
Context Diagram
0
Process 0
External
Entity 1
External
Entity 2
System
Dataflow 1
Dataflow 2
Level 1 Diagram
1.0
Process 1
2.0
Process 2
External
Entity 2
Flow
2,1
External
Entity 1
Dataflow 2
Dataflow 1
Flow
1,3
Flow
M1,1
M1
3.0
Process 3
Datastore 1
Flow
3,D1
Level 2 Diagram
1.1
Process 1.1
1.2
Process 1.2
Flow 2,1
External
Entity 1
1.3
Flow
M1, 1.1
Process 1.3
Flow 1.1, 1.3
M1
Datastore 1
Flow 1,3
SAD4.DOC
CMSCS201
6
Systems Analysis & Design
Hence, we have the overall process of the system on the context diagram being broken
down into processes 1.0, 2.0 and 3.0 on the level 1 diagram and then process 1.0
broken down into processes 1.1, 1.2 and 1.3 on the level 2 diagram.
The high-level DFD is not yet complete: we have not identified how many processes
each of these functional areas perform, and what data stores are used. As we are
describing a physical system, we must consider the types of data moving through the
system. As a rule of thumb, we can consider the following types of data store:
1. Standing data, used for the day-to-day functioning of the system and is kept
updated.
2. Historical data that is required to be maintained for reference and enquiry
purposes, but is no longer 'live'.
3. Temporary data stores, which will cease to exist when the need for their data is
exhausted.
4. Extracted data that is retrieved from different sources for the purpose of preparing
reports, statistics and so on.
We can now consider the data flows which cross boundaries into processes/functional
areas and determine what actions are carried out on them. Each process will probably
require one data store. Our initial investigations will identify all such data stores and
their access, so what ever is unclear at this point can be clarified.
Validating the DFD
Before moving on from this initial high-level DFD, we must ensure it is consistent.
Below is a checklist of points to watch out for before moving on to a detailed
investigation which will take us to lower levels.
1. Has each process a strong imperative verb and object?
2. Are data flows in related to data flows out? Data should not be swallowed up by a
process, only transformed in some way. A data store is the only place data is
allowed to rest. Similarly, data cannot be generated by a process. A document may
be, but the data on the document comes from a data flow into that process.
3. Can the flows be reduced? If a process is too busy, it can perhaps be broken down
into two or more processes: six data flows in or out of a process should be enough.
4. Do all data stores have flows both in and out? A one-way data store is of little use,
unless it is a reference file. If the Current Physical DFD should identify such a
data store, confirm with the User that you have correctly understood the
procedures.
5. Are symbols correctly labelled and uniquely referenced?
6. Do all external entities communicate with a process? No entity should be allowed
direct access to data, either to read or to update it.
When these checks are complete we can verify the diagram with the user. On being
satisfied that the diagram is a faithful reflection of the business area, we can proceed
to decompose the diagram.
SAD4.DOC
CMSCS201
7
Systems Analysis & Design
Decomposition of top-level DFDs
The Level 1 DFD presents us with an overview of the system, a description that could
come from a preliminary interview with departmental managers, perhaps. Now we
must examine each process in more detail and break it down into other processes. The
following steps explain how this is done.
Step 1. Make each process box the system boundary. All data flows to or from that
process are now flows across the lower-level system boundary.
Step 2. Draw, outside the new boundary, the sources and recipients of these flows, as
shown on the higher level DFD, (these can be external entities, data stores or other
processes. Ensure the labelling is consistent with the higher level.
Step 3. Identify and draw the processes at the lower levels that act on these data flows.
Number the sub-processes with a decimal extension of the higher level number. i.e.
Level 1, Process 3 will break down to processes 3.1, 3.2, 3.3 etc. Those processes that
cannot be decomposed further, mark with an asterisk in the bottom right-hand corner.
Step 4. Carry out consistency checks as before.
Step 5. Make sure that all lower level DFDs map onto the Level 1 diagram, by
checking data flows.
Step 6. Review the lower levels with the User to be sure that every activity performed
by the system is depicted.
When the DFD has progressed as far as it is possible to go, the details must be
recorded on an Elementary Process Description (EPD) using a concise and precise
narrative. If more than four or five sentences are required, perhaps the process has still
to be broken down to another level.
Supporting documentation
A data dictionary, either paper or automatic, should be maintained at every stage of
DFD production. The dictionary should contain the following descriptions.
External Entity Description This describes all the external entities shown on the
diagram. Included will be such details as the functions of the entity and constraints on
how it is to interface to the system.
Input/Output Description A list of all data flows, the contents and the start and end
references for each flow crossing the system boundary.
It is important that this dictionary is maintained for the current system and for the
required system. The details will grow with each iteration, of course the first attempts
are not expected to be more than a guide.
Some Additional Notes on DFD Production.
SAD4.DOC
CMSCS201
8
Systems Analysis & Design
All activities, data flows and data stores used in this lower-level view of the system
must be included within the previous data flow diagram. The lower-level diagrams
must be consistent with the higher-level view.
In general the following rules apply:
All data flows that appeared on the previous diagram explaining the process are
included in the lower level diagram.
New data flows and data stores are added if they are used internally in the process to
link processes introduced for the first time in the explosion at this level.
Data flows and data stores that originate within the process must be shown.
No entries should contradict the descriptions of the higher level data flow diagrams (if
they do, one or the other is either incorrect or incomplete and a change must be
made).
How far should the explosion of detail be carried out? Because the nature and
complexity of systems vary, it is inadvisable to fix a specific number of levels. In
general, we should go as far as necessary to understand the details of the system and
the way it functions.
Deriving the Logical View
Physical DFDs are a means to an end, not an end in themselves. They are drawn to
describe an implementation of the existing system for two reasons:
 to ensure a correct understanding of the current implementation (users are generally
better able to discuss the physical system as they know it through people,
workstations and days of the week.)
 the implementation itself may be a problem or limiting factor; changing the
implementation, rather than the system concept may provide the desired results.
A logical view steps back from the actual implementation and provides a basis for
examining the combination of processes, data flows, data stores, inputs and outputs
without concern for the physical devices, people or control issues that characterise the
implementation.
A logical data flow diagram is derived from the physical version by doing the
following:
 Show actual data needed in a process, not the documents that contain them.
SAD4.DOC
CMSCS201
9
Systems Analysis & Design
 Remove routing information; that is, show the flow between procedures, not
between people, offices or locations.
 Remove references to physical devices.
 Remove references to control information
 Consolidate redundant data stores.
 Remove unnecessary processes, such as those that do not change the data or data
flows.
General Rules for Drawing Logical Data Flow Diagrams
. Any data flow leaving a process must be based on data input to the process.
. All data flows are named; the name reflects that data flowing between processes,
data stores, sources and sinks.
. Only data needed to perform the process should be an input to the process.
. A process should know nothing about, that is, be independent of any other process
in the system; it should depend only on its own input and output.
. Processes are always running; they do not start or stop. Analysts should assume a
process is always ready to function or perform necessary work.
. Output from processes can take one of several forms:
a)
b)
c)
d)
e)
An input data flow with information added by the process (for example, an
annotated invoice).
A response or change of data form (such as a change of £’s profit to profit
percentage.
Change of status (from unapproved to approved status).
Change of content (assembly or separation of information contained in one or
more incoming data flows).
Change in organisation (e.g. the physical separation or rearrangement of data).
Maintain Consistency Between Processes
When developing DFDs in more detail it is important to maintain consistency between
levels. No new inputs or outputs to a process should be introduced at a lower level
that were not identified at a higher level. However, within a process, new data flows
and data stores may be identified.
Follow Meaningful Levelling Conventions
SAD4.DOC
CMSCS201
10
Systems Analysis & Design
Levelling refers to the handling of local files (those that are used within a process).
The details that pertain only to a single process on a particular level should be held
within the process. Data stores and data flows that are relevant only to the inside of a
process are concealed until that process is exploded into greater detail.
Add Control on Lower-Level Diagrams Only
The logical data flow diagrams developed to this point do not include control
information. No mention has been made of how to handle errors or exceptions.
Although this information is necessary in the final analysis, it should not be a concern
while identifying the overall data flow. The secondary diagrams (below second or
third level) show error and exception handling in the process being exploded.
Some physical control information is unnecessary in logical DFDs. Copy numbers or
annotations for documents (e.g. Copy 1, Copy 2, Shipping copy or Accounting copy),
procedural orders (e.g. Find the record; Review the record; Annotate the record), or
day-of-the-week triggers (e.g. Do on Monday; Do the last day of the month) do not
belong with the logical and data aspects of requirements determination. The important
elements for understanding a process during logical data flow analysis are not
document copy numbers but descriptions of the data needed to perform the process.
Assign Meaningful Labels
The descriptions assigned to data flows and processes should tell the reader what is
going on. All data flows should be named to reflect their content accurately.
Data Flow Naming
The names assigned to data flows should reflect the data of interest to the analysts, not
the documents on which they reside. For example, an invoice contains many different
elements of information. Analysts are concerned with the contents of the invoice that
are important for a particular process. It may be the invoice number and date of issue
or the signature or authorisation associated with the invoice. It is not the sheet of
paper itself.
Data flowing into a process undergo change. Therefore, the outbound data flow is
named differently from the inbound one. (If no change is made to the data flow, what
is the purpose of the process?)
Process Naming and Numbering
All processes should be assigned names that tell the reader something specific about
the nature of the activities in the process. The names INVENTORY CONTROL,
PURCHASING and SALE are too general to be useful in a logical DFD. It is much
better to use ADJUST QUANTITY ON HAND, PREPARE PURCHASE ORDER or
EDIT SALES ORDER to describe the process.
SAD4.DOC
CMSCS201
11
Systems Analysis & Design
The following guidelines can be used for process naming:
 Select names that indicate the action taking place. Selecting an action verb and an
object to receive the action is most appropriate.
 Be sure the name fully describes the process. (If a process both edits and validates
invoice data, it should not be labelled EDIT INVOICES).
 Select process names that explain the linkage between inflows and outflows of
data.
 Avoid vague process names, such as PROCESS, REVIEW, ASSEMBLE,
HANDLE or ORGANISE.
 Use lower-level process names that are much more specific and descriptive than
those associated with high-level processes.
 Assign process names that are unique to the activity they describe.
The process numbering system introduced earlier further identifies processes
especially between levels of detail. The highest level diagram (Context) need not be
numbered. All lower level diagrams should be identified by number.
So if a Level 1 diagram identifies five processes (numbered 1 to 5) then lower-level
explosions of these processes are assigned a decimal to indicate that they are further
explanations of a higher-level process. For example, if high-level process 3 contains
four processes then they are numbered 3.1, 3.2, 3.3, 3.4. Successive explosions add
additional decimal digits: 3.1.1, 3.1.2., 3.1.3., etc.
Evaluating Data Flow Diagrams for Correctness
It is essential to evaluate all DFDs carefully to determine if they are correct. Errors,
omissions and inconsistencies can occur for several reasons, including mistakes in
drawing the diagrams. But the presence of what appears to be an error may in fact
point out a deficiency in the system or a situation in which users are not aware of how
certain processes operate.
These questions are useful in evaluating data flow diagrams:
 Are there any unnamed components in the data flow diagram (data flows,
processes, stores, inputs or outputs)?
 Are there any data stores that are input but never referenced?
 Are there any processes that do not receive input?
 Are there any processes that do not produce output?
SAD4.DOC
CMSCS201
12
Systems Analysis & Design
 Are there any processes that serve multiple purposes? If so, simplify by exploding
them into multiple processes that can be better studied).
 Are there data stores that are never referenced?
 Is the inflow of data adequate to perform the process?
 Is there excessive storage of data in a data store (more than the necessary details)?
 Is the inflow of data into a process too much for the output that is produced?
 Are aliases introduced in the system description?
 Is each process independent of other processes and dependent only on the data it
receives as input?
SAD4.DOC
CMSCS201
13
Systems Analysis & Design
Elementary Process Description
Variant:
Current Physical
Process ID/Common processing ref:
Process name:
4.3
Update Wallchart
Common processing cross-reference
N/A
Description
The Booking Clerk receives no. of places booked for a given Course
Run, and records on the wallchart the numbers of provisional/confirmed
numbers.
After making the update to the wallchart, the Bookings Clerk posts all the
delegate details to the Bookings Folder.
SAD4.DOC
CMSCS201
14
Systems Analysis & Design
I/O Description
Variant:
Project/System
Required Physical
Author
Date
Version
Status
Page Of
ANO System
From
To
Data Flow Name
Data content
Comments
D
7.1
Notice of
Cancellation
Course Code
Course Date
Delegate No.
Branch No.
Input to process
7.2
Cancellation
Notice
Course Code
Course Date
Delegate No.
Branch No.
M5
Old Delegate
Details
7.1
7.3
Request
for
Standby
Course Code
Course Date
Branch No.
No. of Places
7.3
D
Offer
Course Code
Course Date
New Delegate No.
New Delegate Name
7.3
Candidate
Details
Branch No.
Branch Address
Delegate No.
Delegate Name
7.1
7.2
M3
SAD4.DOC
Course Code
Course Date
Delegate No.
CMSCS201
15
Systems Analysis & Design
External Entity Description
Variant:
Current Physical
Project/System
Author
Date
Version
Status
Page Of
ANO System
ID
SAD4.DOC
Name
A
Branch
B
Tutor
C
Course Manager
Description
A regional unit of ANO PLC that places requests,
via nominating managers, for training for it
members.
An employee of ANO PLC, who delivers
sessions on Scheduled Courses
The owner of a Course Title, who is responsible
for providing details of courses and making the
decision to cancel Scheduled Courses
CMSCS201
16
Systems Analysis & Design
Tutorial Question
Data Flow Diagrams
From the following investigation notes:
 



Produce a Level 0 Context Diagram.
Produce a Level 1 DFD of the physical system
Produce a Level 2 DFD of the physical Reception Process
Produce a Level 2 DFD of the physical Filing Process
X-Ray Management Investigation Notes
Reception
Patients present X-ray request forms obtained from their GP to reception. Each X-ray
request form is allocated an appointment which is written on an appointment card and
given to the patient. X-ray request forms are filed. A diary is maintained which
contains details of all appointments. When patients arrive for X-ray, they present their
appointment card. A nurse checks the validity of the appointment, passes the
appointment card to a clerk and takes care of the patient. The clerk generates an X-ray
file/report request for the filing section. The X-ray request form is retrieved from the
file and given to the radiographer. X-ray film/report requests are placed in a temporary
file for collection by the filing section.
Radiographer
On receipt of the X-ray request form, the radiographer takes the appropriate X-rays
(called films) and places them in a temporary file for collection by the filing section.
Each appointment results in a set of X-ray films.
Filing Clerk
The filing clerks collect the X-ray film/report requests. These request all X-ray films
and reports previously generated for the patients. Patients can have many X-ray films
and reports. The new X-ray films are attached and the complete set placed in a
temporary file for the attention of the radiologist who makes out a report for the
appointment. When a copy of the new report is received from the radiologist, all X-ray
films and reports are returned to their permanent file.
Radiologist
The radiologist examines all X-ray films and reports a patient has and makes out a
new report. The report is sent to the GP with a copy to the filing section.
SAD4.DOC
CMSCS201
17