Introduction to

Systems Analysis and

Design

Lorenz Raphael Camacho – ULCCS, Faculty

Objective
Discuss the
impact of
information
technology
on business
operations
Introduction
 Why do businesses depend on
information more than ever?
 Global competition
 Intense pressure for quality
 Information technology can mean
the difference between survival and
failure
Introduction
 What is required for successful
business information systems?
 The right hardware and software
 A team of talented, motivated
people who use information
technology to achieve business
goals
Introduction
IBM summed it up this way:
Business Process Modeling
 Business process modeling
is used to represent a
company’s operations and
information needs
 Business profile
Defines a company’s overall
functions, processes, organization,
products, services, customers,
suppliers, competitors, constraints,
and future direction.
 Business model
 Graphically represents business functions that consist of business
processes, such as sales, accounting, and purchasing, which
perform specific tasks.
Business process
Describes specific event, tasks, and desired results.
 Contacta person at school or
nearby company who use
information systems. List the
system, the position titles of the
users, and the business
functions that the systems
support. Include the overview of
the company that you selected.
 Introduction to
Systems Analysis
and Design
Lorenz Raphael Camacho – ULCCS, Faculty
Objectives
 Describe an information system and explain
its components and characteristics
 Identify common types of information
systems and explain who uses them
Information System Components

People

Hardware

Processes

Software

Data
Information System Components
 Hardware  Software
- is the physical - System software
controls the hardware and
layer of the software environment and
information includes the operating
system system
- Application software
consists of programs that
that process data to produce
information
Information System Components
 Data stored in files and
databases is a vital
component of every
system
 Processes define
the tasks that
must be
performed by
users, managers,
and IS staff
Information System Components

 People who use

the system are
called users, or
end users.

(employees, customers,
vendors, or others who
interact with the system)
Categories of Companies
(classified based on their main activities)

 Production-oriented
(industrial ) companies that
manufacture & sell goods
 Service-oriented
companies that mainly offer
information, services, or sell
goods made by others
 Internet-dependent firms –
dot-com (.com)
Characteristics of Information Systems
(affect a business information system’s complexity)

1. Relationships with other systems

2. Boundaries
3. Specialized business needs
4. Size of the company
 Types of Information Systems
Traditional categories (based on the audience they served)
Office systems
Operational systems
Management information systems
Executive information systems
Decision support systems
Expert systems
 Types of Information Systems
Categories (based on functions and features)
Enterprise computing systems
Transaction processing systems
Business support systems
Knowledge management systems
User productivity systems
Enterprise computing systems
Refers to information systems that
support company-wide data
management requirements
e.g.
airline reservation system
credit card billing system
Transaction processing systems
Process data generated by
day-to-day business
operations

Transaction processing (TP)

Online transaction processing (OLTP)
 OPERATIONAL SYSTEMS

e.g.
customer billing
accounts receivable
warranty claim processing
Business support systems
Provide job-related information to users at all
levels in the company
Can analyze transactional data,
generate information
needed to manage and
control business processes,
and provide information that
leads to better decision
making

An important feature is decision

support capability to
conduct what-if analysis
 Knowledge management systems

Expert systems
Simulate human
reasoning by
combining a
knowledge base with
inference rules that
determine how the
knowledge is applied
User productivity systems

Provide employees at all organizational level with

a wide array of tools to improve quality and
job performance
e.g. LAN, WAN, e-mail, voice mail, fax, video conferencing, word processing,
automated calendars, data management, spreadsheets, desktop
publishing, presentation graphics, company intranets, internet
 Organizational Structure
Strategic planning

Tactical planning

Operational plans

Empowerment
 Introduction to
Systems Analysis
and Design
Lorenz Raphael Camacho – ULCCS, Faculty
Objectives
 Explain systems development techniques
and tools, including modeling, prototyping,
and CASE tools
 Distinguish between structured analysis and
object-oriented methodology
 Describe the systems development life cycle
 Discuss the role of the information
technology department and the systems
analysts who work there
Systems Development Techniques & Tools

1. Modeling
2. Prototyping
3. Computer-Aided Systems Engineering (CASE)
4. Joint Application Development (JAD)
5. Rapid Application Development (RAD)
Modeling
Produces a graphical representation of a concept or
process that systems developers can analyze, test,
and modify.
 Business model or requirements model
 Describes business functions that an IS must support
 Data model
 Describes data structures and design
 Object model
 Describes objects which combine data and processes
 Network model
 Portrays the design and protocols of telecommunications links
 Process model
 Describes system logic and processes that programmers use to develop necessary code
