Merge Lesson 1 7

Introduction to
Information Systems
❑ System Definition
❑ System Concepts
❑ Information Systems
❑ Types of Information Systems
❑ General System Principles
❑ Players in System Game
❑ Roles of the System Analyst
❑ Required Skills of the System Analyst
System Definition
∙ What is a System?
∙ an interrelated set of components that function
together to achieve an outcome
∙ Three major components:

∙ Input
∙ Processing
∙ Output
System Definition
∙ Elements of a system:
∙ Purpose
∙ Subsystems
∙ Environment
∙ Boundary
∙ Connections
∙ Control mechanisms
System Concepts
∙ Business System
∙ Is a collection of policies, procedures,
methods, people, machines, and other
elements that interact and enable the
organization to achieve its goal.
∙
System Concepts
∙ Information System
∙ Is a collection of interrelated components
that collect, process, store, and provide as
output the information needed to
complete a business task.
∙
Information Systems
∙ Components
∙ Work practice
∙ Information
∙ People
∙ Information Technology
∙
Information Systems
∙ Reasons why information system is needed:
∙ growing size of the organization and the
number of competitors
∙ growing ability of computers to process large
amount of data with great speed
∙
Information Systems
∙ advances in communication technologies to

permit faster data transmission
∙ increase in pace of business transactions
∙ much more sophisticated technology today
Types of Information System
∙ Transaction Processing Systems (TPS)
∙ process large amount of data for routine
business activities or transactions
∙
∙ Management Information Systems (MIS)
∙ provide a standard reports for managers about
transaction data
∙ work on the purposeful interaction between
people and computers
∙ supports a broader range of organizational tasks
to include not only TPS but also decision
analysis and decision making
∙ help unite some of the computerized
information functions of a business
∙ Designed to take the relatively raw data
available through a TPS and convert them into
a summarized and aggregated form for
managers, usually in a report format.
∙
∙ Decision Support Systems (DSS)
∙ designed to help organizational decision makers
identify and choose between options or
decisions
∙ provides an interactive environment in which
decision makers can quickly manipulate data
and models of business operations
∙
∙ Office Automation Systems (OAS)
∙ support general office work for handling and
managing documents and facilitating
communication
∙
∙ Expert Systems (ES)
∙ perform a task that would otherwise be
performed by a human expert
∙ designed to take the place of human expert,
while others are designed to aid them
∙ are part of a general category of computer
applications known as Artificial Intelligence
(AI)
∙ Executive Information Systems (EIS)
∙ provide a generalized computing and
communication environment to senior
managers to support strategic decisions
∙ rely on the information generated by MIS and
allow communication with external sources of
information
∙
General System Principles
∙ The more specialized a system is, the less
able it is to adapt to different
circumstances.
∙ The more general-purpose a system is, the
less optimized it is for any situation.
∙ The larger the system is the more of its
resources that must be devoted to its
everyday maintenance.
∙ Systems are always part of larger systems,
and they can always be partitioned into
smaller systems.
∙ Systems grow. This principle could not be
true for all systems, but many of the systems
with which we are familiar do grow,
because we often fail to take it into account
when we begin developing the system.
Players in the System Game
∙ System sponsors/owners
∙ pay for the system to be built and operated and
set the vision and priorities for the system
∙ System users
∙ use the system on a regular basis to support the
operation and management of the organization
∙ System designers
∙ technical specialists that translate the business
requirements into a feasible technical solution
∙ System builders
∙ technical specialists who build, test, and deliver
the information system
∙ System analysts
∙ who determine the requirements that must be
met by the information system
Roles of the Systems Analyst
∙ Systems Analyst as Consultant
∙ address specific information systems issues
within a business
∙ Systems Analyst as Supporting Expert

∙ draws on professional expertise concerning
computer hardware and software and their uses
in the business
Roles of the Systems Analyst
∙ Systems Analyst as Agent of Change
∙ perform any of the activities in the SDLC and
are present in the business for an extended
period
∙ advocates a particular avenue of change
involving the use of information systems
Required Skills of the Systems
Analyst
Technical Technical
Knowledge Skills
Analyst
∙ Technical Knowledge and Skills
∙ Computers and how they work
∙ Devices that interact with computers, including
input devices, storage devices, and output
devices
∙ Communications networks that connect
computers
∙ Databases and database management systems
Analyst
∙ Programming languages
∙ Operating systems and utilities
∙ Software packages such as Microsoft Access
that can be used to develop systems
∙ Integrated development environments (IDEs)
for specific programming languages
Analyst
∙ Computer-aided system engineering (CASE)
tools that store information about system
specifications created by analysts and
sometimes generate program code
∙ Program code generators, testing tools,
configuration management tools, software
library management tools, documentation
support tools, project management tools, and
others
Analyst
Business Business
Knowledge Skills
Analyst
∙ Business Knowledge and Skills
∙ have an understanding of the business
organizations in general
∙ understand the type of organization for which

they work
Analyst
∙ some specifics the analyst needs to know about
the company:
∙ What the specific organization does

∙ What makes it successful
∙ What its strategies and plans are
∙
Analyst
People People
Knowledge Skills
Analyst
∙ People Knowledge and Skills
∙ understand a lot about people since they usually
work on development teams with other
employees
∙ possess many interpersonal skills

Analyst
∙ understand how people:

∙ Think
∙ Learn
∙ React to change
∙ Communicate
∙ Work (in a variety of jobs and levels)
Approaches to System
Development
❑ System Development Life Cycle
❑ Approaches to System Development
❑ Waterfall Model
❑ Prototype Model
❑ Spiral Model
❑ Extreme Programming
❑ Unified Process
❑ Agile Modeling
❑ Rapid Application Development
❑ Joint Application Development
System Development Life Cycle
∙ conceptual model that describes the phases
involved in an information system
development project
∙ possible to complete some activities in one
phase in parallel with some activities of
another phase
∙ phases are repeated as required until an
acceptable system is found
∙ General steps of an SDLC methodology:
1. The existing system is evaluated.
2. The new system requirements are defined.
3. The proposed system is designed.
4. The new system is developed.
5. The system is put into use.
6. The new system should be evaluated once it is
up and rynning.
∙ Planning Phase
∙ process of defining clear, discrete activities, and
the work needed to complete each activity
within a single project
∙ primary objectives:
∙ identify the scope of the new system
∙ ensure that the project is feasible
∙ develop a schedule, resource plan, and budget.
∙ activities:
∙ define the problem
∙ confirm project feasibility
∙ produce the project schedule
∙ staff the project
∙ Launch the project
∙ Analysis Phase
∙ understand and document the business needs

and the processing requirements of the new
system
∙ Activities:
∙ gather information
∙ define system requirements
∙ build prototypes for discovery of requirements
∙ prioritize requirements
∙ generate and evaluate alternatives
∙ review recommendations with management
∙ Design Phase
∙ design the solution system based on the
requirements defined and decisions made
during the analysis phase
∙ Activities:
∙ design and integrate the network
∙ design the application architecture
∙ design the user interfaces
∙ design the system interfaces
∙ design and integrate the database
∙ prototype for design details
∙ design and integrate the system control
∙ Implementation Phase
∙ final system is built, tested, and installed
∙ ensure that the users are all trained and that the
organization is ready to benefit as expected
from use of the system
∙ Activities:
∙ construct software components
∙ verify and test
∙ convert data
∙ train users and document the system
∙ install the system
∙ Maintenance Phase
∙ keep the system running productively during
the years following its initial installation
∙ upgrades or enhancements may be carried out

to expand the system’s capabilities
∙ Activities:
∙ maintain the system
∙ enhance the system
∙ support the users
Development
∙ Traditional Approach
∙ also known as structured system development

Development
∙ Includes three techniques:
∙ Structured analysis
∙ Structured design
∙ Loosely coupled
∙ Highly cohesive
∙ Structured programming
∙ A sequence of program statements
∙ A decision where one set of statements or another set of
statements executes
∙ A repetition of a set of statements
Development
∙ Object Oriented Approach
∙ views an information system as a collection of
interacting objects that work together to
accomplish tasks
∙ system consists of objects
Development
∙ includes three techniques:
∙ Object-oriented analysis (OOA)
∙ defines all of the types of objects
∙ shows what user interactions are required
∙ Object-oriented design (OOD)

∙ defines all of the additional types of objects necessary to
communicate with people and devices in the system
∙ shows how the objects interact to complete the tasks
∙ refines the definition of each type of object
Development
∙ Object-oriented programming (OOP)

∙ writing of statements using a programming language
Waterfall Model
∙ describes a development method that is
linear and sequential
∙ based on the metaphor that when one phase

was finished, the development proceeds to
the next phase and there is no going back
Waterfall Model
∙ does not accept the expected changes and
revisions that become necessary with most
projects
∙ some alternatives include joint application

