System Analysis and Design

CS-1st Year
Systems Analysis and Design
G.K.A. Dias
University of Colombo School of Computing 1

References
Ref : System Analysis and DESIGN
METHODS
By Jeffrey L Whitten & Lonnie

D Bentley ISBN 0-07-063417-3
(7th Edition)
Recommended Links
http://www.mhhe.com/whitten
2
Introduction to Information System
Environment
What is an information system?

Types of Information Systems and
processing types
System development life cycle ???
Major components of the development
process???
3
Information Systems
Applications
Earlier applications
Airline Reservations Keeping records Keeping records

of transactions of Stock
4
Information Systems
Introduction
Computers are now becoming part of virtually
every activity in an organization
Production HRM - Training Telephone Integration
5
Information System
An arrangement of
People Interface Data Information Network Process

Technology
To support and Improve day to day operations
problem solving and decision making needs of
management and users
6
Information System
Information Technology
A combination of
Computer Technology Telecommunication
Data, image, voice

Hardware & Software
Computer Technology Telecommunication Technology
7
Information Systems
The Players - System Stakeholders
any person who has an interest in an existing or proposed
information system.
Can be classified into five broader categories
may include both

technical and non-technical workers
Internal and External workers
8
Information Systems
System stakeholders
can be classified into five groups
System User System Owner System Builders
System Designer System Analysts

9
Information Systems
Stakeholders cont..
a customer who will use or
is affected by an information
system on a regular basis
capturing, validating,
entering, responding to,
storing, and exchanging
data and information.
System Users
or Clients
10
Information Systems
Stakeholders cont.. An information systems sponsor
and advocate
Owns the system
Set the vision and

priorities
Determine the policies
Responsible for funding the

project of
System Owner Developing
Operating
Maintaining
11
Information Systems
Stakeholders cont.. technical specialists
Translates system users

business requirements and
constraints into technical
solutions.
Design the system (data-bases,

inputs, outputs, screens, network,
software) to meet the users
System Designer
requirements
12
Information Systems
Stakeholders cont..
Design the computer

files, databases, inputs,
outputs, screens,
networks, and programs
that will meet the system
users requirements.
System Designer
13
Information Systems
Stakeholders cont..
Construct, test and deliver

the Information System
based on the design
specifications generated by
the system designer.
System Builders
14
Information Systems
Stakeholders cont..
People who understand

both business and
computing.
Systems Analysts
15
Information Systems
Stakeholders cont.. Studies the problems and
needs of an organization
Determine how people, data,

processes, and information
technology can best accomplish
improvements for the business
Bridge the communication gap

that exists between non
Systems Analysts technical and technical people
involved with building systems.
16
Information Systems
Stakeholders cont..
What does a systems analyst
do?
- Identify the problem
- Analyze and understand the
problem
- Identify the requirements
- Identify the solution
- Identify alternative solutions
- Design and implement the
Systems Analysts best solution
- Evaluate the result
17
Information Systems
Legacy systems
an existing computer system or
application program
continues to be used because the user
does not want to replace or redesign it
an "antiquated" systems.
Ref : http://en.wikipedia.org/wiki/Legacy_system
18
Information Systems
Legacy systems cont
potentially problematic
often run on obsolete (and usually slow) hardware
spare parts for such computers become increasingly difficult to

obtain
hard to maintain, improve, and expand because there is a

general lack of understanding of the system
The designers of the system may have left the organization,

leaving no one left to explain how it works
Integration with newer systems may also be difficult because

new software may use completely different technologies.
19
Information Systems
Legacy systems cont
Support old business Support new

requirements business requirements
Old Euro? Euro New

technology Converted to satisfy standard
Y2K? new environments Y2K free New
Old technology
standard Old system New system
New
functionality
20
Information Systems
Legacy systems cont
Many complex legacy systems yet to be

upgraded to new technologies because of
Cost,
Skills and
People required
Force to change to reflect new or changing

business requirements.
Year 2000 problem (Y2K)
Euro conversion
21
Information Systems
Legacy systems cont.
Y2K problem
Many computers and applications stored

date with only 2 digits.
(e.g. 99 =1999)
Problems : when the millennium changed

(e.g. 03=2003)
Born in 1978
Age? -74, 0, 74
22
Types of Information Systems
Transaction Process Systems (TPS)

Management Information Systems (MIS)
Decision Support Systems (DSS)
Executive Information Systems (EIS)
Expert Systems
Communications and collaboration
Systems
Office Automation Systems
1
Transaction Process Systems
(TPS)
Capture and process data about
business transactions
Airline Reservations Bank deposit and

withdrawal
2
Management Information System
(MIS)
Designed for management oriented reporting
Based on transaction processing and
operations of the organization
Production scheduling Inventory reporting
3
Decision Support System (DSS)
Helps to identify decision making opportunities
Provides information to help make decisions
Provides its user with decision-oriented
information whenever decision making
situation arises.
Executes at work
With DSS 4
Executive Information Systems
Designed for top-level
managers.
Supports the planning

and assessment needs of
executive managers.
Integrates data from all

over the organization into
at-a-glance graphical
indicators and controls.
5
Expert Systems
An expert system is a programmed
decision making information
system. I am a
Capture and reproduce the human
knowledge and expertise of a
decision maker
Simulates the thinking of the
expert.
6
Communications and Collaboration
Systems
Enables more effective
communications between
Workers
Partners
Customers
Suppliers
Enhance their ability to

collaborate
7
Office Automation Systems
Supports the wide range of business office
activities
Provides improved work flow between workers.
g
ed
ul i n
a i l
ch M
ou p s
E - e nt
r u m
r kg oc
W o
ile ng ni cd
s im puti
ct r o
f ac p co m
Ele
r ou
or kg
W
8
Information technology Features
Centralized Systems
- All the components are hosted by a central, multi user system

- User interact with the host computer via terminals
- Virtually all of the actual processing and work is done on the host computer.
I am doing all processing

I have all system
data
Databases Provide
interfaces
1
Information technology features
Distributed Systems
- Components are distributed across multiple locations and computer networks
- Processing work load required to support these components are distributed

across multiple computers on the net work.
Distributed
to multiple
locations
-- Components of an information system
-- Processing workload required to
support the components
2
Distributed Systems
1. Client Server Systems
The presentation, presentation logic, application logic, data
manipulation and data layers are distributed between client PCs
and one or more servers.
Accounts
Sales
Client Computers :
Any combination
of personal
Computers or
Workstations,
sometimes Design
connected
Construction
3
Distributed Systems
Client Server Systems cont..
Clients may be thin or flat
Almost all PCs

Acts only as
a terminal
e.g. Windows terminal
4
Distributed Systems
2. File server Architecture
A LAN (Local area network) based solution

A server computer hosts only the data layer
All other layers are implemented on the client
PC.
Practical only for small database applications
shared by relatively few users
5
Distributed Systems
3. Network Computing Systems
Presentation and presentation logic layers are implemented in a client
side web browser
The presentation logic layer then connects to the application logic
layer that run on an application server,
Subsequently connects to the database server/s
6
Processing Types
1. Batch Processing
Data about many transactions is collected as a single file
which is then processed
The data entered is collected into files called batches.
Each file is processed as a batch of many transactions.
Super market-Batch processing 7

Processing Types
2. Online Processing
The data about a single transaction is

processed immediately.
ATM-Real time processing

8
CS-1st Year
Systems Analysis and Design
G.K.A. Dias
University of Colombo School of Computing 1

System Development Life Cycle (SDLC)
Problem Definition
System
Maintenance Analysis
System Testing System Design
System
Implementation
2
System Development Life Cycle (SDLC)
A systematic approach to software development
Composed of several phases,
Problem Definition - identifies and defines a need for the new
system
System Analysis - analyzes the information needs of the end
users
System Design - creates a blueprint for the design with the
necessary specifications for the hardware, software, people and
data resources
System Implementation- creates and programs the final system
System testing - evaluates the system's actual functionality in
relation to expected or intended functionality.
Maintenance keeping the system up to date with the changes in
the organization and ensuring it meets the goals of the
organization
3
Why we need a life cycle in systems
development?
to ease the process of building
a system
to build high quality systems that meets
customer expectations, within time and cost
estimates
to work effectively and efficiently in the
current and planned information technology
infrastructure
to avoid failures like unclear objectives, cost
overruns, and
to maintain cheaply and enhance cost effectively
4
Sequential or Waterfall development
approach
An approach to system analysis and design
Completes each phase one after another and only
once.
Problem Definition
Requirement Analysis
System Design
System Development
System Testing
Maintenance
1
Problem Definition
Provides a broad statement of user
Project requirements in users terms, or what
goals the users expect the system to do
project bounds are set during this

Project phase. Defines what part of the
bound system can be changed by the project
and what parts are to remain same.
Specify the resources to be made
Project available for the project (resource
limits limits).
2
System Analysis
The study of a business problem domain to
recommend improvements
Specify the business requirements and priorities
for the solution
Business area is studied and analyzed to gain
more information
Produces a statement of the system users
business requirements, expectations and
priorities for a solution to the business problem
3
System Analysis
how the current
system works and
what it does
Producing a detailed model of what the

new system will do and how it will work.
Producing a high-level
description of the system
4
System Design
The specification or construction of a technical, computer
based solution for the business requirements identified in a
system analysis
Initially explore alternative technical solutions
Develops the technical blueprints and specifications
Analysts Design
5
System Design
Things to be done:
Select equipment
Specify new programs or
changes to existing
programs
Specify new database or
changes to existing
database
produce detailed
procedures
Design
6
System Implementation
Individual system components are built and
tested
Data and tools are used to build the system
User interfaces are developed and tried by
users
Database is initialized with data
Analysts System
7
System testing
Test and evaluate results, and
the system ready to be delivered to the
user/client.
8
Maintenance
Eliminate errors in the system
during its working life.
Fixing any bugs and problem

found by users
Tune the system to any

variations in its working
environment
9
Problems with waterfall cycle
9 It has a rigid design

9 Inflexible
9 It has a top-down procedure
9 One phase must be completed before the
next phase starts
9 No phase can be repeated
9 Time consuming
10
Criticisms fall into the following
categories:
9 Real projects rarely follow the sequential flow

that the model proposes.
9 At the beginning of most projects there is often a

great deal of uncertainty about requirements and
goals, and it is therefore difficult for customers to
identify these criteria on a detailed level. The
model does not accommodate this natural
uncertainty very well.
11
Criticisms fall into the following
categories: cont
9 Assumptions made in the early phases no

longer hold
9 Some of the early work is incomplete
9 Something was overlooked or not completely

understood.
12
Modified Waterfall Model
Problem Definition
Requirement Analysis
System Design
Implementation
System Testing
Maintenance
13
Modified Waterfall Model
Allow some of the stages to overlap, such as the
requirements stage and the design stage
Make it possible to integrate feedback from one phase
to another
Incorporate prototyping.
Verification and validation are added.
Verification checks that the system is correct (building the
system right).
Validation checks that the system meets the users desires
(building the right system).
Progress is more difficult to track.
14
Iterative development approach
An approach to systems analysis and design
Completes the entire information system in
successive iterations
Each iteration does some
Analysis
design
Construction
Allows versions of usable information to be

delivered in regular and shorter time frames
15
Iterative development approach
Complete
problem
Iteration # 1
definition
Some Some Some
System System System
Analysis Design Implementation
Iteration # 2
More More More
Iteration # 3
Still more Still more Still more
Repeat until no additional

