Table of Contents

1 Introduction

This section should provide an overview of the document and should contain the following subsections.

1.1 Purpose of the Vision Document

This document collects, analyzes, and defines high-level user needs and product features. Focus on capabilities needed by the target users and why these needs exist. The specific requirements of how the application fulfills these needs should be provided elsewhere in the use-case model and supplementary specification.

1.2 Product Overview

State the purpose of the product, its version, and intended use. This subsection should

• Identify the product or application to be created or enhanced

• Provide a general description of what the product will and, if necessary, will not do

• Describe the intended use of the product, including its relevant benefits, goals, and objectives

1.3 References

This subsection should

• Provide a list of all documents referenced elsewhere in the Vision document

• Identify each document by title, report number (if applicable ), date, and publishing organization

• Specify the sources from which the references can be obtained

• This information may be provided by reference to an appendix or to another document.

2 User Description

To effectively provide products and services that meet your customers' needs, it is necessary to understand the challenges they confront when performing their jobs. This section should profile the intended users of the application and the key problems that limit the user's productivity. This section should not be used to state specific requirements . Instead, provide the background and the justification for why the features specified in Section 5 are needed.

2.1 User/Market Demographics

Summarize the key market demographics that motivate your product decisions. Describe and position target-market segments. Estimate the market's size and growth by using the number of potential users or the amount of money your customers spend trying to meet needs that your product/enhancement would fulfill. Review major industry trends and technologies. Answer these strategic questions.

• What is your organization's position in these markets?

• What would you like it to be?

• How does this product or service support your goals?

2.2 User Profiles

Describe each unique user of the system. User types can be as divergent as gurus and novices. For example, a guru might need a sophisticated, flexible tool with cross-platform support, whereas a novice might need an easy-to-use and user-friendly tool. A thorough profile should cover the following topics for each type of user:

• Technical background and degree of sophistication

• Key responsibilities

• Deliverables the user produces and for whom

• Trends that make the user's job easier or more difficult

• Problems that interfere with success

• The target user's definition of success and how the user is rewarded

2.3 User Environment

Detail the working environment of the target user. Here are some suggestions.

• How many people are involved in completing the task? Is this changing?

• How long is a task cycle? How much time is spent in each activity? Is this changing?

• Are there any unique environmental constraints: mobile, outdoors, in-flight, and so on?

• Which system platforms are in use today? Future platforms?

• What other applications are in use? Does your application need to integrate with them?

2.4 Key User Needs

List the key problems or needs as perceived by the user. Clarify the following issues for each problem.

• What are the reasons for this problem?

• How is it solved now?

• What solutions does the user envision?

It is important to understand the relative importance the user places on solving each problem. Ranking and cumulative-voting techniques indicate problems that must be solved versus issues the user would like addressed.

2.5 Alternatives and Competition

Identify alternatives the user perceives as available. These can include buying a competitor's product, building a homegrown solution, or simply maintaining the status quo. List any known competitive choices that exist or that may become available. Include the major strengths and weaknesses of each competitor as perceived by the end user.

2.5.1 Competitor 1

2.5.2 Competitor 2

3 Product Overview

This section provides a high-level view of the product capabilities, interfaces to other applications, and systems configurations. This section usually consists of three subsections, as follows .

3.1 Product Perspective

This subsection should put the product in perspective to other related products and the user's environment. If the product is independent and totally self-contained, state so here. If the product is a component of a larger system, this subsection should relate how these systems interact and should identify the relevant interfaces among the systems. One easy way to display the major components of the larger system, interconnections, and external interfaces is via a block diagram.

3.2 Product Position Statement

Provide an overall statement summarizing, at the highest level, the unique position the product intends to fill in the marketplace . Moore [1991] calls this the product position statement and recommends the following format.

For	(target customer)
Who	(statement of the need or opportunity)
The (product name )	is a (product category)
That	(statement of key benefit, that is, compelling reason to buy)
Unlike	(primary competitive alternative)
Our product	(statement of primary differentiation)

