<ch11 toc ch13>

12 The problem statement

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 problem’s 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 analyst’s understanding of the nature of the problem and an initial sense of the problem’s resource implications.

12.2 Strengths, weaknesses, and limitations

A well-written problem statement is an effective means of communicating the analyst’s understanding of the problem and its causes to the user, technical personnel, and management, thus helping to ensure that the right problem is solved. The focus on symptoms, objectives, and scope supports high level verification.

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 preliminary estimate of system scope as a serious cost estimate, and writing a problem 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 interviews (# 8) or observations. The detailed system requirements defined at the end of the analysis stage (Part IV) often reference the objectives 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 implications must be communicated to the user, to management, and to technical personnel. Generally, this communication takes the form of a written problem statement, sometimes called a statement of scope and objectives, a user needs assessment, an operations concept document, or a mission statement.

12.4.1 Problem statement components

The precise form of the problem statement varies from organization to organization. The ideal length varies from project to project. No matter what format is used, however, a good problem statement includes the following elements (Table 12.1):

  A list of observed symptoms (the things that are wrong) stated in measurable 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 application) objectives. The objectives, if met, are likely to contribute to solving the problem (or fixing the symptoms).
  A preliminary estimate of the problem’s resource implications, or scope, typically (but not always) stated in financial terms. The scope represents the analyst’s sense of the problem’s magnitude.
Table 12.1 The Contents of a Good Problem Statement

A. The problem A list 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 solving 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 problem’s 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.

12.4.2 Verification

The first step in verifying the problem statement is to compare the symptoms 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 solving 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.

12.5 Key terms

Objective —
A measurable 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 problem’s scope.
Scope —
A sense of the problem’s magnitude; often, a preliminary estimate of the problem’s 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.
<ch11 toc ch13>