<Company Name>

<Project Name>
Vision
Version <1.0>
[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square
bracets and displa!ed in blue italics "st!le#$nfo%lue& is included to provide guidance to the author and should be
deleted before publishing the document. ' paragraph entered following this st!le will automaticall! be set to normal
"st!le#%od! Text&.(
[To customi)e automatic fields in *icrosoft +ord "which displa! a gra! bacground when selected&, select
-ile.Properties and replace the Title, /ub0ect and 1ompan! fields with the appropriate information for this
document. 'fter closing the dialog, automatic fields ma! be updated throughout the document b! selecting
2dit./elect 'll "or 1trl3'& and pressing -4, or simpl! clic on the field and press -4. This must be done separatel!
for 5eaders and -ooters. 'lt3-4 will toggle between displa!ing the field names and the field contents. /ee +ord
help for more information on woring with fields.(
<Project Name>
Version: <1.0>
Vision Date: <dd/mmm/yy>
<document identifier>
Revision History
Date Version Description Author
<dd/mmm/yy> <x.x> <details> <name>
Confidential <Company Name>, 201 !a"e 2
<Project Name>
Version: <1.0>
Vision Date: <dd/mmm/yy>
<document identifier>
Table of Contents
1. #ntroduction
1.1 !urpose
1.2 $cope
1.% Definitions, &cronyms, and &''re(iations
1. )eferences
1.* +(er(ie,
2. !ositionin"
2.1 -usiness +pportunity
2.2 !ro'lem $tatement
2.% !roduct !osition $tatement
%. $ta.e/older and 0ser Descriptions
%.1 1ar.et Demo"rap/ics
%.2 $ta.e/older $ummary
%.% 0ser $ummary
%. 0ser 2n(ironment
%.* $ta.e/older !rofiles
%.*.1 <$ta.e/older Name> *
%.3 0ser !rofiles
%.3.1 <0ser Name> *
%.4 5ey $ta.e/older or 0ser Needs
%.6 &lternati(es and Competition
%.6.1 <aCompetitor> *
%.6.2 <anot/erCompetitor> *
. !roduct +(er(ie,
.1 !roduct !erspecti(e
.2 $ummary of Capa'ilities
.% &ssumptions and Dependencies
. Cost and !ricin"
.* 7icensin" and #nstallation
*. !roduct 8eatures
*.1 <a8eature>
*.2 <anot/er8eature>
3. Constraints
4. 9uality )an"es
6. !recedence and !riority
:. +t/er !roduct )e;uirements
:.1 &pplica'le $tandards
:.2 $ystem )e;uirements
:.% !erformance )e;uirements
Confidential <Company Name>, 201 !a"e %
<Project Name>
Version: <1.0>
Vision Date: <dd/mmm/yy>
<document identifier>
:. 2n(ironmental )e;uirements
10. Documentation )e;uirements
10.1 0ser 1anual
10.2 +nline <elp
10.% #nstallation =uides, Confi"uration, and )ead 1e 8ile
10. 7a'elin" and !ac.a"in"
& 8eature &ttri'utes
&.1 $tatus
&.2 -enefit
&.% 2ffort
&. )is.
&.* $ta'ility
&.3 >ar"et )elease
&.4 &ssi"ned >o
&.6 )eason
Confidential <Company Name>, 201 !a"e
<Project Name>
Version: <1.0>
Vision Date: <dd/mmm/yy>
<document identifier>
Vision
1. Intro!ction
[The purpose of this document is to collect, anal!)e, and define high3level needs and features of the <<$ystem
Name>>. $t focuses on the capabilities needed b! the staeholders and the target users, and why these needs exist.
The details of how the <<$ystem Name>> fulfills these needs are detailed in the use3case and supplementar!
specifications.(
[The introduction of the Vision document provides an overview of the entire document. $t includes the purpose,
scope, definitions, acron!ms, abbreviations, references, and overview of this Vision document.(
1.1 P!rpose
[/pecif! the purpose of this Vision document.(
1." #cope
[' brief description of the scope of this Vision document6 what Pro0ect"s& it is associated with and an!thing else that
is affected or influenced b! this document.(
1.$ %efinitions& 'cronyms& an 'bbreviations
[This subsection provides the definitions of all terms, acron!ms, and abbreviations required to properl! interpret the
Vision document. This information ma! be provided b! reference to the pro0ect7s 8lossar!.(
1.( References
[This subsection provides a complete list of all documents referenced elsewhere in the Vision document. $dentif!
each document b! title, report number if applicable, date, and publishing organi)ation. /pecif! the sources from
which the references can be obtained. This information ma! be provided b! reference to an appendix or to another
document.(
1.) *vervie+
[This subsection describes what the rest of the Vision document contains and explains how the document is
organi)ed.(
". Positionin,
".1 -!siness *pport!nity
[%riefl! describe the business opportunit! being met b! this pro0ect.(
"." Problem #tatement
[Provide a statement summari)ing the problem being solved b! this pro0ect. The following format ma! be used:(
>/e pro'lem of [describe the problem(
affects [the staeholders affected b! the problem(
t/e impact of ,/ic/ is [what is the impact of the problem9(
a successful solution ,ould 'e [list some e! benefits of a successful solution(
".$ Pro!ct Position #tatement
[Provide an overall statement summari)ing, at the highest level, the unique position the product intends to fill in the
maretplace. The following format ma! be used:(
Confidential <Company Name>, 201 !a"e *
<Project Name>
Version: <1.0>
Vision Date: <dd/mmm/yy>
<document identifier>
8or [target customer(
?/o [statement of the need or opportunit!(
>/e @product nameA is a [product categor!(
>/at [statement of e! benefit6 that is, the compelling reason to bu!(
0nli.e [primar! competitive alternative(
+ur product [statement of primar! differentiation(
[' product position statement communicates the intent of the application and the importance of the pro0ect to all
concerned personnel.(
$. #ta.e/oler an 0ser %escriptions
[To effectivel! provide products and services that meet !our staeholders7 and users: real needs, it is necessar! to
identif! and involve all of the staeholders as part of the Requirements *odeling process. ;ou must also identif! the
users of the s!stem and ensure that the staeholder communit! adequatel! represents them. This section provides a
profile of the staeholders and users involved in the pro0ect, and the e! problems that the! perceive to be addressed
b! the proposed solution. $t does not describe their specific requests or requirements as these are captured in a
separate staeholder requests artifact. $nstead, it provides the bacground and 0ustification for wh! the requirements
are needed.(
$.1 1ar.et %emo,rap/ics
[/ummari)e the e! maret demographics that motivate !our product decisions. <escribe and position target maret
segments. 2stimate the maret7s si)e and growth b! using the number of potential users or the amount of mone!
!our customers spend tr!ing to meet needs that !our product or enhancement would fulfill. Review ma0or industr!
trends and technologies. 'nswer these strategic questions:
= +hat is !our organi)ation7s reputation in these marets9
= +hat would !ou lie it to be9
= 5ow does this product or service support !our goals9(
$." #ta.e/oler #!mmary
[There are a number of staeholders with an interest in the development and not all of them are end users. Present a
summar! list of these non3user staeholders. "The users are summari)ed in section >.>.&(
Name Description Responsibilities
[Name the
staeholder t!pe.(
[%riefl! describe the
staeholder.(
[/ummari)e the staeholder7s e!
responsibilities with regard to the s!stem
being developed6 that is, their interest as a
staeholder. -or example, this staeholder:
B ensures that the s!stem will be
maintainable
B ensures that there will be a maret demand
for the product7s features
B monitors the pro0ect7s progress
B approves funding
B and so forth(
Confidential <Company Name>, 201 !a"e 3
<Project Name>
Version: <1.0>
Vision Date: <dd/mmm/yy>
<document identifier>
$.$ 0ser #!mmary
[Present a summar! list of all identified users.(
Name Description Responsibilities Stakeholder
[Name
the user
t!pe.(
[%riefl! describe
what the! represent
with respect to the
s!stem.(
[?ist the user7s e! responsibilities
with regard to the s!stem being
developed6 for example:
B captures details
B produces reports
B coordinates wor
B and so on(
[$f the user is not directl!
represented, identif! which
staeholder is responsible for
representing the user7s
interest.(
$.( 0ser 2nvironment
[<etail the woring environment of the target user. 5ere are some suggestions:
Number of people involved in completing the tas9 $s this changing9
5ow long is a tas c!cle9 'mount of time spent in each activit!9 $s this changing9
'n! unique environmental constraints: mobile, outdoors, in3flight, and so on9
+hich s!stems platforms are in use toda!9 -uture platforms9
+hat other applications are in use9 <oes !our application need to integrate with them9
This is where extracts from the %usiness *odel could be included to outline the tas and roles involved and so on.(
$.) #ta.e/oler Profiles
[<escribe each staeholder in the s!stem here b! filling in the following table for each staeholder. Remember that
staeholder t!pes can be as divergent as users, departments, and technical developers. ' thorough profile would
cover the following topics for each t!pe of staeholder.(
3.5.1 <Stakeholder Name>
Representative [+ho is the staeholder representative to the pro0ect9 "@ptional if documented
elsewhere.& +hat we want here is names.(
Description [' brief description of the staeholder t!pe.(
Type [Aualif! the staeholder7s expertise, technical bacground, and degree of
sophisticationBthat is, guru, business, expert, casual user, and so on.(
Responsibilities [?ist the staeholder7s e! responsibilities with regard to the s!stem being
developedBthat is, their interest as a staeholder.(
Success riteria [5ow does the staeholder define success9
5ow is the staeholder rewarded9(
!nvolvement [5ow is the staeholder involved in the pro0ect9 Relate where possible to Rational
Unified Process rolesBthat is, Requirements Reviewer and so on.(
Deliverables ['re there an! additional deliverables required b! the staeholder9 These could be
Confidential <Company Name>, 201 !a"e 4
<Project Name>
Version: <1.0>
Vision Date: <dd/mmm/yy>
<document identifier>
pro0ect deliverables or outputs from the s!stem under development.(
omments " !ssues [Problems that interfere with success and an! other relevant information go here.(
$.3 0ser Profiles
[<escribe each unique user of the s!stem here b! filling in the following table for each user t!pe. Remember user
t!pes can be as divergent as gurus and novices. -or example, a guru might need a sophisticated, flexible tool with
cross3platform support, while a novice might need a tool that is eas! to use and user3friendl!. ' thorough profile
needs to cover the following topics for each t!pe of user.(
3.6.1 <User Name>
Representative [+ho is the user representative to the pro0ect9 "@ptional if documented elsewhere.&
This often refers to the /taeholder that represents the set of users, for example,
/taeholder: /taeholderC.(
Description [' brief description of the user t!pe.(
Type [Aualif! the user7s expertise, technical bacground, and degree of sophisticationB
that is, guru, casual user, and so on.(
Responsibilities [?ist the user7s e! responsibilities with regard to the s!stem being developedB
that is, captures details, produces reports, coordinates wor, and so forth.(
Success riteria [5ow does the user define success9
5ow is the user rewarded9(
!nvolvement [5ow is the user involved in the pro0ect9 Relate where possible to Rational Unified
Process rolesBthat is, Requirements Reviewer, and so on.(
Deliverables ['re there an! deliverables the user produces and, if so, for whom9(
omments " !ssues [Problems that interfere with success and an! other relevant information go here.
These would include trends that mae the user7s 0ob easier or harder.(
$.4 5ey #ta.e/oler or 0ser Nees
[?ist the e! problems with existing solutions as perceived b! the staeholder or user. 1larif! the following issues
for each problem:
= +hat are the reasons for this problem9
= 5ow is it solved now9
= +hat solutions does the staeholder or user want9(
[$t is important to understand the relative importance the staeholder or user places on solving each problem.
Raning and cumulative voting techniques indicate problems that must be solved versus issues the! would lie
addressed.
-ill in the following tableBif using Rational RequisitePro to capture the Needs, this could be an extract or report
from that tool.(
Need Priority oncerns urrent Solution Proposed Solutions
Confidential <Company Name>, 201 !a"e 6
<Project Name>
Version: <1.0>
Vision Date: <dd/mmm/yy>
<document identifier>
-roadcast messa"es
$.6 'lternatives an Competition
[$dentif! alternatives the staeholder perceives as available. These can include bu!ing a competitor7s product,
building a homegrown solution or simpl! maintaining the status quo. ?ist an! nown competitive choices that exist
or ma! become available. $nclude the ma0or strengths and weanesses of each competitor as perceived b! the
staeholder or end user.(
3.8.1 <aCompetitor>
3.8.2 <anotherCompetitor>
(. Pro!ct *vervie+
[This section provides a high level view of the product capabilities, interfaces to other applications, and s!stem
configurations. This section usuall! consists of three subsections, as follows:
= Product perspective
= Product functions
= 'ssumptions and dependencies(
(.1 Pro!ct Perspective
[This subsection of the Vision document puts the product in perspective to other related products and the user7s
environment. $f the product is independent and totall! self3contained, state it here. $f the product is a component of a
larger s!stem, then this subsection needs to relate how these s!stems interact and needs to identif! the relevant
interfaces between the s!stems. @ne eas! wa! to displa! the ma0or components of the larger s!stem,
interconnections, and external interfaces is with a bloc diagram.(
(." #!mmary of Capabilities
[/ummari)e the ma0or benefits and features the product will provide. -or example, a Vision document for a
customer support s!stem ma! use this part to address problem documentation, routing, and status reporting without
mentioning the amount of detail each of these functions requires.
@rgani)e the functions so the list is understandable to the customer or to an!one else reading the document for the
first time. ' simple table listing the e! benefits and their supporting features might suffice. -or example:(
Confidential <Company Name>, 201 !a"e :
<Project Name>
Version: <1.0>
Vision Date: <dd/mmm/yy>
<document identifier>
Table #$% ustomer Support System
ustomer &ene'it Supportin( )eatures
Ne, support staff can ;uic.ly "et up
to speed.
5no,led"e 'ase assists support personnel
in ;uic.ly identifyin" .no,n fixes and
,or.arounds.
Customer satisfaction is impro(ed
'ecause not/in" falls t/rou"/ t/e
crac.s.
!ro'lems are uni;uely itemiCed, classified
and trac.ed t/rou"/out t/e resolution
process. &utomatic notification occurs for
any a"in" issues.
1ana"ement can identify pro'lem
areas and "au"e staff ,or.load.
>rend and distri'ution reports allo, /i"/
le(el re(ie, of pro'lem status.
Distri'uted support teams can ,or.
to"et/er to sol(e pro'lems.
)eplication ser(er allo,s current data'ase
information to 'e s/ared across t/e
enterprise.
Customers can /elp t/emsel(es,
lo,erin" support costs and impro(in"
response time.
5no,led"e 'ase can 'e made a(aila'le
o(er t/e #nternet. #ncludes /ypertext
searc/ capa'ilities and "rap/ical ;uery
en"ine.
(.$ 'ss!mptions an %epenencies
[?ist each of the factors that affect the features stated in the Vision document. ?ist assumptions that, if changed, will
alter the Vision document. -or example, an assumption ma! state that a specific operating s!stem will be available
for the hardware designated for the software product. $f the operating s!stem is not available, the Vision document
will need to change.(
(.( Cost an Pricin,
[-or products sold to external customers and for man! in3house applications, cost and pricing issues can directl!
impact the application7s definition and implementation. $n this section, record an! cost and pricing constraints that
are relevant. -or example, distribution costs, "D of disettes, D of 1<3R@*s, 1< mastering& or other cost of goods
sold constraints "manuals, pacaging& ma! be material to the pro0ects success, or irrelevant, depending on the
nature of the application.(
(.) 7icensin, an Installation
[?icensing and installation issues can also directl! impact the development effort. -or example, the need to support
seriali)ing, password securit! or networ licensing will create additional requirements of the s!stem that must be
considered in the development effort.
$nstallation requirements ma! also affect coding or create the need for separate installation software.(
). Pro!ct 8eat!res
[?ist and briefl! describe the product features. -eatures are the high3level capabilities of the s!stem that are
necessar! to deliver benefits to the users. 2ach feature is an externall! desired service that t!picall! requires a
series of inputs to achieve the desired result. -or example, a feature of a problem tracing s!stem might be the
abilit! to provide trending reports. 's the use3case model taes shape, update the description to refer to the use
cases.
%ecause the Vision document is reviewed b! a wide variet! of involved personnel, the level of detail needs to be
general enough for ever!one to understand. 5owever, enough detail must be available to provide the team with the
information the! need to create a use3case model.
To effectivel! manage application complexit!, we recommend for an! new s!stem, or an increment to an existing
s!stem, capabilities are abstracted to a high enough level so EF344 features result. These features provide the
Confidential <Company Name>, 201 !a"e 10
<Project Name>
Version: <1.0>
Vision Date: <dd/mmm/yy>
<document identifier>
fundamental basis for product definition, scope management, and pro0ect management. 2ach feature will be
expanded in greater detail in the use3case model.
Throughout this section, each feature will be externall! perceivable b! users, operators or other external s!stems.
These features need to include a description of functionalit! and an! relevant usabilit! issues that must be
addressed. The following guidelines appl!:
= 'void design. Geep feature descriptions at a general level. -ocus on capabilities needed and wh! "not how&
the! should be implemented.
= $f !ou are using the Rational RequisitePro toolit, all need to be selected as requirements of t!pe for eas!
reference and tracing.(
).1 <a8eat!re>
)." <anot/er8eat!re>
3. Constraints
[Note an! design constraints, external constraints or other dependencies.(
4. 9!ality Ran,es
[<efine the qualit! ranges for performance, robustness, fault tolerance, usabilit!, and similar characteristics that
are not captured in the -eature /et.(
6. Preceence an Priority
[<efine the priorit! of the different s!stem features.(
:. *t/er Pro!ct Re;!irements
['t a high level, list applicable standards, hardware or platform requirements, performance requirements, and
environmental requirements.(
:.1 'pplicable #tanars
[?ist all standards with which the product must compl!. These can include legal and regulator! "-<', U11&
communications standards "T1PH$P, $/<N&, platform compliance standards "+indows, UN$I, and so on&, and
qualit! and safet! standards "U?, $/@, 1**&.(
:." #ystem Re;!irements
[<efine an! s!stem requirements necessar! to support the application. These can include the supported host
operating s!stems and networ platforms, configurations, memor!, peripherals, and companion software.(
:.$ Performance Re;!irements
[Use this section to detail performance requirements. Performance issues can include such items as user load
factors, bandwidth or communication capacit!, throughput, accurac!, and reliabilit! or response times under a
variet! of loading conditions.(
:.( 2nvironmental Re;!irements
[<etail environmental requirements as needed. -or hardware3 based s!stems, environmental issues can include
temperature, shoc, humidit!, radiation, and so forth. -or software applications, environmental factors can include
usage conditions, user environment, resource availabilit!, maintenance issues, and error handling and recover!.(
Confidential <Company Name>, 201 !a"e 11
<Project Name>
Version: <1.0>
Vision Date: <dd/mmm/yy>
<document identifier>
10. %oc!mentation Re;!irements
[This section describes the documentation that must be developed to support successful application deplo!ment.(
10.1 0ser 1an!al
[<escribe the purpose and contents of the User *anual. <iscuss desired length, level of detail, need for index,
glossar! of terms, tutorial versus reference manual strateg!, and so on. -ormatting and printing constraints must
also be identified.(
10." *nline Help
[*an! applications provide an online help s!stem to assist the user. The nature of these s!stems is unique to
application development as the! combine aspects of programming "h!perlins, and so forth& with aspects of
technical writing, such as organi)ation and presentation. *an! have found the development of an online help s!stem
is a pro0ect within a pro0ect that benefits from up3front scope management and planning activit!.(
10.$ Installation <!ies& Confi,!ration& an Rea 1e 8ile
[' document that includes installation instructions and configuration guidelines is important to a full solution
offering. 'lso, a Read *e file is t!picall! included as a standard component. The Read *e file can include a
J+hat:s New +ith This ReleaseK section, and a discussion of compatibilit! issues with earlier releases. *ost users
also appreciate documentation defining an! nown bugs and worarounds in the Read *e file.(
10.( 7abelin, an Pac.a,in,
[Toda!:s state3of3the3art applications provide a consistent loo and feel that begins with product pacaging and
manifests through installation menus, splash screens, help s!stems, 8U$ dialogs, and so on. This section defines the
needs and t!pes of labeling to be incorporated into the code. 2xamples include cop!right and patent notices,
corporate logos, standardi)ed icons and other graphic elements, and so forth.(
' 8eat!re 'ttrib!tes
[-eatures are given attributes that can be used to evaluate, trac, prioriti)e, and manage the product items proposed
for implementation. 'll requirement t!pes and attributes need to be outlined in the Requirements *anagement Plan,
however, !ou ma! wish to list and briefl! describe the attributes for features that have been chosen. The following
subsections represent a set of suggested feature attributes.(
'.1 #tat!s
[/et after negotiation and review b! the pro0ect management team. Tracs progress during definition of the pro0ect
baseline.(
!roposed [Used to describe features that are under discussion but have not !et
been reviewed and accepted b! the Jofficial channel,J such as a
woring group consisting of representatives from the pro0ect team,
product management, and user or customer communit!.(
&ppro(ed [1apabilities that are deemed useful and feasible, and have been
approved for implementation b! the official channel.(
#ncorporated [-eatures incorporated into the product baseline at a specific point in
time.(
'." -enefit
[/et b! *areting, the product manager or the business anal!st. 'll requirements are not created equal. Raning
requirements b! their relative benefit to the end user opens a dialog with customers, anal!sts, and members of the
development team. Used in managing scope and determining development priorit!.(
Confidential <Company Name>, 201 !a"e 12
<Project Name>
Version: <1.0>
Vision Date: <dd/mmm/yy>
<document identifier>
Critical [2ssential features. -ailure to implement means the s!stem will not meet
customer needs. 'll critical features must be implemented in the release
or the schedule will slip.(
#mportant [-eatures important to the effectiveness and efficienc! of the s!stem for
most applications. The functionalit! cannot be easil! provided in some
other wa!. ?ac of inclusion of an important feature ma! affect customer
or user satisfaction, or even revenue, but release will not be dela!ed due
to lac of an! important feature.(
0seful [-eatures that are useful in less t!pical applications will be used less
frequentl! or for which reasonabl! efficient worarounds can be
achieved. No significant revenue or customer satisfaction impact can be
expected if such an item is not included in a release.(
'.$ 2ffort
[/et b! the development team. %ecause some features require more time and resources than others, estimating the
number of team or person3wees, lines of code required or function points, for example, is the best wa! to gauge
complexit! and set expectations of what can and cannot be accomplished in a given time frame. Used in managing
scope and determining development priorit!.(
'.( Ris.
[/et b! development team based on the probabilit! the pro0ect will experience undesirable events, such as cost
overruns, schedule dela!s or even cancellation. *ost pro0ect managers find categori)ing riss, as high, medium,
and low, is sufficient, although finer gradations are possible. Ris can often be indirectl! assessed b! measuring the
uncertaint! "range& of the pro0ects team7s schedule estimate.(
'.) #tability
[/et b! the anal!st and development team, this is based on the probabilit! that features will change or the team7s
understanding of the feature will change. Used to help establish development priorities and determine those items
for which additional elicitation is the appropriate next action.(
'.3 Tar,et Release
[Records the intended product version in which the feature will first appear. This field can be used to allocate
features from a Vision document into a particular baseline release. +hen combined with the status field, !our team
can propose, record, and discuss various features of the release without committing them to development. @nl!
features whose /tatus is set to $ncorporated and whose Target Release is defined will be implemented. +hen scope
management occurs, the Target Release Lersion Number can be increased so the item will remain in the Vision
document but will be scheduled for a later release.(
'.4 'ssi,ne To
[$n man! pro0ects, features will be assigned to Jfeature teamsJ responsible for further elicitation, writing the
software requirements, and implementation. This simple pull3down list will help ever!one on the pro0ect team to
understand responsibilities better.(
Confidential <Company Name>, 201 !a"e 1%
<Project Name>
Version: <1.0>
Vision Date: <dd/mmm/yy>
<document identifier>
'.6 Reason
[This text field is used to trac the source of the requested feature. Requirements exist for specific reasons. This field
records an explanation or a reference to an explanation. -or example, the reference might be to a page and line
number of a product requirement specification or to a minute marer on a video of an important customer review.(
Confidential <Company Name>, 201 !a"e 1