0% found this document useful (0 votes)
398 views

Vision Corto (Rup)

A "vision statement" is a statement summarizing the problem being solved. Problem statement: "the problem of [describe the problem] affects [the stakeholders affected by the problem] the impact of which is [what is the impact of the problem?] a "successful solution would be [list some key benefits of a successful solution]" stakeholder description: "name the stakeholder type.] [Briefly describe the stakeholder's key responsibilities with regard to the system being

Uploaded by

Mario Betanzos
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
398 views

Vision Corto (Rup)

A "vision statement" is a statement summarizing the problem being solved. Problem statement: "the problem of [describe the problem] affects [the stakeholders affected by the problem] the impact of which is [what is the impact of the problem?] a "successful solution would be [list some key benefits of a successful solution]" stakeholder description: "name the stakeholder type.] [Briefly describe the stakeholder's key responsibilities with regard to the system being

Uploaded by

Mario Betanzos
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 3

<Project Name>

Vision Date: <dd/mmm/yy>


<Project Name>
Vision
Usage note: There is procedural guidance within this template that appears in a style named InfoBlue. This style has a hidden
font attribute allowing you to toggle whether it is visible or hidden in this template. Use the Word menu
ToolsOptionsViewidden Te!t chec"bo! to toggle this setting. # similar option e!ists for printing
ToolsOptions$rint.
1. Introduction
2. Positioning
2.1 Problem Statement
[Provide a statement summarizing the problem being solved by this project. The following format may be used:]
The problem of [describe the problem]
affects [the stakeholders affected by the problem]
the impact of which is [what is the impact of the problem?]
a successful solution would be [list some key benefits of a successful solution]
2.2 Product Position Statement
[Provide an overall statement summarizing, at the highest level, the unique position the product intends to fill in the
marketplace. The following format may be used:]
For [target customer]
Who [statement of the need or opportunity]
The (product name) is a [product category]
That [statement of key benefit; that is, the compelling reason to buy]
nli!e [primary competitive alternative]
"ur product [statement of primary differentiation]
[A product position statement communicates the intent of the application and the importance of the project to all
concerned personnel.]
3. Stakeholder Descritions
3.1 Stakeholder Summar!
Name Description Responsibilities
[Name the
stakeholder type.]
[Briefly describe the
stakeholder.]
[Summarize the stakeholders key
responsibilities with regard to the system
being developed; that is, their interest as a
stakeholder. For example, this stakeholder:
ensures that the system will be maintainable
#onfidential <#ompany $ame>% &'() *a+e (
<Project Name>

Vision Date: <dd/mmm/yy>
Name Description Responsibilities
ensures that there will be a market demand
for the products features
monitors the projects progress
approves funding
and so forth]
3.2 "ser #n$ironment
[Detail the working environment of the target user. Here are some suggestions:
Number of people involved in completing the task? Is this changing?
How long is a task cycle? Amount of time spent in each activity? Is this changing?
Any unique environmental constraints: mobile, outdoors, in-flight, and so on?
Which system platforms are in use today? Future platforms?
What other applications are in use? Does your application need to integrate with them?
This is where extracts from the Business Model could be included to outline the task and roles involved, and so on.]
%. Product &$er$ie'
%.1 Product Persecti$e
[This subsection of the Vision document puts the product in perspective to other related products and the users
environment. If the product is independent and totally self-contained, state it here. If the product is a component of
a larger system, then this subsection needs to relate how these systems interact and needs to identify the relevant
interfaces between the systems. One easy way to display the major components of the larger system,
interconnections, and external interfaces is with a block diagram.]
%.2 (ssumtions and Deendencies
[List each factor that affects the features stated in the Vision document. List assumptions that, if changed, will alter
the Vision document. For example, an assumption may state that a specific operating system will be available for
the hardware designated for the software product. If the operating system is not available, the Vision document will
need to change.]
%.3 Needs and )eatures
[Avoid design. Keep feature descriptions at a general level. Focus on capabilities needed and why (not how)
they should be implemented.]
Need Priority Features Planned Release
%.% (lternati$es and *ometition
[Identify alternatives the stakeholder perceives as available. These can include buying a competitors product,
building a homegrown solution, or simply maintaining the status quo. List any known competitive choices that exist
or may become available. Include the major strengths and weaknesses of each competitor as perceived by the
stakeholder or end user.]
#onfidential <#ompany $ame>% &'() *a+e &
<Project Name>

Vision Date: <dd/mmm/yy>
+. &ther Product ,e-uirements
[At a high level, list applicable standards, hardware, or platform requirements; performance requirements; and
environmental requirements.
Define the quality ranges for performance, robustness, fault tolerance, usability, and similar characteristics that are
not captured in the Feature Set.
Note any design constraints, external constraints, or other dependencies.
Define any specific documentation requirements, including user manuals, online help, installation, labeling, and
packaging requirements.
Define the priority of these other product requirements. Include, if useful, attributes such as stability, benefit, effort,
and risk.]
#onfidential <#ompany $ame>% &'() *a+e ,

You might also like