SYSTEM DESIGN

At the end of this lesson you should be able to interpret;

 Flowcharts
 Function Decomposition (FD) Diagrams
 Context Diagrams
 Data Flow Diagrams (DFD)
 Decision Tables
 Decision Trees
 Data Dictionaries
 Entity Relation Diagrams (ERDs)
 Process

A process is a business activity which when

executed produces certain outputs from given
inputs.
The function(s) performed by a process may be
complex, with multiple inputs, outputs and
users. The entire application itself is a process.
Successive decomposition is used into sub
processes to reveal greater details of the
processing
 Key Definitions
A process model is a formal way of representing
how a business operates
Logical process models describe processes
without suggesting how they are conducted
Physical models include information about how
the processes are implemented
Data flow diagramming shows business
processes and the data that flows between them
 CONTEXT DIAGRAM
Shows the context into which the business
process fits
Shows the overall business process as just one/
single process
Shows all the outside entities that receive
information from or contribute information to the
system (external interfaces)
This is the starting point; also called
Fundamental System Model or Level 0 DFD
Context Diagram…

Input 1
Output 1
Context Diagram of an Order system
Customer - Makes an order,
gets notification of rejection or
an invoice, makes payment
Warehouse - Receives the
list and completes the order
Accounting – receives cash
receipts
Sales rep – receives
commission
Bank – receives deposit
 DATA FLOW DIAGRAM (DFD)
DFDs are the most commonly used way of
documenting the process of current & required
systems. They are a pictorial way of showing the
flow of data into, around & out of a system.
It is a graphical representation of a system’s data
and how the processes transform the data.
They can describe processing at physical as well
as logical levels
 Its shows flow of data and not flow of control
 Data Flow Diagram (DFD)…
DFDs facilitate top-down development
They permit outlining of preferences and scope
Unlike flowcharts, DFDs do not give detailed
descriptions of modules but graphically describe a
system’s data and how the data interact with the
system.
FDD may be done before DFD or one may prepare
DFDs directly
 It has more contents than FDDs
 Components of DFD
DFDs are constructed using four major components;
external entities
data stores
processes and
data flows
 Components of DFD…
External Entities: represent the source of data as
input to the system and also the destination of system
data. E.g. Student, patient, Doctor etc. External
entities can be called data stores outside the system.
Represented by squares.
Data Stores: represent stores of data within the
system. Examples, computer files or databases.
Represented by an open-ended box – data at rest or a
temporary repository of data.
 Components of DFD…
Process: represents activities in which data are
manipulated by being stored or retrieved or
transferred in some way; transforms the input data
into output data. Represented by Circles/ovals.
Data Flows: represents the movement of data from
one component to the other. An arrow identifies
data flow/data in motion. Data flows are generally
shown as one-way only. Data Flows between
external entities are shown as dotted lines.
 Steps in Building DFDs
Build the context diagram
Create DFD fragments for each scenario
Organize DFD fragments into level 0
Decompose level 0 DFDs as needed
Validate DFDs with user
 DFD Fragment Tips
All process names must be verb phrases
Maintain organization’s viewpoint in naming
processes
Layouts often place
inputs from the left
processes in the center
outputs to the right
stores beneath the processes
 Qualities of a good DFD
A good DFD should;
have no data flows that split up into a number of
other data flows
have no crossing lines
not include flowchart loops of control elements
not include data flows that act as signals to activate
processes.
 A Patient System DFD
(Level 0)

Process

Input
Output
 A Patient System DFD
(Level 1)

Storage
A Patient System DFD
 Example 2: Book Supplier
Imagine books supplied to customers whereby no
stock is maintained and the books are sourced
directly from the publishers
Level 0 DFD/Context diagram
Book Supplier: Refinement 1
Book supplier: Exploding Process 2
 FLOWCHARTS
It is a diagrammatic/picture representation of the
various steps involved in designing a system.

It consists of a set of ‘flowchart symbols’ connected by

arrows. Each symbol contains information about
what must be done at that point & the arrow shows
the ‘flow of execution’ of the algorithm.
 Flowcharts…
The purpose of using flowcharts is to graphically
present the logical flow of data in the system and
define major phases of processing along with the
various media to be used.
Some of the boxes which are used in flowcharts are:

 
 Flowcharts…
Flowcharts are of three types:
System flowcharts
Run flowcharts
Program flowcharts
 (a) System Flowcharts
System flowchart describes the data flow for a data
processing system.
It provides a logical diagram of how the system
operates, represents the flow of documents, the
operations performed in data processing system and
also reflects the relationship between inputs,
processing and outputs.
 (a) System Flowcharts…
