The ins and outs of problem statements
In this document we answer the following three questions:
1. What is a problem statement, and what’s it good for?
2. What exactly does a problem statement look like?
3. What’s a good process, for deriving a problem statement which will prove
valuable to us during development?
We believe that the creation of problem statements is crucial to the success of any project which has sufficient technical or organizational complexity. You will have several opportunities to create and evaluate problem statements, in CSSE 371 (Requirements Engineering) and also in CSSE 374 (Software Architecture). Usually, both requirements engineers and also architects are involved in the creation of problem statements.
1. What is a problem statement?
a. Short and to the point: A 1 – 3 page statement which everyone on an engineering
project agrees with, saying, “This is what we are doing.” By “everyone,” we mean
official project stakeholders, developers, and everyone else who should have some
say-so in the project’s outcome.
b. A translation: The problem statement translates the business case point of view of
marketing people into the terminology and form used by the technical team who will
develop a system, as a solution to a problem or need by paying customers. The
problem statement will help those in business oriented non-technical jobs
communicate effectively with the technical communities that support them, and help
the technical communities understand, prioritize and delineate among needs,
differentiators and wish-lists. It will also improve decision making speed and reduce
rework resulting from a misunderstanding of the underlying reasons for what is
requested by the product management team. These are all reasons why it’s
worthwhile to do this problem statement!
c. Stays away from solving the problem: The problem statement says, “What has to
be done” for a development project to succeed – to meet the needs of its stakeholders
who are external to the development. It does not say, “How that has to be done,”
unless those external stakeholders say so. This makes the problem statement become
a tool for the development team to envision architectural and technology choices.
Specifically, the problem statement matches an architectural document created by the
architects for the project – that architecture document which follows will then say,
point by point, how the proposed overall system design will meet the needs described
in the problem statement. Since both the problem statement and architectural
document are fairly short, they have an “impedance match” which enables the Problem Statement Guide 3 September, 2003 1
architectural document to convince stakeholders of the viability of the proposed
d. Something done separately: It is not a part of a larger requirements document,
because it is a more conceptual document and is intended for a very wide audience.
Also, the problem statement usually needs to be done first, so that the requirements
reflect the concepts described in the problem statement. Thus, the problem statement
does not fit in with the schedule of creation and organizational approvals for the
related, thick requirements document.
e. More than just the “short list” of requirements: Furthermore, this is not just a
consolidation of detailed requirements. The problem statement must say, for example,
which really are the key requirements, and which ones are less important, something
a requirements document may not say at all. And the problem statement explains
why those are important to the success of the stakeholders.
f. Serves a crucial role in software project success: In other words, the problem
statement is a format or tool for the stakeholders and developers to communicate in
concise, plain language, about what tasks are being paid for, and what must be
accomplished conceptually for the project to be a success. It is something everyone
involved can tape on their office wall and know, “When we have done this, we made
it!” Notice in the template for the problem statement, below, there is a place for
stakeholders to sign-off on this document. This is very important! The problem
statement forces all parties involved (including the development team’s leaders), to
reach a conceptual agreement about what they are doing, and sign their names to this
2. What exactly does a problem statement look like?
Here is one sample format, which you can use as a template:
Problem Statement for
-- under each heading, below, is described the nature of the contents of that section. Overall, it should sound like the answer to our question, “What is a problem statement?” above.
Problem Statement Guide 3 September, 2003 2
High Level Problem Summary
1“Elevator statement” describing the problem to be solved - a single sentence that captures the essence of the issue.
Summary of Primary Success Criteria
How we will know when we’ve succeeded? A bullet list of the 3-5 key indicators of success: prioritized
metrics for things such as speed to market, market dominance, quality, reusability…
A short, high level description of the problem boundaries – what is considered to be “inside” and “outside”
the system for this particular release. (This is crucial to success – many projects fail because of a failure in
mutual understanding of project boundaries.) One should be able to tell here what the system won’t do.
Detailed Problem Statement
What the solution must do and how it will be used: identifies key features and prioritizes needs and wants. Often, these are described at a fairly high level here. Most critically, though, only the most important ones 3are shown, the short list. The top 10 things the system must have, for example.
Key Business features
A bullet list of the features that provide business value for the system: the ones the end users care about.
4Key Enabling Features
5A bullet list of the administrative features necessary to provision the system and keep it up and running:
the ones the administrators care about.
Key Concurrency Issues
Which key functions must happen at the same time?
The form the system must take in providing the functional features. Form requirements have a major impact on the architecture style chosen. Think “What shape is the software, in terms the stakeholders can understand?” So, you might say here that it’s going to have to be an “Oracle based” system, if that’s really
a requirement and not a design choice. But you wouldn’t say, “We’re going to use abstract factory” or
1 An “elevator statement” is the message you would want to tell a stakeholder about your project, if you got on an elevator together and they asked, “So, what’s this project all about?”, and you had till they got off to explain the key points. 2 The “Function – Form – Economy – Time” model is used here for describing the problem. This model is due to the US architectural firm CRSS (now part of HOK). See William Pena’s Problem Seeking: An
Architectural Programming Primer, Third Edition. AIA Press, 1987, ISBN 0-913962-87-2. 3 If there are 100 features in the must have list, and you can’t generalize these, that’s usually a bad sign for the success of the engineering project. Especially if the project is really something new. 4 Specifically, what Administrative and Operational features must be included, the activities which must be done behind the scenes or invisible to end-users. 5 “Provisioning” means supplying the system with data. For example, when a new account is created,
something has to happen to capture all the related data, verify it, and get it into a system’s database.
Problem Statement Guide 3 September, 2003 3
even “it will be a client-server system,” because these are pretty far into design (even if there’s a chance all
the non-technical stakeholders would understand you).
Here are some further examples of topics you could cover under “Form,” depending of course on which ones are important enough to merit that!
The -illities that impact architecture style and their priorities. In each case, what you want to say here is what the system “has to be,” not what you think it will do. For example, under performance and capacity, has somebody said how many transactions per hour the system has to do? The list can vary a lot for different kinds of devices and software. However, the goal is to have a general list you can use for whole families of products used in a certain environment:
； Usability (& environmental considerations)
； Availability (reliability)
； Performance (speed & capacity)
； Modifiability (maintainability, customizability, plus manufacturability for hardware)
； Security (& safety)
6 ； Testability (& traceability)
Hardware & Software Constraints
This includes the hardware, software, and customer environment within which the system will operate, such as constraints such as tools and languages used for implementation, hardware platforms
The offer & network infrastructure, external systems that provide or receive information from the system… Required data formats or shared data needs…
Constraints on the solution such as environmental standards, interface specifications…
A description of the product line or product family the solution is a part of: key commonalities and variabilities for this particular problem. Again, these only go in the problem statement if they are specified as requirements. If they are design choices, they belong in an architecture document!
The expected value and cost of the solution to customers and to your own organization (parent company, 7etc. – beyond your own development group): can include benefits, market strategies, COGS, variable
pricing strategies, resource constraints...
8Overview of the business problem you are solving for the customers, and the market drivers which impact
the need for a solution to the problem. Additional details can be in the appendix.
6 There could be many more of these “-ilities,” which are attributes of the whole system you are creating.
They are so-named because many of them, like “reliability” and “usability” have that word ending.
7 COGS = Cost of Goods Sold. In accounting, this is the direct cost attributable to a specific item being sold. For software, this is often seen as the total cost of development divided by the number of units of that software which you expect to sell.
Problem Statement Guide 3 September, 2003 4
9 ； Value proposition10； Customer willingness to pay
Customer Organization Constraints
The people who will use the solution: includes constraints on geographic location, skill sets, internal/external reporting structures...
11Development Organization Constraints
The people who will develop the solution: includes constraints on geographic location, skill sets, internal/external reporting structures...
Development organization’s available budget, expected cost for solution.