86One of the fi rst activities of an analyst is to determi.docx

86
One of the fi rst activities of an analyst is to determine the
business requirements for a new
system. Th is chapter begins by presenting the requirements defi
nition, a document that lists
the new system’s capabilities. It then describes how to analyze
requirements using require-
ments analysis strategies and how to gather requirements using
interviews, JAD sessions,
questionnaires, document analysis, and observation. Th e
chapter also describes a set of alter-
native requirements-documentation techniques and describes the
system proposal document
that pulls everything together.
OBJECTIVES
■ Understand how to create a requirements defi nition
■ Become familiar with requirements-analysis techniques
■ Understand when to use each requirements-analysis technique
■ Understand how to gather requirements using interviews, JAD
sessions, questionnaires,
document analysis, and observation
■ Understand the use of concept maps, story cards, and task
lists as requirements-
documentation techniques
■ Understand when to use each requirements-gathering
technique
■ Be able to begin creating a system proposal

INTRODUCTION
Th e systems development process aids an organization in
moving from the current system
(oft en called the as-is system) to the new system (oft en called
the to-be system). Th e output of
planning, discussed in Chapter 2, is the system request, which
provides general ideas for the
to-be system, defi nes the project’s scope, and provides the
initial workplan. Analysis takes the
general ideas in the system request and refi nes them into a
detailed requirements defi nition
(this chapter), functional models (Chapter 4), structural models
(Chapter 5), and behavioral
models (Chapter 6) that together form the system proposal. Th e
system proposal also includes
revised project management deliverables, such as the feasibility
analysis and the workplan
(Chapter 2).
Th e output of analysis, the system proposal, is presented to the
approval committee, who
decides if the project is to continue. If approved, the system
proposal moves into design, and
its elements (requirements defi nition and functional, structural,
and behavioral models) are
used as inputs to the steps in design. Th is further refi nes them
and defi nes in much more
detail how the system will be built.
Th e line between analysis and design is very blurry. Th is is
because the deliverables
created during analysis are really the fi rst step in the design of
the new system. Many of
the major design decisions for the new system are found in the
analysis deliverables. It is

C H A P T E R 3
Requirements Determination
Copyright © 2015 John Wiley & Sons, Inc.
Requirements Determination 87
important to remember that the deliverables from analysis are
really the fi rst step in the
design of the new system.
In many ways, because it is here that the major elements of the
system fi rst emerge, the
requirements-determination step is the single most critical step
of the entire system devel-
opment process. During requirements determination, the system
is easy to change because
little work has been done yet. As the system moves through the
system development process,
it becomes harder and harder to return to requirements
determination and to make major
changes because of all of the rework that is involved. Several
studies have shown that more
than half of all system failures are due to problems with the
requirements.1 Th is is why the
iterative approaches of object-oriented methodologies are so eff
ective—small batches of
requirements can be identifi ed and implemented in incremental
stages, allowing the overall
system to evolve over time.
REQUIREMENTS DETERMINATION

Th e purpose of requirements determination is to turn the very
high-level explanation of
the business requirements stated in the system request into a
more precise list of require-
ments that can be used as inputs to the rest of analysis (creating
functional, structural, and
behavioral models). Th is expansion of the requirements
ultimately leads to the design of
the system.
Defi ning a Requirement
A requirement is simply a statement of what the system must do
or what characteristic it
must have. During analysis, requirements are written from the
perspective of the busi-
nessperson, and they focus on the “what” of the system.
Because they focus on the needs
of the business user, they are usually called business
requirements (and sometimes user
requirements). Later in design, business requirements evolve to
become more technical,
and they describe how the system will be implemented.
Requirements in design are writ-
ten from the developer’s perspective, and they are usually
called system requirements.
We want to stress that there is no black-and-white line dividing
a business requirement
and a system requirement—and some companies use the terms
interchangeably. Th e impor-
tant thing to remember is that a requirement is a statement of
what the system must do,
and requirements will change over time as the project moves
from inception to elaboration
to construction. Requirements evolve from detailed statements
of the business capabilities

that a system should have to detailed statements of the technical
way the capabilities will be
implemented in the new system.
Requirements can be either functional or nonfunctional in
nature. A functional require-
ment relates directly to a process a system has to perform or
information it needs to contain.
For example, requirements stating that a system must have the
ability to search for available
inventory or to report actual and budgeted expenses are
functional requirements. Functional
requirements fl ow directly into the creation of functional,
structural, and behavioral models
that represent the functionality of the evolving system (see
Chapters 4, 5, and 6).
Nonfunctional requirements refer to behavioral properties that
the system must have,
such as performance and usability. Th e ability to access the
system using a Web browser is
considered a nonfunctional requirement. Nonfunctional
requirements can infl uence the rest
of analysis (functional, structural, and behavioral models) but
oft en do so only indirectly;
nonfunctional requirements are used primarily in design when
decisions are made about the
database, the user interface, the hardware and soft ware, and the
system’s underlying physical
architecture.
1 For example, see Th e Scope of Soft ware Development
Project Failures (Dennis, MA: Th e Standish Group, 1995).

88 Chapter 3 Requirements Determination
Nonfunctional requirements describe a variety of characteristics
regarding the system:
operational, performance, security, and cultural and political.
Operational requirements
address issues related to the physical and technical requirements
in which the system will
operate. Performance requirements address issues related to the
speed, capacity, and reli-
ability of the system. Security requirements deal with issues
with regard to who has access
to the system and under what specifi c circumstances. Cultural
and political requirements
deal with issues related to the cultural, political factors and
legal requirements that aff ect the
system. Th ese characteristics do not describe business
processes or information, but they
are very important in understanding what the fi nal system
should be like. Nonfunctional
requirements primarily aff ect decisions that will be made
during the design of a system. We
will return to this topic later in the book when we discuss
design (see Chapters 9, 10, and 11).
One area of information systems development that focused on
diff erentiating functional
and nonfunctional requirements is soft ware quality. Th ere
have been many diff erent models
proposed to measure the quality of soft ware. However,
virtually all of them diff erentiate func-
tional and nonfunctional requirements. From a quality
perspective, functional quality is related
to the degree that the soft ware meets the functional
requirements, i.e., how much of the actual

problem is solved by the soft ware solution provided. Whereas,
the nonfunctional requirements
are associated with the effi ciency, maintainability, portability,
reliability, reusability, testability,
and usability quality dimensions. As stated above, the
nonfunctional related dimensions are
associated primarily with the actual detailed design and
implementation of the system.
When considering ISO 9000 compliance, quality dimensions are
further decomposed into
those that the user can see (external) and those that the user
cannot see (internal). Th e external
nonfunctional dimensions include effi ciency, reliability, and
usability, whereas the internal
nonfunctional dimensions include maintainability, portability,
reusability, and testability.
From a user perspective, the external dimensions are more
important. If the system is simply
too diffi cult to use, regardless how well the system solves the
problem, the user will simply
not use the system. In other words, from a user’s perspective,
for an information system to be
successful, the system must not only meet the functional specifi
cation, but it must also meet
the external nonfunctional specifi cations. From a developer
perspective, the internal dimen-
sions are also important. For example, given that successful
systems tend to be long-lived and
multiplatform, both the maintainability and portability
dimensions can have strategic implica-
tions for the system being developed. Also, given the agile
development approaches being used
in industry today, the development of reusable and testable soft
ware is crucial.

Th ree additional topics that have infl uenced information
system requirements are the
Sarbanes-Oxley Act, COBIT (Control OBjectives for
Information and related Technology)
compliance and Capability Maturity Model compliance.
Depending on the system being con-
sidered, these three topics could aff ect the defi nition of a
system’s functional requirements,
nonfunctional requirements, or both. Th e Sarbanes-Oxley Act,
for example, mandates addi-
tional functional and nonfunctional requirements. Th ese
include additional security concerns
(nonfunctional) and specifi c information requirements that
management must now provide
(functional). When developing fi nancial information systems,
information system developers
should be sure to include Sarbanes-Oxley expertise in the
development team. Moreover, a client
could insist on COBIT compliance or that a specifi c Capability
Maturity Model level had been
reached in order for the fi rm to be considered as a possible
vendor to supply the system under
consideration. Obviously, these types of requirements add to the
nonfunctional requirements.
Further discussion of these topics is beyond the scope of this
book.2
2 A concise discussion of the Sarbanes-Oxley Act is presented
in G. P. Lander, What is Sarbanes-Oxley? (New York:
McGraw-Hill, 2004). A good reference for Sarbanes-Oxley Act-
based security requirements is D. C. Brewer, Security
Controls for Sarbanes-Oxley Section 404 IT Compliance:
Authorization, Authentication, and Access (Indianapolis, IN:
Wiley, 2006). For detailed information on COBIT, see
www.isaca.org; for ISO 9000, see www.iso.org; and for details
on the Capability Maturity Model, see www.sei.cmu.edu/cmmi/.

Another recent topic that infl uences requirements for some
systems is globalization. For
example, a global information supply chain generates a large
number of additional nonfunc-
tional requirements. If the necessary operational environments
do not exist for a mobile solu-
tion to be developed, it is important to adapt the solution to the
local environment. Or, it may
not be reasonable to expect to deploy a high-technology-based
solution in an area that does not
have the necessary power and communications infrastructure. In
some cases, we may need to
consider supporting some parts of the global information supply
chain with manual—rather
than automated—systems.
Manual systems have an entirely diff erent set of requirements
that create diff erent per-
formance expectations and additional security concerns.
Furthermore, cultural and political
concerns are potentially paramount. A simple example that aff
ects the design of user inter-
faces is the proper use of color on forms (on a screen or paper).
Diff erent cultures interpret
diff erent colors diff erently. In other words, in a global,
multicultural business environment,
addressing cultural concerns goes well beyond simply having a
multilingual user interface.
We must be able to adapt the global solution to the local

realities. Friedman refers to these
concerns as glocalization.3 Otherwise, we will simply create
another example of a failed infor-
mation system development project.
Requirements Defi nition
Th e requirements defi nition report—usually just called the
requirements defi nition—is a
straightforward text report that simply lists the functional and
nonfunctional requirements
in an outline format. Figure 3-1 shows a sample requirements
defi nition for an appointment
system for a typical doctor’s offi ce. Notice it contains both
functional and nonfunctional
requirements. Th e functional requirements include managing
appointments, producing
schedules, and recording the availability of the individual
doctors. Th e nonfunctional require-
ments include items such as the expected amount of time that it
takes to store a new appoint-
ment, the need to support wireless printing, and which types of
employees have access to the
diff erent parts of the system.
Th e requirements are numbered in a legal or outline format so
that each requirement
is clearly identifi ed. Th e requirements are fi rst grouped into
functional and nonfunctional
requirements; within each of those headings, they are further
grouped by the type of nonfunc-
tional requirement or by function.
Sometimes business requirements are prioritized on the
requirements defi nition. Th ey
can be ranked as having high, medium, or low importance in the
new system, or they can

be labeled with the version of the system that will address the
requirement (e.g., release 1,
release 2, release 3). Th is practice is particularly important
when using object-oriented meth-
odologies since they deliver systems in an incremental manner.
Th e most obvious purpose of the requirements defi nition is to
provide the information
needed by the other deliverables in analysis, which include
functional, structural, and behav-
ioral models, and to support activities in design. Th e most
important purpose of the require-
ments defi nition, however, is to defi ne the scope of the
system. Th e document describes to
the analysts exactly what the system needs to end up doing.
When discrepancies arise, the
document serves as the place to go for clarifi cation.
Determining Requirements
Determining requirements for the requirements defi nition is
both a business task and an
information technology task. In the early days of computing,
there was a presumption that
3 T. L. Friedman, Th e World is Flat: A Brief History of the
Twenty-First Century, Updated and Expanded Edition. (New
York: Farrar, Straus, and Giroux, 2006.)
the systems analysts, as experts with computer systems, were in
the best position to defi ne

how a computer system should operate. Many systems failed
because they did not adequately
address the true business needs of the users. Gradually, the
presumption changed so that the
users, as the business experts, were seen as being the best
position to defi ne how a computer
system should operate. However, many systems failed to deliver
performance benefi ts because
users simply automated an existing ineffi cient system, and
they failed to incorporate new
opportunities off ered by technology.
Th erefore, the most eff ective approach is to have both
business people and analysts
working together to determine business requirements.
Sometimes, however, users don’t
know exactly what they want, and analysts need to help them
discover their needs. A set of
strategies has become popular to help analysts do problem
analysis, root cause analysis, dura-
tion analysis, activity-based costing, informal benchmarking,
outcome analysis, technology
analysis, and activity elimination. Analysts can use these tools
when they need to guide the
users in explaining what is wanted from a system. Th ese
strategies work similarly. Th ey help
users critically examine the current state of systems and
processes (the as-is system), identify
exactly what needs to change, and develop a concept for a new
system (the to-be system).
Functional Requirements
1. Manage Appointments
1.1. Patient makes new appointment.
1.2. Patient changes appointment.