development (JAD), rapid application
development (RAD), and spiral model
Waterfall Model
Prototype Model
∙ systems development methodology in which
a prototype is built, tested, and then
reworked as necessary until an acceptable
prototype is finally achieved from which the
complete system or product can now be
developed
∙ an iterative, trial-and-error process that
takes place between developers and end
users
Prototype Model
Prototype Model
∙ Advantages:
May provide the proof of concept necessary to
attract funding
Early visibility of the prototype gives users an
idea of what the final system looks like
Encourages active participation among users
and producer
Enables a higher output for user.
Prototype Model
Cost effective (Development costs reduced)
Increases system development speed
Assists to identify any problems with the
efficacy of earlier design, requirements analysis
and coding activities
Helps to refine the potential risks associated
with the delivery of the system being developed
Prototype Model
∙ Disadvantages:
Possibility of causing systems to be left
unfinished
Producer might produce a system inadequate
for overall organization needs
User can get too involved whereas the program
cannot be to a high standard
Prototype Model
Structure of system can be damaged since many
changes could be made
Not suitable for large applications
Spiral Model
∙ combines the features of the prototyping
model and the waterfall model
∙ shows the life cycle as a spiral, starting in
the center and works its way around, over
and over again, until the project is complete
∙ intended for large, expensive, and
complicated projects
Spiral Model
Spiral Model
∙ General steps of Spiral Model:
1. The new system requirements are defined in
details.
2. An initial design is created for the new
system.
3. A first prototype of the new system is
constructed from the initial design.
Spiral Model
4. A second prototype is evolved by a fourfold
procedure: (1) evaluating the first prototype in
terms of its strengths, weaknesses, and risks;
(2) defining the requirements of the second
prototype; (3) planning and designing the
second prototype; (4) constructing and testing
the second prototype.
5. At the customer's option, the entire project
can be aborted if the risk is deemed too great.
Spiral Model
6. The existing prototype is evaluated in the
same manner as was the previous prototype,
and, if necessary, another prototype is
developed from it according to the fourfold
procedure outlined above.
7. The preceding steps are iterated until the
customer is satisfied that the refined prototype
represents the final product desired.
Spiral Model
8. The final system is constructed based on the
refined prototype.
9. The final system is completely evaluated and
tested.
Spiral Model
∙ Advantages
Estimates of the budget and schedule become
more realistic as work progresses because of
the questions that have been raised
Easier to cope with the changes inherent to
software development
Software engineers can start working on the
project earlier rather than wading through a
lengthy early design process
Spiral Model
A drawback of a spiral model is that estimates

of budget and time are harder to judge at the
beginning of the project since the requirements
evolve through the process.
Extreme Programming
∙ discipline of system development that
follows a specific structure that is designed
to simplify and expedite the process of
developing new software
∙ developed by Kent Beck to be used with
small teams of developers who need to
develop software quickly in an environment
of rapidly-changing requirements
Extreme Programming
∙ emphases on its use of two-person
programming teams and having a customer
on-site during the development process
Extreme Programming
∙ Relevant parts of XP that relate to design
specifications:
1. How planning, analysis, design, and
construction are all fused into a single phase
of activity, and
2. Its unique way of capturing and presenting
system requirements and design
specifications.
Extreme Programming
∙ In XP, coding and testing are related parts of
the same process, which means the
programmers who write the code can also
develop the tests.
∙ The overall philosophy of XP is that code
will be integrated into the system it is being
developed for and tested within a few hours
after it has been written.
Extreme Programming
∙ Advantages of pair programming practice:
More and better communication among
developers
Higher levels of productivity
Higher-quality code
Reinforcement of the other practices in XP,
such as the code-and-test discipline
Extreme Programming
∙ Disadvantages:
Problems with unstable requirements
No documented compromises of user conflicts
Lack of an overall design specification or
document
Unified Process
∙ object-oriented system development
methodology offered by Rational Software
∙ uses UML (a standard modeling notation for

OO approach) for system models
Unified Process
∙ designed to reinforce six “best practices” for
system development that are common to
many system development methodologies
∙ Develop iteratively
∙ Define and manage system requirements
∙ Use component architectures
∙ Create visual models
∙ Verify quality
∙ Control changes
Unified Process
∙ Four Phases
∙ Inception
∙ Elaboration
∙ Construction
∙ Transition
Unified Process
∙ defines disciplines within each phase to
make iterative development manageable
∙ defines roles played by developers and

models created during the project
Agile Modeling
∙ popularized by Scott Ambler
∙ practice-based methodology for modeling
and documentation of software-based
systems
∙ proposed to be a collection of values,
principles, and practices for modeling
software that can be applied on software
development project in a more flexible
manner
Agile Modeling
∙ core practices:
∙ Iterative and Incremental Modeling
∙ Teamwork
∙ Simplicity
∙ Validation
Agile Modeling
∙ Typical Agile modeling process would go
like:
∙ Listen for user stories from the customer.
∙ Draw a logical workflow model to gain an
appreciation for the business decisions
represented in the user story.
∙ Create new user stories based on the logical
model.
Agile Modeling
∙ Develop some display prototypes. In doing so,
show the customer what sort of interface they
will have.
∙ Using feedback from the prototypes and the
logical workflow diagrams, develop the system
until you create a physical data model.
Rapid Application Development
∙ emphasizes speed of development through
extensive user involvement in the rapid,
iterative, and incremental construction of a
series of functioning prototypes of a system
that eventually evolves into the final system
(or a version)
∙ Consider using RAD when:
∙ The team includes programmers and analysts
who are experienced with it
∙ There are pressing business reasons for
speeding up a portion of an application
development
∙ Working with a novel ecommerce application
and the development team believes that the
business can sufficiently benefit over their
competitors from being an innovator if this
application is among the first to appear on the
Web
∙ Users are sophisticated and highly engaged
with the organizational goals of the company
∙ Advantages:
It is useful for projects in which the user
requirements are uncertain or imprecise.
It encourages active user and management
participation, which increases end-user
enthusiasm for the project.
Projects have higher visibility and support
because of the extensive user involvement
throughout the process.
Errors and omissions tend to be detected earlier
in prototypes than in system models.
The iterative approach is a more “natural”
process because change is an expected factor
during development.
∙ Disadvantages:
RAD prototypes can easily solve the wrong
problems since problem analysis is abbreviated
or ignored.
A RAD-based prototype may discourage
analysts from considering other, more useful
technical alternatives.
The emphasis on speed can adversely impact

