Page |1

SYSTEM
ANALYSIS
AND DESIGN

Author
ALKING P. SUNGA, MSIT
Prepared by: ALKING P. SUNGA, MSIT IT 3: System Analysis and Design
Page |2

MODULE 3:
Technical Documents in SAD

Lesson 1: Data Flow Diagram

What is DFD?
• a means of representing a system at any level of detail with graphic network
processes and data sources/destinations.
• is an important technique for modeling a system’s high-level detail by showing
how input data is transformed to output results through a sequence of
functional transformations
• DFDs consists of four major components: entities, processes, data stores and
data flows.
• In other words, it shows:
• What goes in
• How it is changed
• What comes out

DFD Symbols
 Entity

• aka: Source, Terminator

• Represents sources of data to the system or destination of data from the
system.

Prepared by: ALKING P. SUNGA, MSIT IT 3: System Analysis and Design

Page |3

• A person or group which interacts with the system. Something outside the
system. It is not a user. E.g. Customer, Supplier, Government Agency,
Accounting Department, the Human Resource System, etc.

Process

• Aka: Activity, Function

• Should generally move from top to bottom and left to right.
• Transforms of incoming data flow(s) to outgoing data flow(s). • Show
data transformation or change. Data coming into a process must be
“worked on” or transformed in some way.
• A process is a unit of work that operates on the data. The process maybe
automated or manual, on-line, batch, or real-time.
• Use a verb-adjective-noun format for detailed processes. The verb
describes the type of activity.
Example: compute print
verify add
prepare check
 Data Store

• Where information is kept.

• Represents data that is not moving (delayed data at rest)
• Are generic for physical files (index cards, desk drawers, magnetic disk,
magnetic tape, shirt pocket, human memory, etc.)
• Can be duplicated one or more times, to avoid line crossing.
• Names have plural nouns to describe collections of data eg., customers,
orders, employees.

Data Flow

• Represents movement of data

• Are represented with a line with an arrowhead on one end.
• Must have unique names

Rules Creating DFD

• All data flows must originate or terminate at a process.

• Data stored in a system must go through a process with a data flow • Each
data store must have at least one data flow going into it and one data flow
leaving it
• Data stores cannot be connected to another data store directly.

Prepared by: ALKING P. SUNGA, MSIT IT 3: System Analysis and Design

Page |4

• All processes in DFD must be linked to either another process or a data store •
Do no cross line.
• No more than 9 process symbols should appear on one diagram. • Use a unique
reference for each process symbol. The reference number points to the DFD that
contains the next level of detail for that process.
• A context diagram has only one process, which is numbered 0. •
A context diagram has no data stores and must fit on one page.

Types of DFD
Context Dataflow Diagram / Level 0
• First method in constructing the dataflow diagram.
• Representation of all entities involves in the system process, flow of the
system and documents in the system.
Level 1
• A level 1 DFD is a diagram showing the system itself. It pictures the major
processes along with the external entities, data stores and data flow. Exploded
DFD
• It is expanded or decomposed into separate lower-level dataflow diagram
that preserves exactly the same input and output.

DFD Example:
Online Ordering System

Online ordering system allows people to shop from home. When a customer
wants to buy something, they can telephone, fax or email their order to the
company. The company gets the order and deliver the goods together with an invoice
and a delivery note. When the customer receives the goods they send payment and
receive a receipt for their payment.

Construct the Following DFD:

• Context Dataflow Diagram
• Level 1
• Exploded DFD

Solution
• The first thing we must do is model the main outputs and sources of data in
the scenario above.
• Then we draw the system box and name the system.
• Next we identify the information that is flowing to the system and from the
system

Prepared by: ALKING P. SUNGA, MSIT IT 3: System Analysis and Design

Page |5

Context Dataflow Diagram / Level 0

The next stage is to create the Level 1 Data Flow Diagram. This highlights the main
functions carried out by the system. As a rule, we try to describe the system using
between two and seven functions – two being a simple system and seven being a
complicated system. This enables us to keep the model manageable on screen or
paper.
Try to describe what the Online ordering system in a number (two to seven)
of short sentences - these sentences become the system's functions. Let's describe
the system in two sentences / process.
1. Gets orders from customers
2. Receives payment when they are delivered.

Prepared by:
ALKING P. SUNGA, MSIT IT 3: System Analysis and Design
Page |6

Checking the Level 1 DFD

• We now create the Exploded Data Flow Diagrams.

 • Find the sub-process in the two processes. (Order Process and Payment Process)
1. Process Order 1.1 Receive order
1.2 Issue invoice delivery notes and goods.

