INTRODUCTION
After an overview of the systems analysis phase, this
chapter describes requirements modeling techniques
and team-based methods that systems analysts use
to visualize and document new systems. The chapter
then discusses system requirements and factfinding
techniques, which include interviewing,
documentation review, observation, surveys and
questionnaires, sampling, and research.
Chapter 4 includes a Video Learning Session that
shows you how to use a functional decomposition
diagram (FDD) to model business functions and
processes.
Introduction
Phase 2 Systems Analysis
141
CHAPTER INTRODUCTION CASE: Mountain View College Bookstore
Background: Wendy Lee, manager of college services at Mountain View College, wants a new
information system that will improve efficiency and customer service at the three college
bookstores.
In this part of the case, Tina Allen (systems analyst) and David Conroe (student intern)
are talking about requirements modeling tasks and concepts.
Participants: Tina and David
Location: Tina’s office, Monday morning, October 3, 2011
Project status: The project has advanced to the systems analysis phase. Now, Tina and David will work on
modeling, fact-finding, and the documentation they need to build a requirements model for
the proposed bookstore information system.
Discussion topics: Modeling, team-based development strategies, fact-finding techniques, and documentation
Tina: Before I tell you about the project,
look at this Dilbert cartoon. You’ll
like it!
David: It’s funny, but scary too. Hope it
doesn’t apply to us!
Tina: Me too. That’s why we have to
do a good job of requirements
modeling.
David: So, what do we do next?
Tina: We need to create a model of the
new system. We call this a requirements
model, because it will
include all the outputs, inputs, processes,
and controls for the new
system. The model will consist of
various diagrams, charts, and documentation.
David: How will we use the model when
we’re done?
Tina: We’ll study it carefully and review it frequently with system users.
David: Who are the users?
Tina: Users might include bookstore staff, students, faculty members, and the college business office. External users
might include textbook publishers and suppliers of bookstore merchandise. The main thing is to work with
users every step of the way. We’ll perform fact-finding, and we’ll document everything carefully. Here’s a task
list to get us started:
DILBERT: © Scott Adams/Dist. by United Feature Syndicate, Inc.
FIGURE 4-1 Typical requirements modeling task list.
SYSTEMS ANALYSIS PHASE
OVERVIEW
The overall objective of the systems analysis
phase is to understand the proposed project,
ensure that it will support business requirements,
and build a solid foundation for system
development. In this phase, you use
models and other documentation tools to
visualize and describe the proposed system.
Systems Analysis Activities
The systems analysis phase includes the four
main activities shown in Figure 4-2: requirements
modeling, data and process modeling,
object modeling, and consideration of development
strategies.
Although the waterfall model shows
sequential SDLC phases, it is not uncommon
for several phases (or certain tasks within a
phase) to interact during the development process,
just as they would in an adaptive model.
For example, this occurs whenever new facts
are learned or system requirements change
during the modeling process. Figure 4-2 shows
typical interaction among the three modeling
tasks: requirements modeling, data and process
modeling, and object modeling.
REQUIREMENTS MODELING This chapter describes requirements modeling, which
involves fact-finding to describe the current system and identification of the requirements
for the new system, such as outputs, inputs, processes, performance, and security.
Outputs refer to electronic or printed information produced by the system. Inputs refer
to necessary data that enters the system, either manually or in an automated manner.
Processes refer to the logical rules that are applied to transform the data into meaningful
information. Performance refers to system characteristics such as speed, volume,
capacity, availability, and reliability. Security refers to hardware, software, and procedural
controls that safeguard and protect the system and its data from internal or
external threats.
DATA AND PROCESS MODELING In Chapter 5, Data and Process Modeling, you will
continue the modeling process by learning how to represent graphically system data and
processes using traditional structured analysis techniques. As you learned in Chapter 1,
structured analysis identifies the data flowing into a process, the business rules that transform
the data, and the resulting output data flow.
OBJECT MODELING Chapter 6 discusses object modeling, which is another popular
modeling technique. While structured analysis treats processes and data as separate
components, object-oriented analysis (O-O) combines data and the processes
that act on the data into things called objects. These objects represent actual
people, things, transactions, and events that affect the system. During the system
FIGURE 4-2 The systems analysis phase consists of requirements modeling,
data and process modeling, object modeling, and consideration of development
strategies. Notice that the systems analysis tasks are interactive, even though
the waterfall model generally depicts sequential development.
Data and
Process
Modeling
Requirements
Modeling
Development
Strategies
Object
Modeling
Systems Analysis Phase Tasks
VIDEO
LEARNING
SESSIONS
To learn more about
data flow diagrams,
visit the
Management
Information Systems
CourseMate Web
site at www.
cengagebrain.
com and navigate to
the Video
Learning Sessions
for this book. These
sessions can help
you understand key
concepts, practice
your skills, and
check your work.
Joint Application Development
Phase 2 Systems Analysis
143
development process, analysts often use both modeling methods to gain as much
information as possible.
DEVELOPMENT STRATEGIES In Chapter 7, Development Strategies, you will consider
various development options and prepare for the transition to the systems design phase
of the SDLC. You will learn about software trends, acquisition and development alternatives,
outsourcing, and formally documenting requirements for the new system.
The deliverable, or end product, of the systems analysis phase is a system requirements
document, which is an overall design for the new system. In addition, each activity within
the systems analysis phase has an end product and one or more milestones. As you learned
in Chapter 3, project managers use various tools and techniques to coordinate people,
tasks, timetables, and budgets.
Systems Analysis Skills
You will need strong analytical and interpersonal skills to build an accurate model of the
new system. Analytical skills enable you to identify a problem, evaluate the key elements,
and develop a useful solution. Interpersonal skills are especially valuable to a systems
analyst who must work with people at all organizational levels, balance conflicting needs
of users, and communicate effectively.
Because information systems affect people throughout the company, you should consider
team-oriented strategies as you begin the systems analysis phase.
Team-Based Techniques: JAD, RAD, and Agile Methods
The IT department’s goal is to deliver the best possible information system, at the lowest
possible cost, in the shortest possible time. To achieve the best results, system developers
view users as partners in the development process. Greater user involvement usually
results in better communication, faster development times, and more satisfied users.
The traditional model for systems development was an IT department that used
structured analysis and consulted users only when their input or approval was needed.
Although the IT staff still has a central role, and structured analysis remains a popular
method of systems development, most IT managers invite system users to participate
actively in various development tasks.
As you learned in Chapter 1, team-based approaches have been around for some time.
A popular example is joint application development (JAD), which is a user-oriented technique
for fact-finding and requirements modeling. Because it is not linked to a specific
development methodology, systems developers use JAD whenever group input and interaction
are desired.
Another popular user-oriented method is rapid application development (RAD).
RAD resembles a condensed version of the entire SDLC, with users involved every step
of the way. While JAD typically focuses only on fact-finding and requirements determination,
RAD provides a fast-track approach to a full spectrum of system development
tasks, including planning, design, construction, and implementation.
Finally, as you learned in Chapter 1, agile methods represent a recent trend that
stresses intense interaction between system developers and users. JAD, RAD, and agile
methods are discussed in the following sections.
JOINT APPLICATION DEVELOPMENT
Joint application development (JAD) is a popular fact-finding technique that brings
users into the development process as active participants.
To learn more about
interpersonal skills,
visit the Management
Information Systems
CourseMate Web
site at www.
cengagebrain.
com, navigate to On
the Web Links for
this chapter, and
locate the
Interpersonal
Skills link.
User Involvement
Users have a vital stake in an information system, and they should participate fully in
the development process. Until recent years, the IT department usually had sole responsibility
for systems development, and users had a relatively passive role. During the
development process, the IT staff would collect information from users, define system
requirements, and construct the new system. At various stages of the process, the IT staff
might ask users to review the design, offer comments, and submit changes.
Today, users typically have a much more active role in systems development. IT professionals
now recognize that successful systems must be user-oriented, and users need
to be involved, formally or informally, at every stage of system development.
One popular strategy for user involvement is a JAD team approach, which involves a
task force of users, managers, and IT professionals that works together to gather information,
discuss business needs, and define the new system requirements.
JAD Participants and Roles
A JAD team usually meets over a period of days or weeks in a special conference room
or at an off-site location. Either way, JAD participants should be insulated from the distraction
of day-to-day operations. The objective is to analyze the existing system, obtain
user input and expectations, and document user requirements for the new system.
The JAD group usually has a project leader, who needs strong interpersonal and
organizational skills, and one or more members who document and record the results
and decisions. Figure 4-3 describes typical JAD participants and their roles. IT staff
members often serve as JAD project leaders, but that is not always the case. Systems
analysts on the JAD team participate in discussions, ask questions, take notes, and provide
support to the team. If CASE tools are available, analysts can develop models and
enter documentation from the JAD session directly into the CASE tool.
A typical JAD session agenda is shown in Figure 4-4. The JAD process involves
intensive effort by all team members. Because of the wide range of input and constant
interaction among the participants, many companies believe that a JAD group produces
the best possible definition of the new system.
To learn more about
JAD, visit the
Management
Information Systems
CourseMate Web
site at www.
cengagebrain.
com, navigate to
On the Web Links
for this chapter, and
locate the JAD link.
FIGURE 4-3 Typical JAD participants and roles.
JAD PARTICIPANT ROLE
JAD project leader Develops an agenda, acts as a facilitator, and leads the JAD session
Top management Provides enterprise-level authorization and support for the project
Managers Provide department-level support for the project and understanding
of how the project must support business functions and requirements
Users Provide operational-level input on current operations, desired changes,
input and output requirements, user interface issues, and how the project
will support day-to-day tasks
Systems analysts and Provide technical assistance and resources for JAD team members on
other IT staff members issues such as security, backup, hardware, software, and network
capability
Recorder Documents results of JAD sessions and works with systems analysts
to build system models and develop CASE tool documentation
Rapid Application Development
Phase 2 Systems Analysis
145
JAD Advantages and Disadvantages
Compared with traditional methods, JAD is more expensive and can be cumbersome if
the group is too large relative to the size of the project. Many companies find, however,
that JAD allows key users to participate effectively in the requirements modeling process.
When users participate in the systems development process, they are more likely to feel a
sense of ownership in the results, and support for the new system. When properly used,
JAD can result in a more accurate statement of system requirements, a better understanding
of common goals, and a stronger commitment to the success of the new system.
RAPID APPLICATION DEVELOPMENT
Rapid application development (RAD) is a team-based technique that speeds up
information systems development and produces a functioning information system.
Like JAD, RAD uses a group approach, but goes much further. While the end product
of JAD is a requirements model, the end product of RAD is the new information system.
RAD is a complete methodology, with a four-phase life cycle that parallels the
traditional SDLC phases. Companies use RAD to reduce cost and development time,
and increase the probability of success.
RAD relies heavily on prototyping and user involvement. The RAD process allows
users to examine a working model as early as possible, determine if it meets their needs,
and suggest necessary changes. Based on user input, the prototype is modified and the
interactive process continues until the system is completely developed and users are satisfied.
The project team uses CASE tools to build the prototypes and create a continuous
stream of documentation.
RAD Phases and Activities
The RAD model consists of four phases: requirements planning, user design, construction,
and cutover, as shown in Figure 4-5. Notice the continuous interaction between the
user design and construction phases.
To learn more about
RAD, visit the
Management
Information Systems
CourseMate Web
site at www.
cengagebrain.
com, navigate to
On the Web Links
for this chapter, and
locate the RAD link.
REQUIREMENTS PLANNING The requirements planning phase combines elements of
the systems planning and systems analysis phases of the SDLC. Users, managers, and IT
staff members discuss and agree on business needs, project scope, constraints, and system
requirements. The requirements planning phase ends when the team agrees on the
key issues and obtains management authorization to continue.
USER DESIGN During the user design phase, users interact with systems analysts and
develop models and prototypes that represent all system processes, outputs, and inputs.
The RAD group or subgroups typically use a combination of JAD techniques and
CASE tools to translate user needs into working models. User design is a continuous,
Requirements
Planning
User
Design Construction
Cutover
Cutover Tasks
• Data conversion
• Full-scale testing
• System changeover
• User training
Construction Tasks
• Program and
application
development
• Coding
• Unit, integration,
and system testing
Requirements Planning
Tasks
• Users, managers, and IT
staff agree upon business
needs, project scope, and
systems requirements
• Obtain approval to
continue
User Design Tasks
• Interact with users
• Build models and
prototypes
• Conduct intensive
JAD-type sessions
FIGURE 4-5 The four phases of the RAD model are requirements planning, user design, construction,
and cutover. Notice the continuous interaction between the user design and construction phases.
Agile Methods
Phase 2 Systems Analysis
147
interactive process that allows users to understand, modify, and eventually approve a
working model of the system that meets their needs.
CONSTRUCTION The construction phase focuses on program and application development
tasks similar to the SDLC. In RAD, however, users continue to participate and
still can suggest changes or improvements as actual screens or reports are developed.
CUTOVER The cutover phase resembles the final tasks in the SDLC implementation
phase, including data conversion, testing, changeover to the new system, and user training.
Compared with traditional methods, the entire process is compressed. As a result,
the new system is built, delivered, and placed in operation much sooner.
RAD Objectives
The main objective of all RAD approaches is to cut development time and expense by
involving users in every phase of systems development. Because it is a continuous
process, RAD allows the development team to make necessary modifications quickly,
as the design evolves. In times of tight corporate budgets, it is especially important to
limit the cost of changes that typically occur in a long, drawn-out development
schedule.
In addition to user involvement, a successful RAD team must have IT resources, skills,
and management support. Because it is a dynamic, user-driven process, RAD is especially
valuable when a company needs an information system to support a new business function.
By obtaining user input from the beginning, RAD also helps a development team design a
system that requires a highly interactive or complex user interface.
RAD Advantages and Disadvantages
RAD has advantages and disadvantages compared with traditional structured analysis
methods. The primary advantage is that systems can be developed more quickly with significant
cost savings. A disadvantage is that RAD stresses the mechanics of the system itself
and does not emphasize the company’s strategic business needs. The risk is that a system
might work well in the short term, but the corporate and long-term objectives for the system
might not be met. Another potential disadvantage is that the accelerated time cycle
might allow less time to develop quality, consistency, and design standards. RAD can be an
attractive alternative, however, if an organization understands the possible risks.
AGILE METHODS
In Chapter 1, you learned that agile methods attempt to develop a system incrementally,
by building a series of prototypes and constantly adjusting them to user requirements.
As the agile process continues, developers revise, extend, and merge earlier versions into
the final product. An agile approach emphasizes continuous feedback, and each incremental
step is affected by what was learned in the prior steps.
As agile methods become more popular, a large community of agile-related software
and services has evolved. For example, Visual Paradigm offers Agilian, which includes a
set of agile modeling tools, as shown in Figure 4-6 on the next page. The Agilian modeling
toolset includes support for many modeling tools, such as the Unified Modeling
Language, entity-relationship diagrams, data flow diagrams, and business process
modeling, among others.
Some agile developers prefer not to use CASE tools at all, and rely instead on whiteboard
displays and arrangements of movable sticky notes. This approach, they believe,
reinforces the agile strategy: simple, rapid, flexible, and user-oriented.
Scrum is another agile approach. The name is derived from the rugby term scrum
(Figure 4-7), where team members prepare to lunge at each other to achieve their objectives.
The systems development version of Scrum involves the same intense interaction,
though more mental than physical. In a Scrum session, agile team members play specific
roles, including colorful designations as pigs or chickens. These roles are based on the
old joke about the pig and chicken who discuss a restaurant where ham and eggs would
be served. However, the pig declines, because that role would require a total commitment,
while for the chicken, it would only be a contribution.
In the agile world, the pigs include the product owner, the facilitator, and the development
team; while the chickens include users, other stakeholders, and managers. Scrum
sessions have specific guidelines that emphasize time blocks, interaction, and team-based
activities that result in deliverable software.
To learn more
about agile methods,
visit the
Management
Information Systems
CourseMate Web
site at www.
cengagebrain.
com, navigate to
On the Web
Links for this chapter,
and locate the
Agile Methods link.
FIGURE 4-6 Visual Paradigm’s Agilian includes many types of agile modeling tools.
Modeling Tools and Techniques
Phase 2 Systems Analysis
149
Agile Method Advantages and Disadvantages
Agile, or adaptive, methods are very flexible and efficient in dealing with change. They
are popular because they stress team interaction and reflect a set of community-based
values. Also, frequent deliverables constantly validate the project and reduce risk.
However, some potential problems exist. For example, team members need a high
level of technical and interpersonal skills. Also, a lack of structure and documentation
can introduce risk factors. Finally, the overall project may be subject to significant
change in scope as user requirements continue to evolve during the project.
FIGURE 4-7 In a rugby scrum, team members prepare to lunge at each other to achieve their objectives.
CASE IN POINT 4.1: NORTH HILLS COLLEGE
North Hills College has decided to implement a new registration system that will allow
students to register online, as well as in person. As IT manager, you decide to set up a JAD
session to help define the requirements for the new system. The North Hills organization
is fairly typical, with administrative staff that includes a registrar, a student support and services
team, a business office, an IT group, and a number of academic departments. Using
this information, you start work on a plan to carry out the JAD session. Who would you
invite to the session, and why? What would be your agenda for the session, and what
would take place at each stage of the session?
MODELING TOOLS AND TECHNIQUES
Models help users, managers, and IT professionals understand the design of a system.
Modeling involves graphical methods and nontechnical language that represent the system
at various stages of development. During requirements modeling, you can use various tools
to describe business processes, requirements, and user interaction with the system.
In Chapter 1, you learned about CASE tools that offer powerful modeling features.
CASE tool modeling is discussed in detail in Part B of the Systems Analyst’s Toolkit.
Systems analysts use modeling and fact-finding interactively — first they build factfinding
results into models, then they study the models to determine whether additional
fact-finding is needed. To help them understand system requirements, analysts use functional
decomposition diagrams, business process models, data flow diagrams, and
Unified Modeling Language diagrams. Any of these diagrams can be created
with CASE tools or standalone drawing tools if desired.
Functional Decomposition Diagrams
A functional decomposition
diagram (FDD) is a topdown
representation of a
function or process. Using
an FDD, an analyst can
show business functions
and break them down into
lower-level functions and
processes. Creating an FDD
is similar to drawing an
organization chart — you
start at the top and work
your way down. Figure 4-8
shows an FDD of a library
system drawn with the
Visible Analyst CASE tool.
FDDs can be used at several
stages of systems development.
During
requirements modeling,
analysts use FDDs to model
business functions and show
how they are organized into
lower-level processes. Those processes translate into program modules during application
development.
Business Process Modeling
As you learned in Chapter 1, a business process model (BPM) describes one or more business
processes, such as handling an airline reservation, filling a product order, or updating
a customer account. During requirements modeling, analysts often create models that use
a standard language called business process modeling notation (BPMN). BPMN includes
various shapes and symbols to represent events, processes, and workflows.
FIGURE 4-8 FDD showing five top-level functions. The Library
Operations function includes two additional levels that show processes
and subprocesses.
VIDEO LEARNING SESSION: FUNCTIONAL DECOMPOSITION
DIAGRAMS (FDDS)
Video Learning Sessions can help you understand key concepts, practice your skills, and check your
work. To access the sessions, visit the Management Information Systems CourseMate Web site at
www.cengagebrain.com and navigate to the Video Learning Sessions for this book. This
session is about functional decomposition diagrams (FDDs). You’ll learn about FDDs and why they
are important, how to use FDDs to model business functions and processes, and how to use CASE
tools to create FDDs.
ms, ed
TOOLKIT TIME
The CASE tools in
Part B of the
Systems Analyst’s
Toolkit can help you
document business
functions and processes,
develop
graphical models,
and provide an overall
framework for
information system
development. To
learn more about
these tools, turn to
Part B of the
four-part Toolkit that
follows Chapter 12.
Modeling Tools and Techniques
Phase 2 Systems Analysis
151
When you create a business process model
using a CASE tool such as Visible Analyst, your
diagram automatically becomes part of the overall
model. In the example shown in Figure 4-9,
using BPMN terminology, the overall diagram is
called a pool, and the designated customer areas
are called swim lanes. Integrating BPM into the
CASE development process leads to faster
results, fewer errors, and reduced cost. Part B of
the Systems Analyst’s Toolkit describes business
process modeling in more detail.
Data Flow Diagrams
Working from a functional decomposition
diagram, analysts can create data flow diagrams
(DFDs) to show how the system stores, processes,
and transforms data. The DFD in
Figure 4-10 describes adding and removing
books, which is a function shown in the Library
Management diagram in Figure 4-8. Notice that
the two shapes in the DFD represent processes,
each with various inputs and outputs. Additional levels
of information and detail are depicted in other, related
DFDs. Data and process modeling is described in detail
in Chapter 5.
Unified Modeling Language
The Unified Modeling Language (UML) is a widely used
method of visualizing and documenting software systems
design. UML uses object-oriented design concepts, but it is
independent of any specific programming language and
can be used to describe business processes and requirements
generally.
UML provides various graphical tools, such as use case
diagrams and sequence diagrams. During requirements
modeling, a systems analyst can utilize the UML to represent
the information system from a user’s viewpoint. Use
case diagrams, sequence diagrams, and other UML concepts
are discussed in more detail in Chapter 6, along with
other object-oriented analysis concepts. A brief description
of each technique follows.
USE CASE DIAGRAMS During requirements modeling, systems analysts and users
work together to document requirements and model system functions. A use case
diagram visually represents the interaction between users and the information
system. In a use case diagram, the user becomes an actor, with a specific role that
describes how he or she interacts with the system. Systems analysts can draw use
case diagrams freehand or use CASE tools that integrate the use cases into the
overall system design.
Figure 4-11 shows a simple use case diagram for a sales system where the actor is a
customer and the use case involves a credit card validation that is performed by the
system. Because use cases depict the system through the eyes of a user, common business
FIGURE 4-9 Using the Visible Analyst CASE tool, an analyst can create
a business process diagram. The overall diagram is called a pool, and the
two separate customer areas are called swim lanes.
FIGURE 4-10 A library system DFD shows how books
are added and removed.
To learn more about
the Unified Modeling
Language, visit the
Management
Information Systems
CourseMate Web
site at www.
cengagebrain.com,
navigate to On the
Web Links for this
chapter, and locate
The Unified Modeling
Language link.
FIGURE 4-11 Use case diagram of a sales system,
where the actor is a customer and the use case involves
a credit card validation.
FIGURE 4-13 Use case diagram of a student records system.
FIGURE 4-12 A table documents the credit card validation use case shown in Figure 4-11.
Name of Use Case: Credit card validation process
Actor: Customer
Description: Describes the credit card validation process
Successful Completion: 1. Customer clicks the input selector and
enters credit card number and expiration date
2. System verifies card
3. System sends authorization message
Alternative: 1. Customer clicks the input selector and
enters credit card number and expiration date
2. System rejects card
3. System sends rejection message
Precondition: Customer has selected at least one item and
has proceeded to checkout area
Postcondition: Credit card information has been validated
Customer can continue with order
Assumptions: None
language can be used to describe the transactions.
For example, Figure 4-12 shows a table
that documents the credit card validation use
case, and Figure 4-13 shows a student records
system, with several use cases and actors.
SEQUENCE DIAGRAMS A sequence diagram
shows the timing of interactions between
objects as they occur. A systems analyst might
use a sequence diagram to show all possible
outcomes, or focus on a single scenario.
Figure 4-14 shows a simple sequence diagram
of a successful credit card validation.
The interaction proceeds from top to bottom
along a vertical timeline, while the horizontal
arrows represent messages from one object
to another.
System Requirements Checklist
Phase 2 Systems Analysis
153
SYSTEM REQUIREMENTS CHECKLIST
During requirements modeling, systems developers must identify and describe all system
requirements. A system requirement is a characteristic or feature that must be included
in an information system to satisfy business requirements and be acceptable to users.
System requirements serve as benchmarks to measure the overall acceptability of the finished
system.
System requirements fall into five general categories: outputs, inputs, processes, performance,
and controls. Typical examples of system requirements for each category are
listed below.
Output Examples
✓ The Web site must report online volume statistics every four hours, and hourly
during peak periods.
✓ The inventory system must produce a daily report showing the part number,
description, quantity on hand, quantity allocated, quantity available, and unit
cost of all sorted by part number.
✓ The contact management system must generate a daily reminder list for all sales reps.
✓ The purchasing system must provide suppliers with up-to-date specifications.
✓ The sales tracking system must produce a daily fast-moving-item report, listing all
products that exceed the forecasted sales volume grouped by style, color, size, and
reorder status.
✓ The customer analysis system must produce a quarterly report that identifies
changes in ordering patterns or trends with statistical comparisons to the previous
four quarters.
Input Examples
✓ Manufacturing employees must swipe their ID cards into online data collection
terminals that record labor costs and calculate production efficiency.
✓ The department head must enter overtime hours on a separate screen.
✓ Student grades must be entered on machine-scannable forms prepared by the
instructor.
✓ Each input form must include date, time, product code, customer number, and
quantity.
✓ Data entry screens must be uniform, except for background color, which can be
changed by the user.
✓ A data entry person at the medical group must input patient services into the
billing system.
Process Examples
✓ The student records system must calculate the GPA at the end of each semester.
✓ As the final step in year-end processing, the payroll system must update employee
salaries, bonuses, and benefits and produce tax data required by the IRS.
✓ The warehouse distribution system must analyze daily orders and create a routing
pattern for delivery trucks that maximizes efficiency and reduces unnecessary
mileage.
✓ The human resources system must interface properly with the existing payroll
system.
✓ The video rental system must not execute new rental transactions for customers
who have overdue videos.
✓ The prescription system must automatically generate an insurance claim form.
Performance Examples
✓ The system must support 25 users online simultaneously.
✓ Response time must not exceed four seconds.
✓ The system must be operational seven days a week, 365 days a year.
✓ The accounts receivable system must prepare customer statements by the third
business day of the following month.
✓ The student records system must produce class lists within five hours after the
end of registration.
✓ The online inventory control system must flag all low-stock items within one
hour after the quantity falls below a predetermined minimum.
Control Examples
✓ The system must provide logon security at the operating system level and at the
application level.
✓ An employee record must be added, changed, or deleted only by a member of the
human resources department.
✓ The system must maintain separate levels of security for users and the system
administrator.
Future Growth, Costs, and Benefits
Phase 2 Systems Analysis
155
✓ All transactions must have audit trails.
✓ The manager of the sales department must approve orders that exceed a customer’s
credit limit.
✓ The system must create an error log file that includes the error type, description,
and time.
FUTURE GROWTH, COSTS, AND BENEFITS
In addition to the system requirements, systems analysts must consider scalability, which
determines how a system will handle future growth and demands, and the total cost of
ownership, which includes all future operational and support costs.
Scalability
Scalability refers to a system’s ability to handle increased business volume and transactions
in the future. Because it will have a longer useful life, a scalable system offers a better
return on the initial investment.
To evaluate scalability, you need information about projected future volume for all
outputs, inputs, and processes. For example, for a Web-based order processing system,
you would need to know the maximum projected number of concurrent users, the periods
of peak online activity, the number and types of data items required for each transaction,
and the method of accessing and updating customer files.
Even to print customer statements, you need to know the number of active accounts
and have a forecast for one, two, or five years, because that information affects future hardware
decisions. In addition, with realistic volume projections, you can provide reliable cost
estimates for related expenses, such as postage and online charges.
Similarly, to ensure that a Web-based hotel reservation system is sufficiently scalable,
you would need to project activity levels for several years of operation. For example,
you might forecast the frequency of online queries about room availability and estimate
the time required for each query and the average response time. With that information,
you could estimate server transaction volume and network requirements.
Transaction volume has a significant impact on operating costs. When volume exceeds
a system’s limitations, maintenance costs increase sharply. Volume can change dramatically
if a company expands or enters a new line of business. For example, a new Internetbased
marketing effort might require an additional server and 24-hour technical support.
Data storage also is an important scalability issue. You need to determine how
much data storage is required currently and predict future needs based on system
activity and growth. Those requirements affect hardware, software, and network
bandwidth needed to maintain system performance. You also must consider data
retention requirements and determine whether data can be deleted or archived on a
specific timetable.
Total Cost of Ownership
In addition to direct costs, systems developers must identify and document indirect
expenses that contribute to the total cost of ownership (TCO). TCO is especially important
if the development team is assessing several alternatives. After considering the indirect
costs, which are not always apparent, a system that seems inexpensive initially
might actually turn out to be the most costly choice. One problem is that cost estimates
tend to understate indirect costs such as user support and downtime productivity losses.
Even if accurate figures are unavailable, systems analysts should try to identify indirect
costs and include them in TCO estimates.
TOOLKIT TIME
The financial analysis
tools in Part C of
the Systems Analyst’s
Toolkit can help you
analyze project
costs, benefits, and
economic feasibility.
To learn more about
these tools, turn to
Part C of the fourpart
Toolkit that follows
Chapter 12.
Microsoft has developed a method for measuring total costs and benefits, called
Rapid Economic Justification (REJ), which is described in Figure 4-15. According to
Microsoft, REJ is a framework to help IT professionals analyze and optimize IT investments.
Notice that the primary emphasis is on business improvement, rather than operational
efficiency. As the Web site points out, the strategic role of IT investments should
be included, even when the specific benefits are difficult to quantify.
FACT-FINDING
Now that you understand the categories of system requirements, scalability, and TCO,
the next step is to begin collecting information. Whether you are working on your own
or as a member of a JAD team, during requirements modeling you will use various factfinding
techniques, including interviews, document review, observation, surveys and
questionnaires, sampling, and research.
Fact-Finding Overview
Although software can help you to gather and analyze facts, no program actually
performs fact-finding for you. First, you must identify the information you need.
Typically, you begin by asking a series of questions, such as these:
• What business functions are supported by the current system?
• What strategic objectives and business requirements must be supported by the
new system?
• What are the benefits and TCO of the proposed system?
• What transactions will the system process?
• What information do users and managers need from the system?
To learn more
about REJ, visit the
Management
Information Systems
CourseMate Web
site at www.
cengagebrain.
com, navigate to
On the Web
Links for this
chapter, and locate
the REJ link.
FIGURE 4-15 Microsoft developed Rapid Economic Justification (REJ) as a
framework to help IT professionals analyze and optimize IT investments.
Fact-Finding
Phase 2 Systems Analysis
157
• Must the new system interface with legacy systems?
• What procedures could be eliminated by business process reengineering?
• What security issues exist?
• What risks are acceptable?
• What budget and timetable constraints will affect system development?
To obtain answers to these questions, you develop a fact-finding plan, which can
involve another series of questions (who, what, where, when, and how), or use a more
structured approach such as the Zachman Framework, which is explained in a following
section. Either way, you will develop a strategy, carry out fact-finding techniques, document
the results, and prepare a system requirements document, which is presented to
management.
Who, What, Where, When, How, and Why?
Fact-finding involves answers to five familiar questions: who, what, where, when, and
how. For each of those questions, you also must ask another very important question:
why. Some examples of these questions are:
1. Who? Who performs each of the procedures within the system? Why? Are the
correct people performing the activity? Could other people perform the tasks
more effectively?
2. What? What is being done? What procedures are being followed? Why is that
process necessary? Often, procedures are followed for many years and no one
knows why. You should question why a procedure is being followed at all.
3. Where? Where are operations being performed? Why? Where could they be performed?
Could they be performed more efficiently elsewhere?
4. When? When is a procedure performed? Why is it being performed at this time?
Is this the best time?
5. How? How is a procedure performed? Why is it performed in that manner?
Could it be performed better, more efficiently, or less expensively in some other
manner?
There is a difference between asking what is being done and what could or should be
done. The systems analyst first must understand the current situation. Only then can he
or she tackle the question of what should be done. Figure 4-16 lists the basic questions
and when they should be asked. Notice that the first two columns relate to the current
system, but the third column focuses on the proposed system.
FIGURE 4-16 Sample questions during requirements modeling as the focus shifts from the current system to
the proposed system.
The Zachman Framework
In the 1980s, John Zachman observed how industries such as architecture and
construction handled complex projects, and he suggested that the same ideas could be
applied to information systems development. His concept, the Zachman Framework for
Enterprise Architecture, is a model that asks the traditional fact-finding questions in a
systems development context, as shown in Figure 4-17. The Zachman Framework is a
popular approach, and the Visible Analyst CASE tool now includes a Zachman
Framework interface that allows users to view a systems project from different perspectives
and levels of detail. The Zachman Framework helps managers and users understand
the model and ensures that overall business goals translate into successful IT projects.
FIGURE 4-17 Visible Analyst uses the Zachman Framework for Enterprise Architecture. The Zachman concept
presents traditional fact-finding questions in a systems development context.
To learn more
about the Zachman
Framework, visit the
Management
Information Systems
CourseMate Web
site at www.
cengagebrain.
com, navigate to
On the Web
Links for this
chapter, and locate
The Zachman
Framework link.
Interviews
Phase 2 Systems Analysis
159
INTERVIEWS
Interviewing is an important fact-finding tool during the systems analysis phase. An
interview is a planned meeting during which you obtain information from another person.
You must have the skills needed to plan, conduct, document, and evaluate interviews
successfully.
After you identify the information you need, as described earlier in the chapter, you
can begin the interviewing process, which consists of seven steps for each interview:
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.
Step 1: Determine the People to Interview
To get an accurate picture, you must select the right people to interview and ask them
the right questions. During the preliminary investigation, you talked mainly to middle
managers or department heads. Now, during the systems analysis phase, you might need
to interview people from all levels of the organization.
Although you can select your interview candidates from
the formal organization charts that you reviewed earlier, you
also must consider any informal structures that exist in the
organization. Informal structures usually are based on interpersonal
relationships and can develop from previous work
assignments, physical proximity, unofficial procedures, or personal
relationships such as the informal gathering shown in
Figure 4-18. In an informal structure, some people have more
influence or knowledge than appears on an organization
chart. Your knowledge of the company’s formal and informal
structures helps you determine the people to interview during
the systems analysis phase.
Should you interview several people at the same time?
Group interviews can save time and provide an opportunity to
observe interaction among the participants. Group interviews
also can present problems. One person might dominate the
conversation, even when questions are addressed specifically
to others. Organization level also can present a problem, as
the presence of senior managers in an interview might prevent
lower-level employees from expressing themselves candidly.
Step 2: Establish Objectives for the Interview
After deciding on the people to interview, you must establish
objectives for the session. First, you should determine the general
areas to be discussed, and then list the facts you want to
gather. You also should try to solicit ideas, suggestions, and
opinions during the interview.
FIGURE 4-18 When setting up interviews, an analyst
should look outside a formal organization chart to
identify people who might provide valuable information
The objectives of an interview depend on the role of the person being interviewed.
Upper-level managers can provide the big picture and help you to understand the system
as a whole. Specific details about operations and business processes are best learned
from people who actually work with the system on a daily basis.
In the early stages of systems analysis, interviews usually are general. As the factfinding
process continues, however, the interviews focus more on specific topics.
Interview objectives also vary at different stages of the investigation. By setting specific
objectives, you create a framework that helps you decide what questions to ask and how
to phrase the questions.
Step 3: Develop Interview Questions
Creating a standard list of interview questions helps to keep you on track and avoid
unnecessary tangents. Also, if you interview several people who perform the same job, a
standard question list allows you to compare their answers. Although you have a list of
specific questions, you might decide to depart from it because an answer to one question
leads to another topic that you want to pursue. That question or topic then should be
included in a revised set of questions used to conduct future interviews. If the question
proves to be extremely important, you may need to return to a previous interviewee to
query him or her on the topic.
The interview should consist of several different kinds of questions: open-ended,
closed-ended, or questions with a range of responses. When you phrase your questions,
you should avoid leading questions that suggest or favor a particular reply. For example,
rather than asking, “What advantages do you see in the proposed system?” you might
ask, “Do you see any advantages in the proposed system?”
OPEN-ENDED QUESTIONS Open-ended questions encourage spontaneous and
unstructured responses. Such questions are useful when you want to understand a
larger process or draw out the interviewee’s opinions, attitudes, or suggestions. Here
are some examples of open-ended questions: What are users saying about the new
system? How is this task performed? Why do you perform the task that way? How
are the checks reconciled? What added features would you like to have in the new
billing system? Also, you can use an open-ended question to probe further by asking:
Is there anything else you can tell me about this topic?
CLOSED-ENDED QUESTIONS Closed-ended questions limit or restrict the response.
You use closed-ended questions when you want information that is more specific or
when you need to verify facts. Examples of closed-ended questions include the following:
How many personal computers do you have in this department? Do you review
the reports before they are sent out? How many hours of training does a clerk receive?
Is the calculation procedure described in the manual? How many customers ordered
products from the Web site last month?
RANGE-OF-RESPONSE QUESTIONS Range-of-response questions are closed-ended
questions that ask the person to evaluate something by providing limited answers
to specific responses or on a numeric scale. This method makes it easier to tabulate
the answers and interpret the results. Range-of-response questions might include
these: On a scale of 1 to 10, with 1 the lowest and 10 the highest, how effective
was your training? How would you rate the severity of the problem: low, medium,
or high? Is the system shutdown something that occurs never, sometimes, often,
usually, or always?
Interviews
Phase 2 Systems Analysis
161
Step 4: Prepare for the Interview
After setting the objectives and developing the questions, you must prepare for the
interview. Careful preparation is essential because an interview is an important meeting
and not just a casual chat. When you schedule the interview, suggest a specific day and
time and let the interviewee know how long you expect the meeting to last. It is also a
good idea to send an e-mail or place a reminder call the day before the interview.
Remember that the interview is an interruption of the other person’s routine, so you
should limit the interview to no more than one hour. If business pressures force a postponement
of the meeting, you should schedule another appointment as soon as it is
convenient. Remember to keep
department managers informed of
your meetings with their staff
members. Sending a message to
each department manager listing
your planned appointments is a
good way to keep them informed.
Figure 4-19 is an example of such
a message.
You should send a list of topics
to an interviewee several days before
the meeting, especially when
detailed information is needed, so
the person can prepare for the interview
and minimize the need for a
follow-up meeting. Figure 4-20
shows a sample message that lists
specific questions and confirms the
date, time, location, purpose, and
anticipated duration of the
interview.
If you have questions about documents,
ask the interviewee to have
samples available at the meeting.
Your advance memo should
include a list of the documents you
want to discuss, if you know what
they are. Also, you can make a general
request for documents, as the
analyst did in her e-mail shown in
Figure 4-20.
Two schools of thought exist
about the best location for an
interview. Some analysts believe
that interviews should take place
in the interviewee’s office, whereas
other analysts feel that a neutral
location such as a conference
room is better.
Supporters of interviews in the
interviewee’s office believe that is
the best location because it makes
the interviewee feel comfortable
during the meeting. A second
FIGURE 4-19 Sample message to a department head about interviews.
FIGURE 4-20 Sample message to confirm an interview.
argument in favor of the interviewee’s office is that the office is where he or she has the
easiest access to supporting material that might be needed during the discussion. If you
provide a complete list of topics in advance, however, the interviewee can bring the necessary
items to a conference room or other location.
Supporters of neutral locations stress the importance of keeping interruptions to a
minimum so both people can concentrate fully. In addition, an interview that is free of
interruptions takes less time. If the meeting does take place in the interviewee’s office,
you should suggest tactfully that all calls be held until the conclusion of the interview.
Step 5: Conduct the Interview
After determining the people to interview, setting your objectives, and preparing the
questions, you should develop a specific plan for the meeting. When conducting an
interview, you should begin by introducing yourself, describing the project, and explaining
your interview objectives.
During the interview, ask questions in the order in which you prepared them, and
give the interviewee sufficient time to provide thoughtful answers. Establishing a good
rapport with the interviewee is important, especially if this is your first meeting. If the
other person feels comfortable and at ease, you probably will receive more complete and
candid answers. Your primary responsibility during an interview is to listen carefully to
the answers. Analysts sometimes hear only what they expect to hear. You must concentrate
on what is said and notice any nonverbal communication that takes place. This
process is called engaged listening.
After asking a question, allow the person enough time to think about the question
and arrive at an answer. Studies have shown that the maximum pause during a conversation
is usually three to five seconds. After that interval, one person will begin talking.
You will need to be patient and practice your skills in many actual interview situations
to be successful.
When you finish asking your questions, summarize the main points covered in the
interview and explain the next course of action. For example, mention that you will
send a follow-up memo or that the interviewee should get back to you with certain
information. When you conclude the interview, thank the person and encourage him or
her to contact you with any questions or additional comments. Also, when the interview
ends, it is a good idea to ask the interviewee whether he or she can suggest any additional
topics that should be discussed.
After an interview, you should summarize the session and seek a confirmation from
the other person. By stating your understanding of the discussion, the interviewee can
respond and correct you, if necessary. One approach is to rephrase the interviewee’s
answers. For example, you can say, “If I understand you correctly, you are saying that ...”
and then reiterate the information given by the interviewee.
Step 6: Document the Interview
Although taking notes during an interview has both advantages and disadvantages, the
accepted view is that note taking should be kept to a minimum. Although you should
write down a few notes to jog your memory after the interview, you should avoid writing
everything that is said. Too much writing distracts the other person and makes it
harder to establish a good rapport.
After conducting the interview, you must record the information quickly. You
should set aside time right after the meeting to record the facts and evaluate the information.
For that reason, try not to schedule back-to-back interviews. Studies have
shown that 50 percent of a conversation is forgotten within 30 minutes. You, therefore,
should use your notes to record the facts immediately so you will not forget
Interviews
Phase 2 Systems Analysis
163
CASE IN POINT 4.2: DEEP RIVER COLLEGE
Deep River College is a two-year school in Southern California. Twice a year, the fundraising
office at Deep River mails requests for donations to the alumni. The staff uses a word
processing program and a personal information database to create personalized letters. Data
on past contributions and other alumni information, however, is stored manually. The dean,
Alexandra Ali, recently submitted a systems request asking the college’s IT department to
develop a computerized alumni information system. The school does not have a formal systems
review committee, and each department has an individual budget for information services.
Eddie Bateman, a systems analyst, performed a preliminary investigation and he concluded that
the system met all the feasibility tests. After reading his report, Alexandra asked him to proceed
with the systems analysis phase. Eddie has scheduled an interview with her, and he has asked you
to help him prepare for the meeting. Specifically, he wants you to list all the topics he should
cover during the interview. Eddie also wants you to prepare a list of specific questions that he
should ask. Be sure to include open-ended, closed-ended, and range-of-response questions.
them. You can summarize the facts by preparing a narrative describing what took
place or by recording the answers you received next to each question on your prepared
question list.
Tape recorders are effective tools for an interview; however, many people feel uncomfortable
when recorders are present. Before using a recorder, you should discuss its use
with the interviewee. Assure the interviewee that you will erase the tape after you transcribe
your notes and that you will stop and rewind the tape anytime during the interview
at his or her request. If you ask sensitive questions or the interviewee wants to
answer a question without being recorded, explain that you will turn off the tape for a
period of time during the interview.
Even with a tape recorder in use, you should listen carefully to the interviewee’s
responses so you can ask good follow-up questions. Otherwise, you might have to
return for a second visit to ask the questions you missed the first time. Also, remember
that each recorded interview takes twice the amount of time, because you must listen to
or view the recorded meeting again after conducting the interview itself.
After the interview, send a memo to the interviewee expressing your appreciation for
his or her time and cooperation. In the memo, you should note the date, time, location,
purpose of the interview, and the main points you discussed so the interviewee has a
written summary and can offer additions or corrections.
Step 7: Evaluate the Interview
In addition to recording the facts obtained in an interview, try to identify any possible
biases. For example, an interviewee who tries to protect his or her own area or function
might give incomplete answers or refrain from volunteering information. Or, an interviewee
with strong opinions about the current or future system might distort the facts.
Some interviewees might answer your questions in an attempt to be helpful even though
they do not have the necessary experience to provide accurate information.
Unsuccessful Interviews
No matter how well you prepare for interviews, some are not successful. One of the
main reasons could be that you and the interviewee did not get along well. Such a situation
can be caused by several factors. For example, a misunderstanding or personality conflict
could affect the interview negatively, or the interviewee might be afraid that the new system
will eliminate or change his or her job.
In other cases, the interviewee might give only short or incomplete responses to your
open-ended questions. If so, you should switch to closed-ended questions or questions
with a range of responses, or try rephrasing your open-ended questions into those types
of questions. If that still does not help, you should find a tactful way to conclude the
meeting.
Continuing an unproductive interview is difficult. The interviewee could be more
cooperative later, or you might find the information you seek elsewhere. If failure to
obtain specific information will jeopardize the success of the project, inform your supervisor,
who can help you decide what action to take. Your supervisor might contact the
interviewee’s supervisor, ask another systems analyst to interview the person, or find
some other way to get the needed information.
OTHER FACT-FINDING TECHNIQUES
In addition to interviewing, systems analysts use other fact-finding techniques, including
document review, observation, questionnaires and surveys, sampling, and research. Such
techniques are used before interviewing begins to obtain a good overview and to help
develop better interview questions.
Document Review
Document review can help you understand how the current system is supposed to work.
Remember that system documentation sometimes is out of date. Forms can change or be
discontinued, and documented procedures often are modified or eliminated. You should
obtain copies of actual forms and operating documents currently in use. You also should
review blank copies of forms, as well as samples of actual completed forms. You usually
can obtain document samples during interviews with the people who perform that procedure.
If the system uses a software package, you should review the documentation for
that software.
Observation
The observation of current operating procedures is another fact-finding technique.
Seeing the system in action gives you additional perspective and a better understanding
of system procedures. Personal observation also allows you to verify statements made in
interviews and determine whether procedures really operate as they are described.
Other Fact-Finding Techniques
Phase 2 Systems Analysis
165
Through observation, you might discover that neither the system documentation nor the
interview statements are accurate.
Personal observation also can provide important advantages as the development process
continues. For example, recommendations often are better accepted when they are
based on personal observation of actual operations. Observation also can provide the
knowledge needed to test or install future changes and can help build relationships with
the users who will work with the new system.
Plan your observations in advance by preparing a checklist of specific tasks you want
to observe and questions you want to ask. Consider the following issues when you prepare
your list:
1. Ask sufficient questions to ensure that you have a complete understanding of the
present system operation. A primary goal is to identify the methods of handling
situations that are not covered by standard operating procedures. For example,
what happens in a payroll system if an employee loses a time card? What is the
procedure if an employee starts a shift 10 minutes late but then works 20 minutes
overtime? Often, the rules for exceptions such as these are not written or formalized;
therefore, you must try to document any procedures for handling exceptions.
2. Observe all the steps in a transaction and note the documents, inputs, outputs, and
processes involved.
3. Examine each form, record, and report.
Determine the purpose each item of information
serves.
4. Consider each user who works with the system
and the following questions: What information
does that person receive from other people?
What information does this person generate?
How is the information communicated? How
often do interruptions occur? How much downtime
occurs? How much support does the user
require, and who provides it?
5. Talk to the people who receive current reports
to see whether the reports are complete, timely,
accurate, and in a useful form. Ask whether
information can be eliminated or improved and
whether people would like to receive additional
information.
As you observe people at work, as shown in
Figure 4-21, consider a factor called the Hawthorne
Effect. The name comes from a well-known study
performed in the Hawthorne plant of the Western
Electric Company in the 1920s. The purpose of the
study was to determine how various changes in the
work environment would affect employee productivity.
The surprising result was that productivity
improved during observation whether the conditions
were made better or worse. Researchers concluded
that productivity seemed to improve whenever the
workers knew they were being observed.
Although some recent studies have raised questions
about the original findings, you should be aware that
observation can and does have an effect on normal
FIGURE 4-21 The Hawthorne study suggested that worker
productivity improves during observation. Always consider
the Hawthorne Effect when observing the operation of an
existing system.
operations. With this in mind, always give advance notice to the supervisor in that area.
In some situations, it might be helpful to explain the purpose of your visit to the people
being observed.
Questionnaires and Surveys
In projects where it is desirable to obtain input from a large number of people,
a questionnaire can be a valuable tool. A questionnaire, also called a survey, is a document
containing a number of standard questions that can be sent to many individuals.
Questionnaires can be used to obtain information about a wide range of topics,
including workloads, reports received, volumes of transactions handled, job duties,
difficulties, and opinions of how the job could be performed better or more efficiently.
Figure 4-22 shows a sample questionnaire that includes several different question and
response formats.
FIGURE 4-22 Sample questionnaire. Does it follow the suggested guidelines?
Other Fact-Finding Techniques
Phase 2 Systems Analysis
167
A typical questionnaire starts with a heading, which includes a title, a brief statement of
purpose, the name and telephone number of the contact person, the deadline date for completion,
and how and where to return the form. The heading usually is followed by general
instructions that provide clear guidance on how to answer the questions. Headings also are
used to introduce each main section or portion of the survey and include instructions when
the type of question or response changes. A long questionnaire might end with a conclusion
that thanks the participants and reminds them how to return the form.
What about the issue of anonymity? Should people be asked to sign the questionnaire,
or is it better to allow anonymous responses? The answer depends on two questions.
First, does an analyst really need to know who the respondents are in order to
match or correlate information? For example, it might be important to know what percentage
of users need a certain software feature, but specific usernames might not be relevant.
Second, does the questionnaire include any sensitive or controversial topics?
Many people do not want to be identified when answering a question such as “How
well has your supervisor explained the system to you?” In such cases, anonymous
responses might provide better information.
When designing a questionnaire, the most important rule of all is to make sure that your
questions collect the right data in a form that you can use to further your fact-finding. Here
are some additional ideas to keep in mind when designing your questionnaire:
• Keep the questionnaire brief and user-friendly.
• Provide clear instructions that will answer all anticipated questions.
• Arrange the questions in a logical order, going from simple to more complex topics.
• Phrase questions to avoid misunderstandings; use simple terms and wording.
• Try not to lead the response or use questions that give clues to expected answers.
• Limit the use of open-ended questions that are difficult to tabulate.
• Limit the use of questions that can raise concerns about job security or other
negative issues.
• Include a section at the end of the questionnaire for general comments.
• Test the questionnaire whenever possible on a small test group before finalizing it
and distributing to a large group.
A questionnaire can be a traditional paper
form, or you can create a fill-in form and collect
data on the Internet or a company intranet. For
example, you can use Microsoft Word, as
shown in Figure 4-23, to create form fields,
including text boxes, date pickers, and dropdown
lists where users can click selections.
Before you publish the form, you should protect
it so users can fill it in but cannot change the
layout or design. Forms also can be automated,
so if a user answers no to question three, he or
she goes directly to question eight, where the
form-filling resumes.
Sampling
When studying an information system, you
should collect examples of actual documents
using a process called sampling. The samples
might include records, reports, operational logs,
FIGURE 4-23 Using Microsoft Word, you can create a fill-in form
with text boxes, date pickers, and drop-down lists.
data entry documents, complaint summaries, work requests, and various types of forms.
Sampling techniques include systematic sampling, stratified sampling, and random sampling.
Suppose you have a list of 200 customers who complained about errors in their statements,
and you want to review a representative sample of 20 customers. A systematic
sample would select every tenth customer for review. If you want to ensure that the sample
is balanced geographically, however, you could use a stratified sample to select five
customers from each of four zip codes. Another example of stratified sampling is to select
a certain percentage of transactions from each zip code, rather than a fixed number.
Finally, a random sample selects any 20 customers.
The main objective of a sample is to ensure that it represents the overall population
accurately. If you are analyzing inventory transactions, for example, you should select a
sample of transactions that are typical of actual inventory operations and do not include
unusual or unrelated examples. For instance, if a company performs special processing
on the last business day of the month, that day is not a good time to sample typical daily
operations. To be useful, a sample must be large enough to provide a fair representation
of the overall data.
You also should consider sampling when using interviews or questionnaires. Rather
than interviewing everyone or sending a questionnaire to the entire group, you can use a
sample of participants. You must use sound sampling techniques to reflect the overall
population and obtain an accurate picture.
Research
Research is another important fact-finding technique. Your research can include the
Internet, IT magazines, and books to obtain background information, technical material,
and news about industry trends and developments. In addition, you can attend professional
meetings, seminars, and discussions with other IT professionals, which can be
very helpful in problem solving.
The Internet is an extremely valuable
resource. Part D of the Systems Analyst’s
Toolkit describes a variety of Internet
resource tools. Using the Internet, you also
can access information from federal and
state governments, as well as from publishers,
universities, and libraries around the
world. Online forums and newsgroups are
good resources for exchanging information
with other professionals, seeking answers
to questions, and monitoring discussions
that are of interest to you.
All major hardware and software vendors
maintain sites on the Web where you
can obtain information about products
and services offered by the company and
send e-mail with specific questions to company
representatives. In addition to contacting
specific firms, you can access Web
sites maintained by publishers and independent
firms that provide links to hundreds
of hardware and software vendors,
as shown in Figure 4-24. Such sites are
one-stop information centers where IT
professionals can find information, share
ideas, and keep posted on developments in
technology.
To learn more about
sampling, visit the
Management
Information Systems
CourseMate Web
site at www.
cengagebrain.
com, navigate to
On the Web Links
for this chapter, and
locate the Sampling
link.
FIGURE 4-24 InfoWorld’s Web site offers many resources for IT professionals.
Other Fact-Finding Techniques
Phase 2 Systems Analysis
169
Research also can involve a visit to a physical location,
called a site visit, where the objective is to observe a system in
use at another location. If you are studying your firm’s
human resources information system, for example, you might
want to see how another company’s system works. Site visits
also are important when considering the purchase of a software
package. If the software vendor suggests possible sites
to visit, be aware that such sites might constitute a biased
sample. A single site visit seldom gives you true pictures, so
you should try to visit more than one installation.
Before a site visit such as the one shown in Figure 4-25,
prepare just as you would for an interview. Contact the
appropriate manager and explain the purpose of your visit.
Decide what questions you will ask and what processes you
will observe. During your visit, observe how the system works
and note any problems or limitations. You also will want to
learn about the support provided by the vendor, the quality of
the system documentation, and so on.
Interviews versus Questionnaires
When you seek input from a large group, a questionnaire is a very useful tool. On the
other hand, if you require detailed information from only a few people, then you probably
should interview each person individually. Is it better to interview or use a questionnaire?
Each situation is different, and you must consider the type of information, time
constraints, and expense factors.
The interview is more familiar and personal than a questionnaire. People who are
unwilling to put critical or controversial comments in writing might talk more freely in person.
Moreover, during a face-to-face interview, you can react immediately to anything the
interviewee says. If surprising or confusing statements are made, you can pursue the topic
with additional questions. In addition, during a personal interview, you can watch for clues
to help you determine if responses are knowledgeable and unbiased. Participation in interviews
also can affect user attitudes, because people who are asked for their opinions often
view the project more favorably.
Interviewing, however, is a costly and time-consuming process. In addition to the
meeting itself, both people must prepare, and the interviewer has to do follow-up work.
When a number of interviews are planned, the total cost can be quite substantial. The
personal interview usually is the most expensive fact-finding technique.
In contrast, a questionnaire gives many people the opportunity to provide input and
suggestions. Questionnaire recipients can answer the questions at their convenience and do
not have to set aside a block of time for an interview. If the questionnaire allows anonymous
responses, people might offer more candid responses than they would in an interview.
Preparing a good questionnaire, however, like a good interview, requires skill and
time. If a question is misinterpreted, you cannot clarify the meaning as you can in a
face-to-face interview. Furthermore, unless questionnaires are designed well, recipients
might view them as intrusive, time-consuming, and impersonal. As an analyst, you
should select the technique that will work best in a particular situation.
Another popular method of obtaining input is called brainstorming, which refers to a
small group discussion of a specific problem, opportunity, or issue. This technique
encourages new ideas, allows team participation, and enables participants to build on
each other’s inputs and thoughts. Brainstorming can be structured or unstructured. In
structured brainstorming, each participant speaks when it is his or her turn, or passes. In
unstructured brainstorming, anyone can speak at any time. At some point, the results
are recorded and made part of the fact-finding documentation process.
CASE IN POINT 4.4: CYBERSTUFF
Ann Ellis is a systems analyst at CyberStuff, a large company that sells computer hardware and
software via telephone, mail order, and the Internet. CyberStuff processes several thousand
transactions per week on a three-shift operation and employs 50 full-time and 125 part-time
employees. Lately, the billing department has experienced an increase in the number of customer
complaints about incorrect bills. During the preliminary investigation, Ann learned that
some CyberStuff representatives did not follow established order entry procedures. She feels
that with more information, she might find a pattern and identify a solution for the problem.
Ann is not sure how to proceed. She came to you, her supervisor, with two separate questions.
First, is a questionnaire the best approach, or would interviews be better? Second,
whether she uses interviews, a questionnaire, or both techniques, should she select the participants
at random, include an equal number of people from each shift, or use some other
approach? As Ann’s supervisor, what would you suggest, and why?
DOCUMENTATION
Keeping accurate records of interviews, facts, ideas, and observations is essential to successful
systems development. The ability to manage information is the mark of a successful
systems analyst and an important skill for all IT professionals.
The Need for Recording the Facts
As you gather information, the importance of a single item can be overlooked or complex
system details can be forgotten. The basic rule is to write it down. You should document
your work according to the following principles:
• Record information as soon as you obtain it.
• Use the simplest recording method possible.
• Record your findings in such a way that they can be understood by someone else.
• Organize your documentation so related material is located easily.
Often, systems analysts use special forms for describing a system, recording interviews,
and summarizing documents. One type of documentation is a narrative list with
simple statements about what is occurring, apparent problems, and suggestions for
improvement. Other forms of documentation that are described in Chapter 4 include
data flow diagrams, flowcharts, sample forms, and screen captures.
Software Tools
Many software programs are available to help you record and document information.
Some examples are described here.
CASE TOOLS You can use CASE tools at every stage of systems development. This
chapter contains several examples of CASE tools. Part B of the Systems Analyst’s
Toolkit describes other features and capabilities of CASE tools.
PRODUCTIVITY SOFTWARE Productivity software includes word processing,
spreadsheet, database management, presentation graphics, and collaboration software
programs. Although Microsoft Office is the best-known set of productivity software
programs, other vendors offer products in each of these categories.
Documentation
Phase 2 Systems Analysis
171
Using word processing software such as Microsoft Word, Corel WordPerfect, or
OpenOffice.org Writer, you can create reports, summaries, tables, and forms. In addition
to standard document preparation, the program can help you organize a presentation
with templates, bookmarks, annotations, revision control, and an index. You can
consult the program’s Help system for more information about those and other features.
You also can create fill-in forms to conduct surveys and questionnaires, as described
earlier in this chapter.
Spreadsheet software, such as Microsoft Excel, Corel Quattro Pro, or OpenOffice.org
Calc, can help you track and manage numeric data or financial information. You also
can generate graphs and charts that display the data and show possible patterns, and you
can use the statistical functions in a spreadsheet to tabulate and analyze questionnaire
data. A graphical format often is used in quality control analysis because it highlights
problems and their possible causes, and it is effective when presenting results to management.
A common tool for showing the distribution of questionnaire or sampling results
is a vertical bar chart called a histogram. Most spreadsheet programs can create histograms
and other charts that can display data you have collected. Figure 4-26 displays a
typical histogram that might have resulted from the questionnaire shown in Figure 4-22
on page 166.
FIGURE 4-26 This histogram displays results from Question 2 in the questionnaire shown in Figure 4-22 on page 166.
Database management software allows you to document and organize fact-finding
results such as events, observations, and data samples. You can use a database program
such as Microsoft Access to manage the details of a complex project, create queries to
retrieve specific information, and generate custom reports.
Presentation graphics software, such as Microsoft PowerPoint, Apple Keynote, or
OpenOffice.org Impress, is a powerful tool for organizing and developing your formal
presentation. Presentation graphics programs enable you to create organization charts
that can be used in a preliminary investigation and later during requirements modeling.
These high-quality charts also can be included in written reports and management
presentations.
Collaboration software is the latest weapon in the struggle to boost productivity.
More than ever, people work in teams and use Web-based software such as Google
Docs and Microsoft Web Apps to access data and share files. Google and others are
betting that cloud computing will create a virtual workplace, where people will be able
to interact in real time, with all the benefits of a traditional face-to-face workplace, but
none of the limitations.
GRAPHIC MODELING SOFTWARE Microsoft Visio is a popular graphic modeling
tool that can produce a wide range of charts and diagrams. Visio includes a library of
templates, stencils, and shapes. An analyst can use Visio to create many types of visual
models, including business processes, flowcharts, network diagrams, organization
charts, and Web site maps, such as the one shown in Figure 4-27.
FIGURE 4-27 This Microsoft Visio screen shows shapes that can be used to create a Web site map.
Documentation
Phase 2 Systems Analysis
173
PERSONAL INFORMATION MANAGERS A busy analyst needs to keep track of
meetings, interviews, appointments, and deadlines. A personal information manager
(PIM), such as Microsoft Outlook or IBM’s Lotus Organizer, can help manage those
tasks using a personal calendar and a to-do list, with priorities and the capability to
check off completed items.
In addition to desktop-based organizers, handheld computers are popular. Some handheld
computers, also called personal digital assistants (PDAs), accept handwritten input,
while others have small keyboards. These devices can handle calendars, schedules,
appointments, telephone lists, and calculations. A PDA can be standalone, Bluetoothcapable
to synchronize with a desktop, or fully wireless-enabled, such as the HP iPAQ
shown in Figure 4-28.
WIRELESS COMMUNICATION DEVICES Even in the dynamic world of IT, the recent
explosion in wireless technology is almost unprecedented. The latest wireless standard,
called 4G (fourth generation), is opening new frontiers in broadband Web access,
e-mail, social networking, file exchange, and streaming multimedia. Users enjoy new
hardware and software, easy synchronization with office networks, and innovative
services designed for a wired generation.
The rapid growth of wireless communication has resulted in a merger of various
technologies. Many people swear by all-in-one devices such as Research in Motion’s
BlackBerry or smart phones, such as the Apple iPhone. Others are devoted to products
that use Google’s Android operating system, which is a mobile device platform adopted
by many hardware vendors, including Motorola, Kyocera, and LG. Figure 4-29 on the
next page shows some examples of these products.
FIGURE 4-29 Three popular examples of current wireless technology.
Beyond hardware choices, users can select from literally thousands of portable
applications for business and personal use. No one can predict the future with certainty,
but it is apparent that portable wireless technology is having an enormous impact on
business practices, everyday communications, and social interaction.
Chapter Summary
Phase 2 Systems Analysis
175
PREVIEW OF LOGICAL MODELING
At the conclusion of requirements modeling, systems developers should have a clear
understanding of business processes and system requirements. The next step is to
construct a logical model of the system.
Data and process modeling, which is described in Chapter 5, uses a structured
analysis approach. Structured analysis is a popular, traditional technique that describes
the system in terms of data and the processes that act on that data.
An alternative to structured analysis modeling is object modeling, which is described
in Chapter 6. Object modeling is a methodology that combines data and processes into
things called objects that represent actual people, things, transactions, and events.
Systems analysts use object models to visualize and document real-world business processes
and operations.
IT professionals have differing views about systems development methodologies, and
no universally accepted approach exists. By studying both structured analysis and objectoriented
methods, you gain valuable knowledge, skills, and perspective. You then can use
that information to determine what method, or combination of methods, is best for the
different situations you will face in your career.
CHAPTER SUMMARY
The systems analysis phase includes three activities: requirements modeling, data and
process modeling, and consideration of development strategies. The main objective is to
understand the proposed project, ensure that it will support business requirements, and
build a solid foundation for the systems design phase.
During requirements modeling, you identify the business-related requirements for the
new information system, including outputs, inputs, processes, performance, and controls.
You consider scalability to ensure that the system can support future growth and
expansion. You also estimate total cost of ownership (TCO) to identify all costs, including
indirect costs.
Popular team-based approaches include JAD, RAD, and agile methods. Joint application
development (JAD) is a popular, team-based approach to fact-finding and
requirements modeling. JAD involves an interactive group of users, managers, and IT
professionals who participate in requirements modeling and develop a greater commitment
to the project and to their common goals.
Rapid application development (RAD) is a team-based technique that speeds up
information systems development and produces a functioning information system.
RAD is a complete methodology, with a four-phase life cycle that parallels the traditional
SDLC phases.
Agile methods attempt to develop a system incrementally, by building a series of
prototypes and constantly adjusting them to user requirements.
Systems analysts use various tools and techniques to model system requirements.
Unified Modeling Language (UML) is a widely used method of visualizing and documenting
software design through the eyes of the business user. UML tools include use
case diagrams and sequence diagrams to represent actors, their roles, and the sequence
of transactions that occurs.
A functional decomposition diagram (FDD) is a model of business functions and
processes. A CASE tool can generate a set of data flow diagrams directly from a FDD.
The fact-finding process includes interviewing, document review, observation, questionnaires,
sampling, and research. Successful interviewing requires good planning and strong
interpersonal and communication skills. The systems analyst must decide on the people to
interview, set interview objectives, and prepare for, conduct, and analyze interviews. The
analyst also might find it helpful to use one or more software tools during fact-finding.
Systems analysts should carefully record and document factual information as it is
collected, and various software tools can help an analyst visualize and describe an information
system. The chapter concluded with a preview of logical modeling. Data and
process modeling is a structured analysis approach that views the system in terms of
data and the processes that act on that data. Object modeling is an approach that views
the system in terms of data and the processes that act on that data.