quality because of ill-advised shortcuts through
the methodology.
Joint Application Development
∙ involves the client or end users in the design
and development of an application, through
a succession of collaborative workshops
called JAD sessions
∙ developed in the late 1970s by Chuck
Morris and Tony Crawford
∙ thought to lead to faster development times
and greater client satisfaction
Joint Application Development
∙ a variation on JAD is the RAD which
attempts to create an application more
quickly through strategies that include fewer
formal methodologies and reusing software
components
∙ allows for the simultaneous gathering and
consolidating of large amounts of
information
∙ it opens up a lot of scope of inter-personal
conflict
Systems Analysis
Fundamentals
❑ Project Initiation
❑ Project Feasibility
❑ Areas of Feasibility
❑ Feasibility Analysis
❑ Work Breakdown Structure
❑ PERT/CPM Diagram
❑ Gantt Charts
Project Initiation
∙ Three general driving forces:
∙ To respond to an opportunity
∙ To resolve a problem
∙ To conform to a directive
Project Feasibility
∙ During project feasibility, the project manager
answers questions such as,
∙ “Are the expected benefits reasonable?”
∙ “Are the assumed costs realistic?”
∙ The objective of project feasibility is to determine
whether a development project has a reasonable
chance of success.
∙
Areas of Feasibility
∙ Economic Feasibility
∙ process of identifying the financial benefits and
costs associated with a development project
∙ consists of two tests:
∙ Is the anticipated value of the benefits greater than
projected costs of development?
∙ Does the organization have adequate cash flow to
fund the project during the development period?
∙ Cost-benefit analysis is the analysis to compare
costs and benefits to see whether investing in
the development of a new system will be
beneficial.
∙ Three-step process:
∙ Estimate the anticipated development and
operational costs
∙ Estimate the anticipated financial benefits
∙ Cost-benefit analysis is calculated based on the
detailed estimates of costs and benefits
∙ Costs and benefits can be viewed as:
∙ Tangible
∙ Intangible
∙ Three techniques to assess economic feasibility:
∙ Net Present Value (NPV)
∙ Payback Period
∙ Return Of Investment (ROI
∙ The Time Value of Money (TVM) is the concept
applied to each technique, which refers to the
concept of comparing present cash outlays to
future expected returns.
∙ Technical Feasibility
∙ to gain understanding of the organization’s
ability to construct the proposed system
∙ include an assessment of the development’s
group understanding of the possible target
hardware, software, and operating
environments to be used as well as system size,
complexity, and the group’s experience with
similar systems.
∙ Operational Feasibility
∙ process of assessing the degree to which a
proposed system solves business problems or
takes advantage of business opportunities
∙ measure of how well the solution will work in
the organization
∙ dependent on the human resources available for
the project and;
∙ involves projecting whether the system will
operate and be used once it is installed.
∙ Schedule Feasibility
∙ gain understanding of the likelihood that all
potential time frames and completion date
schedules can be met and that meeting these
dates will be sufficient for dealing with the
needs of the organization
∙ measure how reasonable the project timetable
is.
∙ Resource Feasibility
∙ requires the involvement of systems analysts,
system technicians, and users
∙ risk to consider here is that the people who are
assigned may not have the essential skills for
the project
∙ other sources needed for a project to be
successful include adequate computer
resources, physical facilities, and support staff.
Feasibility Analysis
∙ process by which feasibility is measured
∙ designed to determine whether or not a project
will be successful
∙ conducted for a project with an emphasis on
financial feasibility, environmental integrity,
cultural acceptability, or political viability.
∙ It is a determination as to the likelihood of success
and a description of how that determination was
achieved.
Feasibility Analysis
∙ Elements of feasibility analysis for a project
should cover:
∙ Need analysis
∙ Process work
∙ Engineering and design
∙ Cost estimate
∙ Financial analysis
∙ Project impacts
∙ Conclusions and recommendations
Work Breakdown Structure
∙ hierarchy of phases, activities, and individual tasks
that are required to complete the project
∙ the foundation for developing the project schedule,
for identifying milestones in the schedule, and for
managing cost
∙ developed before dependencies are identified and
activity durations are estimated
∙ can be used to identify the tasks in PERT diagram
∙ Block diagram
∙ Outline form
Example of WBS:
PERT/CPM Diagram
∙ PERT is an acronym for Program
Evaluation and Review Technique and CPM
stands for Critical Path Method
∙ diagram of all the tasks identified in the
WBS, illustrating the sequence of
dependencies of the tasks
PERT/CPM Diagram
∙ The critical path is the longest path through
the PERT/CPM diagram and contains all the
tasks that must be done in the defined
sequential order.
PERT/CPM Diagram
PERT/CPM Diagram
∙ Rules in PERT/CPM diagram
∙ Each activity must be represented by its own branch
on the chart.
∙ Direction of time flows is indicated by arrows. An
activity line meeting an event node indicates activity
completion. The length of an activity branch is not
representative of the time the activity will take.
∙ Relationships between activities are determined by
the sequence of the branches.
PERT/CPM Diagram
∙ Rules in PERT/CPM diagram
∙ If several activities terminate at one node, no
activities starting at that node may begin until all
entering activities are completed.
∙ No two activities are allowed to both start and end at
the same nodes.
PERT/CPM Diagram
One of the advantage of the PERT/CPM technique
is that it produces a diagram that makes it easy to
see dependencies and the critical path.
PERT/CPM Diagram
∙ Disadvantages:
There can be potentially hundreds or thousands of
activities and individual dependency relationships.
The lack of a timeframe on most PERT/CPM charts
makes it harder to show status although colors can
help (e.g., specific color for completed nodes).
When the PERT/CPM charts become unwieldy,
they are no longer used to manage the project.
Gantt Charts
∙ developed in 1917 by Henry Gantt
∙ bar chart that represents the tasks and activities of
the project schedule
∙ good for monitoring the progress of the project as
it moves along
Gantt Charts
Gantt Charts
Advantages:
Simplicity
The bars representing activities or tasks are
drawn to scale
Information
Requirements Analysis
❑ Information Gathering
❑ Methods for Information Gathering
❑ Review Existing Reports, Forms, and
Procedure Description
❑ Conduct Interviews and Discussion
with Users
❑ Observe and Document Business Process
❑ Distribute and Collect Questionnaires
❑ Conduct Joint Application Design Sessions
Information Gathering
∙ used to discover business information
details to define the information structure
∙ helps systems analysts to establish the

priorities of the information needs and
further leads to opportunities that highlight
key issues which may cross functional
boundaries or may touch on policies or the
organization itself
∙ must be organized to ensure that nothing is
overlooked and all system details are
eventually captured
∙ General steps conducted in information
gathering:
∙ Schedule initial visit to user site
∙ Gather and read background materials
∙ Establish data gathering objectives
∙ Determine what data gathering techniques to
use
∙ Identify contact persons
∙ Schedule data gathering activities
∙ Assign to data gathering teams
∙ Identify deliverables
Methods for Information
Gathering
∙ Relationship between information gathering
and model building
Methods for Information
Gathering
∙ Review existing reports, forms, and
procedure description
∙ Conduct interviews and discussion with
users
∙ Observe and document business processes
∙ Distribute and collect questionnaires
∙ Conduct joint application design (JAD)
sessions.
Review Existing Reports, Forms,
and Procedure Description
∙ Review of documentation helps identify

business rules that may not come up in the
interviews.
∙ Written procedures help discover
discrepancies and redundancies in the
business processes.
∙ To make sure that assumptions and business

rules derived from existing documentation
are correct, the analysts should review them
along with the users.
∙ Two sources of information for existing
procedures and forms:
∙ External to the organization—at industry-wide
professional organizations and at other
companies
∙ Existing business documents and procedure
description within the organization
∙ it is a good way to get a preliminary understanding
of the processes
∙ the analysts need to learn about the industry or the
specific application that they are studying.
Conduct Interviews and
Discussions with Users
∙ Interviewing is a directed conversation with

a specific purpose that uses a
question-and-answer format.
∙ To conduct an effective interview, a system

analyst need to organize in three areas:
∙ Prepare for the interview
∙ Conduct the interview
∙ Follow-up the interview
∙ Prepare for the Interview

∙ Five major steps:
∙ Read the background material
∙ Establish interviewing objectives
∙ Decide who to interview
∙ Prepare the interviewee
∙ Decide on question types and structure
∙ Question types:
∙ Open-Ended Questions
∙ Please explain how your current inventory system works?
∙ What are the critical objectives of your department?
∙ What are the data entry errors made in your department?
∙ Advantages:
Put the interviewer at ease.
Allow the interviewer to pick up on the
interviewee’s vocabulary.
Reveal avenues of further questioning that may
have gone untapped.
Make it more interesting for the interviewee.
Allow more spontaneity.
Make phrasing easier for the interviewer.
∙ Disadvantages:
The interviewer might be asking questions that
can result in too much irrelevant detail.
There is a possibility of losing control of the
interview.
It may be misconstrued as unprepared on the
part of the interviewer.
It may give the impression that the interviewer is
fishing for information.
∙ Closed Questions
∙ How many times a week is the report updated?
∙ Who receives this input?
∙ Advantages:
Save time.
Easy to compare interviews.
Get to the point.
Keep control over the interview.
Cover lots of ground quickly.
Get to relevant data.
∙ Disadvantages:
Fail to obtain rich detail.
Miss main ideas for the preceding reason.
Fail to build rapport between interviewer and
interviewee.
∙ Question structures:
∙ Pyramid Structure
∙ used if interviewee needs to warm up to the topic
∙ useful as an ending determination about the topic
∙ Funnel Structure
∙ interviewer takes a deductive approach
∙ provides an easy, non-threatening way to begin an
interview
∙ useful when interviewee feels emotional about the topic
∙ Diamond-Shaped Structure
∙ entails beginning in a very specific way
∙ combines the strength of pyramid and funnel structures
∙ takes longer than either other structure.
∙ Conduct the Interview
∙ Dress appropriately
∙ Arrive on time
∙ Limit the time of the interview
∙ Look for exception and error conditions
∙ Probe for details
∙ Take careful notes
∙ Follow-up the Interview
∙ Follow-up is an important part of each
interview.
∙ Information that was obtained should be
absorbed, comprehended, and documented.
∙ Make a list of new questions based on areas
that need further elaboration or that are missing
information.
Observe and Document Business
Process
∙ Observing the business processes in action will
help analysts understand the business
functions.
∙ Observing business processes can be done
from a quick walkthrough.
∙ A quick walkthrough gives a general
understanding of the layout of the office, the
need for and use of computer equipment, and
the general workflow.
Process
∙ Information gathered about business
processes through interviewing and
observing needs to be documented.
∙ An effective way to document this
information is through the use of diagrams.
∙ A workflow is a sequence of steps to
process a business transaction.
Process
∙ Methodologies commonly used to model

workflows include flowcharts, data flow
diagram, and activity diagram.
∙ Flowcharts and activity charts are
specifically designed to represent control
flow among processing steps.
Process
∙ An activity diagram is a workflow diagram that describes the various user
(or system) activities, the person who does each activity, and the sequential
flow of these activities.
∙ The oval represents the individual activities in a workflow.
∙ The arrow represents the sequence between the activities.
∙ The black circles are used to denote the beginning and ending of the
workflow.
∙ The diamond is a decision point at which the flow of the process will
either follow one path or the other path.
∙ The synchronization bar either splits the path into multiple concurrent
paths or combines concurrent paths.
∙ The swim lane represents an agent who performs the activities.
∙
Process
∙ Basic Symbols Used in Activity Diagram
Process
∙ Example of Activity Diagram
Distribute and Collect
Questionnaires
∙ Using questionnaires allows systems

analysts to study attitudes, beliefs, behavior,
and characteristics of several key people in
the organization that may be affected by the
current and proposed systems.
Questionnaires
∙ Guidelines whether use of questionnaires is
appropriate:
∙ The people you need to question are widely
dispersed (different branches of the same
corporation).
∙ A large number of people are involved in the
systems project, and it is meaningful to know
what proportion of a given group approves or
disapproves of a particular feature of the
proposed system.
Questionnaires
∙ You are doing an exploratory study and want to

gauge overall opinion before the systems
project is given any specific direction.
∙ You want to be certain that any problems with
the current system are identified and addressed
in follow-up interview.
Questionnaires
∙ Guidelines to use when choosing language
for questionnaires:
∙ Use the language of respondents whenever
possible. Keep wording simple.
∙ Work at being specific rather than vague in
wording. Avoid overly specific questions as
well.
∙ Keep questions short.
Questionnaires
∙ Do not patronize respondents by talking down

to them through low-level language choices.
∙ Avoid bias in wording. This also means
avoiding objectionable questions.
∙ Target questions to the correct respondents (that
is, those who are capable of responding). Do
not assume too much knowledge.
Questionnaires
∙ Ensure that questions are technically accurate

before including them.
∙ Use software to check whether the reading
level is appropriate for the respondents.
Conduct Joint Application Design
Sessions
∙ JAD is an alternative approach to

interviewing users one-by-one.
∙ The reasons for using JAD are:

∙ to cut the time (and the cost) required by
personal interviews
Sessions
∙ to improve the quality of the results of

information requirements assessment
∙ to create more user identification with new
information systems as a result of the
participative processes
Sessions
∙ Conditions that support the use of JAD:

∙ User groups are restless and want something
new, not a standard solution to a typical
problem.
∙ The organizational culture supports joint
problem-solving behaviors among multiple
levels of employees.
Sessions
∙ Analysts forecast that the number of ideas

generated via one-on-one interviews will not be
as plentiful as the number of ideas possible
from an extended group exercise.
∙ Organizational workflow permits the absence
of key personnel during a two-to-four-day
block of time.
Sessions
∙ Participants involved in JAD sessions:

∙ JAD Session Leader
∙ Users
∙ Technical Staff
∙ Project Team Members
Sessions
∙ Advantages of using JAD over
interviewing:
Time savings over traditional one-on-one
interviews
Rapid development possible via JAD
Possibility of improved ownership of the
information system
Creative development of designs
Sessions
∙ Disadvantages of using JAD:

Requires the commitment of a large block of
time from all participants
If preparation for the JAD sessions is
inadequate in any regard or if the follow-up
report and documentation of specifications is
incomplete
Sessions
The necessary organizational skills and

organization culture may not be sufficiently
developed to enable the concerted effort
required to be productive in a JAD setting
Analysis Process
❑ Data Flow Diagram ❑ Entity Relationship
❑ Types of Data Flow Diagram
Diagram ❑ Determine Hardware and
❑ Data Dictionary Software Needs
❑ Structured English ❑ Identifying and Forecasting
❑ Decision Tables Costs and Benefits
❑ Decision Trees ❑ Comparing Cost and Benefits
❑ HIPO Charts
❑ Guidelines for Analysis
❑ Pareto Charts
❑ Fishbone Diagram ❑ Systems Proposal
Data Flow Diagram
∙ introduced and popularized for structured
analysis and design in the late 1970s (Gane
and Sarson 1979)
∙ invented by Larry Constantine, the original
developer of structured design, based on
Martin and Estrin’s “data flow graph”
model of computation
Data Flow Diagram
∙ enables analyst to model all of the main
requirements for an information system in
one diagram: inputs and outputs, processes,
and data storage
∙ shows the processes that change or
transform data
Data Flow Diagram
∙ DFD Conventions
Process Source/sink
Data flow Data store

Data Flow Diagram
∙ Steps in developing DFDs
1. Make a list of business activities and use it to
determine various data flows, processes, data
stores, and sources/sinks.
2. Create a context diagram that shows
sources/sinks and data flows to and from the
system.
3.
Data Flow Diagram
4. Create a child diagram for each of the

processes in Diagram 0.
5. Check for errors and make sure the labels you
assign to each process and data flow are
meaningful.
6.
Data Flow Diagram
7. Partition the physical data flow diagram by

separating or grouping parts of the diagram in
order to facilitate programming and
implementation.
Data Flow Diagram
∙ Context Diagram
Academic
Department
Schedule
data
Enrollment
0
request
Class list Course
Faculty
Student
Member Registration
System Schedule
Data Flow Diagram
∙ Context Diagram
Borrower Books
0
Loaned Search Request
Library
Database
Borrowed System Book Status
Data Flow Diagram
∙ Diagram 0 Enrollment
2.0 request
Academic
Department Enroll Student
student
Schedule
Student
Schedule
date
Course
enrollment
1.0
Offered
Schedule course
course
3.0
Class list
Faculty
Produce Member
class list
Data Flow Diagram
∙ Child Diagram
1.1 1.3
Course
Choose
days and Assign
times rooms
Academic Offered
Department Available
course
rooms
1.2
Offered
Assign course
Available
faculty
faculty
Data Flow Diagram
∙ Data Flow Rules
∙ Process
∙ No process can have only outputs. It is making data
from nothing. If an object has only outputs, then it
must be a source.
∙ No process can have only inputs. If an object has
only inputs, then it must be a sink.
∙
Data Flow Diagram
∙ Data Store
∙ Data cannot move directly from one data store to
another data store. Data must be moved by a
process.
∙ Data cannot move directly from an outside source to
a data store. Data must be moved by a process that
receives data from the source and places the data
into the data store.
Data Flow Diagram
∙ Data cannot move directly to an outside sink from a

data store. Data must be moved by a process.
∙ A data store has a noun phrase label.
Data Flow Diagram
∙ Source/Sink
∙ Data cannot move directly from a source to a sink.
It must be moved by a process if the data are of any
concern to our system. Otherwise, the data flow is
not shown on the DFD.
∙
Data Flow Diagram
∙ Data Flow
∙ It has only one direction of flow between symbols.

It may flow in both directions between a process and
a data store to show a read before an update. The
latter is usually indicated, however, by two separate
arrows since these happen at different times.
Data Flow Diagram
∙ A fork in a data flow means that exactly the same

data goes from a common location to two or more
different processes, data stores, or sources/sinks.
∙ A join in a data flow means that exactly the same

data come from any of two or more different
processes, data stores, or sources/sinks to a common
location.
Data Flow Diagram
∙ It cannot go directly back to the same process it

leaves. There must be at least one other process that
handles the data flow, produces some other data
flow, and returns the original data flow to the
beginning process.
∙ A data flow to a data store means update (delete or

change).
Data Flow Diagram
∙ A data flow from a data store means retrieve or use.
∙ A data flow has a noun phrase label. More than one

data flow noun phrase can appear on a single arrow
as long as all of the flows on the same arrow move
together as one package.
Data Flow Diagram
∙ DFD Guidelines
∙ Completeness
∙ Consistency
∙ Timing
∙ Iterative Development
Types of Data Flow Diagram
Derive the logical DFD for the current
Current Logical
system by examining the physical DFD and
DFD isolating unique business activities.
Create the logical DFD for the new system

New Logical by adding the input, output, and processes
DFD required in the new system to the logical
DFD for the current system.
Derive the physical DFD by examining

processes on the new logical diagram.
New Physical
Determine where the user interfaces should
DFD exist, the nature of the processes, and
necessary data stores.
∙ Benefits of using logical model:
∙ Better communication with users
∙ More stable systems
∙ Better understanding of the business by analysts
∙ Flexibility and maintenance
∙ Elimination of redundancies and easier creation
of the physical model
∙ Benefits of using physical DFDs:
∙ Clarifying which processes are manual and

which are automated
∙ Describing processes in more detail than logical
DFDs
∙
∙ Identifying temporary data stores

∙ Specifying actual names of files and printouts
∙ Adding controls to ensure the processes are
done properly
∙ Items contained in the physical DFDs that
are not found in logical DFDs:
∙ Manual processes
∙ Processes for adding, deleting, changing, and
updating records
∙ Data entry and verifying processes
∙ Validation processes for ensuring accurate data
input
∙ Sequencing processes to rearrange the order of

records
∙ Processes to produce every unique system
output
∙ Intermediate data stores
∙ Actual file names used to store data
∙ Controls to signify completion of tasks or error
conditions
Data Dictionary
∙ repository for definitions of data processes,
data flows, data stores, and data elements
∙ compiled by systems analysts to guide them
through analysis and design
∙ collects and coordinates specific data terms,
and it confirms what each term means to
different people in the organization
Data Dictionary
∙ can be used to:
∙ validate the data flow diagram for completeness
and accuracy
∙ provide a starting point for developing screens
and reports
∙ determine the contents of data stored in files
∙ develop the logic for data flow diagram
processes
Data Dictionary
∙ Data Dictionary Notation
= is composed of
+ and
( ) optional (may be present or absent)
{ } iteration
[ ] select one of several alternative choices
** comment
@ identifier (key field) for a store
| separates alternative choices in the [ ] construct
Data Dictionary
∙ Examples:
∙ Name = Courtesy Title + First Name + (Middle
Initial) + Last Name
Courtesy Title = [Mr. | Miss | Mrs. | Ms. | Dr. |
Professor]
First Name = {Legal Character}
Middle Initial = {Legal Character}
Last Name = {Legal Character}
Legal Character = [A-Z|a-z|0-9|'|-| | ]
Data Dictionary
∙ Order Picking Slip = Order Number + Order
Date + Customer Number + Customer Name +
Customer Address + Customer Tel + {Order
Item Selection} + Number of Items
∙ Item Master = Item Number + Price + Quantity

on Hand
Structured English
∙ modified form of English that is used to
specify the contents of process boxes in a
DFD
∙ uses action verbs and noun phrases
∙ its main purpose is to represent processes in
a shorthand manner that is rather easy for
users and programmers to read and
understand
Structured English
∙ does not involve declaration, initialization,
or linking
∙ it uses some of the logical constructs of
structured programming to overcome the
lack of structure and precision in the
English language
∙
Structured English
∙ Five conventions followed when using
structured English:
1. Express all logic in terms of sequential
structures, decision structures, or iterations.
2. Use and capitalize accepted keywords, such as
IF, THEN, ELSE, DO, DO WHILE, DO
UNTIL, and PERFORM.
3. Indent blocks of statements to show their
hierarchy (nesting) clearly.
Structured English
4. When words or phrases have been defined in
the Data Dictionary, underline those words or
phrases to indicate that these have a
specialized, reserved meaning.
5.
Structured English
∙ Examples:
∙ Sequential structure Action #1
Action #2
Action #3
∙ Decision structure IF Condition A is TRUE
THEN implement Action A
ELSE implement Action B
∙ Iteration
Structured English
∙ Advantages:
∙ clarify the logic and relationships found in
human languages
∙ it is a communication tool
∙ A structured English is used when:

∙ There are many repetitious actions, or
∙
Decision Table
∙ matrix representation of processing logic,
which specifies the possible conditions for
the decision and the resulting actions
∙ useful when complex combinations of

conditions, actions, and rules are found or if
it requires a method that effectively avoid
impossible situations, redundancies, and
contradictions
Decision Table
∙ Three components of a simple decision
table are:
∙ Conditions – describe the factors that will affect
the decision or policy
∙ Actions – describe the possible policy actions
or decisions
∙ Rules – describe which actions are to be taken
under a specific combination of conditions
Decision Table
∙ In creating decision tables, analysts should:
∙ determine the maximum size of the table

∙ eliminate any impossible situations,
inconsistencies, or redundancies, and
∙ simplify the tables as much as possible
Decision Table
∙ Steps in constructing decision tables:
1. Determine the number of conditions that may
affect the decision.
2. Determine the number possible actions that
can be taken.
3. Determine the number of condition
alternatives for each condition.
Decision Table
4. in the decision table by multiplying the
number of alternatives for each condition.
5. Fill in the condition alternatives.
6. Complete the table by inserting an X where
rules suggest certain actions.
7. Combine rules where it is apparent that an
alternative does not make a difference in the
outcome.
Decision Table
8. Check the table for any impossible situations,

contradictions, and redundancies.
9. Rearrange the conditions and actions (or even
rules) if it makes the decision table more
understandable.
Decision Table
Decision Table
∙ A decision table is used when:
∙ Complex combinations of conditions, actions,

and rules are found, or
∙ A method is required that effectively avoids
impossible situations, redundancies, and
contradictions.
Decision Trees
∙ graphical representation of a decision or
choice situation as a connected series of
nodes and branches
∙ useful when the sequence of conditions and
actions is critical or not every condition is
relevant to every action
∙ designed to make it easier for analysts to
communicate with users
Decision Trees
∙ Two main components:

∙ decision points – represented by nodes
∙ actions – represented by ovals
Decision Trees
∙ Four major steps in drawing a decision tree:
∙ Identify the conditions

∙ Identify the outcomes (condition alternatives)
for each decision
∙ Identify the actions
∙
Decision Trees
∙ A decision tree is used when:
∙ The sequence of conditions and actions is
critical, or
∙ Not every condition is relevant to every action
(the branches are different).
Decision Trees
Sunday
Sleep two more
2 Weekday hours
Saturday
YES Time to get up
1 Sleep one more

hour
NO
Go back to sleep
Legend:
1) Sun up?
2) What day is it?
Decision Trees
∙ Three main advantages of decision tree over
a decision table:
∙ It takes advantage of the sequential structure of
decision tree branches so that the order of
checking conditions and executing actions is
immediately noticeable.
Decision Trees
∙
Decision Trees
∙ Compared with decision tables, decision trees

