In this document we answer the following three questions:
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.
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 architectural document to convince stakeholders of
the viability of the proposed technical solution.
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 agreement!
Here is one sample format, which you can use as a template:
-- 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.
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…
Here are some further examples of topics you could cover under “Form,” depending of course on which ones are important enough to merit that!
Overview of the business problem you are solving for the customers, and the market drivers [7] which impact the need for a solution to the problem. Additional details can be in the appendix.
Development organization’s available budget, expected cost for solution.
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…
Market Window, [10] 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).
| Name |
Client (owner of the budget – in a large company, typically an executive) |
Signature |
| Names |
Other outside organizations which need to sign-off |
Signature |
| Name |
Program Management, Offer Management, etc. – your marketing people |
Signature |
| Name |
Product Management (someone above the project’s own development manager, who represents the Client in frequent decision-making – “owns responsibility for the product’s success” to the Client) |
Signature |
| Name |
Requirements Engineering (may go under other names like Systems Engineering) |
Signature |
| Name |
Architecture (may be a part of development) |
Signature |
| Name |
Development (i.e., your development manager) |
Signature |
| Name |
Integration and Field Support (representing the after-sale support people) |
Signature |
| Name |
Testing (QA, etc., which may be a separate organization, especially for customer acceptance testing) |
signature |
| Name |
Development Management / Project Management |
signature |
| Name |
Customer Representative (external to your company – especially needed if there is a single buyer of your software product) |
signature |
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. |
|
|
|
Acronym/Term |
Definition |
| |
|
| |
|
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.)
Samples –
| |
|
Current Customers & Contractual Commitments |
Customer names, key attributes, schedule requirements… |
Potential Customers |
key attributes, schedule requirements, names if known … |
Key Competitors |
Competitor names, key strengths, key markets, market share… |
Market Drivers |
Market expectations and changes that impact the problem and solution. |
Technology Drivers |
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 Assumptions |
Where you don’t know the exact need or requirement, the “best guess” made (and if applicable, why you made it) |
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 followed by
a facilitated session [11] with the business and technical stakeholders
to 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 platform need to be included. [12] 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 write a “straw horse” Problem Statement. [13]
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
[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
[3] Specifically, what Administrative and Operational features must be included, the activities which must be done behind the scenes or invisible to end-users.
[4] “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.
[5] 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.
[6] 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.
[7] Market drivers are the key wants and needs of the “market” for this product which we believe will make it salable in that market.
[8] 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.
[9] 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.
[10] 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.
[11] With the requirements engineer or system architect typically serving as the trained meeting facilitator.
[12] 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.
[13] An initial version for everyone else to throw darts at.