1.3. Patient cancels appointment.
2. Produce Schedule
2.1. Office Manager checks daily schedule.
2.2. Office Manager prints daily schedule.
3. Record Doctor Availability
3.1. Doctor updates schedule
Nonfunctional Requirements
1. Operational Requirements
1.1. The system will operate in Windows environment.
1.2. The system should be able to connect to printers
wirelessly.
1.3. The system should automatically back up at the end of
each day.
2. Performance Requirements
2.1. The system will store a new appointment in 2 seconds or
less.
2.2. The system will retrieve the daily appointment schedule
in 2 seconds or less.
3. Security Requirements
3.1. Only doctors can set their availability.
3.2. Only a manager can produce a schedule.
4. Cultural and Political Requirements
4.1. No special cultural and political requirements are
anticipated.
FIGURE 3-1
Sample Requirements
Defi nition

Although these strategies enable the analyst to help users create
a vision for the new
system, they are not suffi cient for extracting information about
the detailed business require-
ments that are needed to build it. Th erefore, analysts use a
portfolio of requirements-gathering
techniques to acquire information from users. Th e analyst has
many techniques from which
to choose: interviews, questionnaires, observation, joint
application development (JAD), and
document analysis. Th e information gathered using these
techniques is critically analyzed and
used to craft the requirements defi nition report.
Creating a Requirements Defi nition
Creating a requirements defi nition is an iterative and ongoing
process whereby the analyst
collects information with requirements-gathering techniques
(e.g., interviews, document
analysis), critically analyzes the information to identify
appropriate business requirements
for the system, and adds the requirements to the requirements
defi nition report. Th e require-
ments defi nition is kept up to date so that the project team and
business users can refer to it
and get a clear understanding of the new system.
To create a requirements defi nition, the project team fi rst
determines the kinds of func-
tional and nonfunctional requirements that they will collect

about the system (of course, these
may change over time). Th ese become the main sections of the
document. Next, the analysts
use a variety of requirements-gathering techniques to collect
information, and they list the
business requirements that were identifi ed from that
information. Finally, the analysts work
with the entire project team and the business users to verify,
change, and complete the list and
to help prioritize the importance of the requirements that were
identifi ed.
Th is process continues throughout analysis, and the
requirements defi nition evolves
over time as new requirements are identifi ed and as the project
moves into later phases of the
Unifi ed Process. Beware: Th e evolution of the requirements
defi nition must be carefully man-
aged. Th e project team cannot keep adding to the requirements
defi nition, or the system will
keep growing and growing and never get fi nished. Instead, the
project team carefully identifi es
requirements and evaluates which ones fi t within the scope of
the system. When a requirement
refl ects a real business need but is not within the scope of the
current system or current release,
it is either added on a list of future requirements or given a low
priority. Th e management of
requirements (and system scope) is one of the hardest parts of
managing a project.
Real-World Problems with Requirements Determination
Avison and Fitzgerald provide us with a set of problems that
can arise with regard to deter-
mining the set of requirements with which to be dealt.4 First,
the analyst might not have

access to the correct set of users to uncover the complete set of
requirements. Th is can lead to
requirements being missed, misrepresented, and/or overspecifi
ed. Second, the specifi cation
of the requirements may be inadequate. Th is can be especially
true with the lightweight tech-
niques associated with agile methodologies. Th ird, some
requirements are simply unknowa-
ble at the beginning of a development process. However, as the
system is developed, the users
and analysts will get a better understanding of both the domain
issues and the applicable tech-
nology. Th is can cause new functional and nonfunctional
requirements to be identifi ed and
current requirements to evolve or be canceled. Iterative and
incremental-based development
methodologies, such as the Unifi ed Process and agile, can help
in this case. Fourth, verifying
and validating of requirements can be very diffi cult. We take
up this topic in the chapters
that deal with the creation of functional (Chapter 4), structural
(Chapter 5), and behavioral
(Chapter 6) models.
4 See D. Avison and G. Fitzgerald, Information Systems
Development: Methodologies, Techniques, & Tools, 4th Ed.
(London: McGraw-Hill, 2006).
REQUIREMENTS ANALYSIS STRATEGIES
Before the project team can determine what requirements are

appropriate for a given system,
there needs to be a clear vision of the kind of system that will
be created and the level of
change that it will bring to the organization. Th e basic process
of analysis is divided into three
steps: understanding the as-is system, identifying
improvements, and developing require-
ments for the to-be system.
Sometimes the fi rst step (i.e., understanding the as-is system)
is skipped or is performed in a
cursory manner. Th is happens when no current system exists, if
the existing system and processes
are irrelevant to the future system, or if the project team is
using a RAD or agile development
methodology in which the as-is system is not emphasized.
Newer RAD, agile, and object-oriented
methodologies, such as phased development, prototyping,
throwaway prototyping, extreme pro-
gramming, and Scrum (see Chapter 1) focus almost exclusively
on improvements and the to-be
system requirements, and they spend little time investigating the
current as-is system.
Requirements analysis strategies help the analyst lead users
through the analysis steps
so that the vision of the system can be developed. Requirements
analysis strategies and
requirements-gathering techniques go hand in hand. Analysts
use requirements-gathering
techniques to collect information; requirements analysis
strategies drive the kind of infor-
mation that is gathered and how it is ultimately analyzed. Th e
requirements analysis strat-
egies and requirements gathering happen concurrently and are
complementary activities.

To move the users from the as-is system to the to-be system, an
analyst needs strong
critical thinking skills. Critical thinking is the ability to
recognize strengths and weaknesses
and recast an idea in an improved form, and critical thinking
skills are needed to really under-
stand issues and develop new business processes. Th ese skills
are also needed to thoroughly
examine the results of requirements gathering, to identify
business requirements, and to
translate those requirements into a concept for the new system.
Problem Analysis
Th e most straightforward (and probably the most commonly
used) requirements-analysis
technique is problem analysis. Problem analysis means asking
the users and managers to
identify problems with the as-is system and to describe how to
solve them in the to-be
system. Most users have a very good idea of the changes they
would like to see, and most
are quite vocal about suggesting them. Most changes tend to
solve problems rather than
capitalize on opportunities, but the latter is possible as well.
Improvements from problem
analysis tend to be small and incremental (e.g., provide more
space in which to type the
customer’s address; provide a new report that currently does not
exist).
Th is type of improvement oft en is very eff ective at improving
a system’s effi ciency or
ease of use. However, it oft en provides only minor
improvements in business value—the new
system is better than the old, but it may be hard to identify

signifi cant monetary benefi ts from
the new system.
Root Cause Analysis
Th e ideas produced by problem analysis tend to be solutions to
problems. All solutions make
assumptions about the nature of the problem, assumptions that
might or might not be valid.
In our experience, users (and most people in general) tend to
quickly jump to solutions with-
out fully considering the nature of the problem. Sometimes the
solutions are appropriate, but
many times they address a symptom of the problem, not the true
problem or root cause itself.5
5 Two good books that discuss the diffi culty in fi nding the
root causes to problems are: E. M. Goldratt and
J. Cox, Th e Goal (Croton-on-Hudson, NY: North River Press,
1986); E. M. Goldratt, Th e Haystack Syndrome
(Croton-on-Hudson, NY: North River Press, 1990).
Requirements Analysis Strategies 93
For example, suppose a fi rm notices that its users report
inventory stock-outs. Th e cost of
inventory stock-outs can be quite signifi cant. In this case, since
they happen frequently, custom-
ers could fi nd another source for the items that they are
purchasing from the fi rm. It is in the
fi rm’s interest to determine the underlying cause and not
simply provide a knee-jerk reaction
such as arbitrarily increasing the amount of inventory kept on

hand. In the business world,
the challenge lies in identifying the root cause—few real-world
problems are simple. Th e users
typically propose a set of causes for the problem under
consideration. Th e solutions that users
propose can address either symptoms or root causes, but without
a careful analysis, it is diffi cult
to tell which one is addressed.
Root cause analysis, therefore, focuses on problems, not
solutions. Th e analyst starts by
having the users generate a list of problems with the current
system and then prioritize the
problems in order of importance. Starting with the most
important, the users and/or the
analysts then generate all the possible root causes for the
problems. Each possible root cause
is investigated (starting with the most likely or easiest to check)
until the true root causes
are identifi ed. If any possible root causes are identifi ed for
several problems, those should
be investigated fi rst, because there is a good chance they are
the real root causes infl uencing
the symptom problems. In our example, there are several
possible root causes:
■ Th e fi rm’s supplier might not be delivering orders to the fi
rm in a timely manner.
■ Th ere could be a problem with the fi rm’s inventory controls.
■ Th e reorder level and quantities could be set wrong.
Sometimes, using a hierarchical chart to represent the causal
relationships helps with the analysis.
As Figure 3-2 shows, there are many possible root causes that
underlie the higher-level causes
identifi ed. Th e key point in root cause analysis is always to

challenge the obvious.
Duration Analysis
Duration analysis requires a detailed examination of the amount
of time it takes to perform
each process in the current as-is system. Th e analysts begin by
determining the total amount
of time it takes, on average, to perform a set of business
processes for a typical input. Th ey
then time each of the individual steps (or subprocesses) in the
business process. Th e time to
Frequent
Inventory Stock-Outs
Order Approval
Late
Identifying Vendor
Delayed
Delay in Sending
Order to Vendor
Delays in Order
Processing
Late Recording of
Sales
Late Recording of
Purchases Received
Infrequent Manual
Inventory Reconciliation

Problems with
Inventory Controls
Reorder point set
too low
Reorder Quantity
(EOQ) set too low
Incorrect Reorder
Level and Quantities
FIGURE 3-2 Root Cause Analysis for Inventory Stock-Outs
complete the basic step is then totaled and compared to the total
for the overall process. A
signifi cant diff erence between the two—and in our experience
the total time oft en can be 10
or even 100 times longer than the sum of the parts—indicates
that this part of the process is
badly in need of a major overhaul.
For example, suppose that the analysts are working on a home
mortgage system and dis-
cover that on average, it takes thirty days for the bank to
approve a mortgage. Th ey then look
at each of the basic steps in the process (e.g., data entry, credit
check, title search, appraisal)
and fi nd that the total amount of time actually spent on each
mortgage is about eight hours.
Th is is a strong indication that the overall process is badly
broken, because it takes thirty days

to perform one day’s work.
Th ese problems probably occur because the process is badly
fragmented. Many diff erent
people must perform diff erent activities before the process fi
nishes. In the mortgage exam-
ple, the application probably sits on many people’s desks for
long periods of time before it
is processed.
Processes in which many diff erent people work on small parts
of the inputs are prime
candidates for process integration or parallelization. Process
integration means changing the
fundamental process so that fewer people work on the input,
which oft en requires changing
the processes and retraining staff to perform a wider range of
duties. Process parallelization
means changing the process so that all the individual steps are
performed at the same time.
For example, in the mortgage application case, there is probably
no reason that the credit
check cannot be performed at the same time as the appraisal and
title check.
Activity-Based Costing
Activity-based costing is a similar analysis; it examines the cost
of each major process or step
in a business process rather than the time taken.6 Th e analysts
identify the costs associated
with each of the basic functional steps or processes, identify the
most costly processes, and
focus their improvement eff orts on them.
Assigning costs is conceptually simple. Analysts simply
examine the direct cost of labor

and materials for each input. Materials costs are easily assigned
in a manufacturing process,
whereas labor costs are usually calculated based on the amount
of time spent on the input and
the hourly cost of the staff . However, as you may recall from a
managerial accounting course,
there are indirect costs, such as rent, depreciation, and so on,
that also can be included in
activity costs.
Informal Benchmarking
Benchmarking refers to studying how other organizations
perform a business process in
order to learn how your organization can do something better.
Benchmarking helps the
organization by introducing ideas that employees may never
have considered but that have
the potential to add value.
Informal benchmarking is fairly common for customer-facing
business processes (i.e.,
processes that interact with the customer). With informal
benchmarking, the managers and
analysts think about other organizations or visit them as
customers to watch how the business
process is performed. In many cases, the business studied may
be a known leader in the indus-
try or simply a related fi rm.
6 Many books have been written on activity-based costing.
Useful ones include K. B. Burk and D. W. Webster,
Activity-Based Costing (Fairfax, VA: American Management
Systems, 1994); D. T. Hicks, Activity-Based Costing:
Making It Work for Small and Mid-sized Companies (New
York: Wiley, 1998). Th e two books by Eli Goldratt men-
tioned previously (Th e Goal and Th e Haystack Syndrome) also