are more readily understood by others in the
organization.
HIPO Charts
∙ stands for Hierarchy Input Process Output
∙ was developed by IBM as a tool and
documentation technique that attempts to:
∙ provide a structure by which the function of a
system can be understood
∙ state the functions to be accomplished
∙ provide a visual description of the input,
process, and output for each function
HIPO Charts
∙ its main purpose is to define procedures and

operations in a hierarchical manner,
correlating input, processing, and output
steps
HIPO Charts
∙ A HIPO package is consists of:
∙ hierarchy chart
∙ IPO overview diagram
∙ IPO detail diagram
HIPO Charts
∙ Example of a Hierarchy Chart
HIPO Charts
∙ Example of an IPO Overview Diagram
HIPO Charts
∙ Example of an IPO Detail Diagram
Pareto Charts
∙ used to graphically summarize and display
the relative importance of the differences
between groups of data
∙ special form of a bar graph and is used to
display the relative importance of problems
or conditions
∙ named after Vilfredo Pareto, and its use in
quality assurance was popularized by
Joseph Juran and Kaoru Ishikawa
Pareto Charts
∙ Uses of Pareto Chart:
∙ Focus on critical issues by ranking them in
terms of importance and frequency.
∙ Prioritize problems or causes to efficiently

initiate problem solving.
Pareto Charts
∙ Analyze problems or causes by different

