 |
| This artifact defines the stakeholders view of the product to be developed, specified in terms of the stakeholders key needs and features. It contains an outline of the envisioned core requirements, so it provides a contractual basis for the more detailed technical requirements. |
|
Purpose
|
This artifact provides a high-level, sometimes contractual, basis for the more detailed technical requirements
that are visible to the stakeholders. It captures the "essence" of the envisaged solution in the form of high-level
requirements and design constraints that give the reader an overview of the system to be developed from a behavioral
requirements perspective. It provides input to the project-approval process and is, therefore, closely related to the
Artifact: Business Case. It communicates the fundamental "why and
what" for the project and is a gauge against which all future decisions should be validated.
Another name used for this artifact is the Product Requirement Document.
|
Relationships
| Roles | Responsible:
| Modified By:
|
| Input To | Mandatory:
| Optional:
| External:
|
| Output From |
|
Description
| Brief Outline |
The vision document is written from the customers' perspective, focusing on the essential features of the system and
acceptable levels of quality. The Vision should include a description of what features will be
included as well as those considered but not included. It should also
specify operational capacities (volumes, response times, accuracies), user profiles (who will be using the system), and
inter-operational interfaces with entities outside the system boundary, where applicable.
|
| Main Description | The Vision document provides a complete vision for the software system under development and supports the contract between
the funding authority and the development organization. Every project needs a
source for capturing the expectations among stakeholders. |
Properties
| Optional |  |
| Planned |  |
Illustrations
Tailoring
| Representation Options |
Tailor this artifact as necessary for your project's needs. It is generally good practice to keep this artifact
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.
It is important to express this artifact in terms of its Use Cases and
primary scenarios as these are developed, so that you can see how this artifact is realized by the use cases. |
More Information
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
|
|