modules
Prototyping
Involves the creation of an early working
version of the system or its components
Tests systems concepts and provides an
opportunity to examine input, output, and
user interfaces before final decisions are
made
Computer-aided systems engineering (CASE)
A technique that uses powerful programs called
CASE tools to help systems analysts develop
and maintain information systems
 Provide framework for systems design and
analysis
 Upper CASE tools – support the modeling
process and produce a logical design of the IS.
 Lower CASE tools – speed the development
process by generating source code based on the
logical model.
Joint application development (JAD)
Rapid application development (RAD)
Use teams composed of users, managers and IT
staff to complete projects
 JAD – involves team-based fact finding
techniques
 RAD – condense development process
Other systems development tools

 Word processing
 Spreadsheets
 Presentation software
 Special purpose
charting tools
Overview of Systems
Development Methodologies
 Structured Analysis
 Process-centered
technique
 Uses systems
development life cycle
(SDLC)
 Developing into a
technique known as
information
engineering
Overview of Systems Development
Methodologies
 Object-oriented
analysis
 Combines data and
the processes that act
on the data into things
called objects
Other development methodology

 Microsoft Solutions
Framework (MSF)
 One component of
Enterprise Services
Framework
 Documents the
experience of its own
IT teams
Systems Development Life Cycle

1. Systems planning
2. Systems analysis
3. Systems design
4. Systems implementation
5. Systems operation and support

 Waterfall Model
 Interactive Model
Waterfall Model

 The result of each

phase (end product
or deliverable)
deliverable flows
down into the next
phase
Interactive Model

 An alternative model
where planning,
analysis and design
interact
Systems Planning

 Purpose: to identify problem’s nature/scope

 Systems request begins the process &
describes desired changes/improvements
 Includes preliminary investigation or
feasibility study
 End product – preliminary investigation
report (describes business considerations, reviews anticipated
benefits and costs and recommends a course of action based on
economic, technical and operational factors)
Systems Analysis

 Purpose: to understand business requirements

and build a logical model of the new system
Requirements modeling Data modeling
Process modeling Object modeling

 Fact-finding or requirements determination is

used to define all functions of the current system
 Options
 Develop a system in-house
 Purchase a commercial package
 Modify an existing system
 Stop development

 The end product for this phase is the

systems requirements document (describes requirements,
alternative plans and costs and documentation )
Systems Design
 Purpose: to create blueprint for the new system
that will satisfy all documented requirements
 Identify all outputs, inputs, files, manual
procedures, & application programs

*** Avoid misunderstanding through manager and user

involvement

 End product is system design specification

Systems Implementation
 Construct / deliver information system

Objective: To deliver a completely functioning &

documented information system
 Write, test, document application programs
 User and manager approval obtained
 File conversion occurs
 Users, managers, IS staff trained to operate and support the
system
 Post-implementation evaluation performed
Systems Operation and Support
 IT staff maintains and enhances the system

Maintenance changes correct errors and adapt to

changes in the environment
Enhancements provides new features and
benefits

*** A well-designed system will be reliable,

maintainable and scalable
Systems development guidelines
1. Stick to an overall plan
2. Ensure that users are involved in the
development process
3. Identify milestones for project review and
assessment
4. Establish checkpoints to ensure that project
remains on schedule
5. Be flexible within the framework of your plan
6. Provide accurate and reliable cost and
benefit information
Information Technology Department
 Develops and maintains a company’s
information systems
 The Systems Analyst Position

Responsibilities
1. Translates business requirements into practical IT
projects that meet the company’s needs.
2. Builds business profiles, reviewing business
processes, selecting hardware and software packages,
designing IS, training users and planning e-commerce
Web sites.
3. Plans projects, develops schedules and estimates
costs.
4. Conducts meetings, deliver presentations and writes
memos, reports and documentations.
 The Systems Analyst Position

Required Skills & Background

 College degree in IS, CS, Business or a closely related
field / master’s degree / IT experience
 Solid technical knowledge
 Strong oral & written communication skills
 Good analytical ability & understanding of business
operations and processes
 Good interpersonal skills / leadership & team-building
skills
The Systems Analyst Position

Career Opportunities
 Job Titles
 Company Organization
 Company Size
 Corporate Culture
 Salary, Location and Future Growth
 Phase 1
Systems Planning
Objectives
 Describe the strategic planning process,
and why it is important to IT managers
 Explain the purpose of a mission
statement
 Explain the SDLC as a framework for
systems development and business
modeling
 Explain the reasons for information
systems projects and the factors that
affect such projects
Objectives
 Describe the initial review of systems
requests and the role of the systems
review committee
 Describe the internal and external factors
that affect information systems projects
 Define operational feasibility, technical
feasibility, and economic feasibility
 Describe the steps and end product of a