groupings of data (e.g., by program, by teacher,
by school building, by machine, by team).
∙ Analyze the before and after impact of changes

made in a process.
Pareto Charts
∙ Steps in creating a Pareto chart:
1. Determine the categories of problems or

causes to be compared.
2. Select a Standard Unit of Measurement and
the Time Period to be studied.
Pareto Charts
3. Collect and summarize the data. Create a
three-column table with the following
headings:
∙ Error/Problem Category
∙ Frequency
∙ Percent of Total
Error Category Frequency Percent of Total
Punctuation 22 44%
Grammar 15 30%
Spelling 10 20%
Typing 3 6%
Pareto Charts
4. Create the framework for the horizontal and
vertical axes of the Pareto Chart.
Pareto Charts
5. Plot the bars on the Pareto chart.
6. Interpret the Pareto chart.

Pareto Charts
∙ Some questions that Pareto chart answers:
∙ What are the largest issues facing our team or

business?
∙ What 20% of sources are causing 80% of the
problems (80/20 Rule)?
∙ Where should we focus our efforts to achieve
the greatest improvements?
Fishbone Diagram
∙ invented by Dr. Kaoru Ishikawa
∙ problem analysis tool that provides a
systematic way of looking at effects and the
causes that create or contribute to those
effects
∙ referred to as a cause-and-effect diagram
because of its function
Fishbone Diagram
∙ its main purpose is to assist project teams in

categorizing the many potential causes of
problems or issues in an orderly manner and
in identifying root causes
Fishbone Diagram
∙ The fishbone diagram is used if the project
team:
∙ Need to study a problem/issue to determine the
root cause
∙ Want to study all the possible reasons why a
process is beginning to have difficulties,
problems, or breakdowns
Fishbone Diagram
∙ Need to identify areas for data collection

∙ Want to study why a process is not performing
properly or producing the desired results
Fishbone Diagram
∙ Example of Fishbone Diagram
Fishbone Diagram
∙ Steps in constructing fishbone diagram:
1. List the problem/issue to be studied in the

head of the fish.
2. Label each bone of the fish. The major
categories typically used are:
∙ 4 M’s – Methods, Machines, Materials, Manpower
∙ 4 P’s – Place, Procedure, People, Policies
∙ 4 S’s – Surroundings, Suppliers, Systems, Skills
Fishbone Diagram
∙ 4 S’s – Surroundings, Suppliers, Systems, Skills
Take note that one of the four categories suggested
can be used or can be combined in any fashion. These
categories are helpful in organizing ideas.
4. Use an idea-generating technique to identify

the factors within each category that may be
affecting the problem/issue and/or effect
being studied.
Fishbone Diagram
4. Repeat this step with each factor under the
category to be produce sub-factors. Continue
asking the question: “Why is this happening?”
and put additional segments on each factor
and subsequently under each sub-factor.
5. Continue until you no longer get useful
information as you ask the question: “Why is
that happening?”
Fishbone Diagram
6. Analyze the results of the fishbone diagram
after team members agree to an adequate
amount of detail has been provided under
each major category.
7. Those items identified as the “most likely”
causes should reach the consensus of the team
on listing those items in priority order with
the first item being the “most probable” cause.
Entity-Relationship Diagram
∙ graphical representation of an E-R model
∙ notations used:
∙ Entities
∙ Attributes
∙ Candidate keys and identifiers
∙ Relationships
Determine Hardware and
Software Needs
∙ Steps in determining hardware and software
needs:
Software Needs
∙ Inventory Computer Hardware
∙ If an updated computer hardware is
unavailable, the systems analyst needs to set up
one quickly and carry through on it by
identifying the following:
1. The type of equipment: model number,
manufacturer.
2. The operation status of the equipment: on order,
operating, in storage, in need of repair.
3. The estimated age of the equipment.
Software Needs
4. The projected life of the equipment.

5. The physical location of the equipment.
6. The department or person considered responsible
for the equipment.
7. The financial arrangement for the equipment:
owned, leased, rented.
Software Needs
∙ Estimate Workloads
∙ Systems analysts formulate numbers that
represent both current and projected workloads
for the system so that any hardware obtained
will possess the capability to handle current and
future workloads.
∙ If estimates are accomplished properly, the
business should not have to replace hardware
solely due to unforeseen growth in system use.
Software Needs
∙ Out of necessity, workloads are sampled rather

than actually put through several computer
systems.
Software Needs
∙ Evaluate Computer Hardware
∙ Evaluation of computer hardware is the shared

