Artifact: Subsystem Vision
This is essentially the Vision at one level down. It has to be a different artifact because it has a different responsible role. Otherwise, it has the same purpose and content: it becomes the Vision for the application of RUP to the development of the subsystem.
Domain:  Systems Engineering
Work Product Kinds:  Specification
Purpose

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 behavior and capabilities of the system to be developed, and the justification and rationale for change. It provides input to the project-approval process and is, therefore, intimately related to the Business Case. It communicates the fundamental "why and what" related to the project and is a gauge against which all future decisions need to be validated.

Managers, funding authorities, analysts, engineers, and developers in general read the Vision document..

Relationships
Tailoring
Representation OptionsUML Representation:

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, features and operational scenarios, and avoiding detailed requirements. Details can 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, such as Rational RequisitePro (see Tool Mentor: Developing a Vision using Rational RequisitePro®).

Additional Information

The project vision is meant to be changeable as the understanding of requirements, architecture, plans, and technology evolves. However, it must change slowly and normally only during the earlier portion of the lifecycle. If the vision remains volatile, it is difficult to stabilize the architecture and difficult to make good schedule predictions.

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 embryonic vision is developed outside the project, so the original author could be anyone; once the project is established, however, the vision becomes the responsibility of the System Analyst.

Another name for this document is the "Product Requirement Document."

In the system engineering context, the Vision also fulfills the role of the operational concept document.