Structured Analysis

Lecture 6
Agenda
• What is Structured Analysis?
• Structured Analysis Tools
• Structured Analysis Model
• Data Dictionary
• Entity Relationship Diagrams
• Data Flow Diagrams
• State Transition Diagrams
What is Structured Analysis?
• Structured Analysis is a development method
that allows the analyst to understand the system
and its activities in a logical way.
• It is a systematic approach, which uses graphical
tools that:
• Analyze and refine the requirements of an
existing system
• Develop a new system specification which can
be easily understandable by user.
What is Structured Analysis?
(contd.)
• It has following attributes:
• It is graphic which specifies the presentation of
application.
• It divides the processes so that it gives a clear
picture of system flow.
• It is logical rather than physical i.e., the
elements of system do not depend on vendor
or hardware.
• It is an approach that works from high-level
overviews to lower-level details.
Structured Analysis Tools
• During Structured Analysis, various tools and
techniques are used for system development.
They are −
• Data Dictionary
• Data Flow Diagrams
• Decision Trees
• Decision Tables
• Structured English
• Pseudocode
The Structured Analysis
Model
Data Dictionary
• Core of the structured analysis model

• It is a repository that contains descriptions

(metadata) of all data objects consumed or
produced by the software.
Data Dictionary (contd.)
• Name - the primary name of the data or control item,
the data store or an external entity
• Alias - other names used for the first entry
• Where used/how used - a listing of the processes that
use the data or control item and how it is used (e.g.,
input to the process, output from the process, as a store,
as an external entity
• Content description - a notation for representing content
• Supplementary information - other information about
data types, preset values (if known), restrictions or
limitations, and so forth
 Example 1 of Data Dictionary
Entry
Name: telephone number
Aliases: none
Where used/ how used: assess against set-up (output)
dial phone (output)
Description:
telephone number = [local number | long distance number]
local number = prefix + access number
long distance number = 1 + area code + local number
area code = [800 | 888 | xyz]
prefix = * a three digit number that never starts with 0 or 1 *
access number = * any four number string *
Example 2 of Data Dictionary
Entry
Data vs. Data Dictionary
The Structured Analysis
Model
Entity Relationship Diagram
(ERD)
• Is a type of structural diagram for use in
database design.
• An ERD contains different symbols and
connectors that visualize two important
information:
• The major entities within the system scope,
• The inter-relationships among these entities.
Entity Relationship Diagram
(ERD)(contd.)
• When we talk about “Entities” in ERD, very often
we are referring to business objects such as:
• People/roles (e.g. Student)
• Tangible business objects (e.g. Product)
• Intangible business objects (e.g. Log)
• When we talk about "Relationship" is about how
these entities relate to each other within the
system.
Entity Relationship Diagram
(ERD)(contd.)
• Entities include: Author, Publisher, Customer, Book, and Warehouse
• Each entity has its own attributes (i.e. properties) that we want to
store about that entity
• Each entity must have a primary key, which is a unique attribute to
uniquely identify each record in that entity
• Relationships may be one-to-one, one-to-many- or many-to-many
• Foreign keys are used to connect entities in one-to-many relationships
• Many-to-many relationships are logical relations (i.e. cannot be
implemented in the physical system) that’s why we break them into
two one-to-many relationships such as (from the example in the next
slide):
• ShoppingBasket_Book: each book can be in many shopping baskets and
each shopping basket can have many books
• Warehouse_Book: each warehouse has many books and each book may
be contained in many warehouses.
Entity Relationship Diagram
Example
The Structured Analysis
Model
Data Flow Diagrams
• DFD graphically representing:
• the functions, or processes,
• which capture, manipulate, store, and distribute data
• between a system and its environment and between
components of a system.
• The visual representation makes it a good
communication tool between User and System
designer.
• Structure of DFD allows starting from a broad
overview and expand it to a hierarchy of detailed
diagrams (other levels).
Data Flow Diagrams (contd.)
• DFD has often been used due to the
following reasons:
• Logical information flow of the system
• Determination of physical system construction
requirements
• Simplicity of notation
• Establishment of manual and automated
systems requirements
DFD Notation
1. External Entities  Oval Shape
2. Processes  Rounded corner rectangles, which
contains the process number, the
responsibility, and the process name (has to
start with a verb)
3. Data Stores  Open right side rectangle, which
contains the data store ID and the data store
name
• Note: Each Data store is an entity in the ERD
4. The Arrows  represent the flow of data
DFD Notation and Example
DFD Rules
 DFD Levelling
vel 0 Level 1 Level 2 Level 3

2 2.2

Entity 1 2.1 2.2.1

Process sub sub-sub

Process Process

2 2.2 2.2.2
Overall sub sub-sub
process Process Process Process

3 2.3 2.2.3
sub sub-sub
Process Process Process
Entity
DFD Levelling (contd.)
Context Diagram (Level 0):
• The process name in the context diagram should be the name of the
information system surrounded by the external entities that the system
deals with.
• For example, Grading System, Order Processing System, Registration
System.
Level 1 DFD
• Process in Level 0 is be expanded further to represent details of the
processing activities. And in this level the data stores are represented too.
Level 2 DFD
• If a process still can be expanded into more details (i.e. sub-processes or
steps) , the we refine the process into a separate level of DFD;
• Most importantly you must ensure the consistency between levels as
shown in the next slide
• You will not be asked to go beyond Level 2 in this course!
DFD Levelling (contd.)
Sales, Dispatch and
Warehouse System
Case Study
Sales, Dispatch and
Warehouse system
• Customers send orders to the Sales Dept. who respond by
sending an order acknowledgement back to the customer.
Each week the Accounts Department send a credit limit list to
the Sales department (this is a list of customers who are up to
their limit and should be refused further orders).

• Assuming the order is acceptable, and internal order form is

sent from Sales to the Warehouse. The Warehouse will check
the appropriate stock levels, and assuming the goods are in
stock will issue a Dispatch instruction set to the Dispatch Dept.
who will package the goods and send them out to the
Customer with a Delivery note. A copy of the Delivery note is
also sent to the Accounts Dept. who will deal with the
invoicing and payment using their own systems.
Sales, Dispatch and
Warehouse system (contd.)
• When the stock levels of items get low, the Warehouse
will pass a re-order card (containing the product details)
to the Accounts Dept., who will note the details and
return the card before dealing with the reordering (using
a different system).

• Suppliers deliver new supplies of goods, along with a

Goods received note to the Warehouse, who will then
maintain the stock control appropriately. The Goods
received note is then passed on to the Accounts Dept.
who will again deal with the invoicing and payment using
their own systems.
Example Context Diagram
b
a
Accounts
Customer
Goods received
Copy delivery note
Delivery note note
Weekly credit Re-order card
Order limit list

Order
acknowledgement
Sales,
Despatch
& Warehouse

Goods
received note

c
Supplier
 Example - Level 1 DFD
a
Cust om er
Deliv er y not e 2 Despat ch
Pack age
O r der O r der goods
ac knowledgem ent & despat ch
*

1 Sales

O r der
Ent r y
Copy deliv er y
* Despat ch
not e
i s t r uc t io n set
n
W eekly c r edit
lim it lis t
b I nt er nal or der
f or m
Ac count s G oods r ec eiv ed
not e

3 W ar ehouse b
G oods r ec eiv ed Ac count s
St oc k
not e cont r ol
c Re- or der c ar d
Supplier
Level 2 DFD - Stock Control
2 Des pat c h
1 Sales
Pac k age
goods
O r der
& des pat c h
Ent r y *
*

I nt er nal or der Des pat c h

f or m ins t r uc t io n s et

b
Ac c ount s 3 St oc k c ont r ol

Re- or der c ar d
3. 1 St oc k Clk I nt er nal or der 3. 2 Ty pis t
f or m Ty pe t he
Allo c at e
des pat c h
s t oc k
ins t r uc t io n
t o or der
* s et *
r ead & updat e
s t oc k

M 3/ 1 St oc k

s t oc k addit ions
3. 3 W 'h m en s t oc k lev el 3. 4 G oods Rec
Chec k goods
M onit or
r ec eipt not e
s t oc k
t o s t oc k r ec ei-
lev els
v ed & inc r e *

Re- or der c ar d
G oods r ec eiv ed
G oods r ec eiv ed not e
not e

b c
Ac c ount s Supplier
 Level 3 DFD - Monitor Stock
Levels
3 .3 Mo n ito rs to c k le v e ls

3 .3 .1 Sto c k Clk 3 .3 .2 S/v is o r

Mo n ito rs to c k
Sto c k re c e ip t Re p la c e
le v e ls a n d
n o te re -o rd e r
re p o rtlo w
c a rd
s to c k * *
s to c k le v e l
Re -o rd e rc a rd
L o ws to c k
M3 /1 Sto c k Re -o rd e r
d e ta ils M3 .3 /1 Re -o rd e rc a rd
c a rd s
Re -o rd e rc a rd
3 .3 .3 S/v is o r
Ex tra c t Re -o rd e rc a rd
a p p ro p ria te
Ac c o u n ts
re -o rd e r
c a rd *
Good Practise
• Level 0 diagram shows the whole system as just
one process
• Level 1 diagram has one process for each
department
• Level 2 shows what happens within each
department
• Level 3 could show processes performed by a
single named job role – eg warehouse supervisor
• This is not always possible, but is very effective
when it can be done
Drawing DFD Tips
• Identify data flows, data stores and processes, as
described in the last lecture
• Draw processes first, down the centre of the page
• Add external entities down the left hand side
• Draw data stores down the right hand side
• Finally add the data flows
• Flow lines should not cross, use duplicate symbols to
avoid crossing lines and keep DFD neat and tidy ...
The Structured Analysis
Model
State Transition Diagrams
• The basic idea is to define a machine that has a
number of states (hence the term finite state
machine).
• The machine receives events from the outside
world, and each event can cause the machine to
transition from one state to another.
When to use State Transition
Diagrams?
• State models are ideal for describing the
behavior of a single object.
• They are also formal, so tools can be built which
can execute them.
• Their biggest limitation is that they are not good
at describing behavior that involved several
objects.
• For these cases use an activity diagram (to be
discussed in lecture 7 – OO Analysis)
State Transition Diagrams
Notation
• State. A condition during the life of an object in which it
satisfies some condition, performs some action, or waits for
some event.
• Event. An occurrence that may trigger a state transition. Event
types include an explicit signal from outside the system, an
invocation from inside the system, the passage of a designated
period of time, or a designated condition becoming true.
• Transition. The change of state within an object.
• Initial State - The initial state (there can be only one) is the
state that a new object will be in immediately following its
creation
• Final State - A final state (there can be many) is a state that
represents the object going out of existence
State Transition Diagram
Example 1
• The example in the next slide shows a simple state-transition
diagram for a media player with three buttons: stop, play and
pause.
• The initial state of the player is stopped.
• In each state, only the buttons for the other states can be
pressed (e.g. in play, only the stop and pause buttons can be
pressed).
• Pressing the pause button when the player is stopped does
not result in any change to the player.
• The event (press pause when state is Stopped) that does not
cause any change in state is indicated by the circular arrow.
State Transition Diagram
Example 1 (contd.)
State Transition Diagram
Example 2
The machine is a bottle in a bottling plant.
• It begins in the empty state.
• In that state it can receive squirt events.
• If the squirt event causes the bottle to become full, then it
transitions to the full state, otherwise it stays in the empty
state (indicated by the transition back to its own state).
• When in the full state the cap event will cause it to transition
to the sealed state.
• The diagram indicates that a full bottle does not receive squirt
events, and that an empty bottle does not receive cap events.
• Thus you can get a good sense of what events should occur,
and what effect they can have on the object.
State Transition Diagram
Example 2 (contd.)
State Transition Diagram
Example 3
Thanks 