UML 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®).
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.
|