preliminary investigation
The Importance of Strategic
Planning
Strategic Planning
 The process of identifying long-term
organizational goals, strategies, and
resources.
SWOT analysis
Strengths
Weaknesses
Opportunities
Threats
SWOT Analysis example
Strengths (S)
 What are our major strengths, how can we
utilize them in the future?
 What must we do to strengthen our IT function,
including our people and technology
infrastructure?
Weaknesses (W)
 What are our major weaknesses, and how can
we overcome them?
 How should we address weaknesses in IT
resources and capability?
Opportunities (O)
 What are major opportunities, and how can we
take full advantage of them?
 What IT plans do we have to support business
opportunities?
Threats (T)
 What major threats do we face, and what can
we do about them?
 What can we do to deal with potential threats
to IT success?
Mission statement
 Briefly
defines the company’s business, its values, objectives and
approach to reach those objectives
Goals
 Accomplish the mission
Objectives
 Has shorter time frame
Stakeholders
 Include
anyone affected by the company’s performance (customers,
employees, suppliers, stockholders and members ofhte community)
Systems Requests
 Starting point for a project
Formal way of asking for IT support

 Might propose
1. enhancements for an existing system
2. correction of problems
3. development of entirely new information
system
Reasons for Systems Projects
Factors Affecting Systems
Projects
Systems Request Forms

 Streamlines the process

 Ensures consistency
 Must be easy to understand and use
 Must include clear instructions
 Include enough space for all required
information
 Indicate what supporting documents are
needed
Sample system request form
Evaluation of Systems
Requests

Systems Review Committee /

Computer Resources Committee
1. Evaluate requests
2. Set priorities
3. Assess feasibility
 Purpose of Feasibility Study

To determine quickly and at

minimum expense, if the
problem can be solved
 Operational Feasibility

A system that has operational

feasibility is one that will be
used effectively after it has
been developed.
 Technical Feasibility

A systems request has

technical feasibility if the
organization has the resources
to develop or purchase, install,
and operate the ssytem.
 Economic Feasibility

A systems request has economic

feasibility if the projected benefits
of the proposed system outweigh
the estimated cost involved in
acquiring, installing, and operating
it.
 Tangible Benefits

Advantages measured in terms of dollar

saved, resources saved, or time saved
1. increase of speed of processing
2. getting information on a more timely basis
3. take advantage of computer’s calculating power
4. lower amount of employee time to update specific
task
 Intangible Benefits

Benefits difficult to measure but

are important
1. improve decision making
2. enhance accuracy
3. more competitive in customer satisfaction
4. increase job satisfaction
Criteria used to evaluate
systems requests
 Reduce costs
 Increase revenue
 Produce more information or better results
 Serve customers and the organization better
 Reasonable time frame and lasting results
 Resources available
Discretionary vs. non-
discretionary projects
Discretionary projects
 Projects where management has a
choice in implementing them.
them

Nondiscretionary projects
 Projects where no choice exists.
exists
Model of a Preliminary Investigatio
Preliminary Investigation
 Purpose
 To decide whether to continue the project
 Objectives for a preliminary investigation
1. Understand the problem
2. Define the project scope and constraints
3. Identify the benefits
4. Estimate the time and costs
5. Report to management
 Interaction with managers and users
Step 1:
Understand the problem
 Identify the true nature of the problem
and the reason for the systems request
 Stated problem may not be the real
problem
 Clear statement defines the
investigation scope
Step 2:
Define the project scope &
constraints
Project scope
 Define the range or extent of the project
 Set project boundaries

Constraints
 Identify conditions, restrictions, or
requirements
 Present vs. future
 Internal vs. external
 Mandatory vs. desirable
Step 3:
Perform fact finding
 Analyze organization charts
 Conduct interviews
 Observe operations
 Carry out a user survey
Step 4:
Determine feasibility
 Determine operational, technical,
economic feasibility, and schedule
feasibility
Step 5:
Estimate time & cost to
continue development
 Determine what information is needed
 Identify the sources of information
 Decide whether to use interviews, if so how
many, and what time needed
 Decide whether to use surveys, if so who to
complete it, and what time needed
 Estimate the cost of gathering, analyzing,
and reporting the information to
management
Step 6: Present results &
recommendations to
management
 Final task in the preliminary
investigation
 Key elements
 Evaluation of systems request
 Estimate of costs and benefits
 Recommendations

 Oral and written presentations

Sample of Preliminary
investigation report
Contents
I. Introduction
Overview of the report (brief description of the system,
name of persons/group who performed the investigation &
initiated the investigation)

II. Systems Request Summary

Describes the basis of the systems request

III. Findings
Results of preliminary investigation (description of project’s
scope, constraints, and feasibility)
Contents
IV. Recommendations
Recommendations for further action, with specific reasons and
justification.

