Appendix B

Managing Software Requi= rements; Second Edition - A Use Case Approach - Appendix B – Vision Document T= emplate

Note: The publisher has gra= nted permission for readers of the book to use this electronic template in their= projects. The following permission must be included in any electronic reproduction:

Leffingwell/Widrig, MANAGING SOFTWA= RE REQUIREMENTS 2E, C 2003 Pearson
Education, Inc. Reproduced by permission of Pearson Education, Inc. Publishing as Pearson Addison Wesley. ALL RIGHTS RESERVED.

Fund= amental to the success of a project is a Vision document that identifies and organizes the high-level user needs and features of an application. Th= is document is updated as needed and shared among team members and other invol= ved personnel. The document template in this appendix is intended to be used as= a starting point and may be customized according to your organization’s needs.

Company Name

Project Name
Vision Document

Revision History

= Date	= Revision	= Description	= Author
mm/dd/yy	1= .0	I= nitial version	A= uthor name
<= o:p>	<= o:p>	<= o:p>	=
<= o:p>	<= o:p>	<= o:p>	=

Table of Contents

1 &nbs= p; Introduction

This section should provide an overview of the entire Vision docum= ent 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 ne= eds 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 application, its version, and new features for delivery.= 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 application 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), dat= e, and publishing organization

· = Specify the sources from which the references can be obtained =

This infor= mation 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 intend= ed users of the application and the key problems that limit the user’s productivity. This section should n= ot be used to state specific requirements. Instead, provide the background and the justification for why the features specified in Section 5 are needed. <= /p>

2.1 User/Market Demographic= s

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

· = What is your organization’s reputation in these markets?

· = What would you like = it to be?

· = How does this produc= t or service support your goals?

2.2 User Profiles

Describe each unique user of the system here. User types can be as divergent as guru= s 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 changi= ng?

· = How long is a task cycle? How much time is spent in each activ= ity? 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 u= ser would like addressed.

2.5 Alternati= ves 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 weaknes= ses of each competitor as perceived by the end user.

2.5.1 Competitor 1

2.5.2 Competitor 2

3 &nb= sp; Product Overview

This section provides a high-level view of the produ= ct 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 oth= er 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 syste= ms 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 lev= el, 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)<= o:p>
Who	(statement of the = need or opportunity)
The (product name)=	is a (product cate= gory)
That	(statement of key = benefit, that is, compelling reason to buy)
Unlike	(primary competiti= ve alternative)
Our product	(statement of prim= ary 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 funct= ions 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 sys= tem 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 (number of diskettes and CD-ROMs, CD mastering) or other cost-of-goods-sold constraints (manuals, packaging) may be material to the project’s suc= cess or irrelevant, depending on the nature of the application.

4 &= nbsp; Feature Attributes

As with requirements, 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 review= ed 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 mem= bers of the development team. Priorities are used in managing scope and determin= ing development priority. One possible prioritization scheme follows.

· = Critical: Essent= ial 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. L= ack of inclusion of an important feature may affect customer or user satis= faction or even revenue, but release will not be delayed due to lack of any importa= nt feature.

·= ; = Useful: Features= that are useful in less typical applications, will be used less frequently, or f= or which reasonably efficient workarounds can be achieved. No significant reve= nue or customer satisfaction impact can be expected if such an item is not incl= uded 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 t= he 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 probabil= ity that the project will experience undesirable events, such as cost overruns, schedule delays, or even cancellation. Most project managers find categoriz= ing 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, bas= ed 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 com= bined with the status field, your team can propose, record, and discuss various features of the release without committing them to development. Only featur= es whose status is set to Incorporated and whose target release is defined wil= l 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 featu= re. 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 mark= er 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. Ea= ch feature provides a service that fulfills a user need. For example, a featur= e 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 invol= ved personnel and serves as the basis of agreement, features should be expresse= d 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 use= rs, 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, per= haps those that are architecturally significant or those that will most rea= dily help the reader understand how the system is intended to be used. In a= ny event, all use cases will be found in the use-case model.

Note: The following se= ctions contain some of the identified primary nonfunctional requirements for the system. These will typically be elaborated in the supplementary specificati= on (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 (F= DA, 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, configu= rations, 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 Requirement= s

Performance issues can include such items as user load factors, bandwidth or communicat= ion 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, le= vel 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 aspec= ts 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-f= ront scope management and planning activity.

8.3 Installation Guides, Configuration, Read Me File

A document that includes installation instructions and configuration guidelin= es 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 iss= ues 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, spl= ash 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 a= nd other graphic elements, and so on.

9 Glossary

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

&nb= sp;