System Analysis and Design slides by Belew yenealem DTU Ethiopia

System Analysis and
Design (SAD)
By
Yared(Belew) Yenealem
Debre Tabor University,
Ethiopia

About me
Name: Belew Yenealem (aka. Yared)
Graduated from Addis Ababa Institute
of Technology in Software Engineering.
Currently an instructor at Debre Tabor
University, Computer Science
Department, Ethiopia
Address: belewyenealem@gmail.com

Viva!
 Complete Notes and Slides for
System Analysis and Design
Enjoy it!

Required Text Book
 Shelly and Rosenblatt System
Analysis and Design. 3rd
and 8th
edition
 Satyinger Jacson Burd. System
analysis ad Design in Changing the
world. 5th editioin
 William Amadio System Development
a Practical Approach

Course Objective
Understand the design and development
of Computer Based Information System
(CBIS) in an organization.
 Know about the various aspects and
components of System Life Cycle in a
CBIS.
 Apply the general concept of System
Analysis.

Chapter 1: System-Overview
Data, information, knowledge,
wisdom?
What is a System?
What is Analysis?
What is Design?
What is System Analysis?
What is System Design?
What is SAD?

Data vs. Information
wisdom?
– Data- unorganized/unprocessed/ raw
facts [names, numbers, words, symbols,
signs]
– Information- processed and
contextualized data, meaningful [answers
the questions: what, who, when, where]