V. Time and Cost Estimates

Describe the cost of acquiring and installing the system.

VI. Expected Benefits

Anticipated tangible and intangible benefits, and timetable.

VIII. Appendix
Attach supporting information
Economic Feasibility

“Do benefits outweigh

cost?”
Cost Benefit Analysis
 Spending versus Investing

 Two Steps:
1. Producing the estimates of cost and benefits
2. Determining whether the project is
worthwhile
1. Producing Costs and Benefits
 Cost
 Money flowing from the organization
 The sum value of costs of items needed to
implement the system
a. Operating Costs - are expenses
b. Development Cost - capital investment
c. Benefits - The sum value of the savings made
 Useful Life
 The period of time during which an asset will
have economic value and be usable. The useful
life of an asset is sometimes called the economic
life of the asset
 Salvage Value
 Isthe “re-sell” value or scrap value of the asset at
the end of its life
 Depreciation
A decrease in value of property
2. Determining if project is worthwhile

 The costs and benefits are used to

determine whether a project is
economically feasible.

 Two Ways:
 Payback method
 Present value method
Methods
 Payback Method
 Defines
the time required to recover the
money spent on a project
 Present Value Method
 Determine how much money it is worthwhile
investing now in order to receive a specific
return in a particular period
Methods
 Present Value
The current value of future cash flows.
 Return on Investment (ROI)
Percentage rate that measures profitability by comparing
the total net benefits received from a project to the total
cost (investment) of the project
 Internal Rate of Return
Interest rate received for an investment consisting of
payments and income that occur at regular periods. (should
be ≥ minimum desired rate of return of the company)
 Payback Period
A measurement of the time period required to recover the
project’s initial investment
Systems Analysis
Phase 2: Systems Analysis

Objectives
 Develop a logical model of the proposed
system
 Learn about requirements modeling, data and
process modeling, and object modeling
 Consider the transition from logical to physical
design
Objectives
 Explain systems analysis phase activities
and the end product of the systems analysis
phase
 Describe joint application development (JAD)
 Describe the Unified Modeling Language
(UML) and explain use case diagrams and
sequence diagrams
Objectives
 Explain how functional decomposition
diagrams (FDD) are used during systems
development
 List and describe system requirements,
including outputs, inputs, processes,
performance, and controls
 Explain the importance of scalability in
system design
Objectives
 Explain when and how to use fact-finding
techniques, including interviews,
documentation review, observation,
questionnaires, sampling, and research
 Develop effective documentation methods
to use during systems development
Systems Analysis
Phase Overview
Requirements Modeling
 Involves investigation and fact-finding to
describe the current system and define the
requirements for the new system

System Requirements Document

- end product of the systems analysis
- overall design blueprint for the new system
Systems Development Methods

Joint
Application
Development
Joint Application Development
Joint Application Development
Systems Requirements
Checklist
System Requirements
Characteristics or features that
must be included to satisfy
business requirements and be
acceptable to users.
1. Outputs
2. Inputs
3. Processes
4. Performance
5. Controls
Scalability
 The ability to adjust system capacity as business
requirements change
Total Cost of Ownership
 The sum of the direct costs and indirect expenses
 Systems developers must identify and document
indirect expenses: a system that seems inexpensive
initially might turn out to be the most expensive
Fact-Finding
Software helps you gather and
analyze facts; however, it cannot
perform fact-finding for you.
Fact-Finding
Interview
 Is a planned meeting during which you
obtain information from another person.
1. Determine the people to interview
2. Establish objectives for the interview
3. Develop interview questions
4. Prepare for the interview
5. Conduct the interview
6. Document the interview
7. Evaluate the interview
1. Determine the people to interview
 Selectthe right people
 Consider informal structures
2. Establish objectives for the interview
 Determine the areas to be discussed
 List the facts you want to gather
 Solicit ideas, suggestions, and opinions
3. Develop interview questions
 Open-ended questions
 encourage spontaneous and unstructured responses

 Closed-ended questions
 restrict the response

 Range-of-response questions
 ask the person to evaluate something
4. Prepare for the interview
 Schedule a specific day and time
 Place a reminder call
 Send a memo to managers
 Send a list of essential questions to an interviewee
ahead of time
5. Conduct the interview
 Introduce yourself
 Describe the project
 Explain your objectives
 Ask questions in order
 Listen carefully
 Summarize the main points
 Explain the next course of action
6. Document the interview
 Keep note-taking to a minimum
 Record the information quickly
 Thank the interviewee with a memo
 Note the date, time, location, and purpose
 Review the main points discussed
7. Evaluate the interview
 Identify
possible biases
 Determine whether interviewees have