2. Process Payments 2.1 Receive payment

2.2 Issue receipt

Exploded DFD
(Order)
Prepared by: ALKING P. SUNGA, MSIT IT 3: System Analysis and Design
Page |7

Exploded DFD
(Payment)
Checking of Exploded DFD (Order)

Prepared by: ALKING P. SUNGA, MSIT IT 3: System Analysis and Design

Page |8

Checking of Exploded DFD (Payment)

Lesson 2: Data Dictionary

A data dictionary is a collection of descriptions of the data objects or items in
a data model for the benefit of programmers and others who need to refer to them. A
data dictionary is an integral part of a database, which holds information about the
database and the data that it stores, Any well-designed database will surely include a
data dictionary – it provides database administrators and other users, easy access to
the type of data that they should expect to see in every table, row and column of the
database, without actually accessing the database. Since a database is meant to be
built and used by multiple users, making sure that everyone is aware of what types of
data each field will accept becomes a challenge, especially when there is a lack of
consistency when assigning data types to fields. A data dictionary is a simple yet
effective add-on to ensure data consistency. Some of the typical components of a
data dictionary entry are:
∙ Table Name
∙ Field ID
∙ Field Name
∙ Field Data Type
∙ Field Size
∙ Default Value
∙ Keys
∙ Description

Prepared by: ALKING P. SUNGA, MSIT IT 3: System Analysis and Design

Page |9

Example:

SSS Application Database

 Table ID Table Name

01 Personal Information

02 Beneficiaries

Personal_Information

Field ID Field Name Data Type Field Size Not Null Primary Keys Description

01 SSS Number integer 10 Yes Yes Members unique number

02 SurName varchar 30 Yes No Members last name

03 GivenName varchar 30 Yes No Members first name

04 MiddleName varchar 30 Yes No Members middle name

05 Sex varchar 10 Yes No Members sex

06 DateOfBirth Date 8 Yes No Birth date of the member

07 CivilStatus varchar 10 Yes No Civil status of the member

08 Address varchar 70 Yes No Complete address of the member

09 Postal Code integer 4 Yes No Four digit postal code of the member

Beneficiaries

Field ID Field Name Data Type Field Size Not Null Primary Keys Description

01 SSS Number integer 10 Yes Yes Members unique number

02 Father varchar 70 Yes No Members fathers name

03 Mother varchar 70 Yes No Members mothers name

04 Spouse varchar 70 No No Members spouse name

05 Children varchar 70 No No Members children’s name

06 Other varchar 70 No No Other beneficiaries name

Prepared by: ALKING P. SUNGA, MSIT IT 3: System Analysis and Design

P a g e | 10

Lesson 3: Database Schema

database schema is the skeleton structure that represents the logical view of
the entire database. It defines how the data is organized and how the relations
among them are associated. It formulates all the constraints that are to be applied
on the data.
A database schema defines its entities and the relationship among them. It
contains a descriptive detail of the database, which can be depicted by means of
schema diagrams. It’s the database designers who design the schema to help
programmers understand the database and make it useful.

A database schema can be divided broadly into two categories −

∙ Physical Database Schema − This schema pertains to the actual storage of data
and its form of storage like files, indices, etc. It defines how the data will be
stored in a secondary storage.
∙ Logical Database Schema − This schema defines all the logical constraints that
need to be applied on the data stored. It defines tables, views, and integrity
constraints.

Database Instance

It is important that we distinguish these two terms individually. Database

schema is the skeleton of database. It is designed when the database doesn't exist
at all. Once the database is operational, it is very difficult to make any changes to it.
A database schema does not contain any data or information.

Prepared by: ALKING P. SUNGA, MSIT IT 3: System Analysis and Design

P a g e | 11

A database instance is a state of operational database with data at any given

time. It contains a snapshot of the database. Database instances tend to change
with time. A DBMS ensures that its every instance (state) is in a valid state, by
diligently following all the validations, constraints, and conditions that the database
designers have imposed.
If a database system is not multi-layered, then it becomes difficult to make
any changes in the database system. Database systems are designed in multi-layers
as we learnt earlier.

Entity Relationship

The ER model defines the conceptual view of a database. It works around

real-world entities and the associations among them. At view level, the ER model is
considered a good option for designing databases.

Entity
An entity can be a real-world object, either animate or inanimate, that can be
easily identifiable. For example, in a school database, students, teachers, classes,
and courses offered can be considered as entities. All these entities have some
attributes or properties that give them their identity.

