Project 13 - The Ins and Outs of Problem Statements | CSSE 497, Study Guides, Projects, Research of Computer Science

Download Project 13 - The Ins and Outs of Problem Statements | CSSE 497 and more Study Guides, Projects, Research Computer Science in PDF only on Docsity! 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 <name of project> -- 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  Value proposition8  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... Development Organization Constraints9 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 Market Window,10 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). How will the solution need to change in the future? 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. Problem Statement Guide 3 September, 2003 5 Key Stakeholders (some possibilities) 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 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 & 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) 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 followed by a facilitated session11 with the business and technical stakeholders to 11 With the requirements engineer or system architect typically serving as the trained meeting facilitator. Problem Statement Guide 3 September, 2003 7