necessary experience
Unsuccessful interviews
 Not all interviews are successful
 Find a way to conclude an unsuccessful
meeting
 Consider alternatives
Other Fact-Finding Techniques
 Document review
 Observation
 Surveys and questionnaires
 Sampling
 Research
Document Review
 Review existing system documentation
 Obtain copies of actual forms and documents
 Review blank copies of forms
 Review samples of completed forms
 Review software documentation
Observation
 Ask questions about present system
operation
 Observe all steps in the processing cycle
 Examine each form, record, and report
 Consider each person working with the
system
 Talk to people who receive current reports
 Consider the Hawthorne Effect
Questionnaires and surveys
 Brief and user-friendly
 Clear instructions
 Questions in logical order
 Simple wording to avoid misunderstanding
 Avoid leading questions
 Open-ending questions are difficult to tabulate
 Limit questions raising concern/negative issues
 Section for general comments
 Test the questionnaire in advance
Sampling

 Collectexamples of actual documents

 Sampling techniques
 Systematic sample
 Stratified sample
 Random sample

 Main objective is to ensure representation of the

overall population accurately
 Sampling should be considered for interviewing
or questionnaires
Research
 Journals, periodicals, books
 Internet sites
 Hardware and software vendors
 Independent firms that provide information

 Newsgroups

 Professional meetings, seminars, discussions

 Site visits to observe a system in use
Interviews vs. Questionnaires
 Interview
 Need information from only a few people
 More familiar and personal
 Can be costly and time-consuming
 Questionnaire
 Many people able to provide input
 People may offer more candid responses
 If not designed well, may be viewed as intrusive
Documentation
 The need for recording the facts
 Keeping accurate records is essential
 Basic rule: write it down
 Guidelines for good documentation
 Record information as soon as possible
 Use the simplest recording method
 Ensure that your work is understandable
 Organize your documentation material
 Consider a narrative list with simple
statements
Recording the Facts
 Software tools
 CASE tools
 Word processing
 Spreadsheets
 Database
 Presentation graphics
 Personal information managers
 Preview of Data, Process,
and Object Modeling

 Next step is to understand and model the

logical design of the system
 Structuredanalysis
 Object modeling
End
Objectives
1. Describe data and process modeling concepts and tools
2. Describe the symbols used in data flow diagrams and
explain the rules for their use
3. Explain the sequence of data flow diagrams, from
general to specific
4. Explain how to level and balance a set of data flow
diagrams
5. Draw a complete set of data flow diagrams for an
information system
Systems Analysis
DataFlow Diagrams
Data flow diagrams (DFDs) show how
data moves through an information
system
 DFDs represent a logical model that
shows what a system does, not how it
does it
Elements of the DFD
 External entities – person/organization that is
outside the boundaries of the system; may be a
source or a sink
 Data Store – repository/resting place for the data
 Process – work/task/function that must be
completed
 Data Flow – parcel of information that moves
between processes, data stores, and external
entities
PROCESS
 Receives input data and produces
output that has a different content,
form or both
 In DFDs the process symbol appears
as a black box, underlying details not
shown
Symbol is a rectangle with rounded corners

Process name consists of a verb followed by a

singular noun
DATA FLOW
 A path for data to move from one part
of the system to another
 At least one data flow must enter and
exit each process

Symbol is a line with a single or double arrowhead

Data Flow name consists of a singular noun and an

adjective, if needed
 Incorrect process
and data flow
combinations cause
problems
 Spontaneous
generation
(miracle)
 Black hole
 Gray hole
DATA STORE
 Data store also is called a data repository
 Represents data that is retained for later
processing

Symbol is a rectangle open on the right side

Data store name is a plural name consisting of a noun and

adjectives, if needed.
EXTERNAL ENTITY
 Represents a person, organization, or
other system that provides data or
receives output from the system
 External entities are called terminators
 Source (supplies data to the system)
 Sink (receives data from the system)

Symbol is a square, usually shaded

A external entity name is the singular form of

department, outside organization, other IS or
person
Methods of Constructing DFD
 Construct the Context Diagram
 Context Diagram – the highest level view of the
system.
 Generate a Diagram 0
 Diagram 0–
0 represents the primary individual
processes in the system at the highest possible level.
 Decompose each process diagram 0
 Lower-Level Diagram – a DFD that is generated
from n nested decompositions from diagram 0.
Context diagrams
 Top-level view that shows the systems’
boundaries scope
 One process symbol, numbered 0 (zero) is
drawn in the center
 Data flows connect the process to the entities
Data Flow Diagrams
Conventions for data flow diagrams

1. Each context diagram must fit on one page