Attributes
Entities are represented by means of their properties, called attributes. All
attributes have values. For example, a student entity may have name, class, and age
as attributes.
There exists a domain or range of values that can be assigned to attributes.
For example, a student's name cannot be a numeric value. It has to be alphabetic. A
student's age cannot be negative, etc.

Keys
Key is an attribute or collection of attributes that uniquely identifies an entity
among entity set.
For example, the roll_number of a student makes him/her identifiable among
students.
∙ Super Key − A set of attributes (one or more) that collectively identifies an
entity in an entity set.
∙ Candidate Key − A minimal super key is called a candidate key. An entity set
may have more than one candidate key.
∙ Primary Key − A primary key is one of the candidate keys chosen by the
database designer to uniquely identify the entity set.

Relationship

Prepared by: ALKING P. SUNGA, MSIT IT 3: System Analysis and Design

P a g e | 12

The association among entities is called a relationship. For example, an

employee works_at a department, a student enrolls in a course. Here, Works_at and
Enrolls are called relationships.

Binary Relationship and Cardinality

Cardinality defines the number of entities in one entity set, which can be
associated with the number of entities of other set via relationship set. One-to-one −
One entity from entity set A can be associated with at most one entity of entity set B
and vice versa.

One-to-many − One entity from entity set A can be associated with more than
one entities of entity set B however an entity from entity set B, can be associated
with at most one entity.

Many-to-one − More than one entities from entity set A can be associated
with at most one entity of entity set B, however an entity from entity set B can be
associated with more than one entity from entity set A.

Many-to-many − One entity from A can be associated with more than one
entity from B and vice versa.

Prepared by: ALKING P. SUNGA, MSIT IT 3: System Analysis and Design

P a g e | 13

Database Schema Example:

Lesson 4: Unified Modeling Language

What is UML?

UML is an acronym that stands for Unified Modeling Language. Simply put,
UML is a modern approach to modeling and documenting software. In fact, it’s one
of the most popular business process modeling techniques.
It is based on diagrammatic representations of software components. As the
old proverb says: “a picture is worth a thousand words”. By using visual

Prepared by: ALKING P. SUNGA, MSIT IT 3: System Analysis and Design

P a g e | 14

representations, we are able to better understand possible flaws or errors in

software or business processes.
What is the use of UML?

Mainly, UML has been used as a general-purpose modeling language in the

field of software engineering. However, it has now found its way into the
documentation of several business processes or workflows. For example, activity
diagrams, a type of UML diagram, can be used as a replacement for flowcharts. They
provide both a more standardized way of modeling workflows as well as a wider
range of features to improve readability and efficacy.
UML itself finds different uses in software development and business process
documentation:

Types of UML Diagrams

There are several types of UML diagrams and each one of them serves a
different purpose regardless of whether it is being designed before the
implementation or after (as part of documentation).
The two most broad categories that encompass all other types are Behavioral
UML diagram and Structural UML diagram. As the name suggests, some UML
diagrams try to analyze and depict the structure of a system or process, whereas
other describe the behavior of the system, its actors, and its building components.
The different types are broken down as follows:

▪ Behavioral UML Diagram

o Activity Diagram
o Use Case Diagram
o Interaction Overview Diagram
o Timing Diagram
o State Machine Diagram
o Communication Diagram
o Sequence Diagram

▪ Structural UML Diagram

o Class Diagram
o Object Diagram
o Component Diagram
o Composite Structure Diagram
o Deployment Diagram
o Package Diagram
o Profile Diagram

Prepared by: ALKING P. SUNGA, MSIT IT 3: System Analysis and Design

P a g e | 15

What is a use case diagram?

In the Unified Modeling Language (UML), a use case diagram can summarize the details of
your system's users (also known as actors) and their interactions with the system. To build
one, you'll use a set of specialized symbols and connectors. An effective use case diagram
can help your team discuss and represent:

∙ Scenarios in which your system or application interacts with people, organizations, or

external systems
∙ Goals that your system or application helps those entities (known as actors) achieve
∙ The scope of your system

UML - Use Case Diagram Example

Prepared by: ALKING P.

SUNGA, MSIT IT 3: System Analysis and Design
P a g e | 16

Lesson 5: Cost Benefit Analysis

A cost benefit analysis is used to evaluate the total anticipated cost of a

project compared to the total expected benefits in order to determine whether the
proposed implementation is worthwhile for a company or project team. If the results
of this comparative evaluation method suggest that the overall benefits associated
with a proposed action outweigh the incurred costs, then a business or project
manager will most likely choose to follow through with the implementation.
Generally speaking, a cost-benefit analysis has three parts. First, all potential
costs that will be incurred by implementing a proposed action must be identified.
Second, one must record all anticipated benefits associated with the potential action.
And finally, subtract all identified costs from the expected benefits to determine
whether the positive benefits outweigh the negative costs.

