FYP WORKSHOP
(Wednesday - 9 March, 2016)
SYSTEM ANALYSIS AND DESIGN
PUAN YUHANIS OMAR
UNIKL MIIT
CONTENT
1. System Analysis and Design
2. Requirements Determination (Information
Gathering Technique/Data collection Method)
3. System Development Model
4. System Development Methodology Approach
5. Structured Approach
6. Object-Oriented Approach
7. Physical System Design
System Analysis vs System Design
Systems analysis is a process of
understanding in detail what a system
should accomplish.
Systems design is a process of specifying
in detail how components of an information
system should be physically implemented.
ANALYSIS vs DESIGN
SYSTEM ANALYSIS
Activities :
Gather information to learn problem domain
Define system requirements
Build prototypes for discovery of requirements
Prioritize requirements
Generate and evaluate alternatives
Review recommendations
REQUIREMENTS DETERMINATION
(INFORMATION GATHERING
TECHNIQUE)
Interview
individuals
Questionnaires
Observation
Analyze business
documents and
procedures
DATA ANAYSIS
SYSTEM DESIGN
Activities :
Design and integrate the network
Design the system architecture
Design (and integrate) the database structure
Design the user interfaces
Design the system interfaces
Prototype for design details
Design and integrate system controls
SYSTEM DEVELOPMENT MODEL
Consider System Development Models :
Agile
ADDIE
V Model
Big Bang
Iterations
Evolutionary
Incremental : Staged Delivery Model, Parallel
Development Model
Rapid Application Development : Phased
Development, Prototyping, Throwaway Prototyping
Etc.
GUIDELINES IN SELECTING THE
APPROPRIATE SYSTEM DEVELOPMENT
METHODOLOGY (MODEL)
Clarity of user requirements
Familiarity with technology
System complexity
System reliability
Short time schedules
SYSTEM DEVELOPMENT
METHODOLOGY : TWO COMMON
APPROACHES
TWO APPROACHES TO SYSTEM
DEVELOPMENT
Structured Approach
Includes information engineering (focus on data and
activities)
Structured languages : COBOL, FOTRAN
Object-oriented Approach
Views information system as collection of interacting
objects that work together to accomplish tasks
Objects things in computer system that can respond to
messages
Conceptually, no processes, programs, data entities, or
files are defined just objects
OO languages: Java, C++, C# .NET, VB .NET
STRUCTURED APPROACH
12
SYSTEM ANALYSIS
Define what system needs to do
(processing requirements)
Define data system needs to store and
use (data requirements)
Define inputs and outputs
Define what functions work together to
accomplish tasks
Data flow diagrams (DFD) and Entity
Relationship Diagrams (ERD) show results
of structured analysis
13
SYSTEM DESIGN
The process of defining the elements of a system such
as the architecture, modules and components, the
different interfaces of those components and the data
for a system to satisfy specified requirements.
To satisfy specific needs and requirements of a
business or organization through the engineering of a
coherent and well-running system.
Describe the initial transition from analysis to design.
Design modeling focuses on how system will operate.
Important objective of system designing is concerned
with creating the system which can work efficiently
providing the required output and being responsive
to the time within a given time limit.
SYSTEM DESIGN
Functional model describe business process and the
interaction of an information system with its environment.
Involves identifying data sources, the nature and type of
data that is available.
For example, in order to design a salary system, there is
a need for
using inputs, such as, attendance, leave
details, additions or deductions etc. This facilitates
understanding what kind of data is available and by
whom it is supplied to the system so that the system
may be designed considering all the relevant factors.
Always remember :
FULFILL USER REQUIREMENTS !
FULFILL FYP & PROGRAM REQUIREMENTS !
KEEP THEM AT EASE BEING USER-ORIENTED.
SYSTEM ARCHITECTURE
SYSTEM ARCHITECTURE
TECHNIQUES AND TOOLS
REPRESENTING
Techniques and Tools Representing
FLOW CHART
DATA
FLOW DIAGRAMS (DFD)
Graphically represent the processes that capture,
manipulate, store, and distribute data between a
system and its environment and among system
components.
A process is a systematic series of actions directed
toward an end or outcome.
A Data Flow Diagram (DFD) is a process modeling
methodology. DFDs should be drawn for both the
current and the proposed system.
DFDs are drawn for successive layers, with each
layer delving further into the process and its
functionality
DFD : THE NOTATIONS
EXAMPLE : CONTEXT DIAGRAM
EXAMPLE : DFD LEVEL 0
EXAMPLE : DFD LEVEL 1
EXAMPLE : CONTEXT DIAGRAM
EXAMPLE : DFD LEVEL 0
EXAMPLE : DFD LEVEL 1
EXAMPLE : DFD LEVEL 2
ENTITY-RELATIONSHIP DIAGRAM
(ERD)
29
ENTITY RELATIONSHIP DIAGRAM
(ERD)
EXAMPLE :
ERD
EXAMPLE : ERD
EXAMPLE : ERD
DATA DICTIONARY (DD)
Data dictionary
Provides detailed of all tables found within the
user/designer-created database
Contains (at least) all the attribute names and
characteristics for each table in the system
Contains metadata - data about data
Sometimes described as the database
designers database because it records the
design decisions about tables and their
structures
34
DATA DICTIONARY (DD)
Purpose:
to keep data about:
Data Flow and Data Item Specifications
File Specifications
Process Specifications
Data Specification Language:
Notational Conventions: = , + , [ ] , { } , ( )
e.g. amount due = [dollar amount, sterling amount]
Process Specifications
EXAMPLE : DATA DICTIONARY
36
EXAMPLE : DATA DICTIONARY
OBJECT-ORIENTED
APPROACH
38
TECHNIQUES AND TOOLS
REPRESENTING
Techniques and Tools Representing
ACTIVITY DIAGRAM
Describe dynamic aspects of the system.
Portray the primary activities and the
relationships among the activities in a
process.
The activity can be described as an
operation of the system. So the control
flow is drawn from one operation to
another.
ACTIVITY DIAGRAM : NOTATIONS
GUIDELINES FOR CREATING
ACTIVITY DIAGRAM
GUIDELINES :
Determine the scope or context of the activity
being modeled.
Give the diagram an appropriate title.
Identify activities, control flows and object flows
that occur
between the activities.
Identify any decisions that are part of the
process being modeled.
Identify any prospects for parallelism in the
process.
Draw activity diagram.
EXAMPLE : ACTIVITY DIAGRAM
EXAMPLE : ACTIVITY DIAGRAM
EXAMPLE : INCORRECT ILLUSTRATION
OF ACTIVITY DIAGRAM
EXAMPLE :
INCORRECT
ILLUSTRATION
OF ACTIVITY
DIAGRAM
USE-CASE DIAGRAM
A representation of a user's interaction
with the system that shows the
relationship between the user and the
different use cases in which the user is
involved.
USE-CASE DIAGRAM : NOTATIONS
Notations
Description
Actor
Scope / System boundary
Use-case
Association relationship
USE-CASE DIAGRAM : NOTATIONS
Notations
Description
Include relationship
Extend relationship
GUIDELINES FOR CREATING
USE-CASE DIAGRAM
IDENTIFYING THE MAJOR USE-CASES :
Review requirements definition.
Identify subjects boundaries.
Identify primary actors and goals.
Identify business process and major Use cases.
Review current set of Use cases.
CREATING USE-CASE DIAGRAM
Place and draw Use cases.
Place and draw actors.
Draw subject boundary.
Add associations.
EXAMPLE : ACTIVITY DIAGRAM
EXAMPLE : ACTIVITY DIAGRAM
EXAMPLE : INCORRECT ILLUSTRATION
OF USE-CASE DIAGRAM
EXAMPLE : INCORRECT ILLUSTRATION
OF USE-CASE DIAGRAM
EXAMPLE :
INCORRECT
ILLUSTRATION
OF USE-CASE
DIAGRAM
EXAMPLE :
INCORRECT
ILLUSTRATION
OF USE-CASE
DIAGRAM
EXAMPLE :
INCORRECT
ILLUSTRATION
OF USE-CASE
DIAGRAM
EXAMPLE :
INCORRECT
ILLUSTRATION
OF USE-CASE
DIAGRAM
EXAMPLE :
INCORRECT
ILLUSTRATION
OF USE-CASE
DIAGRAM
CLASS DIAGRAM
CLASS
DIAGRAM
CLASS
DIAGRAM
PHYSICAL SYSTEM DESIGN
Phases include:
Designing output
Creating files and databases
Designing input
Writing computer programs
Developing procedures
Building in controls
PHYSICAL SYSTEM DESIGN
Output Design:
Output usually fits into one of the following four categories:
Scheduled reports have a prespecified content and format and
are prepared on a regular basis.
Special-purpose analysis reports have no prespecified content
or format and are not prepared on a regular schedule.
Triggered exception reports have a prespecified content and
format but are prepared only in response to abnormal conditions.
Demand reports have a prespecified content and format but are
prepared only on request.
PHYSICAL SYSTEM DESIGN
File and Database Design:
Data needs to be stored in compatible formats to help avoid
the problem of having incompatible systems that makes it
impossible to share information and prepare reports.
What is the medium (tape, disc)?
Is processing batch, manual or real-time?
What is the size of the database?
How is the database maintained?
When will information be added, deleted and updated?
PHYSICAL SYSTEM DESIGN
Input Design:
How does data get in the system? Is it
through printed forms? Or is it through online
entry?
Forms design: more and more companies are
moving away from paper documents, but it is
still important.
PHYSICAL SYSTEM DESIGN
Computer screen design: it is more efficient to enter
data directly into the computer than on paper for
subsequent entry.
Design considerations:
+ data should be entered quickly, accurately and
completely.
+ enter data in the same order as displayed on paper.
+ enter left to right & top to bottom, group related data.
+ easy movement across the screen.
+ avoid clutter (e.g., limit number of menu options).
PHYSICAL SYSTEM DESIGN
Program development: is one of the most time-consuming
activities in the SDLC.
Programs subdivided into small, well-defined modules are a
process called structured programming.
To improve software quality, organizations should develop
programming standards.
Although accountants need not be computer programmers,
they should understand how software is created.
SYSTEM IMPLEMENTATION
SYSTEM IMPLEMENTATION
Activities :
Construct software components
Verify and test
Data Conversion
Train users and document the system
Install the system
FB GROUP FOR OPEN DISCUSSION
& KNOWLEDGE SHARING
(SYSTEM ANALYSIS AND DESIGN)
FYP System Analysis and Design ~~ Mdm.
Yuhanis
Thank You
