DOC

VisionScopevisionscope

By Howard Matthews,2014-11-25 10:28
7 views 0
VisionScopevisionscope

    VISION/SCOPE

    This 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 paragraphs written in the “Comment” style are for the benefit of the person writing the document and should be removed before the document is finalized.

    SEPTEMBER 2, 2009

    Revision Chart

This chart contains a history of this document’s revisions. The entries below are provided solely

    for purposes of illustration. Entries should be deleted until the revision they refer to has actually been created.

    The document itself should be stored in revision control, and a brief description of each version should be entered in the revision control system. That brief description can be repeated in this section.

    Version Primary Author(s) Description of Version Date

    Completed

    Draft TBD Initial draft created for distribution and TBD

    review comments

    Preliminary TBD Second draft incorporating initial review TBD

    comments, distributed for final review

    Final TBD First complete draft, which is placed TBD

    under change control

    Revision 1 TBD Revised draft, revised according to the TBD

    change control process and maintained

    under change control

    etc. TBD TBD TBD

Vision/Scope Project Name

    PREFACE

    The preface contains an introduction to the document. It is optional and can be deleted if desired. Introduction

    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. 730708441.doc (11/25/13) Page 1

Vision/Scope Project Name

    CONTENTS

    New paragraphs formatted as Heading 1, Heading 2, and Heading 3 will be added to the table

    automatically. To update this table of contents in Microsoft Word, put the cursor anywhere in the table and press F9. If you want the table to be easy to maintain, do not change it manually.

    1. INTRODUCTION ................................................................................................... 5

    1.1 PURPOSE .............................................................................................................. 5 1.2 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS ................................................... 5

    1.3 REFERENCES ........................................................................................................ 5 2. BUSINESS OPPORTUNITY .................................................................................... 6

    2.1 OPPORTUNITY STATEMENT ................................................................................... 6 2.2 VISION STATEMENT .............................................................................................. 6 2.3 BENEFITS ANALYSIS ............................................................................................. 6 3. SOLUTIONS CONCEPT ......................................................................................... 8

    3.1 GOALS, OBJECTIVES, ASSUMPTIONS, AND CONSTRAINTS ....................................... 8

    3.2 USAGE ANALYSIS ................................................................................................. 8

    3.2.1 User Profiles .......................................................................................................... 9

    3.2.2 Usage Scenarios ..................................................................................................... 9

    3.3 REQUIREMENTS .................................................................................................... 9

    3.3.1 Business Requirements ......................................................................................... 10

    3.3.2 User Requirements ............................................................................................... 10

    3.3.3 Operational Requirements .................................................................................... 10

    3.3.4 System Requirements ............................................................................................ 10

    4. SCOPE ............................................................................................................... 11

    4.1 FEATURE/FUNCTION LIST .................................................................................... 11 4.2 OUT OF SCOPE .................................................................................................... 11 4.3 VERSION RELEASE STRATEGY ............................................................................. 11 4.4 ACCEPTANCE CRITERIA ...................................................................................... 11 4.5 OPERATIONAL CRITERIA ..................................................................................... 12 5. SOLUTION DESIGN STRATEGIES ....................................................................... 13

    5.1 ARCHITECTURAL DESIGN STRATEGY ................................................................... 13 5.2 TECHNICAL DESIGN STRATEGY ........................................................................... 13 6. INDEX ................................................................................................................ 14

    7. APPENDICES ...................................................................................................... 15

    730708441.doc (11/25/13) Page 2

Vision/Scope Project Name

730708441.doc (11/25/13) Page 3

Vision/Scope Project Name

    LIST OF FIGURES

    New figures that are given captions using the Caption paragraph style will be added to the table automatically. To update this table of contents in Microsoft Word, put the cursor anywhere in the table and press F9. If you want the table to be easy to maintain, do not change it manually. This section can be deleted if the document contains no figures or if otherwise desired. Error! No table of figures entries found.

    730708441.doc (11/25/13) Page 4

Vision/Scope Project Name

    1. INTRODUCTION

    This section should provide an overview of the entire document. No text is necessary between the heading above and the heading below unless otherwise desired.

    1.1 Purpose

    Describe the purpose of this document and its intended audience.

    1.2 Definitions, Acronyms, and Abbreviations

    Provide definitions or references to all the definitions of the special terms, acronyms and abbreviations used within this document.

    1.3 References

    List all the documents and other materials referenced in this document. This section is like the bibliography in a published book.

    730708441.doc (11/25/13) Page 5

Vision/Scope Project Name

    2. BUSINESS OPPORTUNITY

    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 the team’s

    understanding of the customer’s current environment and its desired future state. This information is the overall context for the project.

    No text is necessary between the heading above and the heading below unless otherwise desired. 2.1 Opportunity Statement

    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.

    The Opportunity Statement demonstrates that the team 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.

    2.2 Vision Statement

    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.

    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.

    2.3 Benefits Analysis

    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

    730708441.doc (11/25/13) Page 6

Vision/Scope Project Name

    ; Benefits Statement

    Benefits Analysis demonstrates that the team sufficiently understands the customer’s situation. It also defines the customer’s business needs, which may provide vital information for making solution/technology recommendations.

    730708441.doc (11/25/13) Page 7

Vision/Scope Project Name

    3. SOLUTIONS CONCEPT

    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.

    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.

    No text is necessary between the heading above and the heading below unless otherwise desired. 3.1 Goals, Objectives, Assumptions, and Constraints

    The Goals, Objectives, Assumptions, and Constraints section contains the following components that define the product’s parameters:

    ; Goals (the product’s final purpose or aim)

    ; Objectives (the goals broken into measurable components)

    ; Assumptions (factors considered true, real, or certain that are awaiting validation)

    ; Constraints (a nonfunctional requirement that will limit the product).

    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.

    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.

    3.2 Usage Analysis

    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.

    No text is necessary between the heading above and the heading below unless otherwise desired. 730708441.doc (11/25/13) Page 8

Vision/Scope Project Name

    3.2.1 User Profiles

    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.

    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.

    3.2.2 Usage Scenarios

    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.

    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.

    3.3 Requirements

    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.

    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. No text is necessary between the heading above and the heading below unless otherwise desired. 730708441.doc (11/25/13) Page 9

Report this document

For any questions or suggestions please email
cust-service@docsford.com