iterations needed 16
Underlying Principles for System
Development methodology
P1: Get the system users involved
A communication between system users, analysts,
designers, and builders
Minimizes miscommunication and
misunderstanding
Help to win acceptance of new ideas and
technological change
System
Involved Development
1
P2: Use a problem-solving approach.
# Study and understand the problem and its

context
# Define the requirement of a suitable solution.
# Identify candidate solutions that fulfill the

requirements and select the best solution.
# Design and/or implement the solution.
# Observe and evaluate the solutions impact,

and refine the solution accordingly.
2
P3: Establish phases and activities.
All methodologies prescribe phases and activities
The number and scope of phases and activities may
vary.
The Phases are
# Scope definition
# Problem analysis
# Requirement analysis
#Logical design
# Decision analysis
# Physical Design
# Construction &Testing
# Installation & Delivery 3
P4 : Document through out Development
An ongoing activity of recording facts and

specifications for a system for current and future
reference
Documentation enhances communications and

acceptance
Stimulates user involvement and reassures

management about progress
Reveals strengths and weaknesses of the system to

multiple stakeholders.
4
P5: Establish standards.
# Documentation # Quality
# Automated tools #Information Technology
5
P6 :Manage the process and Projects
Process Management
Ensures that an organizations chosen process or management

is used consistently on and across all projects
An ongoing activity
Documents
Teaches An organizations
Oversees the use of chosen methodology
Improves For system development
Concerned with
Phases
Activities
Deliverables
Quality Standards
6
P6 :Manage the process and Projects Cont.
Project Management
Process of
Scoping
Planning
Staffing
Organizing
Directing
Controlling a project
ensures that an information system is developed

at minimum cost,
within a specified time frame and
with acceptable quality.
7
P7:Justify systems as Capital Investments.
# Cost-effectiveness
Obtained by striking a balance between the

lifetime cost of Developing, Maintaining,
Operating an information system and the
benefits derived from that system IS
cost
measured by cost-benefit analysis
Performed throughout the system development
# Risk management
The process of identifying, evaluating,
and controlling, what might go wrong in a
project before it becomes a threat
Driven by risk analysis or assessment
8
P8:Dont be afraid to cancel or
revise scope.
# Cancel the project if it is no Cancel
longer feasible
# If project scope is to be
increased, reevaluate and adjust
the cost and schedule
# If the project budget and

schedule are frozen and not
sufficient to cover all project
objectives, reduce the scope.
9
P9:Divide and conquer.
# divide a system into subsystem
and components
--- Easily to conquer the problem

--- Easy to build a large problem
10
P10: Design systems for growth and change.
# the business, their need and priorities change over
time
# thus, information system that supports a business
must also change over time
# good methodologies should embrace the reality of
change
# the systems should be designed to accommodate
both growth and changing requirements
#the systems should be designed to scale up and
adapt to the business
11
Major components of system
development
Major
Methodology Components
Modeling Methods or Techniques

Tools
1
Methodology
A set of
Activities
Methods
Best practices
Deliverables
Automated tools
Used by stakeholders to
Develop Information systems
and
Continuously improve Software
2
Methodology
Provides the framework
Has a predefined set of steps
Ensures that systems are built in the most
effective way
e.g. SSADM, RUP
3
Methodology
Modeling Methods or Tools

Techniques
Rational Rose,
Class Diagram, Rational Suit
Use Case Diagrams etc.
Eg .Rational Unified Process
4
Methodology
Uses tools and modeling methods
Tools
Most Effective
Way of
Building
Methods
5
Methodology
Supported by Modeling Methods or Techniques
Techniques used to implement the Methodology.

Provides the descriptions of the business system
requirements from various view points.
6
Life Cycle vs. Methodology
The system development methodology

consists of several well-defined steps.
When following a design methodology,

a designer can select appropriate
modeling method related to each step.
7
A system development
life cycle divides the life of Conversion
an information system into

two major stages,
LIFE CYCLE STAGE LIFE CYCLE STAGE
Systems development
A System System Operation
(consists of system analysis, Development
Lifetime and
system design, system Process of a Maintenance
implementation and testing
phases)
using
System Development
System using
Information
Methodology Technology
and
Systems operation and Obsolescence
support (maintenance)
8
A system development methodology is
a very formal and precise system
development process that defines
a set of activities,
methods,
best practices,
deliverables,
and automated tools
9
Modeling Methods
A set of techniques used to implement a
Methodology
DataFlow Diagrams -
A process model
Depict the flow of data through a system and the work
performed by the system
Entity Relationship Diagrams

A data model
Depict data in terms of entities and relationships
described by the data
Consists of several notations
Different Views
of the System
Structure Charts etc.
10
Tools
Software systems
Assists analysts and designer to build
information systems
They will not replace Systems Analysts.
e.g. Easy Case, Rational Rose
11
Tools
General Aim :
Decrease the human effort required to develop the
software.
Increase the quality of software
Tools will support methodologies but will not replace

system analysts.
12
Information Systems
Development
System owners & system users initiate most
Information Systems Development projects
An undesirable situation or problem/s in the
organisation which hinders their progress or
achieving the desired goals may be one reason to
develop a new system
It could also be that a new opportunity has been
identified which would bring more benefits to the
organisation
1
Information Systems
Development
A new requirement that may be imposed on
the organisation by directives issued by
Government/Management/some other External
Influence
2
Scope Definition
This is the first stage/phase of an Information
Systems Development project
The purpose of the scope definition is twofold.
1. Is this problem/opportunity/directive worth looking
at?
2. If the above is worthwhile doing then identifying
the size and boundaries of the project, the project
vision, any constraints, the participants, budget &
the schedule
3
Scope Definition
Scope definition should include:
1. The scope of the project which may later
change during the development life cycle(Scope
is the boundaries of a project the areas of a
business that a project may or may not address)
Project scope can be easily defined using:
What type of data: e.g. For a sales
Information System customer data, product
data etc.
4
What are the business processes in the
system(customer management, order entry,
order fulfillment) etc.
What are the System interface with users,
locations & other systems (e.g. Customers,
Sales reps, Regional sales offices, Accounts
receivable etc.)
Perceived problems (as perceived mostly
by system users)
Opportunities (which would bring more
benefits to the organization)
5
Directives that triggered the project
(Government regulations or mergers)
2. Project worthiness (Is this project worth
doing? Feasibility studies)
3. Schedule & budget
4. Constraints budget limits, deadlines,
availability of human resources etc.
5. Communication of the project plan or
project proposal (Communication skills of
presenters are very important)
6
At this stage it is not necessary to spend a lot
of time preparing this document and modeling
or prototyping may not be required.
Refer to the Sample Problem Statement
Fig. 5 8 in Ref 1 p171.
7
Finding Problems to Solve
Requirements solve problems
E.g. A mother takes her young daughter to
the doctor because the child is ill. The first
thing the doctor tries to do is, identify the
problem.
The child has Are these the
problems?
an earache,
a fever,
a runny nose.
8
E.g. Cont
The mother has been giving the child pain medicine to
ease the pain,
But still the child is not well.
The mother is treating
the symptoms and Conclusion (Root
cause of the childs
NOT the real problem. symptoms) :
However, the doctor, AN EAR
INFECTION
analyze the symptoms further
examine the child
Make the conclusion
9
E.g. Cont
Problem is identified and analyzed,
Recommend a cure (solution)
An antibiotic can be prescribed
Determine constrains on the medicine that can prescribe.
How old is the child?
How much does she weigh?
Is the child allergic to any medications?
Can she swallow pills?
Once the constraints are known, a prescription can be generated.
Systems analysts use the same problem-solving process as

a doctor uses, but instead of diagnosing medical problems
they diagnose system problems.
10
Feasibility Study
Feasibility
The measure of how beneficial / practical an
information system will be to an organization
Should be measured through out the life-cycle
Feasibility Analysis
The process by which the feasibility is measured
An ongoing evaluation of feasibility at various
checkpoints in the life cycle
1
Feasibility Checkpoints in the
Software Development Life Cycle
Feasibility of a project can be changed

during the system development.
For reevaluate feasibility, there are

different checkpoints in the
development.
A project may be canceled, revised or

continued at any checkpoint, despite
whatever resources have been spent.
2
Feasibility Checkpoints
Systems Analysis Scope Definition

Checkpoint
Systems Analysis Problem

Analysis Checkpoint
Systems Design Decision Analysis
Checkpoint
3
Scope Definition Checkpoint
Measure of the urgency of the problem.
Find the first-cut estimate of development
costs.
Answer the question,
Do the problems warrant the cost of a detailed
study & analysis of the current system?
4
Problem Analysis Checkpoint
Occurs after a more detailed study
and problem analysis of the current
system
Can make a better estimate of the

development cost and benefits
Minimum Value of solving a problem = cost of problem
5
Decision Analysis Checkpoint
Represent major feasibility analysis activities
Charts one of many possible implementations as the target
Alternate solutions are defined in terms of,

Input/Output methods
Data storage methods
Hardware requirements
Software requirements
Processing methods
People implications
6
Decision Analysis Checkpoint
Range of options Evaluated by the analyst
Leave current system alone
Re-engineer the manual process
Enhance existing computer processes
Purchase packaged software
Design and construct a new computer-
based system
After defining these options, each option
should be analyzed.
7
Tests for Feasibility
Operational Feasibility
Cultural / Political Feasibility
Technical Feasibility
Schedule Feasibility
Economic Feasibility
Legal Feasibility
8
Operational feasibility.
A measure of how well a solution meets the identified
system requirements to solve the problem.
Take advantage of the opportunities identified during

the scope definition and problem analysis phases.
Will the solution fulfill the users requirements? To what

degree?
How will the solution change the users work
environment?
How do users feel about such a solution?
9
Cultural (or Political) Feasibility
A measure of how well the solution

will be accepted in a given
organizational climate
Deals with how the end users feel
about the proposed system.
Evaluates whether a system will
work in a given organizational
climate.
10
Technical feasibility.
A measure of the
Practicality of a technical solution
Availability of technical recourses and expertise
Addresses three major issues

Is the proposed technology or solution practical?
Do we currently possess the necessary technology
(Hardware/Personnel) ?
Do we possess the necessary technical expertise?
11
Schedule feasibility
A measure of how reasonable a project time
table is.
Can the solution be designed and implemented
within an acceptable time period?
how much time is available to build the new
system?
when it can be built ?
Mandatory / Desirable
deadlines.
12
Economic feasibility.
a measure of the cost-effectiveness of a project
Is the solution cost-effective?
Whether the solution will pay for itself?
How profitable the solution is?
Once the specific requirements and solutions

have been identified
Weight the costs and benefits of each alternative
(Cost benefit Analysis)
e.g. Personnel cost, Computer cost, Training, Software,

Tangible and Intangible benefits 13
Legal Feasibility
A measure of how well a solution can be implemented
within existing legal and contractual obligations.
understand potential legal and contractual ramifications