2. Process name in the context diagram should
be the name of the information system
3. Use unique names within each set of symbols
4. Do not cross lines
5. Use a unique reference number for each
process symbol
Diagram 0
 Displays more detail than the context diagram
 Shows entities, major processes, data flows,
and data stores
 Exploded (partitioned or decomposed) version
of process 0
 Diagram 0 is the child of the parent context
diagram
Lower-level diagrams
 Usuallynecessary to show more detail
 Design must consider
 Leveling
 Process of drawing increasingly detailed diagrams
 Also called exploding, partitioning, or decomposing
 Balancing
 Maintains consistency among an entire set of DFDs
 Parent’s input and output data flows are preserved
on the child
 Data stores
 Might not appear on higher-level DFDs
 Are shown on the the highest-level DFD that has
two or more processes using that data store
Data Flow Diagrams
 Strategies for developing DFDs
 Main objective is to ensure that your model is
accurate and easy to understand
 A diagram should have no more than nine

process symbols
Final Output in SAD
 PIR – Preliminary Investigation Report with
(CBA)
 DFD - Dataflow Diagram of the Proposed
System (Context Diagram & Diagram 0)
 Sample Screens and Major Features of the
Proposed System
 ERD – Entity Relationship Diagram
 Appendix
Objectives
1. Explain the concept of user interface
design and human-computer interaction
2. Define user-centered interface design
principles
3. Describe guidelines for user interface
design
4. Describe user interface controls
User Interface Design
Logical starting point in the systems design
phase
 Many firms offer consulting services to help
companies develop user interfaces
 Requires an understanding of human-
computer interaction and user-centered
design principles
Human-Computer interaction
(HCI)
 Describes the relationship between
computers and people who use them
 HCI concepts apply to everything from PC’s
to the global networks
 Analysts main objective is to create user-
friendly design that is easy to learn and
use
User-centered design principles
1. Understand the underlying business
functions
2. Maximize graphical effectiveness
3. Profile the system’s users
4. Think like a user
5. Use prototyping
6. Design a comprehensive interface
7. Continue the feedback process
8. Document the interface design
User Interface Design Guidelines

Good User interface design is based on a

combination of ergonomics, aesthetics,
and interface technology.
Ergonomics – describes how people work, learn, and interact with computers.
Aesthetics – focuses on how an interface can be made attractive and easy to
use.
Interface Technology – provides the operational structure required to carry out
the design objectives
Build an interface that
is easy to learn and use

 Label clearly all controls, buttons, and icons

 Select only those images that users can
understand easily
 Provide on-screen instructions that are
logical, concise, and clear
 Show all commands in a list of menu items
 Make it easy to return to one or more levels
in the menu structure
Provide features
that promote efficiency

 Organize tasks, commands, and functions

in groups
 Create alphabetical menu lists
 Provide shortcuts
 Use default values
 Use a duplicate value function
 Provide a fast-find feature
 Use a natural language feature
Make it easy for users
to obtain help or correct errors

 Ensure that help is always available

 Provide user-selected Help and context-sensitive
Help
1. User-Selected Help – displays information when the user
requests it.
2. Context- sensitive Help – offers assistance for the task in
progress
 Provide a direct route back from Help
 Include contact information
 Require user confirmation before data deletion
 Provide an Undo key
 Allow for making corrections without retyping the
entire command
 Use hypertext links
Minimize input data problems
 Provide data validation checks
 Display event-driven messages and
reminders
 Establish a list of predefined values
 Build in rules that enforce data integrity
 Use input masks, or templates, that make it
easier to enter data
Provide feedback to users
 Display messages at a logical place on the
screen
 Alert users to lengthy processing times or
delays
 Allow messages to remain on the screen
long enough for users to read them
 Let the user know whether the task was
successful or not
 Provide a text explanation to identify the
control button
 Use messages that are specific,
understandable, and professional
Create an attractive layout & design
 Use appropriate colors to highlight different areas of
the screen
 Use special effects sparingly
 Use hyperlinks
 Group related objects and information
 Keep screen displays uncluttered
 Display titles, messages, and instructions in a
consistent manner
 Use consistent terminology
 Ensure the commands will always have the same
effect
 Ensure that similar mouse actions will produce the
same result
 Require the user to confirm data entry
Use familiar terms and images
 Stick to a pattern
 Provide a keystroke alternative for each
menu command
 Use familiar commands
 Provide a Windows look and feel
 Avoid complex terms and technical jargon
User interface controls
Menu bars  Drop-down list boxes
 Toolbars  Option buttons
 Dialog boxes  Check boxes
 Text boxes  Command buttons
 Toggle buttons  Spin bars
 List boxes  Calendars
 Scroll bars
User interface controls
 Design screens that are attractive,