A product position statement communicates the intent of the application and the importance of the project to all concerned personnel.

3.3 Summary of Capabilities

Summarize the major benefits and features the product will provide. For example, a Vision document for a customer support system may use this subsection to address problem documentation, routing, and status reporting ”without mentioning the amount of detail each of these functions requires.

Organize the features so that the list is understandable to the customer or to anyone else reading the document for the first time. A simple table listing the key benefits and their supporting features might suffice.

Customer Support System

Customer Benefit	Supporting Features
Benefit 1	Feature 1

3.4 Assumptions and Dependencies

List assumptions that, if changed, will alter the vision for the product. For example, an assumption may state that a specific operating system will be available for the hardware designated for the software product. If the operating system is not available, the vision will need to change.

3.5 Cost and Pricing

For products sold to external customers and for many in-house applications, cost and pricing issues can directly impact the application's definition and implementation. In this section, record any relevant cost and pricing constraints. For example, distribution costs (CD-ROMs, CD mastering) or other cost-of-goods-sold constraints (manuals, packaging) may be material to the project's success or irrelevant, depending on the nature of the application.

4 Feature Attributes

Features have attributes that provide additional project information that can be used to evaluate, track, prioritize, and manage the product items proposed for implementation. This section provides suggested attributes for use in your Vision document. This section need describe only the attributes you've chosen and their meaning, so all parties can better understand the context of each feature.

4.1 Status

The status is set after negotiation and review by the project management team. Status information tracks progress during definition of the project baseline.

• Proposed : Used to describe features that are under discussion but have not yet been reviewed and accepted by the "official channel," such as a working group consisting of representatives from the project team, product management, and user or customer community

• Approved : Capabilities that are deemed useful and feasible and have been approved by the official channel for implementation

• Incorporated : Features incorporated into the product baseline at a specific time

4.2 Priority

Product priorities (benefits) are set by the marketing team, the product manager, or the business analyst. Ranking features by their relative priority to the end user opens a dialogue with customers, analysts, and members of the development team. Priorities are used in managing scope and determining development priority. One possible prioritization scheme follows.

• Critical : Essential features. Failure to implement means that the system will not meet customer needs. All critical features must be implemented in the release, or the schedule will slip.

• Important : Features important to the effectiveness and efficiency of the system for most applications. The functionality cannot be easily provided in another way. Lack of inclusion of an important feature may affect customer or user satisfaction or even revenue, but release will not be delayed due to lack of any important feature.

• Useful : Features that are useful in less typical applications, will be used less frequently, or for which reasonably efficient workarounds can be achieved. No significant revenue loss or customer satisfaction impact can be expected if such an item is not included in a release.

4.3 Effort

The level of effort is set by the development team and used in managing scope and determining development priority. Because some features require more time and resources than others, estimating the number of team- or person-weeks, lines of code required, or function points, for example, is the best way to gauge complexity and to set expectations of what can and cannot be accomplished in a given time frame.

4.4 Risk

The development team sets the level of risk, based on the probability that the project will experience undesirable events, such as cost overruns, schedule delays, or even cancellation. Most project managers find categorizing risks as High, Medium , and Low sufficient, although finer gradations are possible. Risk can often be assessed indirectly by measuring the uncertainty (range) of the project team's schedule estimate.

4.5 Stability

The analyst and development team sets the stability attribute, based on the probability that the feature will change or the team's understanding of the feature will change. This information is used to help establish development priorities and to determine those items for which additional elicitation is the appropriate next action.

4.6 Target Release

The target release attribute records the intended product version in which the feature will first appear. This field can be used to allocate features into a particular baseline release. When the target release is combined with the status field, your team can propose, record, and discuss various features of the release without committing them to development. Only features whose status is set to Incorporated and whose target release is defined will be implemented. When scope management occurs, the target release version number can be increased so the item will remain in the Vision document but will be scheduled for a later release.

4.7 Assigned To

In many projects, features will be assigned to "feature teams " responsible for further elicitation, writing the software requirements, and implementation. This simple list will help everyone on the project team better understand responsibilities.

