Directions for using template:
Read the Guidance (Arial blue font in brackets) to understand the information that should be placed in each section of this template. Then delete the Guidance and replace the placeholder within <<Begin text here>> with your response. There may be additional Guidance in the Appendix of some documents, which should also be deleted once it has been used.
Some templates have four levels of headings. They are not indented, but can be differentiated by font type and size:
You may elect to indent sections for readability.
|
Author |
|
|
Author Position |
|
|
|
Version: 1.0
Ó 2002 Microsoft Corporation. All rights reserved.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft and Visual Basic are either registered trademarks or trademarks of Microsoft in the United States and/or other countries.
Change Record
|
Date |
Author |
Version |
Change Reference |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Reviewers
|
Name |
Version Approved |
Position |
Date |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Distribution
|
Name |
Position |
|
|
|
|
|
|
|
|
|
|
|
|
Document Properties
|
Item |
Details |
|
Document Title |
Vision/Scope |
|
Author |
|
|
Creation Date |
|
|
Last Updated |
|
TOC \o "1-3" \h \z
Goals, Objectives, Assumptions, and Constraints
Description: The Vision/Scope document represents the ideas and decisions developed during the envisioning phase. The goal of the phase, represented by the content of the documentation, is to achieve team and customer agreement on the desired solution and overall project direction.
The Vision/Scope document is organized into four main sections:
· Business Opportunity: a description of the customer’s situation and needs
· Solutions Concept: the approach the project team will take to meet the customer’s needs
· Scope: the boundary of the solution defined though the range of features and functions, what is out of scope, a release strategy, and the criteria by which the solution will be accepted by users and operations
· Solution Design Strategies: the architectural and technical designs used to create the customer’s solution
Justification: Vision/Scope documentation is usually written at the strategic level of detail and is used during the planning phase as the context for developing more detailed technical specifications and project management plans. It provides clear direction for the project team; outlines explicit, up-front discussion of project goals, priorities, and constraints; and sets customer expectations.
Team Role Primary: Product Management is the key driver of the envisioning phase and responsible for facilitating the team to the Vision/Scope approved milestone. Product Management defines the customer needs and business opportunity or problem addressed by the solution.
Team Role Secondary: Program Management is responsible for articulating the Solution Concept, Goals, Objectives, Assumptions, Constraints, Scope, and Solution Design Strategies sections of this document.}]
[Description: The Business Opportunity section contains the statement of the customer’s situation. It is expressed in business language, not technical terms. This section should demonstrate Microsoft’s understanding of the customer’s current environment and its desired future state. This information is the overall context for the project.]
[Description: The Opportunity Statement section describes the customer’s current situation that creates the need for the project. It may contain a statement of the customer’s opportunity and the impact of capitalizing on that opportunity (product innovation, revenue enhancement, cost avoidance, operational streamlining, leveraging knowledge). It may contain a statement of the customer’s problem and the impact of solving the problem (revenue protection, cost reduction, regulatory compliance, alignment of strategy and technology). It should include a statement that connects the customer’s opportunity/problem to the relevant business strategy and drivers. The Opportunity Statement is written concisely using a business executive’s voice.
Justification: The Opportunity Statement demonstrates that Microsoft understands the customer’s situation from the business point of view and provides the project team and other readers with the strategic context for the remaining sections.]
<<Begin text here>>
[Description: The Vision Statement section clearly and concisely describes the future desired state of the customer’s environment once the project is complete. This can be a restatement of the opportunity; however, it is written as if the future state has already been achieved. This statement provides a context for decision-making. It should be motivational to the project team and the customer.
Justification: A shared Vision Statement among all team members helps ensure that the solution meets the intended goals. A solid vision builds trust and cohesion among team members, clarifies perspective, improves focus, and facilitates decision-making.]
<<Begin text here>>
[Description: The Benefits Analysis section describes how the customer will derive value from the proposed solution. It connects the business goals and objectives to the specific performance expectations realized from the project. These performance expectations should be expressed numerically. This section could be presented using the following subsections:
· Business Goals and Objectives
· Business Metrics
· Business Assumptions and Constraints
· Benefits Statement
Justification: Benefits Analysis demonstrates that Microsoft sufficiently understands the customer’s situation. It also defines the customer’s business needs, which may provide vital information for making solution/technology recommendations.]
<<Begin text here>>
[Description: A Solutions Concept provides a general description of the technical approach the project team will take to meet the customer’s needs. This includes an understanding of the users and their needs, the solution’s features and functions, acceptance criteria, and the architectural and technical design approaches.
Justification: The Solution Concept provides teams with limited but sufficient detail to prove the solution to be complete and correct; to perform several types of analyses including feasibility studies, risk analysis, usability studies, and performance analysis; and to communicate the proposed solution to the customer and other key stakeholders.]
[Description: The Goals, Objectives, Assumptions, and Constraints section contains the following components that define the product’s parameters:
The solution Goals and Objectives are initially derived from the business and technical goals and objectives that are developed during the opportunity phase and confirmed during the envisioning phase.
Assumptions and Constraints may be derived from the product’s functionality, as well as research regarding the customer’s environment.
Justification: The Goals and Objectives articulate both the customer’s and team’s expectations of the solution and can be converted into performance measurements. Assumptions attempt to create explicit information from implicit issues and to point out where factual data is unavailable. Constraints place limits on the creation of boundaries and decision-making.]
<<Begin text here>>
[Description: The Usage Analysis section lists and defines the solution’s users and their important characteristics. It also describes how the users will interact with the solution. This information forms the basis for developing requirements.]
[Description: The User Profile describes the proposed solution’s users and their important characteristics. The users are identified in groups — usually stated in terms of their functional areas. Often users are from both the IT (help desk, database administration, etc.) and business (accounting, warehouse, procurement, etc.) areas of the customer’s organization. The important characteristics identify what the users are doing that the solution will facilitate. These characteristics can be expressed in terms of activities: for example, the accounting user receives invoices and makes payments to suppliers.
This section should contain a level of user profile information that enables the identification of unique requirements.
Justification: Initially, User Profiles enable the development of usage scenarios (next section). Beyond that, User Profiles provide the project teams with vital requirements information. A complete set of User Profiles ensures that all high-level requirements can be identified. The product team uses these profiles as input when developing the Feature/Function List. The development team uses these profiles as input to its architecture and technology design strategies. The user education team uses these profiles to establish the breadth of their work.]
<<Begin text here>>
[Description: Usage Scenarios define the sequences of activities the users perform within the proposed solutions environment. This information is comprised of a set of key events that will occur within the users’ environment. These events should be described by their objectives, key activities and their sequences, and the expected results.
Justification: Usage Scenarios provide vital information to identify and define the solution’s user and organizational requirements, the look and feel of user interfaces, and the performance users expect of the solution.]
<<Begin text here>>
[Description: Requirements identify what the solution must do. These Requirements can be expressed in terms of functionality (for example, a registration Web site solution will allow the users to register for events, arrange for lodging, etc.) as well as the rules or parameters that apply to that functionality (for example, the user can only register once, and must stay in lodging approved by the travel department).
Requirements exist at both the user level and the organizational level.
Justification: User and Organizational Requirements are the key input to developing product scope and design strategies. Requirements are the bridge between the usage analysis and solution description. A complete statement of Requirements demonstrates that Microsoft understands its customer’s needs. The statement also becomes the baseline for more detailed technical documentation in the planning phase. Good Requirements analysis lowers the risk of downstream surprises.]
<<Begin text here>>
<<Begin text here>>
<<Begin text here>>
<<Begin text here>>
[Description: The Scope places a boundary around the solution by detailing the range of features and functions, by defining what is out of scope, and by discussing the criteria by which the solution will be accepted by users and operations. The Scope clearly delineates what stakeholders expect the solution to do, thus making it a basis for defining project scope and for performing many types of project and operations planning.]
[Description: The Feature/Function List section contains an expression of the solution stated in terms of Features and Functions. It identifies and defines the components required to satisfy the customer’s requirements.
Justification: The Feature/Function List enables the customer and project team to understand what the project will develop and deliver into the customer’s environment. It is also the input to the Architectural and Technical Design Strategies.]
<<Begin text here>>
[Description: The Out of Scope section lists and defines a limited set of features and functions excluded from a product or solution —that is, the features and functions that fall outside its boundaries. It does not list everything that is Out of Scope; it only lists and defines features and functions that some users and other stakeholders might typically associate with a type of solution or product.
Justification: Out of Scope documentation helps to clarify the solution scope and explicitly states what will not be delivered in the solution.]
<<Begin text here>>
[Description: The Version Release Strategy section describes the strategy by which the project will deliver incremental sets of features and functions of the customer’s solution in a series of releases that build upon each other to completion.
Justification: The Version Release Strategy enables the customer to plan for the orderly implementation of the solution, including the acquisition of the required infrastructure to support the solution. It also describes how Microsoft will provide the customer with a usable set of functions and features as soon as possible.]
<<Begin text here>>
[Description: Acceptance Criteria define the metrics that must be met in order for the customer to understand that the solution meets its requirements.
Justification: Acceptance Criteria communicate to the project team the terms and conditions under which the customer will accept the solution.]
<<Begin text here>>
[Description: Operational Criteria define the conditions and circumstance by which the customer’s operations team judges the solution ready to deploy into the production environment. Once deployed, the customer takes ownership of the solution. This section may specify the customer’s requirements for installing the solution, training operators, diagnosing and managing incidents, and so on.
Justification: Operational Criteria communicate to the project team the terms and conditions under which the customer will allow deployment and ultimately sign off on the project. This information provides a framework for planning the solution’s deployment.]
<<Begin text here>>
[Description: The Architectural Design Strategy describes how the features and functions will operate together to form the solution. It identifies the specific components of the solution and their relationships. A diagram illustrating these components and relationships is an excellent communication device.
Justification: The Architectural Design Strategy converts the list of features and functions into the description of a fully functional, integrated environment. This information enables the customer to visualize the solution in its environment. It may drive the selection of specific technologies. The Architectural Design Strategy is key input to the design specification.]
<<Begin text here>>
[Description: The Technical Design Strategy documents the application of specific technologies to the Architectural Design. It is a high-level description of the key products and technologies to be used in developing the solution.
Justification: A Technical Design Strategy identifies the specific Microsoft technologies that will be applied to the solution and demonstrates their benefits to the client.]
<<Begin text here>>