responsibility of management, users, and
systems analysts.
∙ Systems analysts may have to educate users and
management about the general advantages and
disadvantages if hardware before they can
capably evaluate it.
Software Needs
∙ Criteria used by systems analysts and users
in evaluating performance of different
systems hardware:
∙ The time required for average transactions
(including how long it takes to input data and
how long it takes to receive output).
Software Needs
∙ The total volume capacity of the system (how

much can be processed at the same time before
a problem arises).
∙ The idle time of the central processing unit.
∙ The size of the memory provided.
Software Needs
∙ Determine Computer Equipment
∙ Three main options for determining computer
equipment:
∙ Buying
∙ the business itself will own the equipment
∙ Leasing
∙ from vendor or from third-party leasing company
∙ Renting
∙ makes it easier to change system hardware
Software Needs
Advantages Disadvantages
Purchasing - Cheaper than leasing or renting over the - Initial cost is high
long run - Risk of obsolescence
- Ability to change system - Risk of being stuck if choice was
- Provides tax advantages of accelerated wrong
depreciation - Full responsibility
- Full control
Leasing - No capital is tied up - Company doesn’t own the system when

- No financing is required lease expires
- Leases are lower than rental payments - Usually a heavy penalty for terminating
the lease
- Leases are more expensive than buying
Renting - No capital is tied up - Company doesn’t own the computer