off er unique insights into costing.
Requirements-Gathering Techniques 95
Outcome Analysis
Outcome analysis focuses on understanding the fundamental
outcomes that provide value to
customers. Although these outcomes sound as though they
should be obvious, they oft en are
not. For example, consider an insurance company. One of its
customers has just had a car
accident. What is the fundamental outcome from the customer’s
perspective? Traditionally,
insurance companies have answered this question by assuming
the customer wants to receive
the insurance payment quickly. To the customer, however, the
payment is only a means to
the real outcome: a repaired car. Th e insurance company might
benefi t by extending its view
of the business process past its traditional boundaries to include
not paying for repairs but
performing the repairs or contracting with an authorized body
shop to do them.
With this approach, system analysts encourage the managers
and project sponsor to
pretend they are customers and to think carefully about what the
organization’s products and
services enable the customers to do—and what they could
enable the customer to do.

Technology Analysis
Many major changes in business since the turn of the century
have been enabled by new
technologies. Technology analysis starts by having the analysts
and managers develop a list
of important and interesting technologies. Th en the group
systematically identifi es how
every technology could be applied to the business process and
identifi es how the business
would benefi t. It is important to note the technology analysis in
no way implies adopting
technology for technology’s sake. Rather the focus is on using
new technologies to meet the
goals of the organization.
Activity Elimination
Activity elimination is exactly what it sounds like. Th e
analysts and managers work together
to identify how the organization could eliminate each activity in
the business process, how the
function could operate without it, and what eff ects are likely to
occur. Initially, managers are
reluctant to conclude that processes can be eliminated, but this
is a force-fi t exercise in that
they must eliminate each activity. In some cases, the results are
silly; nonetheless, participants
must address every activity in the business process.
REQUIREMENTS-GATHERING TECHNIQUES
An analyst is very much like a detective (and business users are
sometimes like elusive sus-
pects). He or she knows that there is a problem to be solved and
therefore must look for clues
that uncover the solution. Unfortunately, the clues are not
always obvious (and are oft en

missed), so the analyst needs to notice details, talk with
witnesses, and follow leads just as
Sherlock Holmes would have done. Th e best analysts
thoroughly gather requirements using a
variety of techniques and make sure that the current business
processes and the needs for the
new system are well understood before moving into design.
Analysts don’t want to discover
later that they have key requirements wrong—such surprises
late in the development process
can cause all kinds of problems.
Th e requirements-gathering process is used for building
political support for the pro-
ject and establishing trust and rapport between the project team
building the system and
the users who ultimately will choose to use or not use the
system. Involving someone in the
process implies that the project teams view that person as an
important resource and value
his or her opinions. All the key stakeholders (the people who
can aff ect the system or who
will be aff ected by the system) must be included in the
requirements-gathering process. Th e
stakeholders might include managers, employees, staff
members, and even some customers
and suppliers. If a key person is not involved, that individual
might feel slighted, which can
cause problems during implementation (e.g., How could they
have developed the system
without my input?).

Th e second challenge of requirements gathering is choosing the
way(s) information is
collected. Th ere are many techniques for gathering
requirements that vary from asking people
questions to watching them work. In this section, we focus on
the fi ve most commonly used
techniques: interviews, JAD sessions (a special type of group
meeting), questionnaires, docu-
ment analysis, and observation. Each technique has its own
strengths and weaknesses, many of
which are complementary, so most projects use a combination
of techniques.7
Interviews
An interview is the most commonly used requirements-
gathering technique. Aft er all, it is
natural—if you need to know something, you usually ask
someone. In general, interviews are
conducted one-on-one (one interviewer and one interviewee),
but sometimes, owing to time
constraints, several people are interviewed at the same time. Th
ere are fi ve basic steps to the inter-
view process: selecting interviewees, designing interview
questions, preparing for the interview,
conducting the interview, and postinterview follow-up.8
Th e fi rst step in interviewing is to create an interview
schedule listing who will be interviewed,
when, and for what purpose (see Figure 3-3). Th e schedule can
be an informal list that is
used to help set up meeting times or a formal list that is
incorporated into the workplan. Th e
people who appear on the interview schedule are selected based
on the analyst’s information
needs. Th e project sponsor, key business users, and other

members of the project team can
help the analyst determine who in the organization can best
provide important information
about requirements. Th ese people are listed on the interview
schedule in the order in which
they should be interviewed.
People at diff erent levels of the organization have varying
perspectives on the system, so
it is important to include both managers who manage the
processes and staff who actually
perform the processes to gain both high-level and low-level
perspectives on an issue. Also,
the kinds of interview subjects needed can change over time.
For example, at the start of the
project, the analyst has a limited understanding of the as-is
business process. It is common
to begin by interviewing one or two senior managers to get a
strategic view and then to move
to midlevel managers who can provide broad, overarching
information about the business
process and the expected role of the system being developed.
Once the analyst has a good
understanding of the big picture, lower-level managers and staff
members can fi ll in the exact
details of how the process works. Like most other things about
systems analysis, this is an
iterative process—starting with senior managers, moving to
midlevel managers, then staff
members, back to midlevel managers, and so on, depending
upon what information is needed
along the way.
It is quite common for the list of interviewees to grow, oft en by
50 to 75 percent. As peo-
ple are interviewed, more information that is needed and

additional people who can provide
the information will probably be identifi ed.
7 Some excellent books that address the importance of
gathering requirements and various techniques include
Alan M. Davis, Soft ware Requirements: Objects, Functions, &
States, Revision (Englewood Cliff s, NJ: Prentice Hall,
1993); Gerald Kotonya and Ian Sommerville, Requirements
Engineering (Chichester, England: Wiley, 1998); Dean
Leffi ngwell and Don Widrig, Managing Soft ware
Requirements: A Unifi ed Approach (Reading, MA: Addison-
Wesley,
2000).
8 A good book on interviewing is that by Brian James, Th e
Systems Analysis Interview (Manchester, England: NCC
Blackwell, 1989).
1. Select
Interviewees
Th ere are three types of interview questions: closed-ended
questions, open-ended questions,
and probing questions. Closed-ended questions are those that
require a specifi c answer. Th ey
are similar to multiple-choice or arithmetic questions on an
exam (see Figure 3-4). Closed-
ended questions are used when an analyst is looking for specifi
c, precise information (e.g.,

how many credit card requests are received per day). In general,
precise questions are best.
For example, rather than asking, Do you handle a lot of
requests? it is better to ask, How many
requests do you process per day? Closed-ended questions enable
analysts to control the inter-
view and obtain the information they need. However, these
types of questions don’t uncover
why the answer is the way it is, nor do they uncover information
that the interviewer does not
think to ask for ahead of time.
Open-ended questions are those that leave room for elaboration
on the part of the inter-
viewee. Th ey are similar in many ways to essay questions that
you might fi nd on an exam (see
Figure 3-4 for examples). Open-ended questions are designed to
gather rich information and
give the interviewee more control over the information that is
revealed during the interview.
Sometimes the information that the interviewee chooses to
discuss uncovers information that is
just as important as the answer (e.g., if the interviewee talks
only about other departments when
asked for problems, it may suggest that he or she is reluctant to
admit his or her own problems).
Th e third type of question is the probing question. Probing
questions follow up on what
has just been discussed in order to learn more, and they oft en
are used when the interviewer is
unclear about an interviewee’s answer. Th ey encourage the
interviewee to expand on or to con-
fi rm information from a previous response, and they signal that
the interviewer is listening and
is interested in the topic under discussion. Many beginning

analysts are reluctant to use probing
questions because they are afraid that the interviewee might be
off ended at being challenged or
because they believe it shows that they didn’t understand what
the interviewee said. When done
politely, probing questions can be a powerful tool in
requirements gathering.
In general, an interviewer should not ask questions about
information that is readily
available from other sources. For example, rather than asking
what information is used to
perform to a task, it is simpler to show the interviewee a form
or report (see the section on
document analysis) and ask what information on it is used. Th is
helps focus the interviewee
on the task and saves time, because the interviewee does not
need to describe the information
detail—he or she just needs to point it out on the form or report.
No type of question is better than another, and a combination of
questions is usually used
during an interview. At the initial stage of an IS development
project, the as-is process can
2. Design
Interview Questions
FIGURE 3-3
Sample Interview
Schedule
Andria McClellan Director, Accounting Strategic vision for new
Mon., March 1
accounting system 8:00–10:00 AM

Jennifer Draper Manager, Accounts Current problems with
Mon., March 1
Receivable accounts receivable 2:00–3:15 PM
process; future goals
Mark Goodin Manager, Accounts Current problems with Mon.,
March 1
Payable accounts payable 4:00–5:15 PM
process; future goals
Anne Asher Supervisor, Data Entry Accounts receivable and
Wed., March 3
payable processes 10:00–11:00 AM
Fernando Merce Data Entry Clerk Accounts receivable and
Wed., March 3
payable processes 1:00–3:00 PM
Purpose of
Name Position Interview Meeting
be unclear, so the interview process begins with unstructured
interviews, interviews that seek
broad and roughly defi ned information. In this case, the
interviewer has a general sense of the
information needed but has few closed-ended questions to ask.
Th ese are the most challeng-
ing interviews to conduct because they require the interviewer
to ask open-ended questions
and probe for important information on the fl y.
As the project progresses, the analyst comes to understand the

business process much better
and needs very specifi c information about how business
processes are performed (e.g., exactly
how a customer credit card is approved). At this time, the
analyst conducts structured interviews,
in which specifi c sets of questions are developed before the
interviews. Th ere usually are more
closed-ended questions in a structured interview than in the
unstructured approach.
No matter what kind of interview is being conducted, interview
questions must be
organized into a logical sequence so that the interview fl ows
well. For example, when trying
to gather information about the current business process, it can
be useful to move in logical
order through the process or from the most important issues to
the least important.
Th ere are two fundamental approaches to organizing the
interview questions: top down
or bottom up (see Figure 3-5). With the top-down interview, the
interviewer starts with broad,
general issues and gradually works toward more-specifi c ones.
With the bottom-up interview,
the interviewer starts with very specifi c questions and moves to
broad questions. In practice,
analysts mix the two approaches, starting with broad, general
issues, moving to specifi c ques-
tions, and then returning to general issues.
Th e top-down approach is an appropriate strategy for most
interviews (it is certainly the
most common approach). Th e top-down approach enables the
interviewee to become accus-
tomed to the topic before he or she needs to provide specifi cs.

It also enables the interviewer
to understand the issues before moving to the details because
the interviewer might not have
suffi cient information at the start of the interview to ask very
specifi c questions. Perhaps most
importantly, the top-down approach enables the interviewee to
raise a set of big-picture issues
before becoming enmeshed in details, so the interviewer is less
likely to miss important issues.
One case in which the bottom-up strategy may be preferred is
when the analyst already
has gathered a lot of information about issues and just needs to
fi ll in some holes with details.
Bottom-up interviewing may be appropriate if lower-level staff
members feel threatened or
unable to answer high-level questions. For example, How can
we improve customer service?
might be too broad a question for a customer service clerk,
whereas a specifi c question is readily
answerable (e.g., How can we speed up customer returns?). In
any event, all interviews should
begin with noncontroversial questions and then gradually move
into more contentious issues
aft er the interviewer has developed some rapport with the
interviewee.
Closed-ended questions • How many telephone orders are
received per day?
• How do customers place orders?
• What information is missing from the monthly sales report?
Open-ended questions • What do you think about the current
system?

• What are some of the problems you face on a daily basis?
• What are some of the improvements you would like to see in
a
new system?
Probing questions • Why?
• Can you give me an example?
• Can you explain that in a bit more detail?
FIGURE 3-4
Three Types of
Questions
Types of Questions Examples
It is important to prepare for the interview in the same way that
you would prepare to give
a presentation. Th e interviewer should have a general interview
plan listing the questions to
be asked in the appropriate order, should anticipate possible
answers and provide follow-up
with them, and should identify segues between related topics.
Th e interviewer should con-
fi rm the areas in which the interviewee has knowledge so as