easy to use, and workable
 An opening screen can use a main
form that functions as a switchboard
A switchboard uses command buttons
that enable users to navigate the system
and select from groups of tasks
Objectives

1. Explain input design concepts,

techniques, and methods.
2. Describe guidelines for data entry screen
design and validation checks for
reducing input errors.
3. Design effective source documents and
input controls.
Input Design
Main Objective:
To ensure the quality, accuracy, and timeliness of
input data

During input design, you determine how data

will be captured and entered into the
system
Data Capture – is the identification and recording of source data.
Data Entry – is the process of converting source data into
computer-readable form and entering it into the information
system.
Input and data entry methods
1. Batch input
 Data entry is performed on a specified time
schedule
 Collection (batch) of data is input at one time

2. Online input
 Data is validated and available immediately
Input volume
Guidelines for reducing input volume
1. Input necessary data only
2. Do not input data that can be retrieved from
system files or calculated from other data
3. Do not input constant data
4. Use codes
Designing data entry screens
Form filling is the most effective method of online
data entry
Effective screen design guidelines
1. Restrict user access to screen locations where data is
entered
2. Provide a descriptive caption for every field
3. Display a sample format if a user must enter values in
a specific format
4. Require an ending keystroke in every field
5. Do not require leading zeros for numeric fields
6. Do not require trailing zeros
7. Display default values
8. Use default values for constant entries
9. Display a list of acceptable values for fields
10. Provide a way to leave the data entry screen without
entering the current record
11. Provide the opportunity to confirm to confirm the
accuracy of input data
12. Provide for movement among fields in a standard
order or any chosen order
13. Design the screen form layout to match that of the
source documents
14. Allow users to add, change, delete, and view records
15. Provide for users to search for specific information
Input errors
Fewer errors mean better data quality
 Eight types of data validation checks
1. Sequence checks
2. Existence checks
3. Data type checks
4. Range checks
5. Reasonableness checks
6. Validity checks
7. Combination checks
8. Batch controls
Source documents
Source documents
 A form used to request and collect input
data, trigger or authorize input actions
and provide a record of the original
transaction.

Form layout guidelines

1. Allow sufficient space
2. Offer clear instructions
3. Provide logical organization
4. Use captions effectively
Form zones
 Heading zone
 Control zone
 Instruction zone
 Body zone
 Totals zone
 Authorization zone
Information should flow left to right and
top to bottom
Input control
 Measures to ensure that data is correct,
complete, and secure
 Effective source document design
 Data validity checks
 Batch input controls
 Log files for rejected records
 Audit trails
 Data security measures, including encryption
 Password and sign-on procedures
 Records retention policies
Group Task
Situation:
R. George’s, a fashionable clothing store that
also has a mail-order business, would like to
keep track of the customers coming into the
store.
a. Design and draw a form that can be printed on 3 inch
x 5 inch index cards and given to in-store customers
to fill out. (Hint: The form must be aesthetically
appealing to encourage R. George’s upscale clientele
to complete it.)
b. Design a form that captures in-store customer
information from the cards in part a.
Objectives
 Discuss output design issues and various
types of output
 Design various types of printed reports,
and suggest necessary output control and
security
Output Design Issues
 Checklist for output design
 Design process depends on
 What is the purpose of the output?
 Who the information, why is it needed, and
how will it be used?
 What specific information will be included?
 Will the output be printed, viewed on-screen,
or both?
 When will the information be provided, and
how often must it be updated?
 Do security or confidentiality issues exist?
Printed Output
 Printed reports are convenient and
sometimes necessary

 Used as turnaround documents

 Output documents that are later entered back
into the same or another information system

 Printed output is highly visible

 Should be attractive, professional, and easy to
use
Types of Reports

1. Detail Reports
2. Exception Reports
3. Summary Reports
Detail reports
 Produces one or more lines of output for
each record processed.
 Each line of output is called a detail line.

Control-break reports
 Use a control field
 Must be sorted on the control field before printing
 A control break occurs when the control field value changes
Exception reports
 Show only records that meet a specific
condition
 Useful when particular information is
required
 Special parameter queries can be used
to select only the records that meet
specified conditions
Summary reports
 Show only subtotals and totals
 Useful for upper-level managers who do
not require extensive detail
User involvement
 Allreport designs should be approved in
advance
 Submit each design as it is completed
 Prepare a prototype
Report design principles
1. Report headers and footers
2. Page headers and footers
3. Column heading alignment
4. Column spacing
5. Field order
6. Grouping detail lines
Report headers and footers

 Every report should have a report header and a

report footer.

Report header – appears at the beginning of the

report, identifies the reports, and contains the
report title, date, and other necessary information.