- No financing is required - Cost is very high because vendor
- Easy to change systems assumes the risk (most expensive option)
- Maintenance and insurance are usually
included`
Software Needs
∙ Evaluate Software
∙ Analysts and organizations are increasingly
faced with a make, buy, or outsource decision
when assessing software for information
systems projects, particularly when
contemplating upgrades to existing or legacy
systems.
Software Needs
∙ Analysts decide whether to purchase COTS

software, rent software from an application
service provider (ASP), or create custom
software for the project.
Software Needs
Creating Custom Software - Specific response to specialized - May be significantly higher initial
business needs cost compared to COTS software of
Innovation may give firm a ASP
competitive advantage - Necessity of hiring or working
- In-house staff available to maintain with a development team
software - On-going maintenance
- Pride of ownership
Purchasing COTS Packages - Refined in the commercial world - Programming focused; not
- Increased reliability business focused
- Increased functionality - Must live with the existing
- Often lower initial cost features
- Already in use by other firms - Limited customization
- Help and training comes with - Uncertain financial future of
software vendor
- Less ownership and commitment
Software Needs
Using an ASP - Organizations that do not specialize in - Loss of control of data, systems, IT
information systems can focus on what they employees, and schedules
do best (their strategic mission) - Concern over the financial viability
- There is no need to hire, train, or retain a and long-run stability of the ASP
large IT staff - Security, confidentiality, and privacy
- There is no expenditure of employee time concerns
on non-essential IT tasks - Loss of potential strategic corporate
advantage regarding innovativeness
of applications
Identifying and Forecasting
Costs and Benefits
∙ Systems analysts are required to predict
certain key variables before the proposal is
submitted to the client.
∙ The systems analysts uses forecasting

models and the main condition for choosing
a model is the availability of historical data.
Costs and Benefits
∙
Costs and Benefits
∙ Conditional methods:
∙ Correlation
∙ Regression
∙ Leading indicators
∙ Econometrics
∙ Input/Output models
Costs and Benefits
∙ Unconditional methods:
∙ Graphical judgment
∙ Moving averages
∙ Analysis of time series data
Costs and Benefits
∙ If historical data are unavailable, the analyst
must turn to one of the judgment methods:
∙ Estimates from the sales force
∙ Surveys to estimate customer demand
∙ Delphi studies
∙ Creating scenarios
∙ Drawing historical analogies
Costs and Benefits
∙ Tangible Benefits
∙ an advantage measurable in dollars that accrue
to the organization through the use of
information system
∙ examples:
∙ An increase in the speed of processing
∙ Access to otherwise inaccessible information
∙ Access to information on a more timely basis than
was possible before
Costs and Benefits
∙ The advantage of the computer’s superior

calculating power
∙ Decreases in the amount of employee time needed to

complete specific tasks
Costs and Benefits
∙ Intangible Benefits
∙ difficult to measure but are important
nonetheless
∙ examples:
∙ Improving decision-making process
∙ Enhancing accuracy
∙ Becoming more competitive in customer service
∙ Maintaining a good business image
∙ Increasing job satisfaction for employees by
eliminating tedious tasks
Costs and Benefits
∙ Tangible Costs
∙ can be accurately projected by the system
analyst and the business’ accounting personnel
∙ examples:
∙ The cost of equipment such as computers and
terminals
∙ The cost of resources
∙ The cost of systems analysts’ time
∙ The cost of programmers’ time
∙ Other employees’ salaries
Costs and Benefits
∙ Intangible Costs
∙ difficult to estimate and may not be known
∙ examples:
∙ Losing a competitive edge
∙ Losing the reputation for being first with an
innovation or the leader in a field
∙ Declining company image due to increased
customer dissatisfaction
∙ Ineffective decision making due to untimely or
inaccessible information
Comparing Costs and Benefits
∙ Techniques for comparing the costs and
benefits of the proposed system:
∙ Break-Even Analysis
∙ Payback Period
∙ Cash-Flow Analysis
∙ Present Value Analysis
Guidelines for Analysis
1. Use break-even analysis if the project
needs to be justified in terms of cost, not
benefits, or if benefits do not substantially
improve with the proposed system.
2. Use payback when the improved tangible

benefits form a convincing argument for
the proposed system.
Guidelines for Analysis
3. Use cash-flow analysis when the project is
expensive relative to the size of the
company or when the business would be
significantly affected by a large drain on
funds.
4. Use present value analysis when the

payback period is long or when the cost of
borrowing money is high.
Systems Proposal
∙ Ten main sections comprise the written
systems proposal and should be arranged in
the following order:
1. Cover letter
2. Title page of project
3. Table of contents
4.
Systems Proposal
5. Outline of systems study with appropriate
documentation
6. Detailed results of the systems study
7. Systems alternatives (three or four possible
solutions)
8. Systems analysts’ recommendations
9. Proposal summary
10. Appendices (assorted documentation,
summary of phases, correspondence, and so
on)
Systems Proposal
∙ Integrating figures into your proposal helps
demonstrate that you are responsive to the
different ways people absorb information.
∙ Figures in the report supplement written

information and must always be interpreted
in words – these should never stand alone.
Systems Proposal
∙ Effective use of tables provide a different
way of grouping and presenting analyzed
data that the analyst wants to communicate
to the proposal reader.
∙ Tables use labeled columns and rows to

present statistical or alphabetical data in an
organized manner.
Systems Proposal
∙ Some guidelines for tables are the
following:
1. Incorporate tables into the body of the
proposal. Do not refer them to the
appendices.
2. Try to fit the entire table vertically on a single

page, if possible.
Systems Proposal
3. Number and title the table at the top of the
page. Make the title descriptive and relevant.
4. Label each row and column. Use more than
one line for a title, if necessary.
5. Use a boxed table if room permits. Vertically
ruled columns will enhance the readability.
6. If necessary, use footnotes to explain detailed
information contained in the table.
Systems Proposal
∙ The different kinds of graphs used in
systems proposal are:
∙
Systems Proposal
∙ Column Charts
Systems Proposal
∙ Bar Charts
Systems Proposal
∙ Pie Charts
Designing Databases
❑ What is System Design?
❑ Databases
❑ Database Design
❑ File Organization
❑ Relational Database Model
❑ Database Normalization
❑ Database Relationships
❑ Guidelines for Master File or
Database Relation Design
❑ Integrity Constraints
❑ Make Use of the Database
What is System Design?
• the systems analyst and the user develop a
concrete understanding of how the system
will operate
• process of defining the architecture,
components, modules, interfaces, and data
for a system to satisfy specified
requirements
What is System Design?
• similar to a set of blueprints used to build a

house
• also called physical design
• focuses on the technical or implementation
concern of the system
Databases
• integrated collection of stored data that is

centrally managed and controlled
• managed and controlled by a database

management system (DBMS)
Databases
• Effectiveness objectives of the database are:
• Ensure that data can be shared among users for

a variety of applications.
• Maintain data that are both accurate and
consistent.
• Ensure that all data required for current and
future applications will be readily available.
Databases
• Allow the database to evolve as the needs of the

users grow.
• Allow users to create their personal view of the
data without concern for the way the data are
physically stored.
Database Design
• Five purposes of database design:
1. Structure the data in stable structures, called
normalized tables, that are not likely to
change over time and that have minimal
redundancy.
2. Develop a logical database design that reflects
the actual data requirements that exist in the
forms (hard copy and computer displays) and
reports of an information system.
Database Design
3. Develop a logical database design from which
we can do physical database design.
4. Translate a relational database model into a
technical file and database design that
balances several performance factors.
5. Choose data storage technologies (i.e., CD-
ROM or optical disk) that will efficiently,
accurately, and securely process database
activities.
Database Design
• A logical database model is developed,
which describes data using a notation that
corresponds to a data organization used by a
database management system.
• Relational database model
• A physical database model is developed that

provides these specifications.
File Organization
• File Types:
• Master Files
• collection of records pertaining to one of the main
subjects of an information system
• Table Files
• include data that is used to calculate more data or
performance measures
• Transaction Files
• collection of records
File Organization
• Work Files
• sometimes make a program run more efficiently
• Report Files
• a report file is a file that describes how a report is
printed.
Relational Database Model
• represents data in the form of related tables,

or relations
• Relation
• named, two-dimensional table of data
• Example:
Stud_ID Name Course
1001 Juan Dela Cruz BSECE
1002 Tony Sy BSCE
1003 Hannah Reyes BSCS
1004 Maria Santos BSBA
1005 Leah Meneses BSIT
1006 Carol Mina BSN
STUDENT(Stud_ID, Name, Course)

• Properties of relations that differentiate them from
non-relational tables:
1. Entries in cells are simple. An entry at the

intersection of each row and column has a
single value.
2. Entries in a given column are from the same
set of values.
3. Each row is unique. Uniqueness is guaranteed

since the relation has a non-empty primary
key value.
4. The sequence of columns can be interchanged
without changing the meaning or use of the
relation.
5. The rows may be interchanged or stored in
any sequence.
• Steps to follow in creating a relational
database schema:
1. Create a table for each entity type.

2. Choose a primary key for each table (invent
one, if necessary).
3. Add foreign keys to represent one-to-many
relationships.
4. Create new tables to represent many-to-many

relationships.
5. Define referential integrity constraints.
6. Evaluate schema quality and make necessary
improvements.
7. Choose appropriate data types and value
restrictions (if necessary) for each field.
Database Normalization
• First Normal Form (1NF)

• A relation is in first normal form it is contains
no repeating fields or group of fields.
• Example:
Cust_ID First Name Surname Tel_Num
101 Juan Dela Cruz 891-8959
891-8960
102 Tony Sy 874-5612
874-5613
103 Hannah Reyes 887-4526
Cust_ID First Name Surname Tel_Num

102 Tony Sy 874-5612
102 Tony Sy 874-5613
103 Hannah Reyes 887-4526
• Functional Dependency (FD)
• This occurs when one attribute in a relation
uniquely determines another attribute.
• This can be written as A → B which would be
the same as stating "B is functionally dependent
upon A."
• Example:
• name is functionally dependent upon SSN (or SSN
→ name)
• Second Normal Form (2NF)
• A relation is in second normal form if it is in
first normal form and if each non-key element
is functionally dependent on the entire primary
key.
• Example:
Cust_ID Tel_Num
Cust_ID First Name Surname
101 891-8959
101 Juan Dela Cruz 101 891-8960
102 Tony Sy 102 874-5612
103 Hannah Reyes 102 874-5613
103 887-4526
Customer Table Customer_Telephone

Table
• Third Normal Form (3NF)
• A normalized relation is in the third normal
form if it is in second normal form and if no
non-key element is functionally dependent on
any other non-key element.
• Example:
Stud_ID Stud_Name Stud_Add
1010 Roselle Perez Laguna
1020 Sarah Basco Antipolo
1030 Michelle Reyes Rizal
Student Table
Stud_ID Course_ID Instructor_ID
1010 SYSAD 01
1020 COMORG 02
1030 DATACOM 03
Enrollment Table
Course_ID Course_Title
SYSAD Systems Analysis and Design
COMORG Computer Organization
DATACOM Data Communication
Course Table
• Example:
Stud_ID Stud_Name Stud_Add
1010 Roselle Perez Laguna
1020 Sarah Basco Antipolo
1030 Michelle Reyes Rizal
Student Table
Stud_ID Course_ID Instructor_ID
1010 SYSAD 01
1020 COMORG 02
1030 DATACOM 03
Enrollment Table
Course_ID Course_Title
SYSAD Systems Analysis and Design
COMORG Computer Organization
DATACOM Data Communication
Course Table
Instructor_ID Instructor_Name
01 Benet Tanyag
02 Rolly Torio
03 Tanya Torres
Instructor Table
Database Relationships
• One-to-One Relationship
• occurs when there is exactly one record in the
first table that corresponds to exactly one
record in the related table
• Example:
• One-to-Many Relationship
• primary key table contains only one record that
relates to none, one, or many records in the
related table
• Example:
• Many-to-Many Relationship
• relationship between two tables in which one
record in either table can have many matching
records in the other table
• Example:
Guidelines for Master File or
• Each separate data entity should create a

master database table. Do not combine two
distinct entities on one file.
• A specific data field should exist only on
one master table.
Guidelines for Master File or
• Every master table or database relation

should have programs to Create, Read,
Update, and Delete (CRUD) the records. If
possible, only one program should add new
records and only one program should delete
specified records.
Integrity Constraints
• Entity integrity
• rules that manage the composition of primary
keys
• Referential integrity
• describes a consistent state among foreign key
and primary key values
• Domain integrity
• used to validate the data, such as table, limit,
range, and other validation checks
Make Use of the Database
1. Choose a relation from the database.
• accomplished by keeping a directory of user views as
a memory aid
2. Join two relations together.
• intended to obtain two relations and put them together
to create a larger relation
• Example:
CUSTOMER (CUST_NUM, CUST_NAME, WAREHOUSE_NUM)
and
WAREHOUSE (WAREHOUSE_NUM, WAREHOUSE-LOC)
3. Project columns from the relation.

• process of extracting certain columns from a relational
table
• Example:
CUSTOMER-WAREHOUSE-LOCATION (CUST_NUM,
CUST_NAME, WAREHOUSE_NUM), WAREHOUSE_LOC
4. Select rows from the relation.
• creates a new (smaller) relation by extracting records
that consist of an attribute meeting a particular
condition
5. Derive new attributes.

• involves the manipulation of the existing data plus
some additional parameters (if necessary) to derive
new data
6. Index or sort rows.
• Indexing - is the logical ordering of rows in a relation
according to some key.
• Sorting - is the physical ordering of a relation.
7. Calculate totals and performance measures.

• done when the proper subset of data is defined and the
rows of the relation are ordered in the required way
8. Present data.
• final step in the retrieval of data
Designing the User
Interface
❑ What is User Interface?
❑ Guidelines for Designing User Interface
❑ Types of User Interface
❑ Guidelines for Designing Dialog
❑ Providing Feedback for Users
❑ Providing Help
❑ Guidelines for Designing Web Sites
❑ Web Site Design Principles
What is User Interface?
∙ the aggregate of means by which people—
the users—interact with the system
∙ it provides means of input and output.
∙ user interface is the system itself.

∙ aspects:
∙ Physically
∙ Perceptually
∙ Conceptually
∙ Objectives in designing user interface:
∙ Match the user interface to the task.
∙ Make the user interface efficient.
∙ Provide appropriate feedback to users.
∙ Generate usable queries.
∙ Improve productivity of knowledge workers.
∙ Two main components:
∙ Presentation language
∙ Action language
Guidelines for Designing User
Interface
∙ Strive for consistency.
∙ Enable frequent users to use shortcuts.
∙ Offer informative feedback.
∙ Design dialogs to yield closure.
∙ Offer simple error handling.
∙ Permit easy reversal of actions.
∙ Support internal locus of control.
∙ Reduce short-term memory load.
Types of User Interface
∙ Natural-Language Interface
∙ permits users to interact with the computer in
their everyday or natural language
∙ no special skills required of the user who
interacts with the computer
∙ Question-and-Answer Interface
∙ the computer displays a question to the user on
the display
∙ the user enters an answer (via keyboard stroke
or mouse click), and the computer acts on that
input information
∙ dialog box is a type of this interface
∙ examples include use of wizard and Office
Assistant in MS applications
∙ Menu Interface
∙ provides the user with an onscreen list of
available selections
∙ users are limited to the options displayed
∙ users should need to know what task should be
accomplished and not the system.
∙ users should know which task they desire to

perform when utilized
∙ can be set up to use keyboard entry, lightpen, or
mouse
∙ consistency in design
∙ Menu Interface
∙ GUI menus are used to control PC software and
have the following guidelines:
1. The main menu bar is always displayed.
2. The main menu uses single words for menu items.
Main menu options always display secondary pull-
down menus.
3. The main menu should have secondary options
grouped into similar sets of features.
4. The drop-down menus that display when a main
menu item is clicked often composed of more than
one word.
5. These secondary options carry out actions or
display additional menu items.
6. Menu items in grey (disabled) are unavailable for
the current activity.
∙ Clicking on a GUI object with the right mouse
button, an object menu (or pop-up menu) is
displayed.
∙ Form-Fill Interface
∙ input/output forms
∙ consists of onscreen forms or Web-based forms
displaying fields containing data items or
parameters that need to be communicated to
users
∙ effectively designed form contains the
following:
∙ a self explanatory title and field headings
∙ has fields organized into logical groupings with
distinctive boundaries
∙ provides default values when practical
∙ displays data in appropriate field lengths
∙ minimizes the need to scroll windows
∙ input forms for display can be simplified when
supplied with default values for fields and
allow users modify default information
Form-fill interface from the

Google Advanced Search Engine
∙ its benefit is that the printed version of the
filled-in form provides excellent documentation
∙ the main drawback is that experienced users
may become impatient and may want more
efficient ways to enter data
∙ Command-Language Interface
∙ allows the user to enter explicit statements to
invoke operations within a system
∙ requires users to remember command syntax
and semantics
∙ can be a burden to users since they need to
memorize names, syntax, and operations
∙ experienced users prefer this type because of
the faster completion time it allows
∙ Graphical User Interface (GUI)
∙ allows users to directly manipulate the
graphical representation on the screen via
keyboard input, joystick, or mouse
∙ presents graphical icons, visual indicators, or
special graphical elements called “widgets”
∙ continuous feedback on task accomplishment
these provide
∙ sets a challenge because an appropriate model
of reality or a satisfactory conceptual model of
the representation should be invented
∙ when used in on intranets, extranets, or Web, it
requires careful planning
∙ Stylus
∙ pointed stick that looks like a pen
∙ becoming popular because of new handwriting
recognition software and PDAs
∙ examples include Palm and Pocket/PC devices
and tablet PC
∙ Touch-sensitive screens
∙ allow users to use finger in activating the
display
∙ can be useful in public information displays
∙ can be used also in explaining dioramas in
museums and in locating camping facilities in
parks
∙ need no special expertise from users, and the
screen is self-contained
∙ Voice recognition and synthesis
∙ allows the users speak to the computer while
the system is able to recognize the individual’s
vocal signals, convert them, and store the input
∙ its benefit is that it can speed data entry, and
free the user’s hands for other tasks
∙ speech input can be added to PC with the use of
equipment and software that allows a PC user
to speak commands
∙ increased accuracy and greater speed
∙ two main developments:
∙ continuous speech systems that allow for the input
of regular text in word processors, and
∙ speaker independence so that any number of people
can enter commands or words at a given
workstation
∙ Standards to consider in assessing the
interfaces chosen
1. The training period necessary for users should
be acceptably short.
2. Users who are early in their training should be
able to enter commands without thinking
about them or without referring to a help
menu or manual. Keeping the interfaces
consistent throughout the application can be
helpful in this regard.
3. The interface should be faultless so that errors
are few and those that do occur are not
occurring because of poor design.
4. The time that users and the system need to
recover from errors should be short.
5. Occasional users should be able to study
again the system quickly.
Guidelines for Designing Dialog
∙ Meaningful communication so that the
computer understands what people are
entering and people understand what the
computer is presenting or requesting.
∙ Minimal user action.
∙ Standard operation and consistency.
∙ Minimal User Action
1. Entering codes rather than whole words on
entry screens. Codes are also entered when
using a command-language interface.
2. Only entering data that are not already stored
on files.
3. Supplying the editing characters (e.g., slashes
as date field separators).
4. Using default values for fields on entry
screens.
5. GUI’s may include checkboxes and radio
buttons that are selected when a dialog box
open.
6. Designing an inquiry (or change or delete)
program so that the user needs to input only
the first few characters of a name or item
description.
7. Providing keystrokes for selecting pull-down
menu options.
∙ Standard Operation and Consistency
1. Locating titles, date, time, and operator and
feedback messages in the same places on all
displays.
2. Exiting each program by the same key or
menu option.
3. Canceling a transaction in a consistent
manner, usually with the use of a function key
(F12) on a mainframe and the ESC key on a
PC.
4. Getting help in a standardized manner.
5. Standardizing the colors used for all displays.
6. Standardizing the use of icons for similar
operations when using a GUI.
7. Using consistent terminology in a display
screen or Web site.
8. Providing a consistent way to navigate
through the dialog.
9. Using consistent font alignment, size, and
color on a Web page.
Providing Feedback for Users
∙ Status Information
∙ keeps users informed of what is going on
within the system
∙ important during processing operations
∙ inform the user that besides working, the
system has accepted the user’s input and that
the input was in the correct form
∙ assures users that nothing is wrong with the
system and it would make them feel in
command of the system
∙ Prompting Cues
∙ be specific with request when prompting the
user for information or action
∙ example:
READY FOR INPUT: _____
Enter account number (123-456-7): ___-___-__

∙ Error or Warning Messages
∙ messages should be specific and free of error
codes and jargon
∙ messages should never scold the user and
should guide them toward a resolution
∙ messages should be in user terms and not in
computer terms
∙ use multiple messages so users can get more
detailed explanations when needed or wanted
∙ error messages should appear in the same
format and placement each time
Poor Error Messages Improved Error Messages
ERROR 30 OPENING FILE The file name you typed was not found. Press
F2 to list valid file names.
WRONG CHOICE Please enter an option from the menu.

DATA ENTRY ERROR The prior entry contains a value outside the
range of acceptable values. Press F9 for list of
acceptable values.
FILE CREATION ERROR The file name you entered already exists. Press
F10 if you want to overwrite it. Press F2 if you
want to save it to a new name.
Providing Help
∙ Guidelines for designing usable help:
∙ Simplicity
∙ Organize
∙ Show
∙ Types of help:
∙ F1 or pull-down help menu
∙ Context-sensitive help
∙ Pop-up balloon help
∙ Help wizard
Guidelines for Designing
Web Sites
1. Place the organization’s name and logo on

every page and make the logo a link to the
home page.
2. Include a search function if the site has
more than 100 pages.
Web Sites
3. Write straightforward and simple headlines
and page titles that clearly explain what the
page is about and that will make sense
when read out of context in a search engine
listing.
4. Structure the page to facilitate reader
scanning and help users ignore large
chunks of the page in a single glance.
Web Sites
5. Do not place everything about a product or
topic into a single, huge page.
6. Use product photos, however, avoid
cluttered and bloated product family pages
with lots of photos.
7. Use relevance-enhanced image reduction
when preparing small photos and images.
Web Sites
8. Use link titles to give users a preview of
where each link will take them, before they
have clicked on it.
9. Make sure that all necessary pages are
accessible for users with disabilities,
especially visually impaired users.
Web Sites
10.Do the same as everybody else, because if
most big Web sites do something in a
certain way, users will expect other sites to
work similarly.
Web Site Design Principles
∙ Designing for the Computer Medium
1. Craft the look and feel of the pages to take
advantage of the medium.
2. Make the design portable since it will be
accessed with a wide range of technology.
3. Design for low bandwidth since users will not
want to wait for a page to load.
4. Plan for clear presentation and easy access to
information to aid the user in navigating
through the site.
5. Reformat information for online presentation
when it comes from other sources.
∙ Designing the Whole Site
1. Craft the look and feel of the pages to match
the idea preferred by the organization.
2. Create smooth transitions between Web pages
so that users are clear about where they have
been and where they are going.
3. Design each page using a grid pattern to

provide visual structure for related groups of
information.
4. Place a reasonable amount of white space on
each page between groups of information.
∙ Designing for the User
1. Design for interaction since Web users expect
sites to be interactive and dynamic.
2. Guide the user’s eye to information on the
page that is the most important.
3. Keep a flat hierarchy so that the user does not
have to drill down too deeply to find detailed
information.
4. Use the power of hypertext linking to help

users navigate through the site.
5. Decide how much content per page is enough
based on the characteristics of the typical
user; do not clutter the page.
6. Design for accessibility for a diverse group of
users; including those with disabilities.

Merge Lesson 1 7

Uploaded by

Document Information

Original Description:

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

Merge Lesson 1 7

Uploaded by

Copyright:

Available Formats

Introduction to

∙ Three major components:

∙ advances in communication technologies to

∙ Systems Analyst as Supporting Expert

∙ understand the type of organization for which

∙ What the specific organization does

∙ possess many interpersonal skills

∙ understand how people:

∙ understand and document the business needs

∙ upgrades or enhancements may be carried out

∙ also known as structured system development

∙ Object-oriented design (OOD)

∙ Object-oriented programming (OOP)

∙ based on the metaphor that when one phase

∙ some alternatives include joint application

A drawback of a spiral model is that estimates

∙ uses UML (a standard modeling notation for

∙ defines roles played by developers and

The emphasis on speed can adversely impact

∙ helps systems analysts to establish the

∙ Review of documentation helps identify

∙ To make sure that assumptions and business

∙ Interviewing is a directed conversation with

∙ To conduct an effective interview, a system

∙ Prepare for the Interview

∙ Methodologies commonly used to model

∙ Using questionnaires allows systems

∙ You are doing an exploratory study and want to

∙ Do not patronize respondents by talking down

∙ Ensure that questions are technically accurate

∙ JAD is an alternative approach to

∙ The reasons for using JAD are:

∙ to improve the quality of the results of

∙ Conditions that support the use of JAD:

∙ Analysts forecast that the number of ideas

∙ Participants involved in JAD sessions:

∙ Disadvantages of using JAD:

The necessary organizational skills and

Data flow Data store

4. Create a child diagram for each of the

7. Partition the physical data flow diagram by

∙ Data cannot move directly to an outside sink from a

∙ It has only one direction of flow between symbols.

∙ A fork in a data flow means that exactly the same

∙ A join in a data flow means that exactly the same

∙ It cannot go directly back to the same process it

∙ A data flow to a data store means update (delete or

∙ A data flow from a data store means retrieve or use.

∙ A data flow has a noun phrase label. More than one

Create the logical DFD for the new system

Derive the physical DFD by examining

∙ Clarifying which processes are manual and

∙ Identifying temporary data stores

∙ Sequencing processes to rearrange the order of

∙ Item Master = Item Number + Price + Quantity

∙ A structured English is used when:

∙ useful when complex combinations of

∙ determine the maximum size of the table

8. Check the table for any impossible situations,

∙ Complex combinations of conditions, actions,

∙ Two main components:

∙ Identify the conditions

1 Sleep one more

Enter account number (123-456-7): _-_-__