not to ask questions that the
interviewee cannot answer. Review the topic areas, the
questions, and the interview plan,
and clearly decide which have the greatest priority in case time
runs short.
In general, structured interviews with closed-ended questions
take more time to prepare
than unstructured interviews. Some beginning analysts prefer
unstructured interviews, think-
ing that they can wing it. Th is is very dangerous and oft en
counterproductive, because any
information not gathered in the fi rst interview will require
follow-up eff orts, and most users
do not like to be interviewed repeatedly about the same issues.
Th e interviewer should be sure to prepare the interviewee as
well. When the interview
is scheduled, the interviewee should be told the reason for the
interview and the areas that
will be discussed far enough in advance so that he or she has
time to think about the issues
and organize his or her thoughts. Th is is particularly important
when the interviewer is
an outsider to the organization and for lower-level employees,
who oft en are not asked for
their opinions and who may be uncertain about why they are
being interviewed.
Th e fi rst goal is to build rapport with the interviewee, so that
he or she trusts the inter-
viewer and is willing to tell the whole truth, not just give the
answers that he or she thinks
are wanted. Th e interviewer should appear to be a professional
and unbiased, independent
seeker of information. Th e interview should start with an

explanation of why the inter-
viewer is there and why he or she has chosen to interview the
person; then the interviewer
should move into the planned interview questions.
It is critical to carefully record all the information that the
interviewee provides. In our
experience, the best approach is to take careful notes—write
down everything the interviewee
says, even if it does not appear immediately relevant. Th e
interviewer shouldn’t be afraid to ask
the person to slow down or to pause while writing, because this
is a clear indication that the
interviewee’s information is important. One potentially
controversial issue is whether or not
to tape-record an interview. Recording ensures that the
interviewer does not miss important
3. Prepare for the
Interview
4. Conduct the
Interview
FIGURE 3-5 Top-Down and Bottom-Up Questioning Strategies
High-level:
Very general
Top-Down
Bottom-Up
Medium-level:
Moderately specific

Low-level:
Very specific
How
can order
processing
be improved?
How can we reduce
the number of times that
customers return items
they’ve ordered?
How can we reduce the number of
errors in order processing (e.g., shipping
the wrong products)?
points, but it can be intimidating for the interviewee. Most
organizations have policies or
generally accepted practices about the recording of interviews,
so they should be determined
before an interview. If the interviewer is worried about missing
information and cannot tape
the interview, then he or she can bring along a second person to
take detailed notes.
As the interview progresses, it is important to understand the
issues that are discussed.
If the interviewer does not understand something, he or she

should ask for clarifi cation.
Th e interviewer should not be afraid to ask dumb questions,
because the only thing worse
than appearing dumb is to be dumb by not understanding
something. If the interviewer
doesn’t understand something during the interview, he or she
certainly won’t understand it
aft erwards. Jargon should be recognized and defi ned; any
jargon not understood should be
clarifi ed. One good strategy to increase understanding during
an interview is to periodically
summarize the key points that the interviewee is
communicating. Th is avoids misunder-
standings and also demonstrates that the interviewer is
listening.
Finally, facts should be separated from opinion. Th e
interviewee may say, for example,
We process too many credit card requests. Th is is an opinion,
and it is useful to follow this
up with a probing question requesting support for the statement
(e.g., Oh, how many do you
process in a day?). It is helpful to check the facts because any
diff erences between the facts
and the interviewee’s opinions can point out key areas for
improvement. Suppose the inter-
viewee complains about a high or increasing number of errors,
but the logs show that errors
have been decreasing. Th is suggests that errors are viewed as a
very important problem that
should be addressed by the new system, even if they are
declining.
As the interview draws to a close, the interviewee should have
time to ask questions or
provide information that he or she thinks is important but was

not part of the interview plan.
In most cases, the interviewee has no additional concerns or
information, but in some cases
this leads to unanticipated, but important, information.
Likewise, it can be useful to ask the
interviewee if there are other people who should be interviewed.
Th e interview should end on
time (if necessary, some topics can be omitted or another
interview can be scheduled).
As a last step in the interview, the interviewer should briefl y
explain what will happen.
Th e interviewer shouldn’t prematurely promise certain features
in the new system or a spe-
cifi c delivery date, but he or she should reassure the
interviewee that his or her time was well
spent and very helpful to the project.
Aft er the interview is over, the analyst needs to prepare an
interview report that describes the
information from the interview (Figure 3-6). Th e report
contains interview notes, information
that was collected over the course of the interview and is
summarized in a useful format. In
general, the interview report should be written within forty-
eight hours of the interview,
because the longer the interviewer waits, the more likely he or
she is to forget information.
Oft en, the interview report is sent to the interviewee with a
request to read it and inform
the analyst of clarifi cations or updates. Th e interviewee needs
to be convinced that the inter-
viewer genuinely wants his or her corrections to the report.
Usually there are few changes, but
the need for any signifi cant changes suggests that a second

interview will be required. Never
distribute someone’s information without prior approval.
Joint Application Development (JAD)
JAD is an information-gathering technique that allows the
project team, users, and management
to work together to identify requirements for the system. IBM
developed the JAD technique in
the late 1970s, and it is oft en the most useful method for
collecting information from users.9
9 More information on JAD can be found in J. Wood and D.
Silver, Joint Application Development (New York:
Wiley, 1989); Alan Cline, “Joint Application Development for
Requirements Collection and Management,” http://
www.carolla.com/wp-jad.htm.
5. Post-Interview
Follow-up
Capers Jones claims that JAD can reduce scope creep by 50
percent and prevent the system’s
requirements from being too specifi c or too vague, both of
which cause trouble during later stages
of the development process.10
JAD is a structured process in which ten to twenty users meet
together under the direc-

tion of a facilitator skilled in JAD techniques. Th e facilitator
sets the meeting agenda and
guides the discussion but does not join in the discussion as a
participant. He or she does not
provide ideas or opinions on the topics under discussion so as to
remain neutral during the
session. Th e facilitator must be an expert in both group-process
techniques and systems-
analysis and design techniques. One or two scribes assist the
facilitator by recording notes,
making copies, and so on. Oft en the scribes use computers and
CASE tools to record infor-
mation as the JAD session proceedings.
Th e JAD group meets for several hours, several days, or
several weeks until all the issues
have been discussed and the needed information is collected.
Most JAD sessions take place
in a specially prepared meeting room, away from the
participants’ offi ces so that they are not
interrupted. Th e meeting room is usually arranged in a U-shape
so that all participants can
easily see each other. At the front of the room (the open part of
the U), are a whiteboard, fl ip
chart, and/or overhead projector for use by the facilitator
leading the discussion.
FIGURE 3-6 Interview Report
Interview Notes Approved by: Linda Estey
Person Interviewed: Linda Estey,
Director, Human Resources
Interviewer: Barbara Wixom

Purpose of Interview:
• Understand reports produced for Human Resources by the
current system
• Determine information requirements for future system
Summary of Interview:
• Sample reports of all current HR reports are attached to this
report. The information that is not
used and missing information are noted on the reports.
• Two biggest problems with the current system are:
1. The data are too old (the HR Department needs information
within two days of month end;
currently, information is provided to them after a three-week
delay)
2. The data are of poor quality (often reports must be
reconciled with departmental HR
database)
• The most common data errors found in the current system
include incorrect job level information and
missing salary information.
Open Items:
• Get current employee roster report from Mary Skudrna
(extension 4355).
• Verify calculations used to determine vacation time with Mary
Skudrna.

• Schedule interview with Jim Wack (extension 2337) regarding
the reasons for data quality
problems.
Detailed Notes: See attached transcript.
10 See Kevin Strehlo, “Catching up with the Jones and
‘Requirement’ Creep,” Infoworld (July 29, 1996); Kevin
Strehlo,
“Th e Makings of a Happy Customer: Specifying Project X,”
Infoworld (November 11, 1996).
JAD suff ers from the traditional problems associated with
groups: Sometimes people
are reluctant to challenge the opinions of others (particularly
their boss), a few people oft en
dominate the discussion, and not everyone participates. In a fi ft
een-member group, for exam-
ple, if everyone participates equally, then each person can talk
for only four minutes each
hour and must listen for the remaining fi ft y-six minutes—not a
very effi cient way to collect
information.
A new form of JAD called electronic JAD, or e-JAD, attempts
to overcome these prob-
lems by using groupware. In an e-JAD meeting room, each
participant uses special soft ware
on a networked computer to send anonymous ideas and opinions
to everyone else. In this
way, all participants can contribute at the same time without

fear of reprisal from people
with diff ering opinions. Initial research suggests that e-JAD
can reduce the time required
to run JAD sessions by 50 to 80 percent.11 A good JAD
approach follows a set of fi ve steps.
JAD participants are selected in the same way as are interview
participants, based on the
information they can contribute in order to provide a broad mix
of organizational levels and
to build political support for the new system. Th e need for all
JAD participants to be away
from their offi ce at the same time can be a major problem. Th
e offi ce might need to be closed
or operate with a skeleton staff until the JAD sessions are
complete.
11 For more information on e-JAD, see A. R. Dennis, G. S.
Hayes, and R. M. Daniels, “Business Process Modeling
with Groupware,” Journal of Management Information Systems
15, no. 4 (1999): 115–142.
1. Select Participants
Interpersonal skills are skills that enable you to develop
rapport with others, and they are very important for
interviewing. They help you to communicate with others
effectively. Some people develop good interpersonal
skills at an early age; they simply seem to know how to
communicate and interact with others. Other people are
less lucky and need to work hard to develop their skills.
Interpersonal skills, like most skills, can be learned.
Here are some tips:

• Don’t worry, be happy. Happy people radiate con-
fi dence and project their feelings on others. Try inter-
viewing someone while smiling and then interviewing
someone else while frowning and see what happens.
• Pay attention. Pay attention to what the other person
is saying (which is harder than you might think). See
how many times you catch yourself with your mind
on something other than the conversation at hand.
• Summarize key points. At the end of each major
theme or idea that someone explains, repeat the key
points back to the speaker (e.g., Let me make sure I
understand. The key issues are. . . .”). This demon-
strates that you consider the information important,
and it also forces you to pay attention (you can’t
repeat what you didn’t hear).
• Be succinct. When you speak, be succinct. The goal
in interviewing (and in much of life) is to learn, not to
impress. The more you speak, the less time you give
to others.
• Be honest. Answer all questions truthfully, and if you
don’t know the answer, say so.
• Watch body language (yours and theirs). The way a
person sits or stands conveys much information. In
general, a person who is interested in what you are
saying sits or leans forward, makes eye contact, and
often touches his or her face. A person leaning away
from you or with an arm over the back of a chair is
uninterested. Crossed arms indicate defensiveness or
uncertainty, and steepling (sitting with hands raised

in front of the body with fi ngertips touching) indi-
cates a feeling of superiority.
3-1 Developing Interpersonal SkillsPRACTICAL
TIP
Ideally, the participants who are released from regular duties to
attend the JAD sessions
should be the very best people in that business unit. However,
without strong management
support, JAD sessions can fail because those selected to attend
the JAD session are people who
are less likely to be missed (i.e., the least competent people).
Th e facilitator should be someone who is an expert in JAD or
e-JAD techniques and,
ideally, someone who has experience with the business under
discussion. In many cases, the
JAD facilitator is a consultant external to the organization
because the organization might not
have a recurring need for JAD or e-JAD expertise. Developing
and maintaining this expertise
in-house can be expensive.
JAD sessions can run from as little as half a day to several
weeks, depending upon the size and
scope of the project. In our experience, most JAD sessions tend
to last fi ve to ten days, spread
over a three-week period. Most e-JAD sessions tend to last one

to four days in a one-week
period. JAD and e-JAD sessions usually go beyond collecting
information and move into anal-
ysis. For example, the users and the analysts collectively can
create analysis deliverables, such as
the functional models or the requirements defi nition.
JAD sessions usually are designed and structured using the
same principles as inter-
views. Most JAD sessions are designed to collect specifi c
information from users, and this
requires developing a set of questions before the meeting. One
diff erence between JAD
and interviewing is that all JAD sessions are structured—they
must be carefully planned.
In general, closed-ended questions are seldom used because
they do not spark the open
and frank discussion that is typical of JAD. In our experience, it
is better to proceed top
down in JAD sessions when gathering information. Typically
thirty minutes is allocated to
each separate agenda item, and frequent breaks are scheduled
throughout the day because
participants tire easily.
As with interviewing, it is important to prepare the analysts and
participants for a JAD
session. Because the sessions can go beyond the depth of a
typical interview and are usually
conducted off -site, participants may be more concerned about
how to prepare. It is impor-
tant that the participants understand what is expected of them. If
the goal of the JAD session,
for example, is to develop an understanding of the current
system, then participants can
bring procedure manuals and documents with them. If the goal

