DOC

The ins and outs of problem statements

By Kim Howard,2014-06-14 21:59
8 views 0
The ins and outs of problem statements

    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

    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!

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…

Scope

    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

    2FUNCTION

    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?

FORM

    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!

Key Attributes

    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

    Key Interfaces

    The offer & network infrastructure, external systems that provide or receive information from the system… Required data formats or shared data needs…

    Required Standards

    Constraints on the solution such as environmental standards, interface specifications…

    Domain

    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!

ECONOMY

    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...

    Business Context

    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.

TIME

    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…

Historical Context

    What product(s) or manual system this system is replacing, a view of the offer and network level system it will exist in…

Current Context

    12Market Window, both for the development organization and for customers, schedule dependencies, key competitors and their schedules…

Future Context

    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

    sign-off

    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

    development)

    Name Development (i.e., your development Signature

    manager)

    Name Integration and Field Support Signature

    (representing the after-sale support

    people)

    Name Testing (QA, etc., which may be a separate signature

    organization, especially for customer

    acceptance testing)

    Name Development Management / Project signature

    Management

    Name Customer Representative (external to your signature

    company especially needed if there is a

    single buyer of your software product)

Revision History

    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.

    APPENDIX

    Problem Statement Guide 3 September, 2003 6

Sample Appendix Glossary

    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 Customer names, key attributes, schedule requirements…

    & Contractual

    Commitments

    Potential key attributes, schedule requirements, names if known …

    Customers

    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

    Drivers

    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

Report this document

For any questions or suggestions please email
cust-service@docsford.com