Vision Document: Search in This Product..
Vision Document: Search in This Product..
Previous Next
Vision document
Search in all products
Defining requirements
Creating artifacts
Creating collections
Commenting on artifacts
A vision document defines the high-level scope and purpose of a program, product, or project.
A clear statement of the problem, proposed solution, and the high-level features of a product
helps establish expectations and reduce risks This topic provides an outline of potential
https://www.ibm.com/support/knowledgecenter/SSWMEQ_4.0.6/com.ibm.rational.rrm.help.doc/topics/r_vision_doc.html 1/11
1/31/2020 Vision document
helps establish expectations and reduce risks. This topic provides an outline of potential
content for a vision document.
See Developing a vision for an explanation of how the product owner or business analyst works
with stakeholders to develop a vision document. That topic, which is part of the Collaborative
Lifecycle Management scenario guidance, describes the vision-development process. This
topic outlines typical content for the document. You can copy this outline, paste it into a new
document, and use it as the basis for your vision document. Use those portions of this outline
that are relevant for your project.
When a team uses the Requirements Management (RM) capability in the Rational® solution for
Collaborative Lifecycle Management (CLM), the vision document can be expressed in one or
more rich-text documents or modules. You can embed requirements and related artifacts in
rich-text documents or use the numbered hierarchical structure of a module to organize
content. Team members can set attributes, such as priority and status, on each artifact and
create trace links between related documents, modules, and individual artifacts.
To review the steps for creating and linking documents and modules, see:
• Creating modules
1: Introduction
This introduction provides an overview of the entire vision document. It includes the purpose,
scope, definitions, acronyms, abbreviations, references, and an overview of the full document.
1.2 Scope: Briefly describe the scope of this vision document, including which programs,
projects, applications, and business processes the document is associated with. Include
anything else that this document affects or influences.
1.3 Definitions, acronyms and abbreviations: Define all terms, acronyms, and abbreviations
that are required to interpret the vision correctly. This information might be provided by
reference to the project glossary, which can be developed online in the RM repository.
1.4 References: List all documents that the vision document refers to. Identify each document
by title, report number (if applicable), date, and publishing organization. Specify the sources
from which readers can obtain the references; the sources are ideally available in RM or in
th li it i Thi i f ti ight b id d b f
https://www.ibm.com/support/knowledgecenter/SSWMEQ_4.0.6/com.ibm.rational.rrm.help.doc/topics/r_vision_doc.html t di t 2/11
1/31/2020 Vision document
other online repositories. This information might be provided by reference to an appendix or to
another document.
1.5 Overview: Describe the vision-document contents and explain how the document is
organized.
2: Positioning
2.1 Business opportunity: Briefly describe the business opportunity that is addressed by this
project.
2.2 Problem statement: Summarize the problem that this project solves. Use the following
statements as a model, providing project details to replace the parenthetical elements:
The problem of (describe the problem) affects (the stakeholders affected by the problem). The
impact of the problem is (what is the impact of the problem). A successful solution would
include (list some key benefits of a successful solution).
2.3 Product position statement: Provide an overall statement that summarizes at the highest
level the unique position the product intends to take in the marketplace. Use the following
statements as a model, providing project details to replace the parenthetical elements:
A product position statement communicates the intent of the application and the importance of
the project to all concerned stakeholders.
This section provides a profile of the stakeholders and users who are involved in the project.
This section also identifies the key problems that stakeholders and users consider that the
proposed solution must address. This section does not describe specific requests or
requirements; a separate stakeholder requests artifact captures these items. The key-problem
description provides the background and justification for requirements.
https://www.ibm.com/support/knowledgecenter/SSWMEQ_4.0.6/com.ibm.rational.rrm.help.doc/topics/r_vision_doc.html 3/11
1/31/2020 Vision document
3.1 Market demographics: Summarize the key market demographics that motivate your
product decisions. Describe and position target market segments. Estimate the market size and
growth by using the number of potential users. Alternatively, estimate the amount of money
that your customers spend trying to meet the needs that your product or enhancement would
fulfill. Review major industry trends and technologies. Answer these strategic questions:
• What is the reputation of your organization in these markets?
3.2 Stakeholder summary: List all the identified stakeholders. For each stakeholder type,
provide this information:
• Name: Name the stakeholder type.
• Role: Briefly describe the role this stakeholder type plays in the development effort.
3.3 User summary: List all the identified user types. For each user type, provide this
• Description: Briefly describe the relationship of this type of user to the system under
development.
3.4 User environment: Detail the working environment of the target user. Here are some
suggestions:
• How many people are involved in completing the task? Is this changing?
• How long is a task cycle? How much time do users spend in each activity? Is this changing?
• What unique environmental constraints affect the project? For example, do users require
mobile devices, work outdoors, or work during flights?
• Which system platforms are in use today? Are there future platforms planned?
• What other applications are in use? Does your application need to integrate with them?
In this section, you might include extracts from the business model to outline the task and
workers who are involved.
https://www.ibm.com/support/knowledgecenter/SSWMEQ_4.0.6/com.ibm.rational.rrm.help.doc/topics/r_vision_doc.html 4/11
1/31/2020 Vision document
3.5 Stakeholder profiles: Describe each stakeholder in the project by completing the following
table for each stakeholder. Remember: Stakeholder types can be users, strategy departments,
legal or compliance departments, technical developers, operations teams, and others. A
thorough profile covers the following topics for each stakeholder type:
• Representative: State who represents the stakeholder to the project (This information is
optional if it is documented elsewhere.) Enter the representatives' names.
• Type: Qualify the expertise of the stakeholder, such as "guru," "business expert," , or
"casual user." This designation can suggest technical background and degree of
sophistication.
• Responsibilities: List the key responsibilities of the stakeholder on the system under
development; list their interests as a stakeholder.
• Success criteria: State how the stakeholder defines success. How is the stakeholder
rewarded?
• Involvement - Describe how the stakeholder is involved in the project. Where possible,
relate the involvement to the process roles; for example, a stakeholder might be a
• Deliverables: Identify additional deliverables that the stakeholder requires. These items
might be project deliverables or output from the system under development.
• Comments or issues: State problems that interfere with success and any other relevant
information.
3.6 User profiles: Describe each user of the system here by completing the following table for
each user type. Remember user types can be experts and novices; for example, an expert
might need a sophisticated, flexible tool with cross-platform support, while a novice might
need a tool that is easy to use. A thorough profile covers these topics for each type of user:
• Representative: State who represents the user to the project. (This information is optional
if it is documented elsewhere.) This representative often refers to the stakeholder who
represents a set of users; for example, Stakeholder: Stakeholder1.
• Type: Qualify the expertise of the user, such as "guru" or "casual user." This designation can
suggest technical background and degree of sophistication.
• Responsibilities: List the key user responsibilities with respect to the system; for example,
https://www.ibm.com/support/knowledgecenter/SSWMEQ_4.0.6/com.ibm.rational.rrm.help.doc/topics/r_vision_doc.html 5/11
1/31/2020 Vision document
state who captures customer details, produces reports, and coordinates work, and so on.
• Success criteria: State how the user defines success. How is the user rewarded?
• Involvement: Describe how the user is involved in the project. Where possible, relate the
involvement to process roles; for example, a stakeholder might be a requirements reviewer.
• Deliverables: Identify the deliverables that the user produces and for whom.
• Comments or issues: State problems that interfere with success and any other relevant
information. Describe trends that make the user's job easier or harder.
3.7 Key stakeholder or user needs: List the key problems with existing solutions as the
stakeholder perceives them. Clarify these issues for each problem:
• What are the reasons for this problem?
You must understand the relative importance that the stakeholder places on solving each
problem. Ranking and cumulative voting techniques help indicate the problems that must be
solved versus issues that stakeholders would like to be addressed. Use this table to capture
3.8 Alternatives and competition: Identify alternatives that the stakeholder perceives as
available. These alternatives can include buying a competitor's product, building a homegrown
solution, or maintaining the status quo. List any known and available competitive choices.
Include the major strengths and weaknesses of each competitor as the stakeholder perceives
them.
4: Product overview
This section provides a high-level view of the product capabilities, interfaces to other
applications, and systems configurations. This section typically consists of three subsections:
• Product perspective
• Product functions
https://www.ibm.com/support/knowledgecenter/SSWMEQ_4.0.6/com.ibm.rational.rrm.help.doc/topics/r_vision_doc.html 6/11
1/31/2020 Vision document
4.1 Product perspective: Put the product in perspective with regards to other related products
and the user's environment. If the product is independent and completely self-contained, state
it here. If the product is a component of a larger system, relate how these systems interact and
identify the relevant interfaces between the systems. One way to display the major
components of the larger system, interconnections, and external interfaces is to use a business
process or use-case diagram.
4.2 Summary of capabilities: Summarize the major benefits and features that the product will
provide. For example, a customer support system might use this part to address problem
documentation, routing, and status reporting without elaborating on detail that these functions
require. Organize the functions so that the list is understandable to the customer or to anyone
else who reads the document for the first time. A simple table that lists the key benefits and
their supporting features might suffice, as in the following example.
Table 2. Benefits and features example
New support staff can quickly A knowledge base assists support personnel in quickly
Management can identify Trend and distribution reports enable a high-level review
problem areas and gauge staff of problem status.
workload.
Distributed support teams can With a replication server, current database information
work together to solve problems. can be shared throughout the enterprise.
Customers can help themselves, A knowledge base can be made available over the
lowering support costs and Internet. The knowledge base includes hypertext search
improving response time. capabilities and a graphical query engine.
4.3 Assumptions and dependencies: List each of factor that affects the features that the
vision document includes. List assumptions that, if changed, will alter the vision document. For
example, an assumption might state that a specific operating system will be available for the
designated hardware for the software product If the operating system is not available the
https://www.ibm.com/support/knowledgecenter/SSWMEQ_4.0.6/com.ibm.rational.rrm.help.doc/topics/r_vision_doc.html 7/11
1/31/2020 Vision document
designated hardware for the software product. If the operating system is not available, the
vision document will require change.
4.4 Cost and pricing: Record relevant cost and pricing impacts and constraints. For example,
distribution costs (the number of CDs and CD mastering) or other cost-of-goods-sold
constraints (manuals and packaging) might be material or irrelevant to project success,
depending on the nature of the application.
4.5 Licensing and installation: Licensing and installation issues can also directly affect the
development effort. For example, the need to support serializing, password security, or
network licensing will create additional system requirements that must be considered in the
development effort. Installation requirements might also affect coding, or create the need for
separate installation software.
5: Product features
List and briefly describe the product features. Features are the high-level capabilities of the
system that are required to deliver benefits to the users. Each feature is a requested service
that typically requires a series of inputs to achieve a satisfactory result. For example, a feature
of a problem-tracking system might be the ability to provide trending reports. As the use-case
Because the vision document is reviewed by a wide variety of involved personnel, keep the
level of detail general enough for everyone to understand. However, offer sufficient detail to
provide the team with the information it needs to create a use-case model or other design
documents.
To manage application complexity, for a new system or an incremental change, list capabilities
at such a high level that you include approximately 25-99 features. These features provide the
basis for product definition, scope management, and project management. Each feature will be
expanded into greater detail in the use-case model.
Throughout this section, make each feature relevant to users, operators, or other external
systems. Include a description of functions and usability issues that must be addressed. The
following guidelines apply:
• Avoid design. Keep feature descriptions at a general level. Focus on required capabilities
and why (not how) they should be implemented.
• Designate all features as requirements of a specific feature type for easy reference and
tracking.
https://www.ibm.com/support/knowledgecenter/SSWMEQ_4.0.6/com.ibm.rational.rrm.help.doc/topics/r_vision_doc.html 8/11
1/31/2020 Vision document
5.1 Feature 1.
5.2 Feature 2.
6:Constraints
Note any design constraints, external constraints, such as operational or regulatory
requirements, or other dependencies.
7: Quality ranges
Define the quality ranges for performance, robustness, fault tolerance, usability, and similar
characteristics that the feature set does not describe.
9.1 Applicable standards: List all standards that the product must comply with. The list can
include these standards:
• Legal and regulatory standards (FDA, UCC)
9.2 System requirements: Define the system requirements for the application. These can
include the supported host operating systems and network platforms, configurations, memory,
peripheral devices, and companion software.
Status Description
https://www.ibm.com/support/knowledgecenter/SSWMEQ_4.0.6/com.ibm.rational.rrm.help.doc/topics/r_vision_doc.html 10/11
1/31/2020 Vision document
Proposed Describes features that are under discussion but have not been reviewed and
accepted by the "official channel " The official channel might be a working
Find a technical tutorial in IBM Developer Explore, learn and succeed with training on
the IBM Skills Gateway
English
https://www.ibm.com/support/knowledgecenter/SSWMEQ_4.0.6/com.ibm.rational.rrm.help.doc/topics/r_vision_doc.html 11/11