is to identify improvements
for a system, then before they come to the JAD session they can
think about how they would
improve the system.
Most JAD sessions follow a formal agenda, and most have
formal ground rules that defi ne appro-
priate behavior. Common ground rules include following the
schedule, respecting others’ opin-
ions, accepting disagreement, and ensuring that only one person
talks at a time.
Th e role of a JAD facilitator can be challenging. Many
participants come to a JAD session
with strong feelings about the system to be discussed.
Channeling these feelings so that the ses-
sion moves forward in a positive direction and getting
participants to recognize and accept—but
not necessarily agree on—opinions and situations diff erent
from their own requires signifi cant
expertise in systems analysis and design, JAD, and
interpersonal skills. Few systems analysts
attempt to facilitate JAD sessions without being trained in JAD
techniques, and most apprentice
with a skilled JAD facilitator before they attempt to lead their fi
rst session.
Th e JAD facilitator performs three key functions. First, he or
she ensures that the group
sticks to the agenda. Th e only reason to digress from the
agenda is when it becomes clear to
the facilitator, project leader, and project sponsor that the JAD
session has produced some
new information that is unexpected and requires the JAD
session (and perhaps the project)
to move in a new direction. When participants attempt to divert

the discussion away from the
4. Conducting
a JAD Session
2. Design a JAD
Session
3. Preparing for a
JAD Session
agenda, the facilitator must be fi rm but polite in leading
discussion back to the agenda and
getting the group back on track.
Second, the facilitator must help the group understand the
technical terms and jargon
that surround the system-development process and help the
participants understand the
specifi c analysis techniques used. Participants are experts in
their area, or their part of
the business, but they are not experts in systems analysis. Th e
facilitator must, therefore,
minimize the learning required and teach participants how to eff
ectively provide the right
information.
Th ird, the facilitator records the group’s input on a public
display area, which can be a
whiteboard, fl ip chart, or computer display. He or she
structures the information that the
group provides and helps the group recognize key issues and

important solutions. Th e facil-
itator must remain neutral at all times and simply help the group
through the process. Th e
moment the facilitator off ers an opinion on an issue, the group
will see him or her not as a
neutral party but rather as someone who could be attempting to
sway the group into some
predetermined solution.
However, this does not mean that the facilitator should not try
to help the group resolve
issues. For example, if two items appear to be the same to the
facilitator, the facilitator should
not say, “I think these may be similar.” Instead, the facilitator
should ask, “Are these similar?”
If the group decides they are, the facilitator can combine them
and move on. However, if
the group decides they are not similar (despite what the
facilitator believes), the facilitator
should accept the decision and move on. Th e group is always
right, and the facilitator has
no opinion.
As with interviews, a JAD post-session report is prepared and
circulated among session
attendees. Th e post-session report is essentially the same as the
interview report in Figure 3-6.
Because the JAD sessions are longer and provide more
information, it usually takes a week or
two aft er the JAD session before the report is complete.
Questionnaires
A questionnaire is a set of written questions used to obtain
information from individ-
uals. Questionnaires are oft en used when there is a large
number of people from whom

information and opinions are needed. In our experience,
questionnaires are a common
technique with systems intended for use outside the
organization (e.g., by customers or
vendors) or for systems with business users spread across many
geographic locations.
Most people automatically think of paper when they think of
questionnaires, but today
more questionnaires are being distributed in electronic form,
either via e-mail or on the
Web. Electronic distribution can save a signifi cant amount of
money as compared to dis-
tributing paper questionnaires. A good process to use when
using questionnaires follows
four steps.
As with interviews and JAD sessions, the fi rst step is to
identify the individuals to whom the
questionnaire will be sent. However, it is not usual to select
every person who could provide
useful information. Th e standard approach is to select a
sample, or subset, of people who
are representative of an entire group. Sampling guidelines are
discussed in most statistics
books, and most business schools include courses that cover the
topic, so we do not discuss it
here. Th e important point in selecting a sample, however, is to
realize that not everyone who
receives a questionnaire will actually complete it. On average,
only 30 to 50 percent of paper
and e-mail questionnaires are returned. Response rates for Web-
based questionnaires tend to
be signifi cantly lower (oft en only 5 to 30 percent).

1. Select Participants
5. Post-JAD Follow-up
Managing Problems in JAD Sessions
I have run more than a hundred JAD sessions and have
learned several standard “facilitator tricks.” Here are some
common problems and some ways to deal with them.
• Domination. The facilitator should ensure that no one
person dominates the group discussion. The only way
to deal with someone who dominates is head on. Dur-
ing a break, approach the person, thank him or her for
his or her insightful comments, and ask the person to
help you make sure that others also participate.
• Noncontributors. Drawing out people who have par-
ticipated very little is challenging because you want
to bring them into the conversation so that they will
contribute again. The best approach is to ask a direct
factual question that you are certain they can answer.
And it helps to ask the question in a long way to give
them time to think. For example, “Pat, I know you’ve
worked shipping orders a long time. You’ve probably
been in the shipping department longer than anyone
else. Could you help us understand exactly what hap-
pens when an order is received in shipping?”
• Side discussions. Sometimes participants engage in

side conversations and fail to pay attention to the
group. The easiest solution is simply to walk close
to the people and continue to facilitate right in front
of them. Few people will continue a side conversion
when you are two feet from them and the entire
group’s attention is on you and them.
• Agenda merry-go-round. The merry-go-round occurs
when a group member keeps returning to the same
issue every few minutes and won’t let go. One solu-
tion is to let the person have fi ve minutes to ramble
on about the issue while you carefully write down
every point on a fl ip chart or computer fi le. This fl ip
chart or fi le is then posted conspicuously on the
wall. When the person brings up the issue again, you
interrupt them, walk to the paper and ask them what
to add. If they mention something already on the list,
you quickly interrupt, point out that it is there, and
ask what other information to add. Don’t let them
repeat the same point, but write any new information.
• Violent agreement. Some of the worst disagreements
occur when participants really agree on the issues
but don’t realize that they agree because they are
using different terms. An example is arguing whether
a glass is half empty or half full; they agree on the
facts but can’t agree on the words. In this case, the
facilitator has to translate the terms into different
words and fi nd common ground so the parties rec-
ognize that they really agree.
• Unresolved confl ict. In some cases, participants
don’t agree and can’t understand how to determine
what alternatives are better. You can help by structur-
ing the issue. Ask for criteria by which the group will

identify a good alternative (e.g., “Suppose this idea
really did improve customer service. How would I
recognize the improved customer service?”). Then
once you have a list of criteria, ask the group to
assess the alternatives using them.
• True confl ict. Sometimes, despite every attempt, par-
ticipants just can’t agree on an issue. The solution is
to postpone the discussion and move on. Document
the issue as an open issue and list it prominently on
a fl ip chart. Have the group return to the issue hours
later. Often the issue will have resolved itself by then
and you haven’t wasted time on it. If the issue cannot
be resolved later, move it to the list of issues to be
decided by the project sponsor or some other more
senior member of management.
• Humor. Humor is one of the most powerful tools a
facilitator has and thus must be used judiciously. The
best JAD humor is always in context; never tell jokes
but take the opportunity to fi nd the humor in the
situation.
Alan Dennis
PRACTICAL
TIP
Because the information on a questionnaire cannot be
immediately clarifi ed for a confused
respondent, developing good questions is critical for
questionnaires. Questions on question-
naires must be very clearly written and leave little room for
misunderstanding, so closed-ended
questions tend to be most commonly used. Questions must

clearly enable the analyst to sep-
arate facts from opinions. Opinion questions oft en ask
respondents the extent to which they
agree or disagree (e.g., Are network problems common?),
whereas factual questions seek more
2. Designing a
Questionnaire
precise values (e.g., How oft en does a network problem occur:
once an hour, once a day, once
a week?). See Figure 3-7 for guidelines on questionnaire design.
Perhaps the most obvious issue—but one that is sometimes
overlooked—is to have a
clear understanding of how the information collected from the
questionnaire will be analyzed
and used. Th is issue must be addressed before the questionnaire
is distributed, because it is
too late aft erward.
Questions should be relatively consistent in style, so that the
respondent does not have to
read instructions for each question before answering it. It is
generally good practice to group
related questions together to make them simpler to answer.
Some experts suggest that ques-
tionnaires should start with questions important to respondents,
so that the questionnaire
immediately grabs their interest and induces them to answer it.
Perhaps the most important
step is to have several colleagues review the questionnaire and

then pretest it with a few people
drawn from the groups to whom it will be sent. It is surprising
how oft en seemingly simple
questions can be misunderstood.
Th e key issue in administering the questionnaire is getting
participants to complete the
questionnaire and send it back. Dozens of marketing research
books have been written about
ways to improve response rates. Commonly used techniques
include clearly explaining why
the questionnaire is being conducted and why the respondent
has been selected, stating a date
by which the questionnaire is to be returned, off ering an
inducement to complete the ques-
tionnaire (e.g., a free pen), and off ering to supply a summary
of the questionnaire responses.
Systems analysts have additional techniques to improve
response rates inside the organiza-
tion, such as personally handing out the questionnaire and
personally contacting those who
have not returned them aft er a week or two, as well as
requesting the respondents’ supervisors
to administer the questionnaires in a group meeting.
It is helpful to process the returned questionnaires and develop
a questionnaire report soon aft er
the questionnaire deadline. Th is ensures that the analysis
process proceeds in a timely fashion and
that respondents who requested copies of the results receive
them promptly.
Document Analysis
Project teams oft en use document analysis to understand the as-
is system. Under ideal cir-
cumstances, the project team that developed the existing system

will have produced docu-
mentation that was then updated by all subsequent projects. In
this case, the project team can
start by reviewing the documentation and examining the system
itself.
Unfortunately, many systems are not well documented because
project teams fail to
document their projects along the way, and when the projects
are over, there is no time to
go back and document. Th erefore, there might not be much
technical documentation about
the current systems available, or it might not contain updated
information about recent sys-
tem changes. However, many helpful documents do exist in an
organization: paper reports,
3. Administering
the Questionnaire
4. Questionnaire
Follow-up
• Begin with nonthreatening and interesting questions.
• Group items into logically coherent sections.
• Do not put important items at the very end of the
questionnaire.
• Do not crowd a page with too many items.
• Avoid abbreviations.
• Avoid biased or suggestive items or terms.
• Number questions to avoid confusion.
• Pretest the questionnaire to identify confusing questions.
• Provide anonymity to respondents.

FIGURE 3-7
Good Questionnaire
Design
memorandums, policy manuals, user-training manuals,
organization charts, forms, and, of
course, the user interface with the existing system.
But these documents tell only part of the story. Th ey represent
the formal system that the
organization uses. Quite oft en, the real, or informal, system
diff ers from the formal one, and these
diff erences, particularly large ones, give strong indications of
what needs to be changed. For
example, forms or reports that are never used should probably
be eliminated. Likewise, boxes or
questions on forms that are never fi lled in (or are used for
other purposes) should be rethought.
See Figure 3-8 for an example of how a document can be
interpreted.
Th e most powerful indication that the system needs to be
changed is when users
create their own forms or add additional information to existing
ones. Such changes clearly
demonstrate the need for improvements to existing systems. Th
us, it is useful to review both
blank and completed forms to identify these deviations.
Likewise, when users access multiple
reports to satisfy their information needs, it is a clear sign that
new information or new infor-
mation formats are needed.

Name: Buffy Pat Smith
Pet’s Name: Buffy Collie 7/6/99
Address: 100 Central Court. Apartment 10
Toronto, Ontario K7L 3N6
Phone Number: 555-3400
416-
Do you have insurance: yes
Insurance Company: Pet’s Mutual
Policy Number: KA-5493243
CENTRAL VETERINARY CLINIC
Patient Information Card
The staff had to add additional
information about the type of animal
and the animal’s date of birth. This
information should be added to the
new form in the to-be system.
The customer made a mistake.
This should be labeled
Owner’s Name to prevent
confusion.
The customer did not include
area code in the phone
number. This should be made

more clear.
FIGURE 3-8
Performing a
Document Analysis
Observation
Observation, the act of watching processes being performed, is
a powerful tool for gathering
information about the as-is system because it enables the
analyst to see the reality of a situa-
tion, rather than listening to others describe it in interviews or
JAD sessions. Several research
studies have shown that many managers really do not remember
how they work and how
they allocate their time. (Quick, how many hours did you spend
last week on each of your
courses?) Observation is a good way to check the validity of
information gathered from indi-
rect sources such as interviews and questionnaires.
In many ways, the analyst becomes an anthropologist as he or
she walks through the
organization and observes the business system as it functions.
Th e goal is to keep a low pro-
fi le, to not interrupt those working, and to not infl uence those
being observed. Nonetheless,
it is important to understand that what analysts observe may not
be the normal day-to-day
routine because people tend to be extremely careful in their