The features of system flowcharts are:
the sources from which data is generated and device
used for this purpose
various processing steps involved
the intermediate and final output prepared
the devices used for their storage
 System Flow Chart
The Figure is a sample of
system flowchart for the
following algorithm:
Prompt the student for the
Tuition Fees Paid (TFP).
Store the Amount paid
Set Tuition Balance to
Tuition Fees (TF) minus TFP
Print the Tuition Fees
Balance
Stop
 (b) Run flowcharts
Run flowcharts are used to represent the logical
relationship of computer routines along with inputs,
master files, transaction files and outputs.
Run flowcharts…
 (c) Program flowcharts
A program flowchart represents, in detail, the various
steps (logical/ arithmetic operations, algorithms etc)
to be performed within the system for transforming
the input into output.

These flowcharts constitute an important component

of documentation for an application.
 Program
Flowchart
 1st step: TF is
displayed.
 2nd step: The Tuition
fees paid is obtained
 3rd step: TFP is
subtracted from TF
 Logical decision is
displayed
 Report is printed if
TF>TFP
 FUNCTION DECOMPOSITION/
HIERARCHY CHART

Also known as Hierarchy plus Input-Process-Output

HIPO) model
Decomposition splits work of a task into subtasks;
subtasks together make-up the parent task. It should
have characteristics of;
Balanced decomposition: sub-tasks are roughly equal
in complexity
Top-down decomposition: gives hierarchical
structure
 Function Decomposition…
Decomposition should be divided into 2 or more but
not more than 5
A high cohesion (high independence) and minimum
coupling (minimum interdependence) are
fundamental criteria
Elementary process is the smallest unit of activity
meaningful to end user (it sees and leaves data in
consistent state)
 Function Decomposition…
Continue decomposition until elementary processes
are identified
Process decomposition diagram is;
A tree structure
Elementary processes are leaf nodes
Data are not shown
 Decomposition rules
Each process in a decomposition diagram is either a
parent process or a child process of a parent or both
A parent must have two or more children. A single
child does not make sense because that would not
reveal any additional detail about the system
In most decomposition diagramming standards, a
child may have only one parent
Finally a child of one parent may be a parent of its
own children
 Decomposition rules…

System

Function Function Function

1 2 3

Activity Activity Activity Activity

1.1 1.2 2.1 2.2

Task Task Task Task

1.1.1 1.1.2 2.2.1 2.2.2
 FD Diagrams: Examples

Student
Registration

Register for Register for Approve

backlog prescribed registration
courses courses
Customer management System FDD
 Function Decomposition …
Use proper naming of processes
Business functions are named as nouns (marketing,
Inventory control, etc)
Process name consists of an active verb and an object
(accept order, calculate interest, …)
Avoid long names (sentences containing and, if, then,
etc. indicate non-cohesive complex tasks)
Real world is a good reference for selecting proper
names; organizational units are organized functionally
and each unit has a well-defined task
 DECISION TABLES AND DECISION
TREES
Decision tables and trees were developed long before
the widespread use of computers. They not only
isolate many conditions and possible actions but they
help ensure that nothing has been overlooked.
 DECISION TABLES
The decision table is a chart with four sections listing
all the logical conditions and actions. In addition, the
top section allows space for title, date, author, system
and comment
 Five sections of a decision table:

TITLE: 
DATE:
Author :
System :
Comments :

Condition Stub Condition Entry

Action Stub Action Entry

 Five sections of a decision table…
The condition stub contains a list of all the necessary
tests in a decision table.
The action stub is where one may note all the
processes desired in a given module. It contains a list
of all the processes involved in a decision table.
The condition entry contains a list of all possible
permutations of yes and no responses related to the
condition stub arranged as a vertical column called
rules (numbered 1,2,3 etc).
 Five sections of a decision table…
The action entry; X’s or dots indicate whether an
action should occur as a consequence of the yes/no
entries under condition entry. X’s indicate action;
dots indicate no action.
 Example of book order
Let us consider the following example of book order
 If order is from book store  Then discount is 15%
 And if order is for 6 copies  Else if order is for 20 to 49
 Then discount is 25% copies
 Else (if order is for less then  Then discount is 10%
6 copies)  Else if order is for 6 to 19
 No discount is allowed copies
 Else (if order is from  Then discount is 5%
libraries)  Else (order is for less then 6
 If order is for 50 copies or copies)
more  No discount is allowed
Decision Table for above process
 DECISION TREE
The decision tree defines the conditions as a
sequence of left to right tests. A decision tree helps to
show the paths that are possible in a design following
an action or decision by the user.
It turns a decision table into a diagram. This tool is
read from left to right, decision results in a fork, and
all branches end with an outcome.
 Illustration of the concept of
