- Introducing stakeholders and users
- Involving stakeholders and users in your project
- Creating a shared vision
- Bringing it all together: The Vision Document
- Do you really need to do all of this?
Bringing it all together: The Vision Document
The Vision document is the Rational Unified Process artifact that captures all of the requirements information that we have been discussing in this chapter. As with all requirements documentation, its primary purpose is communication.
You write a Vision document to give the reader an overall understanding of the system to be developed by providing a self-contained overview of the system to be built and the motivations behind building it. To this end, it often contains extracts and summaries of other related artifacts, such as the business case and associated business models. It may also contain extracts from the system use-case model where this helps to provide a succinct and accessible overview of the system to be built.
The purpose of the Vision document is to capture the focus, stakeholder needs, goals and objectives, target markets, user environments, target platforms, and features of the product to be built. It communicates the fundamental "whys and whats" related to the project, and it is a gauge against which all future decisions should be validated.
The Vision document is the primary means of communication between the management, marketing, and project teams. It is read by all of the project stakeholders, including general managers, funding authorities, use-case modelers, and developers. It provides
A high-level (sometimes contractual) basis for the more detailed technical requirements
Input to the project-approval process (and therefore it is intimately related to the business case)
A vehicle for eliciting initial customer feedback
A means to establish the scope and priority of the product features
It is a document that gets "all parties working from the same book."
Because the Vision document is used and reviewed by a wide variety of involved personnel, the level of detail must be general enough for everyone to understand. However, enough detail must be available to provide the team with the information it needs to create a use-case model and supplementary specification.
The document contains the following sections:
Positioning: This section summarizes the business case for the product and the problem or opportunity that the product is intended to address. Typically, the following areas should be addressed:
The Business Opportunity: A summary of business opportunity being met by the product
The Problem Statement: A solution-neutral summary of the problem being solved focusing on the impact of the problem and the benefits required of any successful solution
Market Demographics: A summary of the market forces that drive the product decisions.
User Environment: The user environment where the product could be applied.
Stakeholders and Users: This section describes the stakeholders in, and users of, the product. The stakeholder roles and stakeholder types are defined in the project's Vision documentthe actual stakeholder representatives are identified as part of the project plan just like any other resources involved in the project.
Key Stakeholder and User Needs: This section describes the key needs that the stakeholders and users perceive the product should address. It does not describe their specific requests or their specific requirements, because these are captured in a separate stakeholder requests artifact. Instead, it provides the background and justification for why the requirements are needed.
Product Overview: This section provides a high-level view of the capabilities, assumptions, dependencies (including interfaces to other applications and system configurations), and alternatives to the development of the product.
Features: This section lists the features of the product. Features are the high-level capabilities (services or qualities) of the system that are necessary to deliver benefits to the users and satisfy the stakeholder and user needs. This is the most important, and consequently usually the longest, section of the Vision document.
Other Product Requirements: This section lists any other high-level requirements that cannot readily be captured as product features. These include any constraints placed on the development of the product and any requirements the planned product places on its operating environment.
In many cases, a lot more work is put into uncovering the business opportunity and understanding the market demographics related to the proposed product than is reflected in the Vision document. This work is usually captured in-depth in business cases, business models, and market research documents. These documents are then summarized in the Vision document to ensure that they are reflected in the ongoing evolution of the products specification.
We recommend that the Vision document be treated primarily as a report and that the stakeholder types, user types, stakeholder roles, needs, features, and other product requirements be managed using a requirements management tool. If the list of features is to be generated, it is recommended that they be presented in two sections:
Appendix B, Templates for Artifacts, contains a comprehensive Vision document template that contains a full definition of the structure and contents of a typical Rational Unified Process vision document. Appendix C, Case Study, contains a completed Vision document that complements the examples that appear within this chapter.