The Vision
defines the stakeholders view of the product to be developed, specified in
terms of the stakeholders key needs and features. Containing an outline of
the envisioned core requirements, it provides the
contractual basis for the more detailed technical requirements.
The Vision document provides a high-level-sometimes contractual-basis for
the more detailed technical requirements. There can also be a formal
requirements specification. The Vision captures very high-level requirements and
design constraints to give the reader an understanding of the system to be
developed. It provides input to the project-approval process and is, therefore,
intimately related to the Business Case. It communicates the fundamental
"whys and what's" related to the project and is a gauge against which
all future decisions should be validated.
The Vision document will be read by managers, stakeholders in
use-case modeling, and developers in general.
Timing
The Vision document is created early in the inception phase, and it is used
as a basis for the first draft of the Risk List (see Artifact:
Risk List).
The Vision document serves as input to use-case modeling, and is updated and
maintained as a separate artifact throughout the project.
Responsibility
An analyst is responsible for the
integrity of the Vision document, ensuring that:
The Vision document is updated and distributed.
Input from all concerned stakeholders is addressed.
Additional Information
A project vision is meant to be changeable as the understanding of
requirements, architecture, plans, and technology evolves. However, it should be
changing slowly and normally throughout the earlier portion of the lifecycle.
It is important to express the vision in terms of its use cases and primary
scenarios as these are developed, so that you can see how the vision is realized
by the use cases. The use cases also provide an effective basis for evolving a
test case suite.
The original author can be anybody, but when the project is established, the
Vision is the responsibility of the system analyst.
Another name used for this document is the Product Requirement Document.
Tailoring
Tailor as necessary for your project's needs. It is generally good practice
to keep the Vision brief in order to be able to release it to stakeholders as
soon as possible, and to make it easy for stakeholders to review and absorb.
This is done by including only the most important stakeholder requests and features,
and avoiding detailed requirements. Details may be captured in the other requirements
artifacts, or in appendices.
Decide whether feature attributes are documented here or in the Requirements
Management Plan. Decide what information (attributes) to include in the Vision,
and which to manage using requirements management tools.
Artifacts >
Requirements Artifact Set >
Vision