Report footer – appears at the end of the report, can

include grand totals for numeric fields and other
end-of-report information.
Page headers and footers

 Every page should include a page header or a

page footer

Page header – appears at the top of the page that

includes the column heading that identifies the
data (heading should be short but descriptive).

Page footer – appears at the bottom of the page

that displays the name of the report and the
page number.
Column heading alignment
 Some designers use a combination of
alignment techniques by centering
heading for alphanumeric fields over
average field widths, right-justifying
heading over shorter numeric fields, and
centering headings over average widths
for larger numeric fields.
Column spacing

 Should space columns of information

carefully

 A crowded report is hard to read, and

large gaps between columns make it
difficult for the eye to follow a line.
Field order

 Field should be displayed and grouped in

a logical order.
Grouping detail lines

 It is meaningful to arrange detail lines in

groups, based on a control field.

 You can print a group header above the

first detail line and a group footer after the
last detail line in group.
Report design example
Other design issues
 Good design standards produce reports
that are uniform and consistent
 Designer goal is to produce a report that
is attractive, readable, and useful, at a
reasonable price
 Document the design in a report analysis
form
Designing character-based
reports
 Produced on high-speed impact printers

Printer spacing charts

 A grid of rows and columns that represents
the lines and positions on a page of printer
paper
Printing volume & time
requirements
 Factors to consider
 Types of printers
 Print volume calculations

 Print-time calculations
Output control
1. Ensure output is correct, complete, &
secure
2. Include appropriate titles and dates on
reports
3. Number pages consecutively
4. Identify the end of each report
5. Print/reconcile control totals/record
counts
6. Processing errors must be logged and
analyzed
Output security
1. Protects privacy rights and proprietary
data
2. Important tasks to carry out
 Control the number of report copies
 Distribute reports only to authorized users
 Store sensitive reports in secure areas
 Label all pages of confidential reports
 Shred sensitive reports & other output
 Inventory blank checks regularly
 Store signature forms securely
Introduction

 Main focus is on data design and management

issues necessary to construct the physical
model
 Review data design concepts and terminology
 Discuss relationships among data objects
 Draw entity-relationship diagrams
DataDesign Terminology
Definitions
 Entity: aperson, place, thing, or event for
which data is collected and maintained
 Field (attribute):a single characteristic
or fact about an entity
 Record: a collection of fields that
describes one instance of an entity
 File and table: aset of records that
contains data about a specific entity
Key fields
 Used to organize, access, and maintain
data structures
 Four types of keys
 Primary keys
 Candidate keys

 Foreign keys

 Secondary keys
Primary keys
 A field or combination of fields that uniquely
and minimally identifies each member of an
entity

 A primary key composed of more than one

field is called a multivalued key
Candidate keys
 Any field that could serve as primary key

 Any field that is not a primary key or

candidate key is called a nonkey field
Foreign keys
 A field in one file that matches a primary key
value in another file
 A foreign key need not be unique
Secondary keys
 A field or combination of fields that can be
used to access or retrieve records

 Secondary keys do not need to be unique

Referential integrity
A set of rules that avoids data
inconsistency and quality problems

 Referentialintegrity ensures that a foreign

key value cannot be entered unless it
matches a primary key value in another
file
Data Relationships
 A relationship is a logical link between
entities based on how they interact

 Entity-relationship diagrams (ERDs)

 An ERD is a graphical model that shows
relationships among system entities
Entity-relationship diagrams
(ERDs)
 Each entity is a
rectangle,
labeled with a
noun

 Each relationship
is a diamond,
labeled with a
verb
Types of relationships

1. One-to-one (1:1)
2. One-to-many (1:M)
3. Many-to-many (M:N)
One-to-one (1:1) relationship
Exists when exactly one of the second entity occurs for each
instance of the first entity
One-to-many (1:M) relationship
Exists when one occurrence of the first entity can be related to
many occurrences of the second entity, but each occurrence of
the second entity can be associated with only one occurrence of
the first entity
Many-to-many (M:N)
relationship
Exists when one instance of the first entity can be related to many
instances of the second entity, and one instance of the second
entity can be related to many instances of the first
 A complete ERD shows all system
relationships

Examples
 A sales rep serves one or more customers, but each
customer has only one sales rep
 A customer places one or more orders, but each order has
only one customer
 An order lists one or more products, and each product can be
listed in one or more orders
 A warehouse stores one or more products, and each product
can be stored in one or more warehouses
Cardinality

 Describes how
instances of one entity
relate to another

 Crow’s foot notation

is one method of
showing cardinality
Creating an ERD
1. Identify the entities
2. Determine all significant events or
activities for two or more entities
3. Analyze the nature of the interaction
4. Draw the ERD