What is a Cost?

A cost is any expense to the organization, be it an expenditure of capital or an

operating cost for the organization. A cost can also be viewed as any negative effect
on the organization resulting from the implementation of the project.
When identifying costs, be as realistic as possible. For example, depending on
the planned implementation approach, the costs of running two systems in parallel
may have to be included here.

Examples of Costs

The following list provides some examples of costs to consider when identifying
costs for the cost benefit analysis:

· new hardware (or upgrades to existing hardware),

· new software (or upgrades),
· network costs (including management and administration), ·
telecommunications,
· environment (e.g., computer room cost),
· physical installation,
· outside consulting and assistance (e.g., support services),
· training,
· documentation,
· programming,
· software development tools,
· software testing and testing tools,
· conversion,
· operating costs,
· maintenance costs,
· labor costs,

Prepared by: ALKING P. SUNGA, MSIT IT 3: System Analysis and Design

P a g e | 17

· research and development costs,

· opportunity costs,
· technology obsolescence,
· disruption to the organization when implementing the system.
What is a Benefit

A benefit is any positive effect on the organization resulting from the

implementation of the project.
Benefits occur when one gains an objective.

Examples of Benefits

The following list provides some examples of benefits to consider when

identifying benefits for the cost benefit analysis:

· scrap value of equipment,

· increase in productivity due to better system response time, ·
increase in productivity due to improved process,
· decrease in inventory,
· reduction in average annual accounts receivable,
· reduction in errors,
· improved control,
· research and development spill overs,
· reduction in maintenance costs,
· reduction in office space required,
· personnel savings,
· better customer service,
· better system security,
· better fault tolerance,
· disaster recovery,
· employee satisfaction,
· other positive effects in the corporation (e.g., marketing support).

Prepared by: ALKING P. SUNGA, MSIT IT 3: System Analysis and Design

P a g e | 18

Cost Benefit Analysis Example:

Costs:
 Item Quantity Estimat Total Cost
ed cost

Computer equipment:

Desktop Computers with 5 50,000.00 250,000.00

supporting software

Server 1 350,000.00 350,000.00

Printer 3 7,000.00 21,000.00

GSM Modem 1 2,000.00 2,000.00

Installation and Networking

Networking Materials - 20,000.00 20,000.00

Labor - 20,000.00 20,000.00

Training costs:

MIS for Saint John Hill Academy 10 5,000.00 50,000.00

person

Other costs:

Expenses due - 20,000.00 20,000.00

inefficiency during first
months

Electricity 12 months 10,000.00 120,000.00

TOTAL COST: 853,000.00

Benefits:
Item Estimate Benefit per Year

More ability to manage student transactions 600,000.00

Improved efficiency and reliability data 200,000.00

Improved customer service and retention 100,000.00

Less human resource 200,000.00

TOTAL BENEFITS: 1,100,000.00

Return of Investment:
 ROI = ((Benefits - Cost) / Cost) * 100

ROI = ((1,100,000.00 - 853,000.00 ) / 853,000.00) * 100

ROI = (.29) * 100

ROI = 29% per year

Prepared by: ALKING P. SUNGA, MSIT IT 3: System Analysis and Design

P a g e | 19

Lesson 6: Test Plan

What is a Test Plan

A Test Plan is a detailed document that is required in performing the testing of
a software product. Test Plan helps us determine the effort needed to validate the
quality of the application under test. The test plan serves as a blueprint to conduct
software testing activities as a defined process, which is minutely monitored and
controlled by the test manager.

What is the Importance of Test Plan?

Making Test Plan document has multiple benefits:
∙ Help people outside the test team such as developers, business managers,
customers understand the details of testing.
∙ Test Plan guides our thinking. It is like a rule book, which needs to be
followed.
∙ Important aspects like test estimation, test scope, Test Strategy are
documented in Test Plan, so it can be reviewed by Management Team
and re-used for other projects.

The following are the content of a sample test plan document:

∙ Objectives
∙ Scope
∙ Test Strategy
o Alpha Testing (Unit Testing)
o System and Integration Testing
o Performance and Stress Testing
o Quality Assurance Testing
o User Acceptance Testing
o Regression Testing
o Beta Testing
∙ Hardware Requirements
∙ Environmental Requirements
∙ Estimation and Test Schedule
Objectives
Describe the objectives supported by the Master Test Plan, For Example,
defining tasks and responsibilities, a vehicle for communication, a document to be
used as a service level agreement, etc.

