1999 by CRC Press LLC

chapter twelve
The problem statement
William S. Davis
Contents
12.1 Purpose
12.2 Strengths, weaknesses, and limitations
12.3 Inputs and related ideas
12.4 Concepts
12.4.1 Problem statement components
12.4.2 Verification
12.5 Key terms
12.6 Software
12.7 References
12.1 Purpose
A good problem statement lists symptoms, suggests the problems likely
causes, and estimates the resources needed to solve the problem. It serves to
communicate to the user, to management, and to the technical people the
analysts understanding of the nature of the problem and an initial sense of
the problems resource implications.
12.2 Strengths, weaknesses, and limitations
A well-written problem statement is an effective means of communicating
the analysts understanding of the problem and its causes to the user, tech-
nical personnel, and management, thus helping to ensure that the right
problem is solved. The focus on symptoms, objectives, and scope supports
high level verification.
1999 by CRC Press LLC
The problem statement is, by its very nature, preliminary. By itself,
it does not represent a sufficient base for selecting, designing, or
implementing a specific physical system. In particular, the scope should be
viewed as a ballpark or order of magnitude cost estimate. Common
mistakes include suggesting possible physical solutions to the problem
rather than logical objectives for solving the problem, treating the prelimi-
nary estimate of system scope as a serious cost estimate, and writing a prob-
lem statement that includes too much technical detail.
12.3 Inputs and related ideas
The problem statement often serves as a charter, or formal authorization
for the information gathering and problem definition phase (Part II). The
problem statement is often based on a limited number of preliminary inter-
views (Chapter 8) or observations. The detailed system requirements
defined at the end of the analysis stage (Part IV) often reference the objec-
tives in the initial problem statement. Detailed cost estimates, schedules, and
budgets are typically based on the requirements and prepared before the
design stage begins.
12.4 Concepts
Once a problem is defined, a sense of its causes and its likely resource impli-
cations must be communicated to the user, to management, and to
technical personnel. Generally, this communication takes the form of a writ-
ten problem statement, sometimes called a statement of scope and objec-
tives, a user needs assessment, an operations concept document, or a mis-
sion statement.
12.4.1 Problem statement components
The precise form of the problem statement varies from organization to orga-
nization. The ideal length varies from project to project. No matter what for-
mat is used, however, a good problem statement includes the following ele-
ments (Table 12.1):
Alist of observed symptoms (the things that are wrong) stated in mea-
surable form. The more specific the symptoms, the more likely it is
that the problem will be solved.
A list of suspected causes stated as measurable business (or applica-
tion) objectives. The objectives, if met, are likely to contribute to solv-
ing the problem (or fixing the symptoms).
A preliminary estimate of the problems resource implications, or
scope, typically (but not always) stated in financial terms. The scope
represents the analysts sense of the problems magnitude.
1999 by CRC Press LLC
12.4.2 Verification
The first step in verifying the problem statement is to compare the symp-
toms to the objectives. Each symptom should be addressed by one or more
objectives, because orphan symptoms are not likely to be corrected.
Each objective should address one or more symptoms, because orphan
objectives suggest overlooked symptoms or superfluous features.
Comparing the scope to the symptoms allows the user to judge if solv-
ing the problem is worth the cost. Comparing the scope to the objectives
allows the technical personnel to judge if they can achieve the objectives
given the scope. The scope, by itself, allows management to determine if
adequate resources are available. The combination of the symptoms, the
scope, and the objectives allows users, management, and technical personnel
to independently determine if the problem is worth solving.
Table 12.1 The Contents of a Good Problem Statement
A. The problem Alist of measurable symptoms.
Examples: Inventory value is $100,000 too high.
Our competitor can process an order in
one day but we need three.
B. The objectives The likely cause or causes, usually stated
as measurable objectives that, if
achieved, are likely to contribute to solv-
ing the problem.
Examples: Reduce average stock time by two days.
Reduce inventory cost by $100,000 by
eliminating obsolete inventory.
Reduce inventory cost by $100,000 by
reducing safety stock to a level sufficient
to cover expected reorder time plus five
days.
Reduce sales order processing time by
one day by improving paperwork flow.
C. The scope A sense of the problems magnitude,
often stated as a preliminary cost
estimate.
Examples: The estimated cost of this system is
$10,000 plus or minus 25 percent.
Preliminary estimates suggest that a
team of three analyst/programmers will
need six months to solve this problem.
1999 by CRC Press LLC
12.5 Key terms
Objective Ameasurable goal which, if met, is likely to contribute to
solving the problem.
Problem statement A written statement that defines a problem by
listing its symptoms, identifying a set of objectives for solving the
problem, and indicating the problems scope.
Scope A sense of the problems magnitude; often, a preliminary
estimate of the problems resource implications or cost.
12.6 Software
Not applicable.
12.7 References
1. Blanchard, K. and Johnson, The One Minute Manager, William Morrow, New
York, 1982.
2. Davis, W. S., Business Systems Analysis and Design, Wadsworth Publishing,
Belmont, CA, 1994.
3. Gause, D. C. and Weinberg, Are your Lights On? How to Figure Out What the
Problem REALLY Is, Dorset House Publishing, New York, 1990.
4. Paulos, J. A., Innumercy, Vintage Books, New York, 1988.