behavior when they are being
watched. Even though normal practice may be to break formal
organizational rules, the
observer is unlikely to see this. (Remember how you drove the
last time a police car followed
you?) Th us, what you see might not be what you get.
Observation is oft en used to supplement interview information.
Th e location of a person’s
offi ce and its furnishings give clues to the person’s power and
infl uence in the organization and
can be used to support or refute information given in an
interview. For example, an analyst
might become skeptical of someone who claims to use the
existing computer system exten-
sively if the computer is never turned on while the analyst
visits. In most cases, observation
supports the information that users provide in interviews. When
it does not, it is an important
signal that extra care must be taken in analyzing the business
system.
Selecting the Appropriate Techniques
Each of the requirements-gathering techniques discussed earlier
has strengths and weak-
nesses. No one technique is always better than the others, and in
practice most projects use a
combination of techniques. Th us, it is important to understand
the strengths and weaknesses
of each technique and when to use each (see Figure 3-9). One
issue not discussed is that of the
analysts’ experience. In general, document analysis and
observation require the least amount
of training, whereas JAD sessions are the most challenging.
Type of Information Th e fi rst characteristic is the type of

information. Some techniques are
more suited for use at diff erent stages of the analysis process,
whether understanding the as-is
system, identifying improvements, or developing the to-be
system. Interviews and JAD are
commonly used in all three stages. In contrast, document
analysis and observation usually are
most helpful for understanding the as-is, although occasionally
they provide information about
FIGURE 3-9 Table of Requirements-Gathering Techniques
Type of information As-is, improvements, As-is,
improvements, As-is, improvements As-is As-is
to-be to-be
Depth of information High High Medium Low Low
Breadth of information Low Medium High High Low
Integration of information Low High Low Low Low
User involvement Medium High Low Low Low
Cost Medium Low to Medium Low Low Low to Medium
Joint Application Document
Interviews Design Questionnaires Analysis Observation
current problems that need to be improved. Questionnaires are

oft en used to gather informa-
tion about the as-is system as well as general information about
improvements.
Depth of Information Th e depth of information refers to how
rich and detailed the infor-
mation is that the technique usually produces and the extent to
which the technique is useful
for obtaining not only facts and opinions but also an
understanding of why those facts and
opinions exist. Interviews and JAD sessions are very useful for
providing a good depth of rich
and detailed information and helping the analyst to understand
the reasons behind them. At
the other extreme, document analysis and observation are useful
for obtaining facts, but little
beyond that. Questionnaires can provide a medium depth of
information, soliciting both facts
and opinions with little understanding of why they exist.
Breadth of Information Breadth of information refers to the
range of information and infor-
mation sources that can be easily collected using the chosen
technique. Questionnaires and
document analysis are both easily capable of soliciting a wide
range of information from a large
number of information sources. In contrast, interviews and
observation require the analyst to
visit each information source individually and, therefore, take
more time. JAD sessions are in
the middle because many information sources are brought
together at the same time.
Integration of Information One of the most challenging aspects
of requirements gather-
ing is integrating the information from diff erent sources.

Simply put, diff erent people can
provide confl icting information. Combining this information
and attempting to resolve
diff erences in opinions or facts is usually very time consuming
because it means contacting
each information source in turn, explaining the discrepancy, and
attempting to refi ne the
information. In many cases, the individual wrongly perceives
that the analyst is challenging
his or her information, when in fact it is another user in the
organization who is doing so.
Th is can make the user defensive and make it hard to resolve
the diff erences.
All techniques suff er integration problems to some degree, but
JAD sessions are designed
to improve integration because all information is integrated
when it is collected, not aft er-
ward. If two users provide confl icting information, the confl ict
becomes immediately obvi-
ous, as does the source of the confl ict. Th e immediate
integration of information is the single
most important benefi t of JAD that distinguishes it from other
techniques, and this is why
most organizations use JAD for important projects.
User Involvement User involvement refers to the amount of
time and energy the intended
users of the new system must devote to the analysis process. It
is generally agreed that as users
become more involved in the analysis process, the chance of
success increases. However, user
involvement can have a signifi cant cost, and not all users are
willing to contribute valuable
time and energy. Questionnaires, document analysis, and
observation place the least burden

on users, whereas JAD sessions require the greatest eff ort.
Cost Cost is always an important consideration. In general,
questionnaires, document
analysis, and observation are low-cost techniques (although
observation can be quite time
consuming). Th e low cost does not imply that they are more or
less eff ective than the other
techniques. Interviews and JAD sessions generally have
moderate costs. In general, JAD ses-
sions are much more expensive initially, because they require
many users to be absent from
their offi ces for signifi cant periods of time, and they oft en
involve highly paid consultants.
However, JAD sessions signifi cantly reduce the time spent in
information integration and
thus can cost less in the long term.
Combining Techniques In practice, requirements gathering
combines a series of diff erent tech-
niques. Most analysts start by using interviews with senior
manager(s) to gain an understanding
of the project and the big-picture issues. From these interviews,
it becomes clear whether large
or small changes are anticipated. Th ese interviews are oft en
followed with analysis of documents
12 See B. Henderson-Sellers, A. Simons, and H. Younessi, Th e
OPEN Toolbox of Techniques (Harlow, England:
Addison-Wesley, 1998).

13 For more information on concept mapping, see J. D. Novak
and D. B. Gowin, Learning How to Learn (Cambridge,
UK: Cambridge University Press, 1984); J. D. Novak, Learning,
Creating, and Using Knowledge: Concept MapsTM as
Facilitative Tools in Schools and Corporations (Mahwah, NJ:
Lawrence Erlbaum Associates, Publishers, 1998). Also, a
free concept mapping tool is available from the Institute of
Human and Machine Cognition at cmap.ihmc.us.
and policies to gain some understanding of the as-is system.
Usually interviews come next to
gather the rest of the information needed for the as-is picture.
In our experience, identifying improvements is most commonly
done using JAD sessions
because the JAD session enables the users and key stakeholders
to work together through an
analysis technique and come to a shared understanding of the
possibilities for the to-be sys-
tem. Occasionally, these JAD sessions are followed by
questionnaires sent to a much wider set
of users or potential users to see whether the opinions of those
who participated in the JAD
sessions are widely shared.
Developing the concept for the to-be system is oft en done
through interviews with senior
managers, followed by JAD sessions with users of all levels to
make sure that the key needs of
the new system are well understood.
ALTERNATIVE REQUIREMENTS DOCUMENTATION
TECHNIQUES
Some other very useful requirements-gathering and

documentation techniques include
throwaway prototyping, use cases, role-playing CRC cards with
use-case-based scenarios,
concept mapping, and recording user stories on story cards and
task lists. Th rowaway pro-
totyping was described in Chapter 1. In essence, throwaway
prototypes are created to better
understand some aspect of the new system. In many cases, they
are used to test out some
technical aspect of a nonfunctional requirement, such as
connecting a client workstation to a
server. If you have never done this before, it will be a lot easier
to develop a very small example
system to test out the necessary design of the connection from
the client workstation to the
server instead of trying to do it the fi rst time with the full-
blown system. Th rowaway proto-
typing is very useful in designing user interfaces (see Chapter
10).
Use cases, as described in Chapter 1, are the fundamental
approach that the Unifi ed Process
and Unifi ed Modeling Language (UML) use to document and
gather functional requirements.
We describe them in Chapter 4. Role-playing CRC cards with
use-case-based scenarios are
very useful when creating functional (see Chapter 4), structural
(see Chapter 5), and behavioral
(see Chapter 6) models. We describe this approach in Chapter 5.
Th e remainder of this section
describes the use of concept mapping recording user stories on
story cards and task lists.
Concept Maps
Concept maps represent meaningful relationships between
concepts. Th ey are useful for

focusing individuals on the small number of key ideas on which
they should concentrate.
A concept map is essentially a node-and-arc representation,
where the nodes represent the
individual requirements and the arcs represent the relationships
among the requirements.
Each arc is labeled with a relationship name. Concept maps also
have been recommended as
a possible technique to support modeling requirements for
object-oriented systems develop-
ment and knowledge-management systems.12 Concept mapping
is an educational psychology
technique that has been used in schools, corporations, and
health care agencies to facilitate
learning, understanding, and knowledge creation.13 Th e
advantage of the concept-mapping
approach to representing requirements over the typical textual
approach (see Figure 3-1) is
that a concept map is not limited to a hierarchical
representation. Concept maps allow the rela-
tionships among the functional and nonfunctional requirements
to be explicitly represented.
Figure 3-10 shows a concept map that portrays the information
contained in the requirements
R
eq
ui
re
m

en
ts
C
ul
tu
ra
l a
nd
Po
lit
ic
al
R
eq
ui
re
m
en
ts
N
on
fu
nc

ti
on
al
R
eq
ui
re
m
en
ts
Se
cu
ri
ty
R
eq
ui
re
m
en
ts
O
pe
ra

ti
on
al
R
eq
ui
re
m
en
ts
Pe
rf
or
m
an
ce
R
eq
ui
re
m
en
ts

B
ac
ku
p
Sc
he
du
le
D
ai
ly
Su
pp
or
t W
ir
el
es
s
Pr
in
ti
ng
St

or
e
N
ew
A
pp
oi
nt
m
en
t
in
2
S
ec
on
ds
o
r
Le
ss
R
et
ri

ev
e
D
ai
ly
A
pp
oi
nt
m
en
t
Sc
he
du
le
in
2
Se
co
nd
s
or
L

es
s
O
pe
ra
te
in
W
in
do
w
s
En
vi
ro
nm
en
t
M
ak
e
A
pp
oi

nt
m
en
t
C
an
ce
l A
pp
oi
nt
m
en
t P
ri
nt
S
ch
ed
ul
e
U
pd

at
e
Sc
he
du
le
C
he
ck
S
ch
ed
ul
e
C
ha
ng
e
A
pp
oi
nt
m
en

t
M
an
ag
e
A
pp
oi
nt
m
en
ts
Pr
od
uc
e
Sc
he
du
le
Fu
nc
ti
on

al
R
eq
ui
re
m
en
ts
R
ec
or
d
D
oc
to
r
A
va
ila
bi
lit
y
O
nl

y
M
an
ag
er
s
C
an
Pr
od
uc
e
Sc
he
du
le
O
nl
y
D
oc
to
rs
S

et
A
va
ila
bi
lit
y
im
pa
ct
s
im
pa
ct
s
im
pa
ct
s
im
pa
ct
s

im
pa
ct
s
im
pa
ct
s
in
cl
ud
e
in
cl
ud
e
in
cl
ud
e
in
cl
ud
e

in
cl
ud
e
in
cl
ud
e
in
cl
ud
e
in
cl
ud
e
in
cl
ud
e
FI
G
U
R

E
3
-1
0
Sa
m
p
le
R
eq
u
ir
em
en
ts
C
o
n
ce
p
t
M
ap

111
defi nition shown in Figure 3-1. By using a concept map to
represent the requirements instead
of the textual approach, the relationship between the functional
and nonfunctional require-
ments can be made explicit. For example, the two security
requirements Only Doctors Set
Availability and Only Managers Can Produce Schedule are
explicitly linked to the Record
Doctor Availability and Produce Schedule functional
requirements, respectively. Th is is very
diffi cult to represent in a text-only version of the requirements
defi nition. Also, by having
the user and analyst focus on the graphical layout of the map,
additional requirements can
be discovered. One obvious issue with this approach is that if
the number of requirements
becomes many and the relationships between them become
complex, then the number of
nodes and arcs will become so intertwined that the advantage of
being able to explicitly see the
relationships will be lost. However, by combining both text and
concept-map representations,
it is possible to leverage the strength of both textual and
graphical representations to more
completely represent the requirements.
User Stories
User stories, along with their associated story cards and task
lists, are associated with the
agile development approaches. User stories have been shown to

be very useful in gathering
requirements in a nonthreatening manner that respects the user’s
point of view. Th ey are
typically captured using story cards (index cards) and are
recorded on a task list (or from a
Scrum perspective, on the product backlog). Both story cards
and task lists are considered
to be lightweight approaches to documenting and gathering
requirements.14 Stories capture
both functional and nonfunctional requirements. For example,
with regard to the doctor’s
offi ce appointment example, a functional requirement-based
story could be:
As a secretary, I want to be able to schedule appointments for
our patients so that we can
meet our patients’ needs.
While an operational nonfunctional requirement-based story
could be:
As a secretary, I want to be able to print the daily schedule
using wireless technology so
that all printing can be performed using a shared printer without
having to deal with
printer cables connecting all of the computers to the printer.
Once the story is written down, it is discussed to determine the
amount of eff ort it will take
to implement it. During the discussion, a task list is created for
the story. If the story is
deemed to be too large—e.g., there are too many tasks on the
task list—the story is split up
into multiple stories each being recorded on its own story card
and the tasks are allocated
across the new stories. In many shops, once a set of tasks has