Scope
This section describes what is being tested, which is new to all the functions
of a specific product, its existing interfaces, integration of all functions, etc.

Prepared by: ALKING P. SUNGA, MSIT IT 3: System Analysis and Design

P a g e | 20

Testing Strategy
Describe the overall approach to testing. For each major group of features or
feature combinations, specify the approach which will ensure that these feature
groups are adequately tested.
Specify the major activities, techniques, and tools which are used to test the
designated groups of features.
The approach should be described with sufficient details to permit the
identification of the major testing tasks and estimation of the time required to do
each one. Here are some example of test strategies:

∙ Unit Testing
Unit Testing is a type of software testing where individual units or
components of a software are tested. The purpose is to validate that each unit
of the software code performs as expected. Unit Testing is done during the
development (coding phase) of an application by the developers. Unit Tests
isolate a section of code and verify its correctness. A unit may be an individual
function, method, procedure, module, or object.

∙ System and Integration Testing

System Integration Testing is defined as a type of software testing
carried out in an integrated hardware and software environment to verify the
behavior of the complete system. It is testing conducted on a complete,
integrated system to evaluate the system's compliance with its specified
requirement.
System Integration Testing (SIT) is performed to verify the interactions
between the modules of a software system. It deals with the verification of
the high and low-level software requirements specified in the Software
Requirements Specification/Data and the Software Design Document.
It also verifies a software system's coexistence with others and tests
the interface between modules of the software application. In this type of
testing, modules are first tested individually and then combined to make a
 system.

∙ Performance and Stress Testing

Performance testing is a type of testing for determining the speed of a
computer, network or device. It checks the performance of the components
of a system by passing different parameters in different load scenarios.
While stress testing is a type of testing that determines the stability
and robustness of the system. It is a non-functional testing technique. This
testing technique uses auto-generated simulation model that checks all the
hypothetical scenarios.

Prepared by: ALKING P. SUNGA, MSIT IT 3: System Analysis and Design

P a g e | 21

∙ Quality Assurance Testing

A quality testing process that ensures that an organization delivers the
best products or services possible. The key thing to keep in mind is that QA
doesn't involve the actual testing of products. Instead, it focuses on the
procedures to ensure the best outcome.

∙ User Acceptance Testing

The purpose of the acceptance test is to confirm that the system is
ready for operational use. During the Acceptance Test, end-users (customers)
of the system compare the system to its initial requirements before moving
the software application to the production environment. UAT is done in the
final phase of testing after functional, integration and system testing is done.

∙ Regression Testing
Regression testing is defined as a type of software testing to confirm
that a recent program or code change has not adversely affected existing
features.
Regression Testing is nothing but a full or partial selection of already
executed test cases which are re-executed to ensure existing functionalities
work fine.
This testing is done to make sure that new code changes should not
have side effects on the existing functionalities. It ensures that the old code
still works once the latest code changes are done.

Hardware Requirements

List of the minimum hardware requirements needed in order to run the

system.
It may include the Computer Hardware specification (PC/Server),
Required computer Peripherals (Printer, Scanner, speaker, Web Cam), Other
 hardware (RPID Device, Barcode Scanner, Biometrics, Sensors, Signature Pad,
etc.)

Environment Requirements
It is the requirements for implementing and executing the test cases like a
platform to run the software product. The environment are the required hardware
and software along with proper network configuration and necessary settings.

Prepared by: ALKING P. SUNGA, MSIT IT 3: System Analysis and Design

P a g e | 22

Estimation and Test Schedule

In the Test Estimation phase, suppose you break out the whole project into small tasks and
add the estimation for each task as below

Then you create the schedule to complete these tasks.

Making schedule is a common term in project management. By creating a solid schedule in

the Test Planning, the Test Manager can use it as tool for monitoring the project progress,
control the cost overruns.

Sample Test Schedule:

Prepared by:
ALKING P. SUNGA, MSIT IT 3: System Analysis and Design

P a g e | 23

MODULE 3: System Proposal Outline and Format

Chapter 1 BACKGROUND OF THE STUDY

Rationale
Objectives

Chapter 2 EXISTING AND PROPOSED SYSTEM

Operational Process of Existing System

Scope and Limitation of the Proposed System
Data Flow Diagram of the Proposed System
User Beneficiaries

Chapter 3 REQUIREMENT ANALYSIS

System Development Framework Data

Dictionary
Database Schema
Unified Modeling Language
Hardware Requirements
Software Requirements
Cost Benefit Analysis
User Interface
Quality Assurance Test Plan
Prepared by: ALKING P. SUNGA, MSIT IT 3: System Analysis and Design