4.8 Reason

This text field is used to track the source of the requested feature. Features exist for specific reasons. This field records an explanation or a reference to an explanation. For example, the reference might be to a page and line number of a product requirement specification, or to a minute marker on a video of an important customer interview.

5 Product Features

This section documents the product features. Features provide the system capabilities that are necessary to deliver benefits to the users. Each feature provides a service that fulfills a user need. For example, a feature of a problem-tracking system might be the ability to "provide trending reports." Trending reports might, in turn , support a user need to "better understand the status of my project."

Because the Vision document is reviewed by a wide variety of involved personnel and serves as the basis of agreement, features should be expressed in the user's natural language. Features descriptions should be short and pithy, typically one or two sentences.

To effectively manage application complexity, we recommend that for any new system or increment to an existing system the capabilities be abstracted to a high enough level to result in 25 “50 features. These features provide the fundamental basis for product definition, scope management, and project management. Each feature will be expanded in greater detail in the follow-on specifications.

Throughout this section, each feature should be perceivable by users, operators, or other external systems.

5.1 Feature 1

5.2 Feature 2

6 Exemplary Use Cases

[Optional] You may wish to describe a few exemplary use cases, perhaps those that are architecturally significant or those that will most readily help the reader understand how the system is intended to be used. In any event, all use cases will be found in the use-case model.

Note

The following sections contain some of the identified primary nonfunctional requirements for the system. These will typically be elaborated in the supplementary specification (template provided in Appendix D) later in the development cycle. Once the supplementary specification has been developed, you may wish to delete these sections from the Vision document so that these items are not maintained in two places.

However, new nonfunctional requirements may often be recorded here in the Delta Vision document format.

7 Other Product Requirements

7.1 Applicable Standards

List all standards the product must comply with, such as legal and regulatory (FDA, FCC), communications standards (TCP/IP, ISDN), platform compliance standards (Windows, UNIX), and quality and safety standards (UL, ISO, CMM).

7.2 System Requirements

Define any system requirements necessary to support the application. These may include the supported host operating systems and network platforms, configurations, memory, peripherals, and companion software.

7.3 Licensing, Security, and Installation

Licensing, security, and installation issues can also directly impact the development effort. For example, the need to support restrictions on use, trial or evaluation usage, copy protection, right to create a backup, and provisions for individual or concurrent user licensing will create additional system requirements that must be considered in the development effort. Installation requirements may also affect coding or create the need for separate installation software.

7.4 Performance Requirements

Performance issues can include such items as user load factors, bandwidth or communication capacity, throughput, accuracy, reliability, or response times under a variety of loading conditions.

8 Documentation Requirements

This section describes the documentation that must be developed to support successful application deployment.

8.1 User Manual

Describe the purpose and contents of the user manual. Discuss its desired length, level of detail, need for index and glossary, tutorial versus reference manual strategy, and so on. Formatting and printing constraints should also be identified.

8.2 Online Help

Many applications provide an online help system to assist the user. The nature of these systems is unique to application development since they combine aspects of programming, such as hyperlinks , with aspects of technical writing, such as organization and presentation. Many people have found that the development of an online help system is a project within a project that benefits from up-front scope management and planning activity.

8.3 Installation Guides, Configuration, Read Me File

A document that includes installation instructions and configuration guidelines is important to a full solution. Also, a read me file is typically included as a standard component. The read me file may include a "What's New with This Release" section and a discussion of compatibility issues with earlier releases. Most users also appreciate documentation in the read me file defining any known bugs and workarounds.

8.4 Labeling and Packaging

Today's state-of-the-art applications provide a consistent look and feel that begins with product packaging and manifests itself through installation menus , splash screens, help systems, GUI dialogs, and so on. This section defines the needs and types of labeling to be incorporated into the code. Examples include copyright and patent notices, corporate logos, standardized icons and other graphic elements, and so on.

9 Glossary

The glossary defines all terms that are unique to the project. Include any acronyms or abbreviations that may not be understood by users or other readers of this document.