Data vs. Information
wisdom?
– Knowledge- an understanding gained
thru experience. [answers the question:
How
– Wisdom- Applied knowledge
Fact!=data!=information!
=knowledge!=wisdom!=future

What is a System?
A collection of parts that work together to
achieve a goal/task
– Examples
• Solar system
• Digestive systems
• Public transport system
• Central heating system
• Computer system
• Information system
 an interrelated set of business
procedures (or components) used within
one business unit, working together for
some purpose.

Cont?
 Elements of System
– Input, Process, and Output
 Characteristics of a system
– Components, Interrelated components,
Boundary, Purpose, env’t, interfaces,
constraints, input ,and output
 System concepts
– Decomposition, Modularity, coupling,
and Cohesion

System Elements
INPUT OUTPUTPROCESS
FEEDBACK

Characteristics of System
 Components— Subsystem –an irreducible
or aggregate parts in a system.
Interrelated components- dependence of
one part of the system to the other
[components are interrelated]
Boundary- the limits of a system,
separating it from other systems.
Purpose – the overall goal/ function of the
system

 Environment— A system exists within an
environment—everything outside the
system’s boundary that influences the
system
Interfaces--Point of contact where a
system meets its environment or where
subsystems meet each other
Constraint– a limit to what a system can
accomplish

Input – System takes input from its
environment
Output - System returns output to its
environment as a result of its functioning to
achieve the purpose. Output from individual
subsystems may be inputs to other
subsystems.

System concepts
Decomposition [ Why?]
– Process of breaking down a system into smaller
components (parts)
Modularity
– Dividing a system up into chunks or
modules of a relatively uniform size.

System concepts
Coupling
– System being dependent on other systems,
represents the degree to which a single unit is
independent from others.
Cohesion
– Extent to which a subsystem performs a single
function, represents the degree to which a part
of a system forms a logically single, atomic unit.

Approach to system development
 There are three strategies of IS
development
1. Process-oriented approach
2. Data-oriented approach
3. Object-oriented approach

Process-oriented approach
• An strategy to IS development that focuses on how and
when data are moved through and changed by an IS
[ focuses on Process]
Data-oriented approach
• An strategy to IS development that focuses on the ideal
organization of data rather than where and how data are
used. [ focuses on Data]
Object-oriented approach
• A system development methodologies and techniques
base on objects rather than data or process [ focuses on
Object]

Information System?
IS
– An arrangement of information for the
purpose of supporting and improving
data processing [ day to day
operations in a business] and
information services [problem
solving and decision making]
1.14

What is an Information Systems?
 Interrelated components working
together to
– Collect
– Process
– Store
– Disseminate information
To support decision making,
coordination, control, analysis and
visualization in an organization

IS components
Hardware, Software, Documentation
and training materials, specific job
roles, controls, and people.
1.23

IS Types
1. Transaction Processing Systems (TPS)
2. Management Information Systems
(MIS)
3. Decision Support Systems (DSS)
4. Expert System and Artificial Intelligence
(ES &AI)


Transaction Processing Systems
(TPS)
 TPS are computerized information systems that
were developed to process large amounts of
data for routine business transaction.
 Automate the handling of data about business
activities and transactions, which can be thought of
a simple discrete events in the life of an
organization.

Management Information Systems
(MIS)
 Information system at the management level of an
organization that serves the functions of:
– planning, controlling, and decision making by providing
routine summary and exception reports.
 It takes the relatively raw data available through a TPS
and converts them into a meaningful aggregated form
that mangers need to conduct their responsibilities.
 Developing an MIS calls for a good understanding of
what kind of information managers require and how
managers use information in their jobs.

Decision Support systems
(DSS)
 DSS are designed to help organizational
decision make decision.
 A DSS is composed of a:
– Database ( may be extracted from a TPS/MIS)
– Graphical/mathematical models for business
process
– User interface that provides a way to
communicate with DSS

Expert System and Artificial
Intelligence (ES & AI)
A system that emulates the decision-making ability
of a human expert.
Designed to solve complex problems by reasoning
about knowledge, like an expert.

Why SAD?
 To improve organizational systems through
developing or acquiring application software that
can help employees accomplish key business
tasks more easily and efficiently.
 To create and maintain information systems
that perform basic business functions.

Individual Assignment(5%)
 Describe your university or college
as a system.
– What is the input?
– What is output?
– What is the boundary?
– What is the components and their
relationship?
– The constraint
– The environment
 Draw a diagram of this system

Chapter 2:
IS development Project

Managing IS Project
Project
– a planned undertaking of a series of
related activities to reach an objective
that has a beginning and an end.
– a temporary attempt or endeavour
made to produce some kind of a tangible
or intangible result ( a unique product,
service, benefit, competitive advantage,
etc. )

Project Management
The science (theory) of:
– organizing all the project components,
– stepping thru all the implementation
stages and phases,
– providing and managing all the
resources,
– protecting the project from potential risks,
– solving problems and managing changes
for the purpose of achieving initial project
goals,
– developing the product, and
– delivering project results

Focus of PM
To ensure that system development
projects meet customer expectations
and are delivered within budget and
time constraints.

Project Manager
A systems analyst with a diverse set
of skills—management, leadership,
technical, conflict management, and
customer relationship—who is
responsible for initiating, planning,
executing, and closing down a project.

Cont.
Project Manager
– Systems Analyst responsible for:
• Project initiation
• Planning
• Execution
• Closing down

Project Manager
Activities
• Management
• Leadership
• Technical
• Problem solving
• Conflict management
• Customer relations
• Team management
• Risk and change management

PMgmt. phases
Initiation
Planning
Execution
Closing down

Project Phases
Planning (Why build the system?)
Analysis (Who, what when, where
will the system be?)
Design (How will the system
work?)
Implementation (System delivery)

Initiation
Assess the size, scope, and
complexity of the project and to
establish procedures to support later
project activities.

Planning
focuses on defining clear, discrete
activities and the work needed to
complete each activity within a single
project

Planning--WBS
Dividing the project into manageable
tasks
Gantt chart
– A graphical representation of a project
that shows each task as a horizontal bar
whose length is proportional to its time
for completion.

Planning - COCOMO
COCOMO
– A method for estimating a software
project’s size and cost.
• To estimate project resources

Planning—Network Diagram
A diagram that depicts project tasks
and their interrelationships

Execution
Prior phases are put into action
It consists to put the planned
baseline project into action

Closing
focuses on bringing a project to an
end
Projects can conclude with a natural
or unnatural termination.

Closing Activities
Termination
– Documentation
– Personnel Appraisal
Conduct post-project reviews
– Determine strengths and weaknesses
of:
• Project deliverables
• Project management process
• Development process
Close customer contract

Techniques for Representing
and Scheduling Project Plans
Gantt and PERT

Gantt and PERT
– Gantt chart is a graphical
representation of a project that shows
each task activity as a horizontal bar
who is proportional to its time for
completion.
– PERT chart is a diagram that
represents project activities & their
dependencies
• There are several tools to support Gantt
and PERT charts

PERT
a critical path scheduling
technique used for controlling
resources and timing
– PERT = Program Evaluation Review
Technique
– It allows to determines critical path
scheduling and Slack Time

Gantt vs. PERT
Gantt
– Visually shows duration of tasks
– Visually shows time overlap between tasks
– Visually shows slack time
PERT
– Visually shows dependencies between tasks
– Visually shows which tasks can be done in
parallel
– Shows slack time by data in rectangles

Question
Can a project have two critical paths?
Why or why not? Give a brief example
to illustrate your point.

Chapter Three:
System Development Life
Cycle

SDLC
Traditional methodology used to
develop, maintain, and replace
information systems.
The SDLC is a phased approach to
analysis and design that holds that
systems are best developed through
the use of a specific cycle of analyst
and user activities.

4 phases of SDLC
System Planning and Selection
System Analysis
System Design
System Implementation

Why SDLC?
SDLC has three primary objectives:
– ensure that high quality systems are
delivered,
– provide strong management controls
over the projects, and
– maximize the productivity of the
systems staff.

Chapter 4:
Systems Planning & Selection
an organization’s total information
system needs are identified, analyzed,
prioritized, and arranged.
The process of
– identifying,
– selecting,
– initiating,
– planning projects and
– assessing projects feasibility.

Project Identification and
Selection
Identify the need for a system
– Problems in existing system or process
– New feature required in an existing
system
– A new idea for which in Information
System is required
– A requirement to improve efficiency in the
organization
– The need to keep up with competitors

Key Sources for IS projects
Managers and business units
IS managers
Formal planning groups

Cont.
Activities
– Identifying potential development
projects,
– classifying and ranking projects and
– selecting projects for development


Evaluation Criteria
Possible Evaluation Criteria when
classifying and ranking projects
– Value chain analysis= Extent to which activities
add value and costs when developing products
and/or services; information systems projects
providing the greatest overall benefits will be
given priority over those with fewer benefits
– Strategic alignment== Extent to which the
project is viewed as helping the organization
achieve its strategic objectives and long-term
goals

Evaluation Criteria cont.
– Potential benefits== Extent to which the project
is viewed as improving profits, customer service,
etc., and the duration of these benefits
– Resource availability== Amount and type of
resources the project requires and their
availability

Evaluation Criteria cont.
– Project size/duration==Number of individuals
and the length of time needed to complete the
project
– Technical difficulty/risks ==Level of technical
difficulty to complete the project successfully
within given time and resource constraints

Selection
Factors to be considered:
– Perceived and Real needs of the
organization
– Existing systems and ongoing projects
– Resource availability
– Evaluation criteria
– Current business conditions
– Perspective of the decision makers

Decision Outcome
From Identification and Selection:
– Accept, Reject, Delay Project
– Refocus Project
– End-User Development
– Purchase System
– Modify and Resubmit

Project Initiation and Planning
Transform a vague system
requirements into a tangible project
description

The two processes
Initiation
– Assess the size, scope, and complexity of the
project and to establish procedures to support
later project activities.
– Projects are selected, authorized, and chartered
Planning
– focuses on defining clear, discrete tasks and the
work needed to complete each task

Outcome of Planning
BPP
– an internal document that contains all information
collected and analyzed during initiation and planning
– reflects the best estimate of the project’s scope,
benefits, costs, risks and resource requirements
SOW
– a short document prepared for the customers that
describes what the project will deliver and outlines
all work required to complete the project
– a useful communication tool that assures that both
system analysts and customers have a common
understanding of the project.

What goes into a BPP?
Introduction
System Description
Feasibility Assessment
Management Issues

What goes into a SOW?
Scope of the work
Location of the work
Period of performance
Deliverables Schedule
Applicable standards
Acceptance Criteria
Specialized Requirements

Feasibility study
an assessment of the practicality of
a proposed plan or method.
an analysis of the viability of an idea.
an analysis of how successfully a
project can be completed
[achievability]
Answer for :“should we proceed with
the proposed project idea?

Technical feasibility
To determine whether the company
has the technical expertise ( the
organization’s ability and experience)
to handle completion of the project.
– Transportation
– Business location
– Technology needed and experience
using it
– Materials and labor

Economic feasibility
Involves a cost/ benefits analysis.
determine the positive economic
benefits to the organization that the
proposed system will provide.
Worthwhileness
a measure of the cost-
effectiveness of a project or
solution
Provides an economic justification
for the system using cost-benefit

Legal feasibility
In accordance to laws
Comply [conform to ] with legal
requirements

Operational feasibility
a measure of how well a proposed
system
– solves the problems, and
– takes advantage of the opportunities
identified during scope definition and
– how it satisfies the requirements
identified in the requirements analysis
phase of system development

Scheduling feasibility
a measure of how reasonable the
project timetable is.
Given our technical expertise, are the
project deadlines reasonable?
Timetable and Deadline [cutoff date
] reasonability
a measure of how reasonable the
project timetable is.

Political Feasibility
 Evaluating how KEY stakeholders
within the organization VIEW the
proposed system

Systems Analysis
system requirements are studied
and structured.
The process of understanding in
detail what a system should
accomplish.
is the study of a business problem for
the purpose of
– specifying the business requirements
for the solution and
– recommending improvements

Analysis
answers the questions of:
– who will use the system,
– what the system will do, and
– where and when it will be used
Goal of Analysis phase
– Truly understand the requirements of
a system

Analysis phase
 Input:
– Accepted project with baseline project plan and Work of
statement
 Output:
– System requirement & best alternatives to design the
system
• Output of phase 3 = Input of phase 4
 Purpose:
– How to determine requirements for the potential system?
– How to structure the generated requirement?
– How to select the best alternative design strategy?
 Process:
– Requirement determination
– Requirement structuring

System Analysis
Determine system requirements
Select appropriate methods to elicit
system requirements from users of
system
– Interviews, focus groups, surveys,
discussions, or other techniques

Analysis cont.
Analysis
– Study of current procedures and
information systems
• Determine requirements
– Study current system
– Structure requirements and eliminate
redundancies
• Generate alternative designs
• Compare alternatives
• Recommend best alternative

3 parts of Analysis
Determining Requirements
Structuring Requirements
Selecting best alternative strategy

Req’t Determination
more detailed, precise list of what the
new system must do to provide the
needed value to the business
Answer the question: What is the
system to do?
gathering information on what the
system should do from as many
sources as possible.

What is Req’t?
a statement of what the system must
do or what characteristics it needs to
have
is a characteristic or feature that
must be included in an information
system to be acceptable to users.
Serves as benchmarks to measure
the overall acceptability of the
finished system.

Req’ts Determination
gathering information on what the
system should do

Determining system Req’t
Methods
Traditional methods :
– Interviews
– Survey via questionnaires
– Direct observation of working people
– Study business documents

Traditional methods of Req't
gathering: Interviews
planned meeting during which you
obtain information from another
person

Interview
An interview is a planned meeting
during which you obtain information
from another person.
Interviewing involves getting people to
recall and convey information they
have.

Interview Guidelines
Plan the Interview
– Prepare interviewee by making an
appointment and explaining the purpose
of the interview. Prepare a checklist, an
agenda, and questions.

Cont.
Be Neutral
– Avoid asking leading questions [that
suggest or favor a particular reply]
– For example, rather than asking,
• “What advantages do you see in the
proposed system?” you might ask,
• “Do you see any advantages in the proposed
system?”

Cont.
Listen and take notes
– Give your undivided attention to the
interviewee and take notes or tape-
record the interview (if permission is
granted).

Cont.
Review Notes
Seek diverse views
– Interview a wide range of people,
including potential users and managers.

Open Ended Questions
Have no prespecified answers.
allow the respondent open options for
responding
leave room for elaboration on the part
of the interviewee.

Closed-ended questions
provide a range of answers from
which the interviewee may choose.
Limit the respondent’s options.
Require a specific answer
Different question forms
– True or False
– Multiple choice
– Rating a response
– Ranking in some order

Probes (Probing
questions)==Follow Up
to go beyond the initial answer to get
more meaning, to clarify, and to draw
out and expand on the interviewee’s
point
Probes allow the systems analyst to
follow up on questions to get more
detailed responses.

Questionnaires[ኩኩኩኩኩ]
A questionnaire, also called a survey, is a
document containing a number of
standard questions that can be sent to
many individuals.
is a set of written questions [either on
paper or electronic] for obtaining
information from individuals.
a list of questions that several people are
asked so that information can be collected
about something

Types of questionnaire
questions
Free-format
– Open ended questions
Fixed format
– Require specific responses
• Multiple questions
• Rating questions/ scaling
• Ranking questions

L Choosing Questionnaire
Respondents / Recipients
Select a sample
– Those people who’re willing and
motivated to respond
A random group
– A random selection
A purposeful sample
– Based on some criteria

rules for designing a good
questionnaire:
Allow ample white space.
Allow ample space to write or type in
responses.
Make it easy for respondents to
clearly mark their answers.
Be consistent in style.
Avoid:
– Bias, crowded pages, leading questions,
threatening, abbreviations

Interviewing vs Questionnaire
Interview is more familiar and
personal than a questionnaire.
During a face-to-face interview, you
can react immediately to anything the
interviewee says but Questionnaire is
passive.
Interviewing, however, is a costly and
time-consuming process.
You seek input form a large group?
Use Questionnaire!

Cont.
In contrast, a questionnaire gives
many people the opportunity to
provide input and suggestions
If a question, in a questionnaire, is
misinterpreted, you cannot clarify the
meaning as you can in a face-to-face
interview.

Cont.
Interview is quite time intensive and
expensive, but gives rich and detailed
info, easy reaction, more familiar and
personal, good for blinds.
Questionnaire
– Inexpensive, take less time, good for
specific info, gathered info is less rich,
passive, easy for many access, difficult
for clarification if misinterpretation occurs,
good for deafs.

Direct Observation
Observation, the act of watching
processes being performed, is a
powerful tool to gain insight into the
as-is system
gather information by watching the
users of the system at work

Ways
Direct Participation
– Work together
By watching
– Personal Observation or at a distant
by camera

Analyzing Documents
Review of existing business
documents.
Useful to understand the as-is
system.

What to find in Documents?
Problems with existing systems (e.g.,
missing information or redundant
steps)
 Opportunities to meet new needs if
only certain information or information
processing were available
Values and missions of the org.
Influential stakeholders.
Principles and rules in the org.

Types of Documents
Procedures
– How a particular job or task is performed
Business Forms
– What data flows in and out of the system
Reports
– Primary output of current system
– How data is manipulated, transformed
Manuals
– Description of current IS, how to of an
existing system

Contemporary Methods
– Joint Application Design
– Rapid Application Design
– Participatory Design
– CASE tools
– Prototyping
They can be used for Req’t
gathering and for system
development model

Why Modern?
Reduces time
– Of collecting and structuring Req't
Easy and consistent data
Efficiency

Prototyping
Designing and Building a scaled-
down version of the desired
information system.
A prototype is an early working
version of an information system.
A small-scale, incomplete, but
working sample of a desired
system.
a rudimentary version of an IS based
on user feedback.

L Prototyping
A compressed version of SDLC
Resembles a condensed version of
the entire SDLC

Advantages of Prototyping
Reduce time and costs
– the early determination of what the user
really wants can result in faster and less
expensive software
– the potential for changing the system
early in its development,
– the opportunity to stop development on a
system that is not working,
Captures Req’t in concrete forms

Contd.
Improved and increased user
involvement [It involves the user in
analysis and design]
– prevents many misunderstandings and
miscommunications
– Better feedback and specifications
– User’s satisfaction
– are useful in seeking user reactions,
suggestions, innovations, and revision
plans
– Users can easily visualize the system
from the very beginning

Disadvantages of Prototyping
Insufficient Analysis
User confusion of prototype with final
version
Excessive development time of
Prototype
Developer attachment to prototype
Tendency to avoid formal
documentation

Process of Prototyping
Identify basic requirements
– Determine basic requirements including
the input and output information desired

Contd.
Develop initial prototype
– The initial prototype is developed that
includes only user interfaces

Contd.
Review
– The customers, including end-users,
examine the prototype and provide
feedback on additions or changes.

Contd.
Revise and enhance the prototype
– Using the feedback both the
specifications and the prototype can be
improved. Negotiation about what is
within the scope of the contract/product
may be necessary. If changes are
introduced then a repeat of steps #3 and
#4 may be needed.

When to use it?
User requests aren’t clear
Few users are involved in the system
– Couse few won’t give detailed Req't
Designs are complex and require
concrete form
There was communication problems
between analysts and users
Tools are readily available to build
prototype

L Reading Assignment
Dimensions of Prototyping
Horizontal and Vertical
Types of Prototyping
– Throwaway
– Evolutionary
– Incremental
– Extreme

CASE Tools
Computer-Aided/Assisted
Software/System
Engineering===refers to automated
software tools used by systems
analysts to develop IS.
Software tools that provide
automated support for some portion
of the systems development process.

L Types of CASE tools
depending on where in the
development process they are most
involved in:
– Upper—support analysis and design
phases
– Lower—support coding phases
[Implementation]
– Integrated—all phases.

Examples
Visible Analyst Workbench
Oracle Designer
Rational Rose
Logic Works suite.
Microsoft Visio

L Benefits : CASE Tools
Tasks are much faster to complete and
alter
Development information is centralized
Information is illustrated through
diagrams, which typically are easier to
understand
Reduce maintenance costs, improve
software quality, and enforce discipline
 To assess the magnitude of changes to
the project.

JAD-Joint Application Design
A structured process in which users,
managers, and analysts work
together [hence Joint] for several
days in a series of intensive meetings
to specify or review system
requirements.
A means to bring together the key
users, managers, and systems
analysts involved in the analysis of a
current system.

Purpose: Why JAD?
To collect systems requirements from
the key people involved with the
system.
Allows analysts to see the areas of
agreement and the areas of conflict.
To have Shared Understanding
When users participate in the systems
development process, they are more
likely to feel a sense of ownership in
the results, and support for the new
system.

L JAD
In this approach, the sponsor company
creates a task force of users, managers,
and IS professionals that works together
to gather information, discuss business
needs, and define the new system
requirements. This group usually meets
over periods of days or weeks.

typical JAD participants
JAD Session Leader
– Plans and leads JAD sessions
– Organizes and runs the JAD
– Sets the agenda and sees that it’s met
– Remains neutral on issues & doesn’t
contribute ideas or opinions
– Concentrate on keeping the group on
agenda, resolving conflicts and
disagreements, and soliciting all ideas

Cont.
Users
– Key users of the system

Cont.
Managers[Project Leader]
Sponsors
System Analysts
Scribe[Documentation Expert]
– The person who makes detailed notes of
the happenings at a JAD session.
IS Staff
– Programmers, database analysts, IS
planners, data-center personnel,
developers

RAD-Rapid Application
Development
Why Prototyping, CASE, JAD?
– -To facilitate development
– To support RAD
To radically decrease the time needed
to design and implement information
systems.
Involves: extensive user
involvement, prototyping, JAD
sessions, integrated CASE tools,
and code generators.

RAD Emphasis
The emphasis in RAD is generally less on
the sequence and structure of processes
in the life cycle and more on doing
different tasks in parallel with each other
and on using prototyping extensively.
The main objective of all RAD
approaches is to cut development time and
expense by involving users in every phase
of systems development.

WHEN TO USE RAD
Consider using RAD when:
– 1. Your team includes programmers and analysts
who are experienced with it; and
– 2. There are pressing business reasons for speeding
up a portion of an application development; or
– 3. When you are working with a novel ecommerce
application and your development team believes that
the business can sufficiently benefit over their
competitors from being an innovator if this
application is among the first to appear on the Web;
or
– 4. When users are sophisticated and highly engaged
with the organizational goals of the company

Disadvantages of RAD
May try and hurry the project too
much
Loosely documented
May not address pressing business
problems
Potentially steep learning curve for
programmers inexperienced with RAD
tools

Cont.
The accelerated time cycle might
allow less time to develop quality,
consistency, and design standards.

PD-Participatory Design
Originally Co-operative design, now
often co-design
– is an approach to design attempting to
actively involve all stakeholders (e.g.
employees, partners, customers, citizens,
end users) in the design process to help
ensure the result meets their needs and
is usable.

L JAD vs PD
They are two established user
involvement methodologies.
JAD is a practitioner-derived
methodology focusing on structured,
facilitated meetings through which
user involvement is elicited in systems
development. PD stresses the social
context of the workplace in workshops
in which designers and workers
collaborate in design and
development activities.

Cont.
Pont of Comparison JAD PD
Criteria for Validation Quantitative:
economic optima, time
savings, performance
indices
Qualitative:
democracy, mutual
learning, mutual
education, conflict
resolution
Goal Improved System Improved Workplace

BPR
The Search for, and implementation
of, radical change in business
processes to achieve breakthrough
improvements in products and
services.
a process in which existing methods
of doing business are replaced with
new and updated methods

Cont.
The overall process by which current
methods are replaced with radically
new methods is referred to as
business process reengineering
(BPR).

Deliverables and Outcomes
Deliverables for Req’t determination
– From interviews and observations
• Interview transcripts, observation notes,
meeting minutes
– From existing written documents
• Mission and strategy statements, business
forms, procedure manuals, job descriptions,
training manuals, system documentation,
flowcharts
– Form Computerized sources
• JAD session results, CASE repositories,
reports from existing systems, displays and
reports from system prototype

Structuring Req’t
Organizing a gathered Req't into a
form that is a meaningful
representation of the existing system.
Structuring taking the system
requirements you find during
requirements determination and
ordering them into tables,
diagrams, and other formats that
make them easier to translate into
technical system specifications.

Two Stages
Process Modeling
– graphically representing the processes
– Use DFD—shows mov’t of data
– Logic Modeling==shows internal
structure and functionalities of the
processes in DFD
Conceptual Data Modeling
– Shows data in a system
– ER diagram—show how data is
organized in a system.

DFD
Shows how data moves thru an IS
but doesn’t show program logic or
processing steps.

Select Best design Strategy
Two basic steps
– 1. generating a comprehensive set of
alternative design strategies
– 2. Selecting the one that is most likely to
result in the desired information system,
given all of the organizational, economic,
and technical constraints that limit what
can be done.

Who’s System Analyst
The organizational role most
responsible for the analysis and
design of ISs
the person in the organization most
involved with systems analysis and
design

Characteristics of a good SA
in Req’t Determination

Chapter 6:
Systems Design
a description of the recommended
solution is converted into logical and
then physical system specifications.
Process of defining the architecture,
components, modules, interfaces, and
data for a system to satisfy specified
requirements.
The design phase of the SDLC uses
the requirements that were gathered
during analysis to create a blueprint

System Design
the determination of the overall
system architecture—
– consisting of a set of physical processing
components, hardware, software, people,
and the communication among them—
that will satisfy the system’s essential
requirements.

Design
Physical design
Architectural design
Interface design
Database and file design
Program design
I/O Design

Activities in Design Phase
After detailed analysis, Determine
preferred system acquisition
strategy(make, buy, or outsource)
Design the architecture for the system
[Architecture Design]
Make hardware and software selections
[Hardware and software specification]
Design system navigation, inputs and
outputs [Interface design]

Input Design
Input mechanisms facilitate the entry of
data into the computer system, whether
highly structured data, such as order
information (e.g., item numbers,
quantities, costs), or unstructured
information (e.g., comments).
Input design means designing the screens
used to enter the information, as well as
any forms on which users write or type
information (e.g., time cards, expense
claims).

Basic Principles in ID
Goal of ID
– To capture accurate information for the
system simply and easily.
The fundamental principles for input
design reflect the nature of the inputs
(whether batch or online) and ways to
simplify their collection

Principles
1. Use Online and Batch
Processing Appropriately
– Two general approaches for entering
inputs into a computer system:
• online processing and
• batch processing.

Online (Transaction)
processing
each input item (e.g., a customer order, a
purchase order) is entered into the system
individually, usually at the same time as the
event or transaction prompting the input.
– E.g., When you borrow a book from the library, buy
an item at the store, or make an airline reservation,
the computer system that supports each process uses
online processing to immediately record the
transaction in the appropriate database(s).

Batch Processing
all the inputs collected over some
period are gathered together and
entered into the system at one time in
a batch.

Principles
2. Capture Data at the Source
– Perhaps the most important principle of
input design is to capture the data in an
electronic format at the original source or
as close to the original source as
possible.

Principles
3. Minimize Keystrokes
Keystrokes cost time and money,

Types of Inputs
Text
Numbers

Output Design
Outputs are the reports that the
system produces, whether on the
screen, on paper, or in other media,
such as the Web.

Output-design
Objectives
Serve the intended purpose
Deliver the right quantity of output
Deliver it to the right place
Provide output on time
Choose the right method

Types of Outputs
Internal outputs stay inside the system
to support the system's users and
managers
External outputs leave the system to
trigger actions on the part of their
recipients or confirm actions to their
recipients
– Turnaround outputs are those which are
typically implemented as a report eventually
re-enters the system as an input

Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
Principles & Guidelines for Output Design
Types of Outputs
– There are two basic types of computer
outputs, external and internal.
• External outputs leave the system to trigger
actions on the part of their recipients or confirm
actions to their recipients.
– Most external outputs are created as preprinted
forms that are designed and duplicated by forms
manufacturers for use on computer printers.
– Some external outputs are designed as turnaround
documents.
• Turnaround outputs are those which are typically
implemented as a form eventually reenters the
system as an input.

SoundStage Entertainment Club
Fax 317-494-0999
The following number must appear on all related correspondence,
shipping papers, and invoices:
P.O. NUMBER: 712812
To: Ship To:
SoundStage Entertainment Club SoundStage Entertainment Club
2625 Darwin Drive Shipping/Receiving Station
Indianapolis, IN 45213 Building A
2630 Darwin Drive
Indianapolis, IN 45213
P.O. DATE REQUISITIONER SHIP VIA F.O.B. POINT TERMS
5-3-96 ldb ups N30
QTY DESCRIPTION UNIT PRICE TOTAL
10000 Powder - VHS 19.99 199,900.00
5000 Now and Then - VHS 15.95 79,750.00
2500 Pulp Fiction Soundtrack - CD 7.99 19,975.00
450 U2 on Tour - T-shirt 3.49 1,570.50
Subtotal 301,195.50
Tax 15,059.77
Total 316,255.27
1. Please send two copies of your invoice.
2. Enter this order in accordance with the prices, terms, delivery method, and
specifications listed above.
3. Please notify us immediately if you are unable to ship as specified.
Madge Worthy 5- 4- 96
Authorized by Date

Invoice No. 301231
Name Carlina Smith Date 7/21/97
Address 3019 Duroc Drive Order No. 346910
City Little Rock State AR ZIP 42653
Phone 502-430-4545 Payment Amt
Detach and return top portion with payment
Qty Description Unit Price TOTAL
1 Star Wars - Empire Strikes Back VHS $19.99 $19.99
1 Eric Clapton Unplugged CD $13.99 $13.99
1 Alladin VHS $17.95 $17.95
SubTotal $51.93
Shipping & Handling $7.00
Cash Taxes $2.95
Check
Credit Card TOTAL $61.88
Name
CC # Office Use Only
Expires
RETURN TOP PORTION WITH PAYMENT
SoundStage
Entertainment Club
2630 Darwin Drive - Bldg B
Indianapolis, IN 45213
317-496-0998 fax 317-494-0999 INVOICE
Payment Details
Customer
Please return top portion invoice with payment. Make checks payable to:
SoundStage Entertainment Club.

Types of Outputs
– There are two basic types of computer
outputs, external and internal.
(continued)
• Internal outputs stay inside the system to
support the system's users and managers.
– Internal outputs fulfill management reporting and
decision support requirements.
• Management information systems typically
produce three types of reports: detailed,
summary, and exception.

Types of Outputs
– Internal Outputs (continued)
• Detailed Reports:
– Present information with little or no filtering or
restrictions.
– Some detailed reports are historical in nature.
– Detailed reports confirm and document the
successful processing of transactions and serve as
an audit trail for subsequent management inquiry.
• These reports assist management planning and
controlling by generating schedules and
analysis.
– Other detailed reports are regulatory, that is, required
by government.

Page 1
SOUNDSTAGE ENTERTAINMENT CLUB
− Products Ordered on 6-31-1996 −
PO Number Product Number Product Type Quantity In Stock Quantity On Order
112312 102774 Merchandise 273 450
202653 Title 75 325
393752 Title 251 125
112313 109833 Merchandise 0 200
111340 Title 46 150
231045 Title 225 1,500
253967 Title 332 850
112314 287904 Title 0 2,000
699034 Merchandise 0 300
836785 Merchandise 35 175
984523 Title 213 250

Types of Outputs
• Summary Reports:
– Categorize information for managers who do not
want to wade through details.
– The data for summary reports is typically
categorized and summarized to indicate trends
and potential problems.
– The use of graphics (charts and graphs) on
summary reports is also rapidly gaining
acceptance because it more clearly summarizes
trends at a glance.

Page 1
− Product Sales Summary as of 7-2-1996 −
Product Type Product Category Current Month’s Unit Sales Current Year Unit Sales
Merchandise Clothing 784 4,312
Media Accessory 541 2,079
Total:
Title Audio 3,815 20,175
Game Title 1,247 5,671
Video Title 2,136 9,032
Total:

Types of Outputs
• Exception Reports:
– Filter data before it is presented to the manager
as information.
– Exception reports only report exceptions to
some condition or standard.

Page 1
− Delinquent Member Accounts as of 7-9-1996 −
− (90 Days Overdue) −
Number Name Area Code Phone Extension Balance Due
137842 Joe Dunn 317 490-0012 111 29.43
142314 Bob Fischer 501 282-7996 43.97
157723 Mary Slatter 218 993-9091 56.99
209438 Harold Martin 823 231-8355 33.17
237121 Kevin Ditmano 655 219-0988 99.23
384563 Rick Carlina 501 454-6311 11.23
421134 Barb Kitts 393 789-5412 231 23.66
476688 Kenny Bum 443 234-8845 123.77

Output Media and Formats
– A good systems analyst will consider all
available options for implementing an
output, especially output medium and
output format.
• A medium is what the output information is
recorded on, such as paper or video display
device.
• Format is the way the information is displayed
on a medium for instance, columns of numbers.
– The selection of an appropriate medium
and format for an output depends on how

Types of Outputs
Detailed Reports:
– Present information with little or no filtering or
restrictions.
– Some detailed reports are historical in nature.
– Detailed reports confirm and document the successful
processing of transactions and serve as an audit trail
for subsequent management inquiry.
Exception Reports:
– Filter data before it is presented to the manager as
information.
– Exception reports only report exceptions to some
condition or standard.

Basic Principles
The goal of the output mechanism is
to present information to users so that
they can accurately understand it with
the least effort.
The fundamental principles for output
design reflect how the outputs are
used and ways to make it simpler for
users to understand them.

Principles
1. Understand Report Usage
– Understand how reports are used.
• Real time reports
• Batch reports
2. Manage Info load
3. Minimize Bias

Types of Outputs
Internal
– stay inside the system to support the
system's users and managers
External
– Reports
– Media

Output Formats
Tabular
Zoned
Graphic
Narrative

Data Storage Formats
Types
– Files
• Electronic lists of data that have been
optimized to perform a particular transaction.
– Database
• a collection of groupings of information that
are related to each other in some way (e.g.,
through common fields).

Steps to develop Logical
Database Model

Purpose of designing Logical
DB
To structure the data in stable structures
Minimal redundancy
To meet actual data requirements of the
system
To ease physical database design

Relational Database Model
An approach to managing data
using tuples
Organizes data in tables

Primary Key
Uniquely identifies a record in a table
Cannot accept null values
A table typically has a column or combination of
columns that contain values that uniquely
identify each row in the table. This column, or
columns, is called the primary key (PK) of the
table and enforces the entity integrity of the
table. Because primary key constraints
guarantee unique data, they are frequently
defined on an identity column.

Foreign Key
a field in the table that is primary
key in another table.

Normalization
used to produce a data model that
has the properties of
– simplicity,
– non-redundancy and
– minimal maintenance.

Referential Integrity
a property of data which, when
satisfied, requires every value of
one attribute (column) of a relation
(table) to exist as a value of another
attribute (column) in a different (or
the same) relation (table)

Group Assignments / 5%
Briefly Discuss about the following
Concepts:
– Logical and Physical Database
– How to design a logical Database and a
physical database?
– Relational database model
– Primary key and foreign key
– Normalization
– Referential Integrity
– Dependency

Chapter 7:
Systems Implementation and
Maintenance
the information system is coded,
tested, installed and supported in
the organization.

System implementation
is the construction, installation and
testing of system components and the
delivery of the system for day-to-day
operation.
Expensive phase
Time consuming
– So many people involved

Maintenance
an information system is
systematically repaired and
improved
Repairing, Looking after, improving

System Implementation &
Operation
Install system
Prepare documentation
Train users of the system
Provide support
Maintain system on a regular basis

7 major activities
Coding
Testing
Installation
Documentation
Training
Support
Maintenance

1. Coding
turning the physical design
specifications created at the design
stage into working computer code
by programmers.
Coding is the process of turning
program logic into specific instructions
that the computer system can
execute. Working from a specific
design, a programmer uses a
programming language to transform
program logic into code statements.

2. Testing
Static and dynamic testing
Whether code is executed or not
Automated and manual testing
– Whether testing is done manually or not

7 types of tests, their category

Inspection
participants manually examine code
for occurrences of well-known errors.
Syntax, grammar and some other
routine errors can be checked by
automated inspection software, so
manual inspection checks are used for
more subtle errors.
Exactly what the code does is not
investigated in an inspection.

Walkthrough
Reviewing what the code does and
thereby finding out errors
Code review

Desk-checking
A testing technique in which the
program code is sequentially executed
manually by the reviewer.
A manual (non-computerized)
technique for checking the logic of an
algorithm.

Syntax checking
Done by the computer/compiler
Code not executed

Unit(module/functional)Testin
g
Each module is tested alone in an
attempt to discover any errors in its
code.

Integration Testing
Combining modules and testing them

System Testing
testing of the IS as a whole (as a
complete entity)
The bringing together for testing
purposes of all the programs that a
system comprises.

Stub Testing
A technique used in testing modules,
especially where modules are written
and tested in a top-down fashion,
where a few lines of code are used to
substitute for subordinate modules.
Stubs are two or three lines of code
written by a programmer to stand in
for the missing modules

Acceptance Testing by Users
Acceptance Testing
– The process whereby actual users test a
completed information system, the end
result of which is the users’ acceptance
of it once they are satisfied with it.
testing the system in the environment
where it will eventually be used

3. Installation
Called System conversion
The process of moving from the
current information system to the new
one
The organizational process of
changing over from the current
information system to a new one

Installation
Strategies/approaches
Direct Installation [Abrupt cut-over]
– old system is terminated on a specific
date and the new system is placed into
operation.
– High risk approach
Changing over from the old
information system to a new one by
turning off the old system when the
new one is turned on.

Cont.
Parallel Installation
– both the old and new systems are
operated for some time period
– Old and new systems coexist
Running the old information system
and the new one at the same time
until management decides the old
system can be turned off.
running the old system and the new
system at the same time, in parallel.

Cont.
Phased Installation
– Changing from the old information
system to the new one incrementally,
starting with one or a few functional
components and then gradually
extending the installation to cover the
whole new system
Staged, incremental, gradual, based
on system functional components

Cont.
Single location installation [Pilot
Installation/Operation]
– involves implementing the complete new
system at a selected location of the
company.
– Trying out a new information system at
one site and using the experience to
decide if and how the new system should
be deployed throughout the organization.

4.Documentation
Documentation describes an
information system and helps the
users, managers, and IT staff who
must interact with it. Accurate
documentation can reduce system
downtime, cut costs, and speed up
maintenance tasks

Types of Documentation
System Documentation
– detailed information about a system’s
design specifications, its internal
workings, and its functionality.
– describes the system’s functions and
how they are implemented.
– is a by-product of the systems analysis
and design process and is created as the
project unfolds.

Types cont.
User Documentation
consists of written or other visual
information about an application
system, how it works and how to use it
Reference guide, user’s guide,
release description, system admins
guide, acceptance sign-off

5. Training
The educational process in which
systems analysts engage in to bring
about the smooth transition from the
old system to the new is called
training.

Issues to consider
Who to Train?
– anyone whose work is affected by the
new information system
– All users [both primary and secondary]
• From data entry personnel to decision
makers
Who be Trainers?
– Vendors
– Systems analysts
– External paid trainers

Issues to consider
What to Train?
– Use of system
– General computer concepts
– IS concepts (batch Vs. online processing)
– Organizational practice concepts ( e.g.
FIFO inventory accounting)
– System management (e.g. how to
request changes to a system)
– System installation

Types of Training Methods
Formal courses —several people
taught at the same time
Resident expert
E-learning/distance learning
Blended learning (combination of
instructor-led training and e-learning)
Software help components
Tutorial ---one person taught at a
time

6. User Support
an ongoing technical support provided
to users
Providing ongoing educational and
problem-solving assistance to
information system users.
User support in an organization is
usually provided in two forms:
– an information center and
– a help desk.

7. Maintenance
Is the process of refining the system
to make sure it continues to meet
business needs.

Types of Maintenance
Corrective
– To fix errors and problems
– diagnoses and corrects errors in an
operational system
– repair defects in the design, coding, or
implementation of an IS.

Adaptive
– Adds new capability and
enhancements
– involves making changes to an
information system to evolve its
functionality to changing business needs

Perfective
– Improving efficiency, reliability, or
maintainability
– involves changes made to a system to
reduce the chance of future system
failure.

Preventive
– reduces the possibility of future system
failure.
– Avoids future problems
– Detailed analysis of areas where troubles
are likely to occur.

Processes and Deliverables
Process Product
Planning
Analysis
Design
Implementation
Project Plan
System Proposal
System
Specification
New System and
Maintenance Plan

SDLC criticisms…
Reliance on the life cycle approach
forced intangible and dynamic
processes such as analysis and
design into timed phases that were
doomed to fail. (martin, 1999)
Massive amount of processes and
documentation does slow down
development, Agile developers claims
that source code is enough
documentation.

Cont. Criticism
Criticism of the SDLC that is based on
fiction is that all versions of SDLC are
waterfall-like with no feedback
between steps.
Another false criticism is that a life
cycle approach limits the involvement
of users, yet Agile and Extreme
programming approaches advocate
an analysis-design-code-test
sequence, and that is itself is a cycle.

System Analysis and Design slides by Belew yenealem DTU Ethiopia

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to System Analysis and Design slides by Belew yenealem DTU Ethiopia

Similar to System Analysis and Design slides by Belew yenealem DTU Ethiopia (20)

Recently uploaded

Recently uploaded (20)

System Analysis and Design slides by Belew yenealem DTU Ethiopia

Editor's Notes