decision tree
The figure illustrates the decision tree for the
book order decision table seen earlier.
 DATA DICTIONARY/
METADATA REPOSITORY
It is a centralized repository of information about
data such as meaning, relationships to other data,
origin, usage, and format.
It is a separate set of tables that describes the
application tables. The Data Dictionary contains such
information as column names, types, and sizes, titles,
captions, primary keys, foreign keys, and hints to the
user interface about how to display the field.
 Simple Data Dictionary
Entity: Student
Field Name Data Type Key Description
StudName Text Student’s Name
Reg No Text Primary Key Student’s Reg
number

Prog ID Text Foreign Key Program Id number

Year Look up wizard Year of study

Gender Lookup Wizard Student’s gender
DOB Date/Time Date of birth
Pic OLE Object Student’s passport
size photograph

Tuition Number Tuition fees paid

ENTITY RELATIONSHIP DIAGRAMS
(ERD) /MODEL (ERM)
Illustrate the logical structure of databases.
It is a specialized graphic that illustrates
the relationships between entities in a database in a
top-down fashion.
The models are used in analysis to describe the data
requirements and assumptions in the system from a
top-down perspective. They also set the stage for the
design of databases later on in the SDLC.
 Entity-Relationship Diagrams…
There are three basic elements in ER models:
Entities - "things" about which information is sought.
Attributes – data collected about the entities.
Relationships - provide the structure needed to draw
information from multiple entities.
They often use symbols to represent three different
types of information.
Boxes - represent entities.
Ovals - represent attributes.
Diamonds - represent relationships
 Developing an ERD
Developing an ERD requires an understanding of the
system and its components. Use the example below;
 Consider a hospital: Patients are treated in a single ward by
the doctors assigned to them. Usually each patient will
be assigned a single doctor, but in rare cases they will have two.
 Healthcare assistants also attend to the patients, a number of
these are associated with each ward. 
 Initially the system will be concerned solely with drug
treatment. Each patient is required to take a variety of drugs a
certain number of times per day and for varying lengths of time.
 Developing an ERD…
The system must record details concerning patient
treatment and staff payment.
Some staff are paid part time and doctors and care
assistants work varying amounts of overtime at
varying rates (subject to grade).
The system will also need to track what treatments are
required for which patients and when and it should be
capable of calculating the cost of treatment per week
for each patient (though it is currently unclear to what
use this information will be put). 
 How do we start an ERD?
1. Define Entities: these are usually nouns used in
descriptions of the system, in the discussion of
business rules, or in documentation; identified in the
narrative (see highlighted items above).
2. Define Relationships: these are usually verbs used
in descriptions of the system or in discussion of the
business rules (entity _ entity); identified in the
narrative (see highlighted items above).
 How do we start an ERD?
3. Add attributes to the relations; these are determined by
the queries and may also suggest new entities, e.g. grade;
or they may suggest the need for keys or identifiers.
What questions can we ask?
a. Which doctors work in which wards?
b. How much will be spent in a ward in a given week?
c. How much will a patient cost to treat?
d. How much does a doctor cost per week?
e. Which assistants can a patient expect to see?
f. Which drugs are being used?
 How do we start an ERD?
4. Add cardinality to the relations.
Many-to-Many must be resolved to two one-to-manys
with an additional entity
Usually automatically happens.
Sometimes involves introduction of a link entity (which
will be a foreign key) Examples: Patient-Drug
 How do we start an ERD?
5. This flexibility allows us to consider a variety of
questions such as:
a. Which beds are free?
b. Which assistants work for Dr. X?
c. What is the least expensive prescription?
d. How many doctors are there in the hospital?
e. Which patients are family related?
Symbols used in ERDs
 Reading an ERD
It takes some
practice reading
an ERD, but they
can be used with
clients to discuss
business rules.
Sample ERDs…
 Summary
Context Diagram – Shows business process as just
a single process
Flow Chart Diagram - represents various steps
involved in designing a system
System Flowchart - shows dataflow description
Run Flowchart – shows routines
Program Flowchart – shows logical/arithmetic/ algorithm
steps
Function Decomposition Diagram – Splits work
into subtasks
 Summary
Dataflow Diagram – shows flow of data into,
around and out of the system to show data
transformation
Decision Table – lists possible conditions and
actions taken in system development
Decision Tree – shows path that are possible in a
design following an action or decision by the user
Data Dictionary/ Metadata repository – describes
application tables
Entity Relationship Diagram – illustrates the
logical structure of relationships between entities