Establishing the Product Vision and Project Scope
Establishing the Product Vision and Project Scope Establishing the Product Vision and Project Scope
82 Part II Software Requirements Development The owner of the vision and scope document is the project's executive sponsor, funding authority, or someone in a similar role. A requirements analyst can work with the owner to write the vision and scope document. Input on the business requirements should come from individuals who have a clear sense of why they are undertaking the project. These individuals might include the customer or development organization's senior management, a project visionary, a product manager, a subject matter expert, or members of the markering department. Figure 5-2 suggests a template for a vision and scope document. Document templates standardize the structure of the documents created by your organization's project teams. As with any template, adapt this one to meet the specifk needs of your own projects. 1. Business Requlrements 1.1 Background 1.2 Business Opportunity 1.3 Business Objectives and Success Criteria 1.4 Customer or Market Needs 1.5 Business Risks 2. VIsion of the Solution 2.1 Vision Statement 2.2 Major Features 2.3 Assumptions and Dependencies 3. Scope and limltations 3.1 SCope of Initial Release 3.2 Scope of Subsequent Releases 3.3 Limitations and Exclusions 4. Business Context 4.1 Stakeholder Profiles 4.2 Project Priorities 4.3 Operating Environment Figure 5-2 Template for vision and scope document. Parts of the vision and scope document might seem repetitive, but they should interlock in a sensible way. Consider the following example: Business Opportunity Exploit the poor security record of a competing product. Business Objective Capture a market share of 80 percent by being recognized as the most secure product in the market through trade journal reviews and consumer surveys.
Chapter 5 Establishing the Product Vision and Project Scope 83 Customer Need A more secure product. Feature A new, robust security engine. 1. Business Requirements Projects are launched in the belief that the new product will make t he world a better place in some way for someonc. The husiness requircments descrihe the primary benefits that the new system will provide to its sponsors, huyen.;, and users. The emphasis will be different for differt'nt kinds of products, such as information systems, commercial software packages, and real-time control systems. 1.1 Background Summarize the rationale and context for the new product. Provide a general description of the history or situation that led to the decision to build this product. 1.2 Business Opportunity For a commercial product, describe the market opportunity that exists and the market in which the product will be competing. For a corporale information system, describe the business problern that is being solved or the business process being improved, as well as the environment in which the system will be used. Irrelude a comparative evaluation of existing products and potential solutions, indicating why the proposed product is attractive and the advantages it provides. Describe the problems that cannot currently be solved without the product. Show how it aligns with market trends, technology evolution, or corporate Strategie directions. Irrelude a brief description of any other technologies, processes, or resources required to provide a complete customer solution. 1.3 Business Objectives and Success Criteria Summarize the important business benefits the product will provide in a quantitative and measurable way. Tahle 5-1 presents some examples of both financial and non-financial business objectives (Wiegers 2002c). If such information appears elsewhere, such as in a business case document, refer to the other document rather than duplicate it here. Derermine how the Stakeholders will define and measure success on this project (Wiegers 2002c). State the factors that have the greatest impact on achieving that success, including factors both within and outside the organization's control. Specify measurable criteria to assess whether the business objectives have been met.
- Page 1 and 2: Establishing the Product Vision and
- Page 3 and 4: Project Scope for release 1.0 Chapt
- Page 8: 84 Part II Software Requirements De
- Page 12 and 13: 88 Part II Software Requirements De
- Page 14 and 15: 90 Part II Software Requirements De
- Page 16 and 17: 92 Part II Software Requirements De
82 Part II Software Requirements Development<br />
The owner of <strong>the</strong> vision <strong>and</strong> scope document is <strong>the</strong> project's executive<br />
sponsor, funding authority, or someone in a similar role. A requirements analyst<br />
can work with <strong>the</strong> owner to write <strong>the</strong> vision <strong>and</strong> scope document. Input<br />
on <strong>the</strong> business requirements should come from individuals who have a clear<br />
sense of why <strong>the</strong>y are undertaking <strong>the</strong> project. These individuals might<br />
include <strong>the</strong> customer or development organization's senior management, a<br />
project visionary, a product manager, a subject matter expert, or members of<br />
<strong>the</strong> markering department.<br />
Figure 5-2 suggests a template for a vision <strong>and</strong> scope document. Document<br />
templates st<strong>and</strong>ardize <strong>the</strong> structure of <strong>the</strong> documents created by your<br />
organization's project teams. As with any template, adapt this one to meet <strong>the</strong><br />
specifk needs of your own projects.<br />
1. Business Requlrements<br />
1.1 Background<br />
1.2 Business Opportunity<br />
1.3 Business Objectives <strong>and</strong> Success Criteria<br />
1.4 Customer or Market Needs<br />
1.5 Business Risks<br />
2. VIsion of <strong>the</strong> Solution<br />
2.1 <strong>Vision</strong> Statement<br />
2.2 Major Features<br />
2.3 Assumptions <strong>and</strong> Dependencies<br />
3. <strong>Scope</strong> <strong>and</strong> limltations<br />
3.1 SCope of Initial Release<br />
3.2 <strong>Scope</strong> of Subsequent Releases<br />
3.3 Limitations <strong>and</strong> Exclusions<br />
4. Business Context<br />
4.1 Stakeholder Profiles<br />
4.2 <strong>Project</strong> Priorities<br />
4.3 Operating Environment<br />
Figure 5-2 Template for vision <strong>and</strong> scope document.<br />
Parts of <strong>the</strong> vision <strong>and</strong> scope document might seem repetitive, but <strong>the</strong>y<br />
should interlock in a sensible way. Consider <strong>the</strong> following example:<br />
Business Opportunity Exploit <strong>the</strong> poor security record of a competing<br />
product.<br />
Business Objective Capture a market share of 80 percent by being recognized<br />
as <strong>the</strong> most secure product in <strong>the</strong> market through trade journal reviews<br />
<strong>and</strong> consumer surveys.
Change language