been identifi ed with a story,
the story and its tasks are taped on a wall together so that all
members of the development
team can see the requirements. Th e story can be prioritized by
importance by placing a rat-
ing on the card. Th e story can also be evaluated for the level of
risk associated with it. Th e
importance level and amount of risk associated with the story
can be used to help choose
which requirements to implement fi rst. Th e advantage of using
story cards and task lists
to document requirements is that they are very low tech, high
touch, easily updatable, and
very portable.
14 For more information on story cards and task lists see M.
Cohn, User Stories Applied: For Agile Soft ware
Development (Boston, MA: Addison-Wesley, 2004); B. Rinzler,
Telling Stories: A Short Path to Writing Better
Soft ware Requirements (Indianapolis, IN: Wiley, 2009); M.
Lippert, S. Roock, H. Wolf, eXtreme Programming
in Action: Practical Experiences from Real World Projects
(Chichester, England: Wiley & Sons, Ltd., 2002);
C. Larman, Agile & Iterative Development: A Manager’s Guide
(Boston, MA: Addison-Wesley, 2004).
1. Table of Contents
2. Executive Summary

A summary of all the essential information in the proposal
so that a busy executive can read it
quickly and decide what parts of the proposal to read in more
depth.
3. System Request
The revised system request form (see Chapter 2).
4. Workplan
The original workplan, revised after having completed
analysis (see Chapter 2).
5. Feasibility Analysis
A revised feasibility analysis, using the information from
analysis (see Chapter 2).
6. Requirements Defi nition
A list of the functional and nonfunctional business
requirements for the system (this chapter).
7. Functional Model
An activity diagram, a set of use-case descriptions, and a
use-case diagram that illustrate the basic
processes or external functionality that the system needs to
support (see Chapter 4).
8. Structural Models
A set of CRC cards, class diagram, and object diagrams that
describe the structural aspects of the
to-be system (see Chapter 5). This may also include structural

models of the current as-is system that
will be replaced.
9. Behavioral Models
A set of sequence diagrams, communication diagrams,
behavioral-state machines, and a CRUDE
matrix that describe the internal behavior of the to-be system
(see Chapter 6). This may include
behavioral models of the as-is system that will be replaced.
10. Appendices
These contain additional material relevant to the proposal,
often used to support the recommended
system. This might include results of a questionnaire survey or
interviews, industry reports and
statistics, and so on.
FIGURE 3-11
System Proposal
Template
15 Depending on the client, much more detailed specifi cations
may be required; for example the Department
of Defense, NASA, IEEE/ANSI, and the Naval Research
Laboratory all have very specifi c formats that must be
followed. For more information on these more detailed specifi
cations, see A. M Davis, Soft ware Requirements,
Revision (Upper Saddle River, NJ: Prentice Hall, 1993); G.
Kotonya and I. Sommerville, Requirements Engineering
(Chichester, England: Wiley, 1998); R. H. Th ayer and M.
Dorfman (eds.), Soft ware Requirements Engineering, 2nd Ed.
(Los Alamitos, CA: IEEE Computer Society Press, 1997).
THE SYSTEM PROPOSAL

A system proposal brings together into a single comprehensive
document the material created
during planning and analysis. Th e system proposal typically
includes an executive summary,
the system request, the workplan, the feasibility analysis, the
requirements defi nition, and the
evolving models that describe the new system. Th e evolving
models include functional models
(see Chapter 4), structural models (see Chapter 5), and
behavioral models (see Chapter 6).15 Th e
executive summary provides all critical information in a very
concise form. It can be thought
of as a summary of the complete proposal. Its purpose is to
allow a busy executive to quickly
read through it and determine which parts of the proposal he or
she needs to go through more
thoroughly. Th e executive summary is typically no more than a
single page long. Figure 3-11
provides a template for a system proposal and references to
where the other sections of the
proposal are described.
The System Proposal 113
CHAPTER REVIEW
Aft er reading and studying this chapter, you should be able to:
Create a requirements defi nition.
Diff erentiate between a functional and a nonfunctional
requirement.
Discuss the problem analysis requirements strategy.
Discuss the root cause analysis requirements strategy.

Discuss the duration analysis requirements strategy.
Discuss the activity-based costing analysis requirements
strategy.
Discuss the informal benchmarking analysis requirements
strategy.
Discuss the outcome analysis requirements strategy.
Discuss the technology analysis requirements strategy.
Discuss the activity elimination requirements strategy.
Discuss how to use interviews to gather requirements.
Discuss how to use joint application development to gather
requirements.
Discuss how to use questionnaires to gather requirements.
Discuss how to use document analysis to gather requirements.
Discuss how to use observation to gather requirements.
Describe how to use concept maps to document requirements.
Describe how to use story cards and task lists to document
requirements.
Describe the purpose and contents of system proposal.
KEY TERMS
Activity elimination
Activity-based costing
Analysis
As-is system
Benchmarking
Bottom-up interview
Breadth of analysis
Business requirements
Closed-ended question
Concept mapping
Concept maps
Critical thinking skills
Document analysis

Duration analysis
Electronic JAD (e-JAD)
Facilitator
Formal system
Functional requirements
Ground rules
Informal benchmarking
APPLYING THE CONCEPTS AT PATTERSON
SUPERSTORE
Chapter 3 introduced requirements determination for object-
oriented systems develop-
ment projects. Determining the system’s requirements is the
most important activity in
the systems development process. A requirement is WHAT the
system must do or WHAT
characteristics it must have. If the requirements are not fully or
correctly defi ned, the sys-
tem developed is unlikely to meet the needs of the user. In other
words, if the requirements
are wrong, the system will be wrong.
In this chapter’s installment of the Patterson Superstore case,
we see the require-
ments analysis and requirement-gathering techniques that the
analysts used to determine
requirements for Version 1 of the Integrated Health Clinic
Delivery System. We also see the
functional and nonfunctional requirements that were developed
and an initial draft of the
developing systems proposal for the project. Th is systems
proposal will be fi nalized aft er
the functional (Chapter 4), structural (Chapter 5), and

behavioral (Chapter 6) modeling of
the system has been completed.
You can fi nd the rest of the case at:
www.wiley.com/go/dennis/casestudy
Informal system
Interpersonal skills
Interview
Interview notes
Interview report
Interview schedule
JAD (joint application
development)
Nonfunctional requirements
Observation
Open-ended question
Outcome analysis
Parallelization
Process Integration
Post-session report
Potential business value
Probing question
Problem analysis
Project cost
Questionnaire
Requirement
Requirements defi nition
Requirements

determination
Risk
Root cause
Root cause analysis
Sample
Scribe
Story cards
Structured interview
System proposal
System requirements
Task lists, 144
Technology analysis
To-be system
Top-down interview
Unstructured interview
User stories
Walkthrough
QUESTIONS
1. What are the key deliverables that are created during
analysis? What is the fi nal deliverable from analysis,
and what does it contain?
2. What is the diff erence between an as-is system and a
to-be system?
3. What is the purpose of the requirements defi nition?
4. What are the three basic steps of the analysis process?
Which step is sometimes skipped or done in a cursory
fashion? Why?
5. Compare and contrast problem analysis and root

cause analysis. Under what conditions would you use
problem analysis? Under what conditions would you
use root cause analysis?
6. Compare and contrast duration analysis and activity-
based costing.
7. Describe the fi ve major steps in conducting interviews.
8. Explain the diff erences among a closed-ended ques-
tion, an open-ended question, and a probing question.
When would you use each?
9. Explain the diff erences between unstructured inter-
views and structured interviews. When would you use
each approach?
10. Explain the diff erence between a top-down and
bottom-up interview approach. When would you use
each approach?
11. How are participants selected for interviews and JAD
sessions?
12. How can you diff erentiate between facts and opinions?
Why can both be useful?
13. Describe the fi ve major steps in conducting JAD
sessions.
14. How does a JAD facilitator diff er from a scribe?
15. What are the three primary things that a facilitator
does in conducting the JAD session?
16. What is e-JAD, and why might a company be inter-

ested in using it?
17. How does designing questions for questionnaires diff er
from designing questions for interviews or JAD sessions?
18. What are typical response rates for questionnaires,
and how can you improve them?
19. What is document analysis?
20. How does the formal system diff er from the informal
system? How does document analysis help you under-
stand both?
21. What are the key aspects of using observation in the
information-gathering process?
22. Explain factors that can be used to select information-
gathering techniques.
23. What is the primary advantage that concept maps
have over traditional textual requirements documents
techniques?
24. What are some of the advantages of using story cards
and task lists as a requirements-gathering and docu-
mentation technique?
25. What information is typically included in a system
proposal?
26. What is the purpose of the executive summary of the
system proposal?
EXERCISES
A. Review the Amazon.com website. Develop the

requirements defi nition for the site. Create a list
of functional business requirements that the system
meets. What diff erent kinds of nonfunctional business
requirements does the system meet? Provide exam-
ples for each kind.
B. Suppose you are going to build a new system that auto-
mates or improves the interview process for the career
Exercises 115
services department of your school. Develop a require-
ments defi nition for the new system. Include both
functional and nonfunctional system requirements.
Pretend you will release the system in three diff erent
versions. Prioritize the requirements accordingly.
C. Describe in very general terms the as-is business
process for registering for classes at your university.
Collaborate with another student in your class, and
evaluate the process using problem analysis and root
cause analysis. Based on your work, list some improve-
ments that you have identifi ed.
D. Describe in very general terms the as-is business pro-
cess for applying for admission at your university.
evaluate the process using informal benchmarking.
Based on your work, list some improvements that you
have identifi ed.

E. Describe in very general terms the as-is business
process for registering for classes at your university.
evaluate the process using activity elimination. Based
on your work, list some improvements that you have
identifi ed.
F. Suppose your university is having a dramatic increase
in enrollment and is having diffi culty fi nding enough
seats in courses for students. Perform a technology
analysis to identify new ways to help students com-
plete their studies and graduate.
G. Suppose you are the analyst charged with developing a
new system for the university bookstore so that students
can order books online and have them delivered to their
dorms or off -campus housing. What requirements-
gathering techniques will you use? Describe in detail
how you would apply the techniques.
H. Suppose you are the analyst charged with developing
a new system to help senior managers make bet-
ter strategic decisions. What requirements-gathering
techniques will you use? Describe in detail how you
would apply the techniques.
I. Find a partner and interview each other about what
tasks each did in the last job you held (full-time,
part-time, past, or current). If you haven’t worked
before, then assume your job is being a student.
Before you do this, develop a brief interview plan.
Aft er your partner interviews you, identify the type
of interview, interview approach, and types of ques-
tions used.
J. Find a group of students and run a sixty-minute

JAD session on improving alumni relations at your
university. Develop a brief JAD plan, select two tech-
niques that will help identify improvements, and then
develop an agenda. Conduct the session using the
agenda, and write your post-session report.
K. Find a questionnaire on the Web that has been created
to capture customer information. Describe the pur-
pose of the survey, the way questions are worded, and
how the questions have been organized. How can it be
improved? How will the responses be analyzed?
L. Develop a questionnaire that will help gather infor-
mation regarding processes at a popular restaurant
or the college cafeteria (e.g., ordering, customer ser-
vice). Give the questionnaire to ten to fi ft een students,
analyze the responses, and write a brief report that
describes the results.
M. Contact the career services department at your uni-
versity, and fi nd all the pertinent documents designed
to help students fi nd permanent and/or part-time
jobs. Analyze the documents and write a brief report.
MINICASES
1. Th e State Firefi ghter’s Association has a membership
of 15,000. Th e purpose of the organization is to pro-
vide some fi nancial support to the families of deceased
member fi refi ghters and to organize a conference
each year bringing together fi refi ghters from all over
the state. Members are billed dues and calls annually.
Calls are additional funds required to take care of
payments made to the families of deceased members.
Th e bookkeeping work for the association is handled
by the elected treasurer, Bob Smith, although it is

