<Project Name> Vision (Small Project)

Authors: <forename.name>(<email> )

Document Number: <reference #> Version: <version #>

Publish Date: 2014-03-2

[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brac ets 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! bac ground 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 wor ing with fields.(

<Project Name> Vision (Small Project) <document identifier>

Version: <1.0> Date: <yyyy-mm-dd>

Record of Processing
No. 1 # $ % & ' ( Version Date Status !o Descri"tion

Record of Approval
No. 1 # $ % & ' ( Version Date ) !o ) Descri"tion

Recipients of Document
No. 1 # $ % & ' ( Version Date of Distri*ution ) +eci"ients

Pa,e #

<Project Name> Vision (Small Project) <document identifier>

Version: <1.0> Date: <yyyy-mm-dd>

Ta le of !ontents
1. -ntroduction 1.1 +eferences #. Positionin, #.1 Pro*lem Statement #.# Product Position Statement $. Sta.e!older and /ser Descri"tions $.1 Sta.e!older Summary $.# /ser Summary $.$ /ser 0n1ironment $.% Summary of 2ey Sta.e!older or /ser Needs $.& 3lternati1es and 4om"etition %. Product 51er1ie6 %.1 Product Pers"ecti1e %.# 3ssum"tions and De"endencies &. Product 7eatures '. 5t!er Product +e8uirements % % % % % % & & & ' ' ' ' ' ' (

Pa,e $

<Project Name> Vision (Small Project) <document identifier>

Version: <1.0> Date: <yyyy-mm-dd>

Vision (Small Project)

"# $ntroduction
[The purpose of this document is to collect, anal!)e, and define high3level needs and features of the <<System Name>>. $t focuses on the capabilities needed b! the sta eholders and the target users, and why these needs exist. The details of how the <<System 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 and references of this Vision document.( "#" 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.(

%#

Positioning

%#" Pro lem Statement [Provide a statement summari)ing the problem being solved b! this pro0ect. The following format ma! be used:( 9!e "ro*lem of affects t!e im"act of 6!ic! is a successful solution 6ould *e [describe the problem( [the sta eholders affected b! the problem( [what is the impact of the problem6( [list some e! benefits of a successful solution(

%#% Product Position Statement [Provide an overall statement summari)ing, at the highest level, the unique position the product intends to fill in the mar etplace. The following format ma! be used:( 7or !o 9!e ("roduct name) 9!at /nli.e 5ur "roduct [target customer( [statement of the need or opportunit!( is a [product categor!( [statement of e! benefit7 that is, the compelling reason to bu!( [primar! competitive alternative( [statement of primar! differentiation(

[' product position statement communicates the intent of the application and the importance of the pro0ect to all concerned personnel.(

&#

Sta'e(older and )ser Descriptions

[To effectivel! provide products and services that meet !our sta eholders8 and users9 real needs it is necessar! to identif! and involve all of the sta eholders as part of the Requirements *odeling process. :ou must also identif! the users of the s!stem and ensure that the sta eholder communit! adequatel! represents them. This section provides a profile of the sta eholders and users involved in the pro0ect, and the e! problems that the! perceive to be Pa,e %

<Project Name> Vision (Small Project) <document identifier>

Version: <1.0> Date: <yyyy-mm-dd>

addressed b! the proposed solution. $t does not describe their specific requests or requirements as these are captured in a separate sta eholder requests artifact. $nstead, it provides the bac ground and 0ustification for wh! the requirements are needed.( &#" Sta'e(older Summar* [There are a number of sta eholders with an interest in the development and not all of them are end users. Present a summar! list of these non3user sta eholders. "The users are summari)ed in section ;.<.&( Name [Name the sta eholder t!pe.( Description [%riefl! describe the sta eholder.( Responsi ilities [/ummari)e the sta eholder8s e! responsibilities with regard to the s!stem being developed7 that is, their interest as a sta eholder. -or example, this sta eholder: ensures that the s!stem will be maintainable ensures that there will be a mar et demand for the product8s features monitors the pro0ect8s progress approves funding and so forth( &#% )ser Summar* [Present a summar! list of all identified users.( Name [Name the user t!pe.( Description [%riefl! describe what the! represent with respect to the s!stem.( Responsi ilities [=ist the user8s e! responsibilities with regard to the s!stem being developed7 for example: captures details produces reports coordinates wor and so on( Sta'e(older [$f the user is not directl! represented, identif! which sta eholder is responsible for representing the user8s interest.(

&#& )ser +nvironment [>etail the wor ing environment of the target user. 5ere are some suggestions: Number of people involved in completing the tas 6 $s this changing6 5ow long is a tas c!cle6 'mount of time spent in each activit!6 $s this changing6 'n! unique environmental constraints: mobile, outdoors, in3flight, and so on6 +hich s!stem platforms are in use toda!6 -uture platforms6 +hat other applications are in use6 >oes !our application need to integrate with them6 This is where extracts from the %usiness *odel could be included to outline the tas and roles involved, and so on.(

Pa,e &

<Project Name> Vision (Small Project) <document identifier>

Version: <1.0> Date: <yyyy-mm-dd>

&#, Summar* of -e* Sta'e(older or )ser Needs [=ist the e! problems with existing solutions as perceived b! the sta eholder or user. 1larif! the following issues for each problem: ? ? ? +hat are the reasons for this problem6 5ow is it solved now6 +hat solutions does the sta eholder or user want6(

[$t is important to understand the relative importance the sta eholder or user places on solving each problem. Ran ing and cumulative voting techniques indicate problems that must be solved versus issues the! would li e addressed. -ill in the following table@if using Rational RequisitePro to capture the Needs, this could be an extract or report from that tool.( Need :roadcast messa,es Priorit* !oncerns !urrent Solution Proposed Solutions

&#. Alternatives and !ompetition [$dentif! alternatives the sta eholder perceives as available. These can include bu!ing a competitor8s 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 wea nesses of each competitor as perceived b! the sta eholder or end user.(

,#

Product /vervie0

[This section provides a high level view of the product capabilities, interfaces to other applications, and s!stem configurations. This section usuall! consists of two subsections, as follows: ? ? Product perspective 'ssumptions and dependencies(

,#" Product Perspective [This subsection of the Vision document puts the product in perspective to other related products and the user8s 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. Ane eas! wa! to displa! the ma0or components of the larger s!stem, interconnections, and external interfaces is with a bloc diagram.( ,#% Assumptions and Dependencies [=ist each factor that affects 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.(

.#

Product 1eatures

[=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 trac ing s!stem might be the

Pa,e '

<Project Name> Vision (Small Project) <document identifier>

Version: <1.0> Date: <yyyy-mm-dd>

abilit! to provide trending reports. 's the use3case model ta es 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 be abstracted to a high enough level so <B344 features result. These features provide the 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 should include a description of functionalit! and an! relevant usabilit! issues that must be addressed. The following guidelines appl!: ? 'void design. Ceep 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 tool it, all need to be selected as requirements of t!pe for eas! reference and trac ing.( [>efine the priorit! of the different s!stem features. $nclude, if useful, attributes such as stabilit!, benefit, effort, and ris .(

2#

/t(er Product Re3uirements

['t a high level, list applicable standards, hardware, or platform requirements7 performance requirements7 and environmental requirements. >efine the qualit! ranges for performance, robustness, fault tolerance, usabilit!, and similar characteristics that are not captured in the -eature /et. Note an! design constraints, external constraints, or other dependencies. >efine an! specific documentation requirements, including user manuals, online help, installation, labeling, and pac aging requirements. >efine the priorit! of these other product requirements. $nclude, if useful, attributes such as stabilit!, benefit, effort, and ris .(

Pa,e (