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.
Key Risks and Uncertainty
Issues that will affect the economic success or failure of the solution.
The relationship of the solution to past, present, and future: This includes what the system is replacing, the proposed lifecycle of the product, the current market window…
What product(s) or manual system this system is replacing, a view of the offer and network level system it will exist in…
12Market Window, both for the development organization and for customers, schedule dependencies, key competitors and their schedules…
Product Line or Product Family Direction (and how this product fits into that larger set).
8 Market drivers are the key wants and needs of the “market” for this product which we believe will make it salable in that market. 9 The Value proposition says why people will find value in the product we are developing, above and beyond its costs to them. The difference here is, financially, their incentive to buy the product. Often, this value proposition is stated in terms of the single greatest benefit expected versus the single greatest cost or
total costs. The costs are figured as a part of the solution, and so don’t really belong in the Problem Statement. But key benefits very much should be quantified here, briefly. 10 This one’s a measure of the marketplace for the product. It typically grows and shrinks with the feature list shown under Function. 11 To the extent a problem statement includes development organization constraints, it drifts from describing purely the problem at hand. For example, our development organization may have database experience only with Oracle, and so our development has to target an Oracle-based solution. However, competing organizations may be able to use some less expensive database, resulting in a more widely marketable product. By including “Must be Oracle based,” in our problem statement, those reading it may lose sight of other options which could impact the long-term success of this project.
12 Market Window is a business term for the length of time (usually a range of months) during which we believe a product solving this problem would be salable to the marketplace described.
Problem Statement Guide 3 September, 2003 5
How will the solution need to change in the future?
Key Stakeholders (some possibilities) Name Client (owner of the budget – in a large Signature
company, typically an executive)
Names Other outside organizations which need to Signature
Name Program Management, Offer Signature
Management, etc. – your marketing people
Name Product Management (someone above the Signature
project’s own development manager, who
represents the Client in frequent decision-
making – “owns responsibility for the
product’s success” to the Client)
Name Requirements Engineering (may go under Signature
other names like Systems Engineering)
Name Architecture (may be a part of Signature
Name Development (i.e., your development Signature
Name Integration and Field Support Signature
(representing the after-sale support
Name Testing (QA, etc., which may be a separate signature
organization, especially for customer
Name Development Management / Project signature
Name Customer Representative (external to your signature
company – especially needed if there is a
single buyer of your software product)
Date Version Reason for change Edited By Xx/xx/xxxx 0.1 Draft Author’s Name(s) Xx/xx/xxxx 1.0 Baseline Stakeholder review comments Author’s Name(s) Etc.
Problem Statement Guide 3 September, 2003 6
Sample Appendix – Glossary
Additional Background and Context Information (as available – may include history, description of
conditions under which the project is being done, things which could change, etc.)
Current Customers Customer names, key attributes, schedule requirements…
Potential key attributes, schedule requirements, names if known …
Key Competitors Competitor names, key strengths, key markets, market share…
Market expectations and changes that impact the problem and solution. Market Drivers
Technology HW and SW changes, tool and process changes impacting this solution
Future Direction Things that are likely to change in the future – not part of the current plan, but likely
Current Where you don’t know the exact need or requirement, the “best guess” made (and if Assumptions applicable, why you made it)
3. What’s a good process, for deriving a problem statement which will prove valuable to us during development?
Here’s an example. The steps and deliverables include the following:
1. Gathering Written Input. Business case information, or first rough draft of the
Product Technology Roadmap based on market and technology directions, covering
at least the next 2 years.
2. Group Activity 1. Problem Statement Stakeholder Session: background phone calls 13followed by a facilitated session with the business and technical stakeholders to
13 With the requirements engineer or system architect typically serving as the trained meeting facilitator.
Problem Statement Guide 3 September, 2003 7
identify the needs, priorities, and success criteria for the product. Participants
represent all aspects of the product life cycle from product management through
deployment and customer support. Representatives of key customers for the overall 14platform need to be included. Identifying the right people is part of the service.
3. Writing It. At the conclusion of such an initial session, someone has to sit down and 15write a “straw horse” Problem Statement.
4. Group Activity 2. Facilitation and consultation with key product managers, systems
engineers and lead developers to develop next iteration of Problem Statement that
incorporates input from key stakeholders.
5. Revising It – Based on the additional input
6. Group Activity 3. Review of Problem Statement by representative stakeholders. 7. Revising It Again -- Updating of the Problem Statement based on review findings. 8. Sign-Offs – Everyone agrees this is the concise statement of what has to be done! 9. Maintenance. Ongoing validation and maintenance of the Problem Statement. It
can’t afford to become obsolete! For example, there can be changes in market drivers.
This activity will go on throughout the development project.
For this effort to be successful, enough of the stakeholders must be involved! A typical group participating in creation of the Problem Statement for a real commercial project may include the following (for our term project these numbers will be scaled down!): ; 1 requirements engineer (systems engineer): owns Problem Statement and
participates in Roadmapping training and all Problem Statement activities ; 1 architect or lead developer: co-authors Problem Statement and participates in
Roadmapping training and all Problem Statement activities
; Key product managers: participate in Problem Statement stakeholder session (1/2
day) and review (1/2 day)
; Key development team members from each lifecycle phase: participate in Problem
Statement stakeholder session (1/2 day) and review (1/2 day)
; Key internal application customer representatives: participate in Problem
Statement stakeholder session (1/2 day) and review (1/2 day)
; Project Executive (client): participate in Problem Statement stakeholder session (1/2
day) and optionally in the Problem Statement review
; Other product managers and development team members: participate as needed
for information gathering and input
14 Often, a single development is a branch off a main product or platform, and the people representing the other, related pieces of software are considered stakeholders in the new project. 15 An initial version for everyone else to throw darts at.
Problem Statement Guide 3 September, 2003 8
Problem Statement Guide 3 September, 2003 9