Vision

Vision
1. Introduction
[The purpose of this document is to collect, analyze, and define high-level needs and features of the
<<System Name>>. It focuses on the capabilities needed by the stakeholders, and the target users, and
why these needs exist. The details of how the <<System Name>> fulfils these needs are detailed in the use-
case and supplementary specifications.]
[The introduction of the Vision document provides an overview of the entire document. It should include
the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Vision
document.]
1.1 Purpose
[Specify the purpose of this Vision document.]
1.2 Scope
[A brief description of the scope of this Vision document; what Project(s) it is associated with and anything
else that is affected or influenced by this document.]
1.3 Definitions, Acronyms, and Abbreviations
[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly
interpret the Vision document. This information may be provided by reference to the project's Glossary.]
1.4 References
[This subsection provides a complete list of all documents referenced elsewhere in the Vision document.
Identify each document by title, report number (if applicable), date, and publishing organization. Specify
the sources from which the references can be obtained. This information may be provided by reference to
an appendix or to another document.]
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]
Unlike [primary competitive alternative]
Our product [statement of primary differentiation]

1/5
Vision

[A product position statement communicates the intent of the application and the importance of the project
to all concerned personnel.]
3. Stakeholder and User Descriptions
[To effectively provide products and services that meet your stakeholders’ and users' real needs, it is
necessary to identify and involve all of the stakeholders as part of the Requirements Modeling process. You
must also identify the users of the system and ensure that the stakeholder community adequately represents
them. This section provides a profile of the stakeholders and users involved in the project, and the key
problems that they perceive to be addressed by the proposed solution. It does not describe their specific
requests or requirements as these are captured in a separate stakeholder requests artifact. Instead, it
provides the background and justification for why the requirements are needed.]
3.1 Stakeholder Summary
[There are a number of stakeholders with an interest in the development and not all of them are end users.
Present a summary list of these non-user stakeholders. (The users are summarized in section 3.3.)]
Name Description Responsibilities
[Name the stakeholder [Briefly describe the [Summarize the stakeholder's key
type.] stakeholder.] 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
- ensures that there will be a
market demand for the product's
features
- monitors the project's progress
- approves funding
- and so forth]

3.2 User Summary

[Present a summary list of all identified users.]
Name Description Responsibilities Stakeholder

[Name the [Briefly [List the user's key responsibilities with [If the user is not directly
user type.] describe what regard to the system being developed; represented, identify which
they represent for example: stakeholder is responsible for
with respect to representing the user's interests.]
- captures details
the system.]
- produces reports
- coordinates work
- and so on]

3.3 User Environment

[Detail the working environment of the target user. Here are some suggestions:
 Number of people involved in completing the task? Is this changing?

2/5
Vision

 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 systems 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 business workers
involved, and so on.]
3.4 Key Stakeholder or User Needs
[List the key problems with existing solutions as perceived by the stakeholder. Clarify the following issues
for each problem:
• What are the reasons for this problem?
• How is it solved now?
• What solutions does the stakeholder or user want?]
[It is important to understand the relative importance the stakeholder or user places on solving each
problem. Ranking and cumulative voting techniques indicate problems that must be solved versus issues
they would like addressed.
Fill in the following table—if using Rational RequisitePro to capture the Needs, this could be an extract or
report from that tool.]
Need Priority Current Solution Proposed Solutions
Broadcast messages

4. Product Overview
[This section provides a high level view of the product capabilities, interfaces to other applications, and
systems configurations. This section usually consists of three subsections, as follows:
• Product perspective
• Product functions
• Assumptions and dependencies]
4.1 Product Perspective
[This subsection of the Vision document puts the product in perspective to other related products and the
user’s 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 relates how these systems interact and identifies 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.]
4.2 Summary of Capabilities
[Summarize the major benefits and features the product will provide. For example, a Vision document for
a customer support system may use this part to address problem documentation, routing, and status
reporting without mentioning the amount of detail each of these functions requires.
Organize the functions so the list is understandable to the customer or to anyone else reading the document
for the first time. A simple table listing the key benefits and their supporting features might suffice.
For example:]
Table 4-1 Customer Support System
Customer Benefit Supporting Features

3/5
Vision

New support staff can quickly get Knowledge base assists support personnel
up to speed. in quickly identifying known fixes and
workarounds.
Customer satisfaction is Problems are uniquely itemized, classified
improved because nothing falls and tracked throughout the resolution
through the cracks. process. Automatic notification occurs for
any aging issues.
Management can identify Trend and distribution reports allow high
problem areas and gauge staff level review of problem status.
workload.
Distributed support teams can Replication server allows current database
work together to solve problems. information to be shared across the
enterprise.
Customers can help themselves, Knowledge base can be made available
lowering support costs and over the Internet. Includes hypertext search
improving response time. capabilities and graphical query engine.

5. Requirements
5.1 System Requirements
[Define any system requirements necessary to support the application. These can include the supported
host operating systems and network platforms, configurations, memory, peripherals, and companion
software.]
5.2 Performance Requirements
[Use this section to detail performance requirements. Performance issues can include such items as user
load factors, bandwidth or communication capacity, throughput, accuracy, and reliability or response
times under a variety of loading conditions.]
5.3 Environmental Requirements
[Detail environmental requirements as needed. For hardware- based systems, environmental issues can
include temperature, shock, humidity, radiation, and so forth. For software applications, environmental
factors can include usage conditions, user environment, resource availability, maintenance issues, and
error handling and recovery.]
6. Product Features
[List and briefly describe the product features. Features are the high-level capabilities of the system that
are necessary to deliver benefits to the users. Each feature is an externally desired service that typically
requires a series of inputs to achieve the desired result. For example, a feature of a problem tracking
system might be the ability to provide trending reports. As the use-case model takes shape, update the
description to refer to the use cases.
Because the Vision document is reviewed by a wide variety of involved personnel, the level of detail needs
to be general enough for everyone to understand. However, enough detail must be available to provide the
team with the information they need to create a use-case model.
To effectively manage application complexity, we recommend for any new system, or an increment to an
existing system, capabilities are abstracted to a high enough level so 25-99 features result. These features
provide the fundamental basis for product definition, scope management, and project management. Each
feature will be expanded in greater detail in the use-case model.

4/5
Vision

Throughout this section, each feature will be externally perceivable by users, operators or other external
systems. These features should include a description of functionality and any relevant usability issues that
must be addressed. The following guidelines apply:
• Avoid design. Keep feature descriptions at a general level. Focus on capabilities needed and why
(not how) they should be implemented.
• If you are using the Rational RequisitePro toolkit, all need to be selected as requirements of type for
easy reference and tracking.]
5.1 <aFeature>

5.2 <anotherFeature>

5/5