of the system
* copyright law
* non-disclosure clauses and non-compete clauses
* code ownership (if developed with outside
assistance) -- be VERY specific
* labor laws
* foreign trade, and labor regulations
* Financial & Accounting standards
* governmental constraints, and pending legislation
14
Cost Benefit Analysis
Determines the cost effectiveness of a project or
solution
The purpose of a cost/benefit analysis is to answer
questions such as:
- Is the project justified (because benefits outweigh
costs)?
- Can the project be done, within given cost constraints?
- What is the minimal cost to attain a certain system?
- What is the preferred alternative, among candidate
solutions?
1
How much will the system cost?
Two types of costs, costs associated with
Developing the system
Can be estimated from the outset of a project
Should be refined at the end of each phase
One time costs (will not recur after the project has
been completed
Operating a system
Can be estimated only after specific computer-
based solutions have been defined
Recur throughout the lifetime of the system
2
How much will the system cost?
System development Cost Categories
Personnel costs
Computer Usage
Training
Supply, duplication, and equipment costs
Cost of any new computer equipment and software
3
What benefits will the system
provide?
Benefits
increase profit
Decrease costs
Can be classified as
Tangible benefits a benefit that
can be easily quantified.
Intangible benefits a benefit that
is believed to be difficult or
impossible to quantify
4
Is the proposed system cost
effective
Cost effectiveness techniques

Payback Analysis
Return on Investment Analysis
Net present value Analysis
5
Payback Analysis
A technique for determining if and when an investment
will pay for itself
How long will it take (usually, in years) to pay back the
project, and accrued costs:
Total costs (initial + incremental) - Yearly return (or savings)
6
Return-on-Investment (ROI)
Analysis
A technique that compares the lifetime
profitability of alternative solutions
Lifetime benefits - Lifetime costs

Lifetime costs
7
Net Present value Analysis
Compares the annual discounted costs

and benefits of alternative solutions
Spreadsheets such as Excel, Lotus 1-2-3
can be used to calculate all these values
8
Feasibility Analysis of Candidate
systems
During the decision analysis phase of
system analysis,
Identifies candidate system solutions
Analyses the solution for feasibility
Can use two alternatives to compare and
contrast candidate system solutions
Candidate System Matrix Use A Matrix
Feasibility Analysis Matrix Format
1
Candidate Systems Matrix
Used to document similarities and
differences between candidate systems
Compare candidate systems
Offers no analysis
Columns represent candidate solutions
Rows represent characteristics that
differentiate the candidates
2
Example
Candidate 1 Candidate 2 Candidate 3
Name Name Name
Stakeholders
Knowledge
Processes
Communications
Template
3
Example
Name Name Name
Stakeholders
Identify how the
Knowledge
system will interact
Processes with people, and other
Communications systems
Template
4
Example
Name Name Name
Stakeholders
Identify how data stores
Knowledge be implemented,
Processes inputs will be captured,
Communicationsoutputs will be generated
Template
5
Example
Name Name Name
Stakeholders Identify How (manual)
Knowledge business process will
Processes be modified, how
computer processes
Communications will be implemented
Template
6
Example
Name Name Name
Stakeholders
Identify how
Knowledge processes and data
Processes will be distributed.
Communications
Template
7
Feasibility Analysis Matrix
Used to rank candidate systems

Columns represent candidate response
Rows correspond to the feasibility criteria
Cell contain the feasibility assessment notes
for each candidate
8
Feasibility Analysis Matrix
Weighting Candidate1 Candidate2 Candidate3
Description
Operational Feasibility
Cultural Feasibility
Technical Feasibility
Economic Feasibility
Schedule Feasibility
Legal Feasibility
Weighted Score
9
The System Proposal
A report / presentation of a recommended solution
Usually a formal written report or oral presentation
Intended for system owners and users
System owners
And
Formal written End Users
report
Oral presentation
1
Written Report
The most abused method used by analysts
Consists of
Primary Elements
Actual information
E.g. introduction, conclusion
Secondary Elements
Package the report
Reader can easily identify the report and its primary elements
Add a professional polish.
2
Secondary elements for a written
report
Letter of transmittal
Title page
Tables of contents
List of Figures, illustrations, and tables
Abstract or executive summary
(primary elements are presented in this
portion of the report)
Appendixes
3
Formal Presentation
A special meeting
Used to sell new ideas and gain approval for
new systems
Can be also used for
Sell a new system, sell new
ideas, sell change, head off
criticisms, address concerns,
verify conclusion, clarify facts
and report progress.
Problems at the end of Chapter 11 in Ref. 1
4
Requirements Analysis
Identifying Requirements
Correct systems can only be built if you know
exactly
what the
what the system user needs
must do
Systems Analyst
Therefore most important factor in building correct
systems is to first clearly define what the system
must do
For that we should have a better communication
between system users and the analyst.
1
Importance of Communication
- Analyst must ensure that no ambiguities arise,

during the discussions between various people
involved in the analysis phase
- Different jargon used by different people may cause
problems
- Reduce misunderstandings between the end-users
and developers
2
Example:
Ambiguous Requirement Statement
Identify the mode of transportation to transfer

a single individual from home to place of work
Management
Interpretation IT Interpretation User Interpretation
3
Disadvantages of not identifying
user requirements correctly
The system will exceed time schedules and cost
schedules
The user may not be satisfied with the system
requirements. Therefore, they may not use the
system
The cost of maintenance may be excessively high
The system may be unreliable and prone to errors
The reputation of the IT staff on the team will be
tarnished
4
Process of Requirements Discovery
Consists of
Problem discovery and analysis (already
discussed in Chapter 3)
Requirements discovery (the process and
techniques used by systems analysts to identify
or extract system problems and requirements
from the user community )
Documenting and analyzing requirements
Requirements management
5
Requirements Discovery
Can start to define requirements after

understanding the problem
Must use effective methods for gathering
information (Fact Finding)
After completing the process of fact finding
use various tools to document the
requirements
6
The process and techniques used by
systems analysts to
Identify System
Analyze Requirements
Understand
Works with
Systems
Analyst
Works
Systems Owner with
Systems User
7
System Requirements
Specify what the information system

must do, or what property / quality the
system must have
8
System Requirements
Functional Non functional Requirements

Requirements Specify a property / quality
Specify what the the system must have
information system
e.g. user friendliness,
must do
Security etc. Refer page 209
Ref1 table 6-1
9
System requirements can be gathered by

using discussions with users, about their
requirements
building systems that satisfy these requirements
10
System requirements should meet the following criteria
Consistent: not conflicting / ambiguous
Complete: describe all possible system inputs and
responses
Feasible: satisfied based on the available resources
and constraints
Required: truly needed and fulfill the purpose of the
system
Accurate: stated correctly
Traceable: directly map to the functions and
features of the system
Verifiable: defined so that they can be demonstrated
during testing.
11
Documenting and Analyzing
Requirements
Assemble or document the gathered

information / draft requirements in an
Organized
Understandable
Meaningful way.
Provide direction for the modeling techniques
12
Requirements
Documenting the draft requirements
Use various tools to draft the initial findings
Use cases: describe the system functions from the
external users perspective
Decision tables: document an organizations

complex business policies and decision making
rules
Requirement tables: document each specific

requirement.
13
Requirements
Analyzing Requirements
Fact finding activities produce requirements that
are in conflict with one another
Requirements analysis activity
Discover and resolve the problems with the
requirements
Reach agreement on any modifications to satisfy
the stakeholders
14
Requirements Management
Help to alleviate the many problems associated

with changing requirements
Emerging new requirements
Changing existing requirements
Encompasses
Policies
Procedures
Processes
Refer Page 215 Ref1
15
Fact Finding Techniques
Fact-Finding
A formal process
Uses techniques to collect / gather information about
System requirements
Problems
Preferences
Also known as Information gathering
Used across the entire development cycle
Extremely critical in the requirement analysis phase
1
Research and
site visits Observations of
Sampling of the work
Existing documents environment
Prototyping
Joint
requirements
Interviews
planning
Questionnaires
2
Fact Finding Ethics
Come across sensitive data

e.g. employee profile: salaries, performance
history, medical history, career plans etc.
Leaving sensitive documents in plain view on

the desks or publicly discuss sensitive data
could cause great harm to the organization
Therefore, analysts must take great care to
protect security and privacy of any facts
3
Sampling of existing Documentation
When you are studying an existing system, you can get
a good idea by studying existing
Documentation Forms Files
First document, that analyst should seek

out is the organizational chart
Should be analyzed to make sure that

they are relevant and up-to-date
4
Research and Site Visits
Thoroughly, research the problem domain.

Identify the material that are relevant and reliable
Internet Intranets Reference books

Computer trade
Journals
World Wide Web
Good sources of information
5
Observations of the work environment

Systems Analyst participates in or
watches a person perform activities to
learn about the system
Often used when
validity of data collected through other
methods is in question or
the complexity of certain aspects of the
system prevents a clear explanation by
the end users.
6
Advantages
Data gathered by observation can be highly reliable

Relatively inexpensive
Allows systems analyst to do work measurements
Systems analyst is able to see exactly what is being
done
7
I dont like being
watched
Disadvantages
People usually feel uncomfortable when being
watched.
Work being observed may not involve the level
of difficulty or volume normally experienced
during that time
Some tasks may not always be performed in the manner
in which they are observed by the system analyst. Etc
Refer page 218 Ref1 The Railroad Paradox
8
Questionnaires
Special purpose documents
Allow the analysts to collect information and
opinions from a large audience.
Advantages :
Most questionnaires can be answered quickly
Allow individuals to maintain anonymity
Relatively inexpensive way of gathering data.
Responses can be tabulated and analyzed
quickly etc.
1
Questionnaires
Disadvantages:
The number of respondents is often low
Mostly suited for closed questions
No guarantee that an individual will answer or
expand on all the questions
Good Questionnaires are difficult to prepare
No immediate opportunity to clarify a vague or
incomplete answer to any question.
2
Questionnaires
Types of Questionnaires
Free-format : A question is asked, and the

respondent records the answer in the space
provided after the question.
Fixed-format : contains questions that

require specific responses from individuals
3
Questionnaires
There are 3 types of fixed-format questions
1. multiple-choice questions: Given several
answers to select one. e.g. Yes, No type
2. rating questions: Given a statement and asked to
use supplied responses to state an opinion.
3. ranking questions: Given several possible answers
to be ranked in order of preference or experience
Refer Page 221-222 Ref1
4
Interviews
Most commonly used technique in analysis
Collects information from individuals face to face.
Must possess good human relations skills for
dealing effectively with different type of people
- Can be used to achieve any of the following goals:
* find facts * get the end-user involved
* verify facts * clarify facts
* generate enthusiasm * identify requirements
* solicit ideas and opinions.
5
n
tio

a
tiv
Mo
Interviews
Advantages
Gives the analyst an opportunity to motivate the
interviewee to respond freely and openly to
questions.
Allow the analyst to look for more feedback from
the interviewee.
Permit the analyst to ask
questions from each individual
etc.
New ideas may arise
6
Interviews
Disadvantages
Very time consuming. Therefore costly

approach
Success of interviews is highly dependent
on the systems analysts human relations
skill.
Interviews may be impractical due to the location of
interviewees etc.
7
Interviews
Types of Interviews
Unstructured interviews
conducted with only a general goal / subject in mind
contain only a few questions if any, specific ones
Interviewer counts on interviewee to provide a frame
work and direct the conversation
Structured interviews
interviewer has a specific set of questions to ask of
the interviewee
8
Interviews
Types of Interview Questions
Open-ended questions
Allows the interviewee to respond in any way
that seems appropriate
Closed-ended questions
Restrict answers to either specific choices or
short, direct responses
9
Interviews
How to conduct an Interview?
Select Interviewees
Interview the end users of the information system you
are studying.
A formal organizational chart will help you identify these
individuals and their responsibilities.
Always make an appointment with the interviewee.
Higher the management level of the interviewees, less
time should be spent.
1
Interviews
Prepare for the Interview
Prepare an interview guide - checklist of specific
questions interviewer will ask the interviewee
Avoid the type of questions such as:
Loaded questions e.g Do you need to include both of
these columns for this report?
Leading questions e.g. You are not going to use this
operator code, are you?
Biased questions e.g. How many codes do we need for
food classification in the inventory file? I think 20 should
cover it ? 2
Interviews
Prepare for the Interview
Interview question guidelines :
Use clear and concise language
Dont include your opinion as part of a question
Avoid long or complex questions
Avoid threatening questions
verify before you leave
The purpose of the interview is to investigate, not to evaluate or
criticize
3
Interviews
Conduct the Interview
The actual interview consist of three phases:
Interview Opening : Intended to influence or motivate the
interviewee to participate
Interview body : Obtain interviewees response to your list
of questions
Interview conclusion : Express your appreciation.
Important for maintaining good relationship and trust.
4
Prototyping
Building a small working model of the users

requirements or a proposed design for an information
system
Usually a design technique
Can also be used to perform fact-finding requirement

analysis (discovery prototyping)
Allows analyst to quickly create mock forms and

tables to simulate the implemented system.
5
Prototyping
Analyst will
develop
a model A repeat visit
following may then
an initial validate
analysis the model Agreement
with the user is reached Further
on the detailed
model data may be
gathered to
elaborate
the model
6
Prototyping
This iterative approach serves a number of purposes:
there is always a record of information gathered
to date
ensures correctness of the information as you
continually verify the results with the user
Analyst does not get too far ahead using wrong
assumptions
7
Prototyping
Advantages
Allow users and developers to experiment with the
software and develop with an understanding
Helps to determine feasibility and usefulness of the
system
Minimize the time spent for fact-finding and help
define more stable requirements.
8
Prototyping
Disadvantages
Developer may need to be trained in the
prototyping approach
Prototype can only simulate system functionality
and are incomplete in nature.
May extend the development schedule
Increase the development costs
9
Joint Requirement Planning (JRP)
Highly structured group meeting are

conducted to analyze problems and define
requirements.
JRP is a subset of a more comprehensive
joint application development or JAD
technique
10
JRP Participants
Sponsor
Serve as JRP champion. Single person in top
management who makes the final decision
Facilitator
Single individual who plays the role of the leader or
facilitator. Someone who has excellent
communication skills
11
JRP Participants
Users and Managers
Number of participants from the user and management.
Both users and managers are relied on to ensure that
their critical success factors are being addressed
Scribes
Those who are keeping responsible for keeping records
pertaining to everything discussed in the meeting.
System analysts frequently play this role
12
JRP Participants
IT Staff
IT personnel who primarily listen and
take notes regarding issues and
requirements. Usually consists of
members of the project team.
Refer page 229-234 Ref1

13
Document Flow Diagrams

Used to identify physical movement of
documents.
Or de r
Purc has e
Purch. Supplier
Dept. .
..
14

shows
where the document comes from,
where it goes to , and
what it is called.
e Or der
rc h a s Supplier
Purch. Pu
Dept. .
..
15

Used to examine the flow of documents within
the existing system.
Order Purch.
Invoice
Dept.
De
liv
Supplier
er
y
e
no
t
no
te
ry
Example:
e
liv
Purchasing
De
System Stores
16

Example:
Purchasing System
Order
Supplier Purch.
Invoice Dept.
De
liv ote
er n
y y
no Stores ver System
te i
el boundary
D
17

Maintenance
Example:
Purchasing System
Order
Supplier Purch.
Invoice Dept.
De
liv ote
er n
y no Stores er
y
System
te i v
el boundary
D
18
Advantages / Usefulness
Used to identify the documents in the system
Identify the flow of documents
To understand the workflow of the existing system
Used to define the system boundary
Used to draw Data Flow Diagrams after further
analyzing
19
Documentation
Documentation is both a communication tool and a

management tool.
It is a communication tool :
because it contains a repository of all work done to date and
makes it available to all persons working on related parts of a
large project.
Such a repository can prevent unnecessary repetitions when
someone leaves the project team.
Proper documentation ensures that all the information
developed about the system is always available to new
people joining the project.
20
Documentation
Documentation is also a management tool:

It supports management in two ways:
gives access to the latest work to all project personnel
and thus reduces the chance of work having to be
repeated.
is the only project deliverable, specially in the early

project phases, and thus serves to determine project
status and progress. Is also a part of the phase output.
21
Documentation
Requirement Definition Document
A formal document that communicates the
requirements of a proposed system to key
stakeholders
Serves as a contract for the systems project
Final deliverable of the requirements analysis phase
Also known as requirements statement, requirements

specification, and functional specification.
22
Documentation

Consists of
Functions and services the system should provide
Nonfunctional requirements (systems features,
characteristics, and attributes)
Constraints
Information about other systems with which the system must
interface
No standard format for the document
Refer page 214 Ref1 Figure 6-2 (Sample Requirements

Definition Outline)
23
Documentation

Readers of the document
System Owners and Users (to specify their
requirements and any changes that may arise)
Managers (to prepare project plans and

estimates)
Developers (to understand what is required and to

develop tests to validate the system)
24
Modeling Methods
How to simplify, present /

document a complex
problem?
The answer is just

Simple, use MODELS
Model : AN
P L
A pictorial representation O OR
FL
of reality. LE
MP
SA
1
Process Modeling
Introduction
Technique for organizing and documenting the structure
and flow of data through a systems process and the logic,
policies, and procedures to be implemented by a systems
process.
Consists of various types of process models.
2
Process Modeling
Models
Logical Models Physical Models

Other names: Other names:
~Essential model ~ Implementation Model
~Conceptual model ~ Technical model
~Business model
3
Logical Process Models
Show what a system is or does.
Implementation independent
depict the system independent of any technical
dependence
Illustrates the essence of the system
Used to Depict business and non technical
requirements
Used to document systems Process focus from the
systems owners and users perspective
Encourage creativity
Reduce the risk of missing business requirements
Allows better communication with end-users in non-
technical / less technical languages.
4
Physical Process Models
Show not only what a system is or does. But

also how the system is physically and
technically implemented.
Implementation dependent
Reflect technology choices and the limitations
of those technology choices
Used to Depict technical designs
5
Process Modeling
Program Structure Charts

Logic Flow Charts
Decision Tables, are some
examples for various types of process
models found in early software engineering
methods and programming.
Data Flow Diagram : Popular System

Analysis Process Model.
6
Data Flow Diagrams
Shows the flow of data through the system
and the processing performed by the system
Other words : bubble chart, transformation
graph, and process model
Some analysts draw a decomposition
diagram before DFD
There exist several competing symbol sets for
DFDs.
Gane and Sarson notation is widely popular
7
Elements in a DFD
(Gane and Sarson Symbols)
Purchasing Supplier
System
A Process An External Agent
Invoice Orders
A Data Flow A Data Store
8
Elements in a DFD
- A Process is work
performed by a system In
Process name response to incoming
data flows or conditions
A Processes or and it transforms
Work to be done
incoming data flow into
Represented by a outgoing data flow.
rounded rectangle
A Synonym is transform
9
Elements in a DFD
Represented An external agent is an

by a square outside person (e.g. supplier,
customer), organization unit
(e.g. other dept), system
External
Agent (other business systems),
or organization (e.g. Bank)
An External that interact with the system.
Agent Also called an external entity.
10
Elements in a DFD
Represented External Agents
by a square Provide the net inputs
into the system and receive
net outputs from the system
External
Agent being defined.
An External External
Agent external to the system
being analyzed or designed.
11
Elements in a DFD
A Data Store is an
Data store
inventory of data.
That is, stored data
A Data Store
intended for later use
Represented by
(data at rest). Also
the open-end box known as a file or
database.
12
Elements in a DFD
A Data Store
Data stores should describe things about which
the business wants to store data.
These include
Persons: Customer, Employee
Places: Building, Room, Campus
Objects: Book, Machine, Product
Events: Invoice, Order, Registration, Renewal
Concepts: Course, Fund, Stock
13
Elements in a DFD
Represent inputs or
Represented outputs, to or from the
by an arrow
processes.
The arrow head indicates
Data flow name the direction of data flow.
Label the arrows with the
A Data Flow name of the data that
moves through it.
Data in motion
14
The Context Data Flow Diagrams
External External
A diagram that shows the Agent Agent
system as a black box
and its main interfaces
with its environment.
External
Used to document the Agent Process
scope of the system
Also known as
environmental model.
External
Agent
15
Used to clarify and agree the scope of the
investigation
Shows the interfaces between the system
under investigation and the external agents with
which it communicates
Subject to constant change
Because the scope of any project is always
subject to change
16
Can be drawn without considering the

Document Flow Diagram
Need to identify
the data flows and
the external agents needed for the context
diagram
17
Think the system as a container
Distinguish the inside from the outside
Ignore the inner workings of the container
Find out the net inputs to the system
Business transactions a system must respond to
For each net input determine its source (External Agents)
Find out the net outputs from the system
Responses produced by the system
For each net output find the destination (External Agents)
Identify any external data stores,
Files or databases of other systems
18
Task 1
Identify all sources and recipients of

data to/from the system.
19
Task 2
Identify major data flows to and from the

System
20
Task 3
Convert each source or recipient into

external agents
Supplier
21
Task 4
Add the data flows between each external

agent and the process representing the
entire system.
Order Purchasing
Supplier
Invoice System
Delivery note
22
Data Flow Diagrams
Draw Context Diagram

Level 0 (Top Level) Data Flow Diagram
Level 1 Data Flow Diagram
Continue up to elementary functions
23
Bank Payment System
Consider a system in a bank whereby account
holders get their withdrawals effected.
Whenever an account holder wants to
withdraw some cash, he presents a cheque or
withdrawal slip.
The account is checked for the appropriate
balance.
If balance exists, the cash is paid and the
account is updated.
24
Context Diagram
Account
Holder With
A ck d
now rawal
ledg
eme
nt
C he Bank
que
/Wi
th
Payment
Slip drawa System
l
25
Decomposition
Is the act of breaking a system into its component

subsystems , processes and sub processes.
Top level function is then decomposed to its
component functions
26
Process Decomposition
Is an act of breaking a system into its component
subsystems, processes, and sub processes.
osit ion
0 p
UCSC System Decom
m
Diagra
1 2
Payroll sub system Registration sub System
1.1 2.1
Process 1.1.1 Process
Sub Process
1.1.1.1
1.2 2.2
1.1.2
Process Sub Process Process
1.1.1.2
27
Context Diagram
Wit
Ack hdr
now awa
Account ledg l
eme
Holder nt
Ch Bank
eq u
e /W
ithd Payment
Slip raw System
al
28
Top Level DFD Step 1
Withdr
Acknow awal
ledgem
ent Verify
Account A/C
Holder Balance
Cheq
ue/W Debit
ithdr
Slip aw al Withdrawal
29
Withdrawal Acknowledgement
Account
Holder Verify
A/C
Balance
Cheque/Withdrawal
Slip Debit
Withdrawal
30
Identify the Data Stores
Account Master
31
Identify the other data flows.

Get current balance
Verify Current Balance

Account Master
A/C
Balance
32

Transfer the verified details
Verify Verified details Debit

A/C Withdrawal
Balance
33

update new balance
Account Master New Debit

Balance Withdrawal
34
Top Level Diagram
Account
nt
Holder
e
1 Ve
dgem
ri fie
Verify dD
Ackn awal
eta
A/C
owle
ils
Balance Cu lan
r
Withd
Ba
rre ce
nt
Cheque/Withdrawal
Slip
w ce 2
e
N an
a l Debit
Account B Withdrawal
Holder Account Master
35
Illegal Data Flows
Illegal data flows Corrected data flows
A process is
needed to
E1
8 E2 E1
Exchange data
Flows between
External
agents
E2
A process is
E1 88 D1 E1
needed to
Update / use
A data
store
D1
36
Illegal Data Flows
Illegal data flows Corrected data flows
A process is
8
needed to
E1 D1 E1
D1 present data
From a
data store
A process is
needed to
move data
D1
8 D2 D1 From one
Store to
another
D2
37
Another Common error
Process 1
8
No data flow should ever go unnamed
38
CASE STUDY
Library System
1
Library System
Library supports
Lending
Cataloging
Registration of Members
and Books
Reservation
Inquiries
Correspondence
All activities are done manually

2
Library System
To Analyze and Design a Library System
What are the Documents in the system?
Study the physical movements of documents
3
Library System
Documents in the system

Application form
Student Id
Membership card
Reminders
Borrowing slips etc.
Reservation ready notice
4
Library System
Identify the physical movements of documents.
Document Flow Diagram
Modeling method or technique used to illustrate
movements of documents.
on
Membership applicati Librarian
Student
.
..
5
Converting Document Flow
Diagrams to DFDs
What process generates this document flow?

What process receives this document ?
Is the document stored by a process?
Where is the document stored?
Is the document created from stored data?
6
Document Flow Diagrams for the
Library System
Student
Member
form ration
Member
Mem
t car d
er
egist
Me
d
. Ca
in
m
m
p
Re S l i
n
rd+
ent r
ber
Stude
i ne n e
slip
F f i
car
Stud
tt l
e
d
S
Library New member
details Admin.
System boundary
7
Data Flow Diagrams (DFDs)
DFDs handle transformation from physical

document to logical data
Advances in technology mean that electronic means
are increasingly supplementing the paper based
documents.
8
Context Diagram
Member
Me r
m. de
t tle
Member Ca in Se ine
rd+ m f
Sl ne
R e
sli
Fi
ip
Me p
mb
er
c ard Library
System
Admin. New er
emb
m ails
Det
9
Top Level Diagram
Member
e r
d
in e
Member Me R em if n
tle
ip
m t
Sl
be
rc Se
ne
M ar
Fi
em d
.C
ar
d+ Lending Returning
sl
ip
Member ry
r a
Admin.
Registration Lib em
me m ber y s t
New S
Details
10
Top Level Diagram
Member Member
Me
m.
Ca
Se
rd
+s
ttl
lip
Memb
e
fin
Fi
e
ne
er car
Sl
em
Lending
ip
in
d
d
er
Returning
Member New member
Registration Details Admin.
11
Data Stores
Mem. Registration
Borrowing Details
Book Details
12
Top Level Diagram
Settle fine
Member Fine Slip
Returning
Reminder
Me return details
Book details
m. Borrowing
C
+sl ard
Mem
ip details
card
Lending Borrowing Details

ber
Boo
k deta
New member details ils
Member member Mem. Registration Book Details
Registration details
New member
Admin.
Details
13
Documenting Elements in DFD
Element name is not enough.

More important for processes
A(int w){
You need to convert a=a-w;
these into programs }
Debit
Withdrawal
14
The Functional Decomposition
Diagram
Shows the top-down functional decomposition /
the structure of the system
Break the system into its component
subsystems , processes and sub processes
Top level function is then decomposed to its
component functions
Provides an outline for drawing the data flow
diagrams
15
The Functional Decomposition
Diagram
Context
diagram
The System
Decomposition
diagram The System
Function1 Function2 Function n
Event1 Event2 Event3 Event4 Event5 Event n-

n-1 Event n
16
Event Diagram
A data flow diagram that depicts the context
for a single event
Shows the inputs, outputs, and data store
interactions for the event.
Users are not overwhelmed by the overall size
of the system
A powerful communication tool between users
and technical professionals
17
Event Diagram
Decomposition
The System
diagram
Function1 Function2 Function n
Event1 Event2 Event3 Event4 Event5 Event n-

n-1 Event n
Event1 Event5 Eventn
Event diagrams
18
Event Diagram
For each event, illustrate the following
The inputs and their sources
Sources are shown as external agents
The data structure for each input should be recorded in
the repository
The outputs and their destination
Destinations are depicted as external agents
The data structure for each output should be recorded
in the repository
Any data stores from which records must be
read
Any data stores from which records must be
created, deleted, or updated
19
Process Descriptions
Structured English
Decision Table
Decision Tree
Eg. A Process that has to determine whether

a customer is to be given credit
20
Structured English
A language and syntax, based on the

relative strengths of structured programming
and natural English, for specifying the
underlying logic of elementary processes on
process models.
21
Structured English
IF credit limit exceeded

THEN
IF Customer has bad payment history
THEN refuse credit
ELSE
IF purchase above Rs.10000/=
THEN refuse credit
ELSE refer to manager
ELSE allow credit
22
Decision Tree
A graph or model of decisions and their possible
consequences, including chance event outcomes, resource
costs, and utility.
Purchase
Good payment above Rs
History 10000/= Refuse credit
Credit limit
exceeded Purchase below
Rs.10000/= Refer to
Manager
Bad payment Refuse credit
Credit limit history
not exceeded Allow credit
23
Decision Table
A tabular form of representation that

specifies a set of conditions and their
corresponding actions
Very useful for specifying complex policies
and decision making rules
24
Decision Table
Y-TRUE
N-NOT TRUE
X-TAKE ACTION
Credit limit exceeded Y Y Y Y N N N N

n
Good payment history Y Y N N Y Y N N

itio
nd
Purchase above Y N Y N Y N Y N
Co
Rs.10000/=
Allow Credit X X X X
n
tio
Refuse X X X
Ac
Refer Manager X
25
Data Modeling
A technique for defining business requirements for a
database
Also known as database modeling
There are several notations
Actual model is called an ERD Entity Relationship
Diagram
Shows data in terms of the entities and relationships
described by the data.
There exist several notations for an ERD
Martin notation is widely used.
1
Data Modeling

Shows data in terms of the entities and relationships
described by data.
Entities
An entity is something about which the business needs
to store data.
Synonyms entity type and entity class
2
Data Modeling
Entity: is a class of
Persons Places Objects Events Concepts

(Customer, (Building, (Book, (Flight, (Account,
Employee) Room) Product) Invoice) Fund)
about which we need to capture and store data.

3
Data Modeling
Entity Instance
An entity instance is a single occurrence
of an entity. Every entity must have an identifier
or key to uniquely identify each instance.
4
Data Modeling
Symbol:
Consider Martin notations.
EMPLOYEE DEPARTMENT
The named rounded rectangle represent

the entity.
A line represent the relationship.
5
Data Modeling
Attribute:
is a descriptive property or characteristics
of an entity. Sometimes called as element,
property, or field.
6
Data Modeling
A key is an attribute, or group of

attributes that assumes a unique
EMPLOYEE
NIC_NO value for each entity instance. It is
Name sometimes called an identifier.
Address
Age
.
.
.
This person can be
identified using his
ID number.
7
Data Modeling
Compound Attribute is one that actually consist of

other attributes.
Synonyms- composite attribute, concatenated attribute
Example : Address Street Address
Postal Code
Student
Country
name
Last Name City
First Name
Middle Name
8
Data Modeling
The values for each attribute are defined in terms of
three properties:
1. Data type What type of data can be stored
in that attribute (Number, Date, Text etc).
2. Domain What values an attribute can
legitimately take on.
Refer to table 8-2 in pg 273 Ref1
3. Default Is the value that will be recorded if

not specified by the user.
9
Data Modeling
Relationships
Natural business association that exists between

one or more entities
E.g.. A Current Student is enrolled in one or more

curricula
STUDENT is enrolled in CURRICULA
10
Data Modeling
Cardinality
Defines the minimum and maximum number of
occurrences of one entity that may be related to a single
occurrences of the other entity.
Exactly one
or
11
Data Modeling
Cardinality
Zero or one
I might be
married or not
Zero, one or
more I may have one,
some friends or
none
12
Data Modeling
Cardinality
I have to work at
One or more least in one, or
more projects.
More than one

I am working on
many projects.
13
Data Modeling
Degree
Number of entities that participate in the relationship
Degree =1
Recursive Relationship Relationship that exists
between different instances of the same entity.
Supervise
EMPLOYEE
14
Data Modeling
Degree
Degree =2
Binary Relationship - When two different entities

participates in a relationship
EMPLOYEE Works DEPARTMENT
15
Data Modeling
Degree
PROJECT EMPLOYEE
Degree =3 requires Is given

Ternary or 3-ary Relationship -
ASSIGNMENT
When more than two different
entities participates in a
relationship. offers
LOCATION
16
Synchronization of System Models
Data and process models represent different views
of the same system
These views are interrelated
Thus, modelers need to synchronize the different
views to ensure consistency and the completeness
of the total system specification.
Synchronization is the process of

maintaining consistency between
the different types of models
17
Object Modeling
A technique for identifying objects within the
systems environment and identifying the
relationships between those objects.
Object Modeling techniques prescribe the use

of methodologies and diagramming notations
that are completely different from the ones
used for data modeling and process modeling.
18
Object Modeling Methods
In the late 80s and early 90s

Booch Method Grady Booch
Object Modeling Technique (OMT) James Rumbaugh
Object-Oriented Software Engineering Ivar Jacobson
To avoid problems of having many different

methods, In 1997,
Unified Modeling Language (UML) - Grady Booch,
James Rumbaugh, Ivar Jacobson
19
System Concepts for
Object Modeling
Objects
Something that is or is capable of being seen,
touched, or otherwise sensed and about which
users store data and associate behavior
Types of objects
Person e.g. employee, customer, instructor, student
Place e.g. warehouse, building, room, office
Thing e.g. product, vehicle, computer, videotape
Event e.g. an order, payment, invoice, application
Sensual e.g. phone call, meeting
20
System Concepts for
Object Modeling
Attributes
The data that represents characteristics of
interest about an object
e.g. Object : Customer
Attributes : Customer no, first name, last
name, home address, work address, contact
no,etc.
21
System Concepts for
Object Modeling
Object instance
Each specific person, place, thing, or event, as
well as the values for the attributes of that
object.
Sometimes referred to as an Object.
Drawn using a rectangle with the name of the
object instance
The name consists of the attribute that
uniquely identifies it, followed by a colon and
then the name of the class in which the object
has been categorized.
22
System Concepts for
Object Modeling
Object instance
e.g. A CUSTOMER Object Instance
001:Customer
001:Customer
OR customerNo =001
lastName = Perera
firstName = Ann
Object name homePhoneNo = 0112123456
city = Colombo
is underlined
and centered
23
System Concepts for
Object Modeling
Behavior
The set of things that an object can do and that
correspond to functions that act on the objects
data or attributes.
Also known as a method, operation or service
e.g. Object : Door
behavior : open, shut, lock or unlock
24
System Concepts for
Object Modeling
Encapsulation
Packaging of several items together into one unit
(both attributes and behavior of the object)
The only way to access or change an objects
attribute is through that objects specific
behavior.
Objects encapsulates what they do.
That is, they hide the inner workings of their operations
from the outside world
and from other objects
25
System Concepts for
Object Modeling
Encapsulation
When an object carries out its operations,
those operations are hidden.
E.g. When most people watch a television show,
- they usually dont know or care about the complex
electronics that sit in back of the TV screen
- or the operations that are happening.
The TV hides
its operations
from the
person
watching it.
26
System Concepts for
Object Modeling
Class name
Object class
A set of object instances
that share the same Book
attributes and behaviors. -ISBN
Also referred to as a class. -title
e.g. UML notation for the -copyrightDate

object class BOOK -edition
+open()
+close()
Attributes of
the class
Behaviors
27
System Concepts for
Object Modeling
An Object instance
e.g.
0-07-231539-3 : Book 0-09-341234-5 : Book
ISBN = 0-07-231539-3 ISBN = 0-09-341234-5

title = Systems Analysis title = Programming in C++
copyrightDate = 2001 copyrightDate = 2006
edition = 5th edition = 7th
28
System Concepts for
Object Modeling
Inheritance
The concept wherein methods and/or attributes
defined in an object class can be inherited or reused
by another object class.
e.g. some individuals in the room might be classified
as STUDENTS and TEACHERS.
Thus, STUDENT and TEACHER object classes are
members of the object class PERSON
29
System Concepts for
Object Modeling
Inheritance
e.g. Cont
Person Class
Student Class Teacher Class
Student A Student B Teacher A Teacher B
30
System Concepts for
Object Modeling
Generalization / Specialization
A technique wherein the attributes and behaviors
that are common to several types of object classes
are grouped / abstracted into their own class
called a super type.
The attributes and methods of the supertype

object class are then inherited by those object
classes (subtype)
Sometimes abbreviated as gen/spec.
31
System Concepts for
Object Modeling
Specialization
Student
Generalization
GPA
Person Classification firstName
firstName lastName
enroll
lastName displayGPA birthdate
Inheritable
birthdate
Attributes
+ gender
gender
And walk
walk Teacher
behavior jump
jump rank
talk talk
sleep sleep
lecture
32
System Concepts for
Object Modeling
Generalization / Specialization
Person
Vehicle
Bus Car Truck

Student Teacher
* Specialized classes inherits from the parent class
33
System Concepts for
Object Modeling
Object Class Relationships
A natural business association that exists
between one or more objects and classes
e.g. You interact with a text book by reading it,
with a telephone by using it,
People interact with each other by
communicating with them.
34
System Concepts for
Object Modeling
Object / Class Association
When you turn on your TV, in object oriented
terms, you are in an association with your TV.
An association is unidirectional (one way) or bi-
directional (two way).
eg. is married to
Some times an object might be associated with
another in more than one way.
Gihan is a co-worker of Damith
Gihan is a friend of Damith
35
System Concepts for
Object Modeling
Object / Class Association
e.g.
A CUSTOMER PLACES zero or more ORDERS
An ORDER IS PLACED BY one and only one
CUSTOMER
Places 0..*
Customer Order
Represent the
relationship
between the classes 36
System Concepts for
Object Modeling
Multiplicity
The minimum and maximum number of occurrences of
one object class for a single occurrence of the related
object class.
e.g. Exactly one -> 1 or leave blank
Zero or 1 -> 0..1
Zero or more -> 0..* or *
1 or more -> 1..*
Specific range -> 7..9
Refer Figure 10-5 pg 377 Ref1 for more details
37
System Concepts for
Object Modeling
Aggregation
A relationship in which one larger whole class
contains one or more smaller parts classes.
Conversely, a smaller part class is part of a
whole larger class.
e.g.
A club a club is made up of several club
members
A computer a computer contains a case, CPU,
motherboard, power supply etc.
38
System Concepts for
Object Modeling
Aggregation
some more examples
0..* 0..*
Glider Plane Engine
UML notation
0..* 12..18
Team Player
Whole object Part Objects
39
System Concepts for
Object Modeling
Composition
An aggregation relationship in which the
whole is responsible for the creation and
destruction of its parts.
If the whole were to die, the part would die
with it.
A stronger form of aggregation.
The relationship between club and club member
would not be composition, because members
have a life out-side the club and can, belong to
multiple clubs.
40
System Concepts for
Object Modeling
Composition
Drawn with a filled diamond.
1
School 1..* Department
Each part can belong to only one whole,

therefore, multiplicity needs to be specified only one
for the part
Components will live and die with the whole object
41
System Concepts for
Object Modeling
Polymorphism
Literally meaning many forms, the concept that
different objects can respond to the same
message in different ways.
e.g. Consider the WINDOW and DOOR objects
Behavior : Close Behavior : Close
Slides downwards Swings shut
Both have the common behavior

But the way it has been carried
Out differs from one another
42
Systems Design
Produces a design specification for the new system.

Also known as physical design.
Design inputs, outputs, files, databases and other
computer based components
Analysis Design
Systems Design
Systems analysis - emphasize on the business

problem
Systems design - emphasize on the technical or
implementation concerns of the system.
Task1
Task2
Systems Design Approaches
Modern structured design

Information engineering
Prototyping
JAD
RAD
Object-oriented design
Modern Structured Design
Process A11
Process A1
is a process-oriented
Process A
technique for breaking up Process A2 Process A12
a large program into a
hierarchy of modules Process A3
Process A13
Process A4
result- in a computer
program that is easier to synonyms are top-down
implement and maintain program design and
(change). structured program
Design.
A system design technique that decomposes
the systems processes into manageable
components / modules that have the following
properties
Modules should be highly cohesive (each module
should accomplish one and only one function)
Modules
- should be loosely coupled (modules should
be minimally dependent on one another)
Modules should be adaptable (It should be easy to
incorporate changes)
Modules should be understandable
Structure Chart
The software model derived from structured

design
It is derived by studying the flow of data
through the program.
Structure Chart
1.2
Calculate
s io n Sales Total Sa
le ct
Sa nsa To les
a Sales ta
Tr l
Sales Total
Transaction
1.2.1 1.2.2 1.2.3
Get Sales Adds to Output
Transaction Total Total
Structure Chart
Parameter Passing
-The calling module passes a set of values to the called
module and receives a set of values in return. These values
are passed as parameter values
eg. A value of sales transaction is passed from module Get

Sales transaction to module Calculate Sales Total
Module Calculate Sales Total then passes the value of sales
transaction to module Add to Total and get a value of sales total
in return
The value of sales total is then passed from module
Calculate Sales Total to module output total
Structure Chart
Execution Sequence
By convention, modules are executed from left to right
in each level.
Thus in the given example, module Get Sales
Transaction is called before module Adds-To-Total.
Module Output Total is the last module to be called.
Certain conventions are also used to represent
decisions and repetition.
Decisions occur whenever a calling module has to
decide to call only one of a number of modules.
Structure Chart
Decisions are modeled by a diamond symbol.
Payment
Or
Cash Cheque
@ Payment pays either cash or Cheque

Structure Chart
Repetition occurs when some modules are

called repetitively by the calling module.
Repetition is modeled by a looping arrow

Structure Chart is a
technique used in Modern
Structured Design
The objective of structured

design is to produce a good
design.
Information Engineering (IE)
Model driven and data centered, but PROCESS-

sensitive technique for planning, analyzing, and
designing information systems.
Primary tool of information engineering is a data
model diagram (ERD).
Involves conducting a business area
requirements analysis from which information
system applications are carved out and
prioritized.
Prototyping
Prototyping:
The prototyping approach is an iterative process
involving a close working relationship between the
designer and the users.
Prototyping
Key Benefits:
Prototyping encourages and requires active end-

user participation.
Iteration and change are a natural consequence of
systems development - that is end-users tend to
change their minds.
Prototyping endorses the philosophy that end-users
will not know what they want until they see it.
Prototyping
Key Benefits:
Prototypes are an active, model that end-users can
see, touch, feel, and experience.
An approved prototype is a working equivalent to a
paper design specification, with one exception --
errors can be detected much earlier.
Prototyping can increase creativity because it
allows for quicker user feedback, which can lead to
better solutions.
Prototyping accelerates several phases of the life
cycle, possibly bypassing the programmer.
Prototyping
Disadvantages:
Prototyping encourages ill-advised

shortcuts through the life cycle.
Joint Application Development (JAD)
JAD emphasize
participative
development
among
system owners, JAD
users,
designers, and
builders.
Joint Application Development (JAD)
JAD sessions for systems design,

systems designer - role of facilitator
for possibly several full-day workshops
intended to address different design
issues and deliverables.
Rapid Application Development (RAD)
RAD is the merger of various structured techniques

(especially the data-driven information engineering)
with prototyping techniques and joint application
development techniques to accelerate systems
development.
Rapid Application Development (RAD)
RAD calls for the interactive use of structured and

prototyping to define the users requirements and design
the final system.
Using structured techniques, the developer first builds the

preliminary data and process models of the business
requirements.
Prototypes then help the analyst and users to verify those

requirements and to formally refine the data and process
models.
Object Oriented Design (OOD)
The newest design strategy

Used to refine the object requirements
definitions identified earlier during analysis and
to define design-specific objects
e.g. based on a design implementation decision,
during OOD the designer may need to revise the
data or process characteristics for an object that
was defined during systems analysis
System Design Tasks
Design the Application Architecture

Design the System Database (s)
Design the System Interface
Package Design Specifications
Update the Project Plan
Application Architecture and Modeling
Application Architecture
9 An application architecture defines the

technologies to be used by (and used to build) one,
more, or all information systems in terms of its data,
process, interface and how these components interact
across a network.
9 It serves as an outline or blueprint for detailed
design and implementation.
9Primary tool : Physical data flow diagram
Physical Data Flow Diagrams (PDFD)
Process
Model the technical and
human decisions to be
ID (optional)
implemented as part of an
information system. Action verb
+
They communicate Noun or Object
technical choices and other Phrase
design decisions to those
Implementation
who will actually construct
and implement the system.
Physical Data Flow Diagrams
(PDFD)
Physical Process
A physical process is either a processor,

such as a computer or person, or a
technical implementation of specific work
to be performed, such as a computer
program or manual process.
(PDFD)
Characteristics of Physical DFDs
# Logical processes may be assigned to physical
processors such as PCs, servers, mainframes,
people, or devices in a network. A physical DFD
would model that network structure.
# Each logical process must be implemented as one
or more physical processes as some logical
processes must be split into multiple physical
processes.
(PDFD)
Physical Data Flows
Represents any of the following:
Planned implementation of an input to / output from
a physical process.
A database command or action (create, read,
update, or delete)
Import of data from or the export of data to another
information system across a network.
Flow of data between two modules within the same
program.
(PDFD)
Physical Data Flows
Physical Data Flow Representation
Implementation method:
Data flow name
Refer Figure 13-2 pg 482 Ref1
OR to learn how to apply one of
Data flow name these naming conventions in
(Implementation method) physical DFDs
eg. PRINTOUT:
Salary Equity Report
(PDFD)
Physical External Agents
No change from logical DFD to Physical

DFD.
External agents were classified during
systems analysis as outside the scope of the
systems and therefore, not subject to change.
Only a change in requirements can initiate a
change in external agents
(PDFD)
Physical Data Stores
Represents the implementation of one of the
following:
A database
A table in a database
A file (computer/non computerized)
A tape / Media backup of anything important
Temporary file needed by a program (e.g. Tax
Tables)
(PDFD)
Representation of physical data stores
ID Implementation Method :
(opt) Data Store Name
OR
ID Data Store Name

(opt) (Implementation Method)
(PDFD)
Logical Data store Purchase Orders
Implementation : A table in a database
Physical Data store

MS Access:
Purchase Orders
Design the System Database
Databases are a shared resource.

A database should be adaptable to future
requirements and expansion.
Issues to be addressed during database design
include
how programs will access the data
Programming data structures and their impact on
performance and flexibility
Internal controls to ensure proper security and disaster
recovery technique, in case data is lost or destroyed.
Record size and storage volume requirement.
Design the System Database
Purpose is to prepare technical design specification for
the database.
Participants
Systems analyst participate in database modeling
System designers complete the database design
Data administrator recognize that the new system most
likely use s some portion of an existing database
System builders build a prototype database for the
project
Inputs : The application architecture and
Distributed analysis decisions
Output / deliverable : Database schema
Designer can work closely with system user to
develop input, output and dialogue specifications.
The precise format and layout of the outputs must be
specified.
Internal controllers must be specified to ensure that
the outputs are not lost, misrouted, misused, or
incomplete.
the data capture methods for the inputs should be
designed.
Editing controllers must be designed to ensure the
accuracy of input data.
For dialogue design the designer must consider

Terminal familiarity
Possible errors and misunderstandings that the end
user may have or may encounter
The need for additional instructions or help at certain
points
The screen content and layout
Participants
System users
System designers
System builders
Package Design Specifications
Package all the specifications

from the previous design tasks
into a set of specifications.
Guide the computer
programmers activities.
Inputs : database, input, and
output specifications
Update the Project Plan
Reevaluate project feasibility & update project plan

Project manager facilitates the task
Analysts and owners should consider the possibility
that, based on the completed design work, the overall
project schedule, cost estimates, and other estimates
may need to be adjusted.
The deliverable : updated project plan
Should include a detailed plan for the construction phase
that should follow.
Information Technology Architecture
System analysts must continuously read
popular trade journals to stay abreast of the
latest technologies and techniques that will
keep their customers and their information
systems competitive.
The information system framework provides
one suitable framework for understanding IT
architecture.
Today information systems are
no longer monolithic, mainframe computer based
systems.
Built on some combination of networks (Distributed)
Centralized Systems
All the components are hosted by a central, multi user
system
User interact with the host computer via terminals
All of the actual processing and work is done on the host
computer
I am doing all I have all system
processing data
Databases Provide
interfaces
Distributed Systems
Components are distributed across multiple

locations and computer networks
Processing work load required to support
these components are distributed across
multiple computers on the net work.
More complicated and more difficult to
implement than centralized systems
Distributed Systems
Why use distributed systems?

Modern businesses are already distributed
Distributed computing moves information and
services closer to the customers
Consolidates the incredible power
More user friendly as they use the PC as the user
interface processor
PCs and network servers are much less expensive
than mainframes
Thus, there is a big trend towards distributed systems.
Distributed Systems
Disadvantages
Network data traffic can cause congestion
that actually slows performance.
Higher security risk due to more possible
access points for intruders and possible
communication with insecure systems.
Many centralized, legacy systems are gradually
being transformed into distributed information
systems
Distributed Systems
Architecture Layers
Presentation layer actual user interface which presents inputs
and outputs to the user
Presentation logic layer any processing that must be done to
generate the presentation. e.g. editing input data, formatting
output data
Application logic layer all the logic and processing required to
support the actual business application and rules. e.g. credit
checking, calculations, data analysis
Data manipulation layer commands and logic required to store
and retrieve data to and from the database
Data layer the actual stored data in the in a database
Distributed Systems
There are three types of distributed

system architectures
File server architecture
Client server architecture
Internet based architecture
Distributed Systems
Stored on the
DATA LAYER
File Server
DATA Executed on
MANIPULATION the Client
LAYER
FILE Executed on
SERVER APPLICATION
LOGIC LAYER the Client
SOLUTION
PRESENTATION Executed on
LOGIC LAYER the Client
PRESENTATION Displayed on
LAYER the Client
Distributed Systems
File server Architecture

A LAN (Local area network) based solution
LAN is a set of client computers connected over a
relatively short distance to one or more servers
A server computer hosts only the data layer
All other layers are implemented on the client
PC.
Practical only for small database applications
shared by relatively few users
Distributed Systems
File server Architecture
Disadvantages
Large amount of unnecessary data must be
moved between the client and the server
Reduce network and application performance
The client PC must be robust.
Data base integrity can be easily compromised
Distributed Systems
DISTRIBUTED
DISTRIBUTED DISTRIBUTED DATA &
PRESENTATION DATA APPLICATION
(2 TIER) (2 TIER) (2 TIER)
Stored on the Stored on the Stored on the

DATA LAYER Database Server Database Server Database Server
CLIENT / SERVER SOLUTION
DATA Executed on the Executed on the Executed on the

MANIPULATION Database Server Database Server Database Server
LAYER
APPLICATION Executed on the Executed on the Executed on the
LOGIC LAYER Server Client Application Server
PRESENTATION Executed on the Executed on the Executed on the

LOGIC LAYER Client Client Client
PRESENTATION Displayed on Displayed on Displayed on the

LAYER the Client the Client Client
Distributed Systems
Client Server Architecture

The presentation, presentation logic, application
logic, data manipulation and data layers are
distributed between client PCs and one or more
servers.
Client Computers :
Any combination of personal Computers
or Workstations, sometimes connected
Distributed Systems
Client/Server Architecture
Accounts
Sales
Design
Construction
Distributed Systems
Clients may be thin or flat
A personal that does a personal computer,

not have to be very notebook computer, or
powerful (acts as a work station that is
terminal) typically powerful
e.g. Remote desktop e.g. Almost all PCs
Distributed Systems
Server must be more powerful and capable than a
server in the file server model
Several types of servers may be used in a
client/server solution.
Database Server : A server that hosts one or more
databases.
Transaction Server : a server that hosts services which
ensure that all database updates for a transaction succeed
or fail as a whole.
Distributed Systems
Application Server : A server that hosts

application logic and services for an information
system
Messaging or Groupware Server : A server that
hosts services for groupware.
Web Server : A server that hosts internet or
intranet web sites
Distributed Systems
Client / Server Distributed Presentation

A client/server system in which presentation and
presentation logic are shifted from the server to reside on
the client
Client / Server Distributed Data

A client/server system in which the data and data
manipulation layers are placed on servers and other layers
are placed on clients. Also called two-tiered client/server
computing.
Distributed Systems
Client / Server Distributed Data and Application

client/server system in which the data and data
manipulation layers are placed on their own server (s).
Application logic is placed on its own server
Presentation logic and Presentation are placed on the
clients.
Also, called three-tiered, or n-tiered, client/server
computing
Distributed Systems
Stored on the
DATA LAYER
Database Server
DATA Executed on the

MANIPULATION Database Server
LAYER
NETWORK APPLICATION Executed on the
COMPUTING LOGIC LAYER Application Server
SOLUTION
PRESENTATION Distributed from
LOGIC LAYER the Web Server
PRESENTATION Displayed on the

LAYER Client
Distributed Systems
Internet-based Architecture
Presentation and presentation logic
layers are implemented in a client side
web browser
The presentation logic layer then
connects to the application logic layer
that run on an application server,
Subsequently connects to the database
server/s
Data Architectures
Client-server and network computing

made it possible to distribute data without
loss of control
Control is accomplished through
advances in distributed relational
database technology
Distributed Relational Database
Stores data in a tabular form

Each file is implemented as a table
Each field is a column in the table
Each record is a row in the table
Related records between two tables (e.g. CUSTOMER
and ORDER) are implemented by internally
duplicating columns in the two tables.
Distributes or duplicates tables to multiple

database servers located in important locations
Management System (RDBMS)
The software required to implement distributed

relational databases
Controls access to and maintenance of the
stored data in the relational format
Provides back-ups, recovery and security
Also called as client-server database
management systems
e.g. Oracle, SQL Server, Sybase
Management System (RDBMS)
Supports two types of data

Data partitioning : truly distributes rows and
columns to specific database servers with
little or no duplication between servers
Data replication : duplicates some or all
tables on more than one database server.
Data Architectures
For a given information system application the

data architecture must specify the RDBMS
technology and the degree to which data will
be partitioned or replicated.
One way to record these decisions is to record
them in a physical data store
For more information Refer pg 495 Ref1
Interface Architectures
Batch inputs or Outputs

Transactions are accumulated into batches for
periodic processing
Batch inputs (e.g. time cards) are processed to
update databases and produce appropriate
outputs (e.g. paychecks, generation of
invoices)
Refer pg 496 Ref1 for more information
Online inputs or Outputs

Provide for a more conversational dialogue
between the user and the computer
applications.
Provide immediate feedback in response to
transactions, problems, and inquiries.
Provide greater human interaction in decision
Remote batch
Combines the best aspects of batch
and online inputs and outputs.
Refer pg 497 Ref1 for more
information
Keyless Data Entry (and automatic identification)
Keying in data has always been a major source of
errors in computer inputs.
In batch systems, keying errors can be eliminated
through optical character reading (OCR) and optical
mark reading (OMR) technology
The real advance in keyless data entry are coming for
online systems in the form of auto-identification
systems. (e.g. bar-coding schemes)
Pen input
A pen-based operating system become more
widely available and used (e.g. Palm OS and
Microsofts Windows Mobile)
Uses this technology to for remote data
collection
Refer pg 498-499 Ref1 for more
information
Electronic Data interchange (EDI)

The standardized electronic flow of
business transactions or data between
businesses
information
Imaging and Document Interchange

The actual images of the forms and data
are transmitted and received.
Useful in applications in which the form
images or graphics are required
information
Middleware
Utility software that enables communication
between different processors in a system
May be built into the respective operating
system or added through purchased
middleware products
Process Architectures
The software development environment (SDE)
A language and tool kit for developing applications
One way to classify SDEs is according to the type of
client/server or network computing architectures they
support
SDEs for Centralized Computing and Distributed
Presentation
SDEs for Two-Tier Client/Server
SDEs for Multi-tier Client/Server
SDEs for Internet and Intranet Client/Server
Refer pg 500-502 Ref1 for more information
Project Management
Demand for Project managers in the Information

system community is strong.
Information system project managers come from
the ranks of experienced IS developers such as
systems analysts
Systems Analysts should be aware of Project
management processes, tools and techniques.
Project Management...
Project
A sequence of unique, complex, and
connected activities that have one goal
or purpose and that must be
completed by a specific time, within
budget, and according to specification
Project manager
The person responsible for
supervising a systems project
from initiation to conclusion.
Should possess a wide range of
technical, management,
leadership and communication Project
skills. Manager
It is the process of
Scoping Planning
Staffing
Directing
Organizing Controlling
the development of an acceptable system at a

minimum cost within a specified time frame.
Necessary to ensure that the project
Delivered on time
Resulting Delivered within Budget

Information
System
Acceptable to the customer
Customer
PM is a cross life cycle activity because it overlaps

all phases of any systems development
methodology.
A project is successful if
The resulting Information system is acceptable to
the customer
The system is delivered on time
The system is delivered within budget
The system development process had a minimal
impact on ongoing business operations.
Not all projects meet the above criteria, thus,
not all projects are successful
Causes of failed projects
Failure to establish upper-management commitment to the
project
Lack of organizations commitment to the system development
methodology
Taking shortcuts through or around the system development
methodology
Premature commitment to a fixed budget and schedule
Poor estimating techniques
Premature commitment to a fixed budget and schedule
Poor estimating techniques
Causes of failed projects
Over optimism
The mythical man-month
Inadequate people management skills
Failure to adapt to business change
Insufficient resources
Failure to manage to the plan
Major cause of project failure is that most project managers

were not educated or trained to be project managers.
Project Manager Competencies
Good project managers possess a core set of competencies.

Some of these can be taught in courses, books and workshops
Some come only with professional experience in the field
basic premises of project management competencies:
individuals cannot manage a process they have never
used
Managers must have an understanding of the business and
culture that provides a context for the project
Project Manager Competencies
Influence Competencies
Problem-Solving Self-Management
Competencies Competencies
Business Achievement People Management

Competencies Competencies
Refer Table 4-1 pg 123 Ref1 for more details
Project management functions
Scoping : scope defines the boundaries of the project. A
project manager must scope project expectations and
constraints in order to plan activities, estimate costs, and
manage expectations.
Planning : planning identifies the tasks required to complete
the project.
Estimating : each task that is required to complete the
project must be estimated. (e.g. how much time will be
required?, how much people will be needed? What skills will
be needed? How much will it cost? Can some of the tasks
overlap?...etc)
Scheduling : given the project plan, all project
activities should be scheduled.
Organizing : should make sure that members of
the project understand their own responsibilities
as well as their reporting.
Directing : once the project has begun the
project manager should direct the teams
activities
Controlling : need to monitor and report progress
against goals, schedule, and costs and need to
make appropriate adjustments when necessary.
Closing : good project managers assess success
and failures at the conclusion of the project. They
learn from mistakes and plan for continuous
improvement of the systems development process.
All these functions depend on ongoing interpersonal
communication among the project manager. The
team, and other managers.
Project Management Tools and Techniques
PERT chart
Gantt chart
A PERT chart is a graphical network model that depicts a
projects tasks and the relationships between those tasks.
Eg.
PERT stands for Project Evaluation and Review
Technique
Developed to make clear the interdependence between
project tasks before those tasks are scheduled.
Boxes represent project tasks
Content of the boxes can be adjusted to show various
project attributes such as schedule and actual start
and finished times.
Arrow indicates that one task is dependent on the start or
completion of another task.
Gantt Chart
The most commonly used project scheduling
and progress evaluation tool
a simple horizontal bar chart that depicts project
tasks against a calendar.
Each bar represents a named project task.
The tasks are listed vertically in the left-hand
column.
e.g.
Gantt
Chart
For more details : Ref1 p122 - 131

Gantt Chart
Advantages
Clearly show overlapping tasks
Tasks that can be performed at the same time
the bars can be shaded to clearly indicate
percentage completion and project progress
Shows which phases are ahead of and behind
schedule at a glance.
Simple
Easy to learn, read, prepare, and use
Gantt Vs. PERT

Gantt and PERT charts are not mutually
exclusive.
Gantt charts are more effective when seeking
to communicate schedule
PERT charts are more effective when you
want to study the relationships between tasks.
Used to help project managers plan projects,
develop schedules, develop budgets, monitor
progress and costs, generate reports, and
effective change.
Automated project management tools :
Nikus Project Manager
Artemis international solutions corporations 9000
Microsofts Project
Primaveras Project Planner and Project Manager
Automated tools and technology
In the not too distant past the

principle tools of the systems
analyst were paper, pencil,
and flowchart template.
Today entire suites of
automated tools have been
developed, marketed and
installed to assist systems
development teams
Benefits
Improved productivity through automation of
tasks
Improved quality because automated tools
check for completeness, consistency, and
contradictions
Better and more consistent documentation
because the tools make it easier to create and
assemble consistent, high-quality documentation
Benefits
Reduced lifetime maintenance because
of the aforementioned system quality
improvements combined with better
documentation
Methodologies that really work through
rule enforcement and built-in expertise
There are three classes of

automated tools for developers.
Computer-aided systems modeling
Application development
environment
Project and process managers
Computer-Assisted Systems
Engineering (CASE)
It is filling
Automatically
The use of automated
software tools that support
the drawing and analysis
of system models, detailed
descriptions and
associated specifications.
Some CASE tools also
provide prototyping and
code generation
capabilities.
Engineering (CASE)
It is the application of
information technology to
system development
activities, technique and
methodologies. Case tools
are programs that automate
or support phases of a
system development life
cycle.
Engineering (CASE)
CASE Repositories
A system developers database where
developers can store system models, detailed
descriptions and specifications, and other
products of system development.
A collection of facilities, for creating system
models and documentation
Also known as data dictionary and encyclopedia
Engineering (CASE)
CASE Facilities
To use the repository, the CASE tools provide
some combination of facilities
Diagramming tools: used to draw the system
models required or recommended in most
system development methodologies
Engineering (CASE)
CASE Facilities
Diagramming tools:
Include capabilities
to produce ERDs, DFDs etc.
to store the details internally
to change and redraw,
Eliminates an activity that analysts find both tedious
and undesirable.
Perform online syntactic checks and semantic checks
Engineering (CASE)
CASE Facilities
Dictionary tools: used to record,
delete, edit, and output detailed
documentation and specifications
Design tools: used to develop mock-
ups of system components such as
inputs and outputs
Engineering (CASE)
CASE Facilities
Quality management tools: analyze system
models, descriptions and specifications, and
designs for completeness, consistency, and
conformance to accepted rules of the
methodologies.
Engineering (CASE)
CASE Facilities
Documentation tools: used to assemble,
organize, and report on system models,
descriptions and specifications, and
prototypes that can be reviewed by system
owners, users, designers and builders.
Engineering (CASE)
CASE Facilities
Design and code generator tools:
automatically generate database
designs and application programs or
significant portions of those programs
Engineering (CASE)
CASE Facilities
Testing tools: simulate transactions and data
traffic, measure performance, and provide
configuration management of test plans and
test scripts.
Eg. Rational Team Test, Rational Purify,
Rational Visual PureCoverage
Engineering (CASE)
Forward and Reverse Engineering

Two distinct ways to develop system models.
Forward Engineering: a CASE tool capability that
can generate initial software or database code
directly from system models.
e.g. generate a program directly from a flow chart
Reverse Engineering: a CASE tool capability that
can automatically generate initial system
models from software or database code
e.g. generate a flow chart from an existing
program
Engineering (CASE)
Systems designed to automate the stages

of Systems Development.
Capable of bringing clear benefits to
Systems Development.
Engineering (CASE)
General Characteristics
Break down complexity
Decompose requirements and design into manageable
components
Presentable to several audiences
End users,
Contracting organization paying for the Software
development,
Developers
Engineering (CASE)
General Characteristics
Cheaper than building using
traditional methods
Verifiable
Maintainable
Graphically Oriented
Easy to understand a graphical illustration
Engineering (CASE)
Analyst/Designer Tool kit Deft

Automate Plus Easy CASE
CASE 2000 Oracle *CASE
Excelerator Designer 2000
Information Engineering OOTher
Workbench Rational Suit
TeamWork Together
Visible Analyst
Benefits of using CASE tools in
Systems Development
CASE tools improve

Quality
Productivity
The amount of interaction between
developers and users
However the Organizations must consider
Whether the features of CASE fit the methods they
use or
Whether they wish to modify their methods to
obtain CASE benefits.
Systems Development
Better documentation (mostly because the

tools make it easier to create and assemble
consistent, high-quality documentation)
Reduce lifetime maintenance (because of
the aforementioned system quality
improvements combined with better
documentation)
Reverse Engineering, Forward Engineering
support
Systems Development
Most Important Elements in the

Development Process
are
Skills and Capabilities of the

Systems Analysts.
Application Development
Environment (ADEs)
An integrated software development tool

Provides all the facilities necessary to
develop new application software with
maximum speed and quality.
Also known as integrated development
environment (IDE)
e.g. IBMs Websphere, Oracle's Developer,
Microsofts Visual Studio.NET etc
Environment (ADEs)
Provide a number of productivity and quality
management facilities
Programming language or interpreters:
help programmers quickly identify and solve
programming problems
Interface construction tools:
help programmers quickly build the user interfaces using
a component library
Middleware:
helps programmers integrate the software being
developed with various databases and computer
networks
Environment (ADEs)
Provide a number of productivity and

quality management facilities (cont.)
Testing tools:
used to build and execute test scripts
that can consistently and thoroughly
test software
Version control tools:
help multiple programmer teams
manage multiple versions of a program
Environment (ADEs)
Provide a number of productivity and

quality management facilities (cont.)
Help authoring tools:
used to write online help systems, user
manuals, and online training.
Repository links:
permit the ADE to integrate with CASE tool
products as well as other ADEs and
development tools.
Process and Project Management
Tools
CASE tools and ADEs support analysis, design
and construction of new information systems and
software
Process manager and project manager
application tools are intended to support cross
life-cycle activities.
Project management tools Microsofts project,
Nikus Open Workbench and Project Manager
Tools
Process manager application

An automated tool
Helps to document and manage a
methodology and routes, its deliverables,
and quality management standards.
Also known as methodware
Tools
Project manager application

An automated tool
Helps to
plan system development activities,
estimate and assign resources,
schedule activities and resources,
monitor progress against schedule and budget,
control and modify schedule and resources, and
report project progress.

System Analysis and Design

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

System Analysis and Design

Uploaded by

Copyright:

Available Formats

CS-1st Year

Systems Analysis and Design

University of Colombo School of Computing 1

By Jeffrey L Whitten & Lonnie

What is an information system?

Airline Reservations Keeping records Keeping records

Production HRM - Training Telephone Integration

People Interface Data Information Network Process

Computer Technology Telecommunication

Data, image, voice

Computer Technology Telecommunication Technology

Can be classified into five broader categories

may include both

can be classified into five groups

System User System Owner System Builders

System Designer System Analysts

Owns the system

Set the vision and

Determine the policies

Responsible for funding the

Translates system users

Design the system (data-bases,

Design the computer

Construct, test and deliver

People who understand

Determine how people, data,

Bridge the communication gap

often run on obsolete (and usually slow) hardware

spare parts for such computers become increasingly difficult to

hard to maintain, improve, and expand because there is a

The designers of the system may have left the organization,

Integration with newer systems may also be difficult because

Support old business Support new

Old Euro? Euro New

Many complex legacy systems yet to be

Force to change to reflect new or changing

Many computers and applications stored

Problems : when the millennium changed

Transaction Process Systems (TPS)

Airline Reservations Bank deposit and

Production scheduling Inventory reporting

Supports the planning

Integrates data from all

Enhance their ability to

- All the components are hosted by a central, multi user system

I am doing all processing

- Components are distributed across multiple locations and computer networks

- Processing work load required to support these components are distributed

Clients may be thin or flat

Almost all PCs

e.g. Windows terminal

A LAN (Local area network) based solution

The data entered is collected into files called batches.

Each file is processed as a batch of many transactions.

Super market-Batch processing 7

The data about a single transaction is

ATM-Real time processing

Systems Analysis and Design

University of Colombo School of Computing 1

System Testing System Design

project bounds are set during this

Producing a detailed model of what the

Fixing any bugs and problem

Tune the system to any