widely known that his wife, Laura, does all the work.
Bob runs unopposed each year at the election, because
no one wants to take over the tedious and time-
consuming job of tracking memberships. Bob is paid
a stipend of $8,000 per year, but his wife spends well
over twenty hours per week on the job. Th e organiza-
tion, however, is not happy with their performance.
A computer system is used to track the billing and
receipt of funds. Th is system was developed in 1984
by a computer science student and his father. Th e
system is a DOS-based system written using dBase 3.
Th e most immediate problem facing the treasurer and
his wife is the fact that the soft ware package no longer
exists, and there is no one around who knows how to
maintain the system. One query, in particular, takes
seventeen hours to run. Over the years, they have just
avoided running this query, although the information
in it would be quite useful. Questions from mem-
bers concerning their statements cannot easily be
answered. Usually Bob or Laura just jots down the
inquiry and returns a call with the answer. Sometimes
it takes three to fi ve hours to fi nd the information
needed to answer the question. Oft en, they have to
perform calculations manually because the system
was not programmed to handle certain types of que-
ries. When member information is entered into the
system, each fi eld is presented one at a time, which

makes it very diffi cult to return to a fi eld and correct
a value that was entered. Sometimes a new member is
entered but disappears from the records. Th e report
of membership used in the conference materials does
not alphabetize members by city. Only cities are listed
in the correct order.
What requirements analysis strategy or strategies
would you recommend for this situation? Explain
your answer.
2. Brian Callahan, IS project manager, is just about ready
to depart for an urgent meeting called by Joe Campbell,
manager of manufacturing operations. A major project
sponsored by Joe recently cleared the approval hurdle,
and Brian helped bring the project through project
initiation. Now that the approval committee has given
the go-ahead, Brian has been working on the project’s
analysis plan.
One evening, while playing golf with a friend who
works in the manufacturing operations department,
Brian learned that Joe wants to push the project’s time
frame up from Brian’s original estimate of thirteen
months. Brian’s friend overheard Joe say, “I can’t see
why that IS project team needs to spend all that time
analyzing things. Th ey’ve got two weeks scheduled
just to look at the existing system! Th at seems like a
real waste. I want that team to get going on building
my system.”
Because Brian has a little inside knowledge about
Joe’s agenda for this meeting, he has been considering
how to handle Joe. What do you suggest Brian tell Joe?
3. Barry has recently been assigned to a project team that

will be developing a new retail store management sys-
tem for a chain of submarine sandwich shops. Barry
has several years of experience in programming, but
he has not done much analysis in his career. He was a
little nervous about the new work he would be doing,
but he was confi dent he could handle any assignment
he was given.
One of Barry’s fi rst assignments was to visit one
of the submarine sandwich shops and prepare an
observation report on how the store operates. Barry
planned to arrive at the store around noon, but he
chose a store in an area of town he was unfamiliar
with, and due to traffi c delays and diffi culty in fi nd-
ing the store, he did not arrive until 1:30. Th e store
manager was not expecting him and refused to let a
stranger behind the counter until Barry had her contact
the project sponsor (the director of store management)
at company headquarters to verify who he was and
what his purpose was.
Aft er fi nally securing permission to observe, Barry
stationed himself prominently in the work area
behind the counter so that he could see everything.
Th e staff had to maneuver around him as they went
about their tasks, but there were only minor occa-
sional collisions. Barry noticed that the store staff
seemed to be going about their work very slowly and
deliberately, but he supposed that was because the
store wasn’t very busy. At fi rst, Barry questioned each
worker about what he or she was doing, but the store
manager eventually asked him not to interrupt their
work so much—he was interfering with their service
to the customers.

By 3:30, Barry was a little bored. He decided to leave,
fi guring he could get back to the offi ce and prepare
his report before 5:00 that day. He was sure his team
leader would be pleased with his quick completion
of his assignment. As he drove, he refl ected, “Th ere
really won’t be much to say in this report. All they
do is take the order, make the sandwich, collect the
payment, and hand over the order. It’s really simple!”
Barry’s confi dence in his analytical skills soared as he
anticipated his team leader’s praise.
Back at the store, the store manager shook her
head, commenting to her staff , “He comes here at the
slowest time of day on the slowest day of the week. He
never even looked at all the work I was doing in the
back room while he was here—summarizing yester-
day’s sales, checking inventory on hand, making up
resupply orders for the weekend . . . plus he never even
considered our store-opening and -closing procedures.
I hate to think that the new store management system
is going to be built by someone like that. I’d better
contact Chuck [the director of store management]
and let him know what went on here today.”
Minicases 117
Evaluate Barry’s conduct of the observation
assignment.
4. Anne has been given the task of conducting a survey

of sales clerks who will be using a new order-entry sys-
tem being developed for a household products catalog
company. Th e goal of the survey is to identify the clerks’
opinions on the strengths and weaknesses of the current
system. Th ere are about 50 clerks who work in three
diff erent cities, so a survey seemed like an ideal way of
gathering the needed information from the clerks.
Anne developed the questionnaire carefully and
pretested it on several sales supervisors who were
available at corporate headquarters. Aft er revising it
based on their suggestions, she sent a paper version
of the questionnaire to each clerk, asking that it be
returned within one week. Aft er one week, she had
only three completed questionnaires returned. Aft er
another week, Anne received just two more completed
questionnaires. Feeling somewhat desperate, Anne
then sent out an e-mail version of the questionnaire,
again to all the clerks, asking them to respond to
the questionnaire by e-mail as soon as possible. She
received two e-mail questionnaires and three mes-
sages from clerks who had completed the paper ver-
sion expressing annoyance at being bothered with the
same questionnaire a second time. At this point, Anne
has just a 14 percent response rate, which she is sure
will not please her team leader. What suggestions do
you have that could have improved Anne’s response
rate to the questionnaire?
Scenario for Assignments 1-5
For Assignments 1-5, you are the new budgeting and finance

administrator for your local government agency. Your first
responsibility is to become familiar with the agency, the budget,
programs, and capital projects. As the administrator, you will be
responsible for analyzing, examining, proposing, and preparing
the agency’s budget for the next five (5) years.
Note: Students cannot use New York City as a selected local
government
Assignment 1:The Operating Budget
Due Week 4 and worth 150 points
Write a four to five (4-5) page paper, titled Part I: The
Operating Budget for the (Selected Agency) in which you
separate the content into sections:
1. Provide background information about the agency, mission,
goals, objectives, departments, and strategic plan. (Title this
section Introduction.)
2. Describe the budget of the agency by addressing the
following items: (Title this section Budget Overview.)
a. Financial Summary, including Revenue and Expenditures
b. Department Budgets
c. Funding
d. Capital Projects
e. Debt Administration
3. Perform a Cost Analysis. (Title this section Cost Analysis.)
The costs should include the following:
3. Fixed Costs
3. Step-fixed Costs
3. Variable Costs
1. Identify and explain one to two (1-2) challenges you will
have in managing the budget. (Title this section Budget
Challenges.)
1. Recommend two to three (2-3) strategies the agency should
review regarding new initiatives and budget cuts over the next
five (5) years. (Title this section Budget Recommendations.)

1. Include the agency’s most recent budget or financial plan.
1. Provide the agency’s Website name, URL, and any other
sources used to support the assignment’s criteria.
Your assignment must follow these formatting requirements:
· Be typed, double spaced, using Times New Roman font (size
12), with one-inch margins on all sides; citations and references
must follow APA. Check with your professor for any additional
instructions.
· Include a cover page containing the title of the assignment, the
student’s name, the professor’s name, the course title, and the
date. The cover page and the reference page are not included in
the required assignment page length.
The specific course learning outcomes associated with this
assignment are:
· Analyze the basic skills and tools needed for budgeting for
public sector agencies and / or departments.
· Recommend appropriate policy actions based on the
evaluation.
· Evaluate a budgeting system at any governmental level.
· Analyze the scope and sequence of budgeting in terms of
sources of revenues, purpose of government expenditures,
budget cycles, budget preparation, and debt administration.
· Examine the process and components of preparing a viable
operating budget.
· Prepare a preliminary budgeting system for presentation
before Congress, state / local government, or other organization.
· Use technology and information resources to research issues in
public budgeting and finance.
· Write clearly and concisely about public budgeting and
finance using proper writing mechanics.
Click here to view the grading rubric for this assignment.
Grading for this assignment will be based on answer quality,
logic/organization of the paper, and language and writing skills,

using the following rubric.
Points: 150
Assignment 1:The Operating Budget
Criteria
Unacceptable
Below 70% F
Fair
70-79% C
Proficient
80-89% B
Exemplary
90-100% A
1. Provide background information about the agency, mission,
goals, objectives, departments, and strategic plan. (Title this
section Introduction.)
Weight: 15%
Did not submit or incompletely provided background
information about the agency, mission, goals, objectives,
departments, and strategic plan.
Partially provided background information about the agency,
mission, goals, objectives, departments, and strategic plan.
Satisfactorily provided background information about the
agency, mission, goals, objectives, departments, and strategic
plan.
Thoroughly provided background information about the agency,
mission, goals, objectives, departments, and strategic plan.
2. Describe the budget of the agency by addressing the
following items: (a) Financial Summary, including Revenue and
Expenditures, (b) Department Budgets, (c) Funding, (d) Capital
Projects, and (e) Debt Administration. (Title this section Budget
Overview.)
Weight: 15%
Did not submit or incompletely described the budget of the
agency by addressing the following items: (a) Financial
Summary, including Revenue and Expenditures, (b) Department
Budgets, (c) Funding, (d) Capital Projects, and (e) Debt

Administration.
Partially described the budget of the agency by addressing the
following items: (a) Financial Summary, including Revenue and
Expenditures, (b) Department Budgets, (c) Funding, (d) Capital
Projects, and (e) Debt Administration.
Satisfactorily described the budget of the agency by addressing
the following items: (a) Financial Summary, including Revenue
and Expenditures, (b) Department Budgets, (c) Funding, (d)
Capital Projects, and (e) Debt Administration.
Thoroughly described the budget of the agency by addressing
the following items: (a) Financial Summary, including Revenue
and Expenditures, (b) Department Budgets, (c) Funding, (d)
Capital Projects, and (e) Debt Administration.
3. Perform a Cost Analysis. The costs should include the
following: (a) Fixed Costs, (b) Step-fixed Costs, and (c)
Variable Costs. (Title this section Cost Analysis.)
Weight: 15%
Did not submit or incompletely performed a Cost Analysis. The
costs should include the following: (a) Fixed Costs, (b) Step-
fixed Costs, and (c) Variable Costs.
Partially performed a Cost Analysis. The costs should include
the following: (a) Fixed Costs, (b) Step-fixed Costs, and (c)
Variable Costs.
Satisfactorily performed a Cost Analysis. The costs should
include the following: (a) Fixed Costs, (b) Step-fixed Costs, and
(c) Variable Costs.
Thoroughly performed a Cost Analysis. The costs should
include the following: (a) Fixed Costs, (b) Step-fixed Costs, and
(c) Variable Costs.
4. Identify and explain one to two (1-2) challenges you will
have in managing the budget. (Title this section Budget
Challenges).
Weight: 15%
Did not submit or incompletely identified and explained one to
two (1-2) challenges you will have in managing the budget.
Partially identified and explained one to two (1-2) challenges

you will have in managing the budget.
Satisfactorily identified and explained one to two (1-2)
challenges you will have in managing the budget.
Thoroughly identified and explained one to two (1-2) challenges
you will have in managing the budget.
5. Recommend two to three (2-3) strategies the agency should
review regarding new initiatives and budget cuts over the next
five (5) years. (Title this section Budget Recommendations.)
Weight: 15%
Did not submit or incompletely recommended two to three (2-3)
strategies the agency should review regarding new initiatives
and budget cuts over the next five (5) years.
Partially recommended two to three (2-3) strategies the agency
should review regarding new initiatives and budget cuts over
the next five (5) years.
Satisfactorily recommended two to three (2-3) strategies the
agency should review regarding new initiatives and budget cuts
over the next five (5) years.
Thoroughly recommended two to three (2-3) strategies the
agency should review regarding new initiatives and budget cuts
over the next five (5) years.
6. Include the agency’s most recent budget or financial plan.
Weight: 10%
Did not submit or incompletely included the agency’s most
recent budget or financial plan.
Partially included the agency’s most recent budget or financial
plan.
Satisfactorily included the agency’s most recent budget or
financial plan.
Thoroughly included the agency’s most recent budget or
financial plan.
7. Provide the agency’s Website name, URL, and any other
sources used to support the assignment’s criteria.
Weight: 5%
No references provided

Does not meet the required number of references; some or all
references poor quality choices.
Meets number of required references; all references high quality
choices.
Exceeds number of required references; all references high
quality choices.
8. Clarity, writing mechanics, and formatting requirements
Weight: 10%
More than 6 errors present
5-6 errors present
3-4 errors present
0-2 errors present

86One of the fi rst activities of an analyst is to determi.docx

More Related Content

Similar to 86One of the fi rst activities of an analyst is to determi.docx (20)

More from ransayo (20)

Recently uploaded (20)

86One of the fi rst activities of an analyst is to determi.docx