Nombre de la Empresa

Nombre del Proyecto

Visin
Versin <1.0>
[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square
brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be
deleted before publishing the document. A paragraph entered following this style will automatically be set to normal
(style=Body Text).]
[To customize automatic fields in Microsoft Word (which display a gray background when selected), select
File>Properties and replace the Title, Subject and Company fields with the appropriate information for this
document. After closing the dialog, automatic fields may be updated throughout the document by selecting
Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately
for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word
help for more information on working with fields.]

Nombre del Proyecto

Visin
<Nombre Fsico del Documento>

Versin:
<1.0>
Fecha: <dd/mmm/aa>

Historial de Revisiones
Fecha
<dd/mmm/aa>

Confidencial

Versin
<x.x>

Descripcin
<detalles>

, 2015

Autor
<nombre>

Pg. 2

Nombre del Proyecto

Visin
<Nombre Fsico del Documento>

Versin:
<1.0>
Fecha: <dd/mmm/aa>

Tabla de Contenidos
1.

Introduccin
1.1
Propsito
1.2
Alcance
1.3
Definiciones, Acrnimos, y Abreviaciones
1.4
Referencias
1.5
Organizacin de este Documento

2.

Posicionamiento
2.1
Oportunidad de Negocio
2.2
Sentencia que define el Problema
2.3
Sentencia que define la posicin del Producto

3.

Descripcin de Stakeholders (Participantes en el Proyecto) y Usuarios

3.1
Mercado Asociado al Producto
3.2
Resumen de Stakeholders
3.3
Resumen de Usuarios
3.4
Entorno de los Usuarios
3.5
Perfil de los Stakeholders
3.5.1 <Nombre del tipo de Stakeholder>
3.6
Perfiles de Usuario
3.6.1 <Nombre del tipo de Usuario>
3.7
Necesidades Claves de los Stakeholders o Usuarios
3.8
Alternativas
3.8.1 <una Alternativar>
3.8.2 <otra Alternativa>

4.

Descripcin Global del Producto

4.1
Perspectiva del Producto
4.2
Resumen de Caractersticas
4.3
Suposiciones y Dependencias
4.4
Costo y Precio
4.5
Licencia e Instalacin

5.

Caractersticas del Producto

5.1
<una Caractersitica>
5.2
<otra Caracterstica>

6.

Restricciones

7.

Rangos de Calidad

8.

Precedencia y Prioridad

9.

Otros Requisitos del Producto

9.1
Estndares Aplicables
9.2
Requisitos de Sistema
9.3
Requisitos de Desempeo
9.4
Requisitos de Entorno

Confidencial

, 2015

3
3
3
3

Pg. 3

Nombre del Proyecto

Visin
<Nombre Fsico del Documento>
10.
10.1
10.2
10.3
10.4
A

Versin:
<1.0>
Fecha: <dd/mmm/aa>

Requisitos de Documentacin
Manual de Usuario
Ayuda en Lnea
Guas de Instalacin, Configuracin, y Fichero Lame
Etiquetado y Empaquetado

Atributos de Caractersticas
A.1 Estado
A.2 Beneficio
A.3 Esfuerzo
A.4 Riesgo
A.5 Estabilidad
A.6 Release que la Incluir
A.7 Asignacin
A.8 Justificacin

Visin
1. Introduccin
[El propsito de este documento es recopilar, analizar y definir las necesidades de alto nivel y las caractersticas de
<<System Name>>. Se centra en las capacidades necesarias de los Stakeholders y los usuarios destino, y el POR
QU existen estas necesidades. Los detalles de cmo el <system name>> satisface estas necesidades se detallan en
las especificaciones de caso de uso y complementarias.]
[The introduction of the Vision document provides an overview of the entire document. It includes the purpose,
scope, definitions, acronyms, abbreviations, references, and overview of this Vision document.]
1.1 Propsito
[Especifica el propsito de este documento VISIN]
1.2 Alcance
[Una breve descripcin del alcance de este documento Visin, qu proyecto (s) est asociado y cualquier otra
cosa que se vea afectada o influenciada por este documento.]
1.3 Definiciones, Acrnimos, y Abreviaciones
[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the
Vision document. This information may be provided by reference to the projects Glossary.]
1.4 Referencias
[This subsection provides a complete 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.]
1.5 Organizacin de este Documento
[This subsection describes what the rest of the Vision document contains and explains how the document is
organized.]

2. Posicionamiento
2.1 Oportunidad de Negocio
[Describa brevemente la oportunidad de negocio que se cumplen por este proyecto.]

Confidencial

, 2015

Pg. 4

Nombre del Proyecto

Visin
<Nombre Fsico del Documento>

Versin:
<1.0>
Fecha: <dd/mmm/aa>

2.2 Sentencia que define el Problema

[Provide a statement summarizing the problem being solved by this project. The following format may be used:]
El problema de

[describe el problema]

afecta a

[Lista de Stakeholders afectados por el problema]

El impacto asociado es

[Cul es el impacto del problema?]

una adecuada solucin sera

[lista de algunos beneficios claves para una solucin exitosa]

2.3 Sentencia que define la posicin del Producto

[Proporcionar una declaracin general que resume, en el ms alto nivel, la posicin nica el producto tiene la
intencin de llenar en el Mercado. Puede usarse el siguiente formato:]
Para

[cliente destino]

Quien

[Declaracin de la necesidad u oportunidad]

El (nombre del producto)

Es un [categora del producto]

Que

[Declaracin de beneficio clave; es decir, la razn de peso para

comprar]

No como

[principal alternativa competitiva]

Nuestro producto

[Declaracin de diferenciacin primaria]

[Una declaracin de posicin del producto comunica la intencin de la aplicacin y la importancia del proyecto a
todo el personal interesado.]

3. Descripcin de Stakeholders y Usuarios

[To effectively provide products and services that meet your stakeholders and users' real needs, it is necessary to
identify and involve all of the stakeholders as part of the Requirements Modeling process. You must also identify the
users of the system and ensure that the stakeholder community adequately represents them. This section provides a
profile of the stakeholders and users involved in the project, and the key problems that they perceive to be addressed
by the proposed solution. It does not describe their specific requests or requirements as these are captured in a
separate stakeholder requests artifact. Instead, it provides the background and justification for why the requirements
are needed.]
3.1 Mercado Demogrfico
[Resumir los datos demogrficos clave del mercado que motivan sus decisiones de producto. Describir y posicionar
los segmentos de mercado objetivo. Estimar el tamao de mercado y el crecimiento mediante el nmero de usuarios
potenciales o la cantidad de dinero que gastan sus clientes tratando de satisfacer las necesidades que su producto o
la mejora cumplira. Revisin de las principales tendencias de la industria y las tecnologas. Responda a estas
preguntas estratgicas:

Cul es la reputacin de su empresa en estos mercados?

Como le gustara que sea?

Cmo este producto o servicio soporta sus objetivos?]

Confidencial

, 2015

Pg. 5

Nombre del Proyecto

Visin
<Nombre Fsico del Documento>

Versin:
<1.0>
Fecha: <dd/mmm/aa>

3.2 Resumen de Stakeholders

[Hay una serie de stakeholders con inters en el desarrollo y no todos ellos son los usuarios finales. Presentar una
lista resumida de estos actores no usuarios. (Los usuarios se resumen en la seccin 3.3.)]
Name

Description

Responsibilities

[Nombre del tipo de

stakeholder.]

[Breve
descripcin
stakeholder.]

del

[Resumir las principales responsabilidades de

los Stakeholders en relacin con el sistema en
desarrollo, es decir, su inters como un
stakeholder]
For example, this stakeholder:
ensures that the system will be maintainable
ensures that there will be a market demand
for the products features
monitors the projects progress
approves funding
and so forth]

3.3 Resumen de Usuarios

[Present a summary list of all identified users.]
Nombre

Descripcin

Responsabilidades

Stakeholder

[Nombre
del
Stakeholde
r tipo.]

[Briefly describe
what
they
represent
with
respect to the
system.]

[List the users key responsibilities

with regard to the system being
developed; for example:

[If the user is not directly

represented, identify which
stakeholder is responsible for
representing
the
users
interest.]

captures details
produces reports
coordinates work
and so on]

3.4 Entorno de los Usuarios

[Proporcione detalles sobre el entorno de trabajo del usuario destino. Aqu estn algunas sugerencias:
Nmero de personas involucradas en la realizacin de la tarea, esto es cambiante?
Cunto dura un ciclo de la tarea? Cantidad de tiempo dedicado a cada actividad? esto es cambiante?
Any unique environmental constraints: mobile, outdoors, in-flight, and so on?
Which systems platforms are in use today? Future platforms?
What other applications are in use? Does your application need to integrate with them?
This is where extracts from the Business Model could be included to outline the task and roles involved and so on.]
3.5 Perfil de los Stakeholders
[Describir cada uno de los Stakeholders en el sistema rellenando el siguiente cuadro para cada uno. Recuerde que
los tipos de stakeholder pueden ser tan divergentes como los usuarios, departamentos, y desarrolladores tcnicos.
Un perfil completo abarcara los siguientes temas para cada tipo de stakeholder.]
Confidencial

, 2015

Pg. 6

Nombre del Proyecto

Visin
<Nombre Fsico del Documento>

3.5.1

Versin:
<1.0>
Fecha: <dd/mmm/aa>

<Nombre del tipo de Stakeholder>

Representante

[Quin es el representante de los Stakeholders del proyecto? (Opcional si es

documentado en otros lugares.) Lo que queremos aqu son los nombres.]

Descripcin

[Una breve descripcin de los tipos de Stakeholder.]

Tipo

[Calificar la experiencia del stakeholder, conocimientos tcnicos y grado de

sofisticacin, es decir, gur, negocios, usuario experto, casual, y as
sucesivamente.]

Responsabilid
ades

[Lista de responsabilidades clave del stakeholder con respecto al sistema que se

est elaborando es decir, su inters como un participante.]

Criterio de
xito

[Cmo es definido el xito del stakeholder?

Grado de
participacin

[Cmo participa el interesado en el proyecto? Relacionados con roles del RUP

siempre que sea posible, es decir, es el revisor de requisito, el analista de procesos
y as sucesivamente.]

Artefactos
adicionales

[Are there any additional deliverables required by the stakeholder? These could be
project deliverables or outputs from the system under development.]

Comentarios

[Problems that interfere with success and any other relevant information go here.]

Cmo es recompensado el Stakeholder?]

3.6 Perfiles de Usuario

[Describir cada usuario nico del sistema rellenando en la siguiente tabla cada tipo de usuario. Recuerde los tipos
de usuario pueden ser tan divergentes como gurs y principiantes. Por ejemplo, un gur que necesite una
herramienta sofisticada y flexible con soporte multiplataforma, mientras que un novato que necesite una
herramienta fcil de usar y fcil de usar. Un perfil completo debe cubrir los siguientes temas para cada tipo de
usuario.]
3.6.1

<Nombre del tipo de Usuario>

Representante

[Quin es el representante de usuario al proyecto? (Opcional si documentan en

otros lugares). Esto a menudo refiere a las partes interesadas que representa el
conjunto de los usuarios.]

Descripcin

[A brief description of the user type.]

Tipo

[Calificar la experiencia, conocimientos tcnicos y grado de sofisticacin del

usuario es decir, gur, usuario casual, etc.]

Responsabilidades

[List the users key responsibilities with regard to the system being developed
that is, captures details, produces reports, coordinates work, and so forth.]

Criterio de xito

[How does the user define success?

How is the user rewarded?]

Grado de
participacin

[How is the user involved in the project? Relate where possible to Rational Unified
Process rolesthat is, Requirements Reviewer, and so on.]

Artefactos

[Are there any deliverables the user produces and, if so, for whom?]

Confidencial

, 2015

Pg. 7

Nombre del Proyecto

Visin
<Nombre Fsico del Documento>

Versin:
<1.0>
Fecha: <dd/mmm/aa>

adicionales
Comentarios

[Problems that interfere with success and any other relevant information go here.
These would include trends that make the users job easier or harder.]

3.7 Necesidades Claves de los Stakeholders o Usuarios

[Lista de los principales problemas con soluciones existentes desde el punto de vista del usuario o los Stakeholder.
Aclarar las cuestiones siguientes para cada problema:

Cuales son las razones para este problema?

Como lo soluciona ahora?

Que soluciones, el stakeholder o usuario deseara?]

[It is important to understand the relative importance the stakeholder or user places on solving each problem.
Ranking and cumulative voting techniques indicate problems that must be solved versus issues they would like
addressed.
Fill in the following tableif using Rational RequisitePro to capture the Needs, this could be an extract or report
from that tool.]
Necesidad

Prioridad

Importancia

Solucin Actual

Soluciones Propuestas

3.8 Alternativas
[Identificar alternativas que el stakeholder percibe como disponibles. Estos pueden incluir la compra del producto
de un competidor, construir una solucin desarrollada internamente o simplemente mantener el statu quo. Lista de
cualquier alternativas competitivas conocida que exista o que estn disponibles. Incluyen las principales fortalezas
y debilidades de cada competidor como percibidos por el interesado o el usuario final.]
3.8.1

<Una Alternativa>

3.8.2

<Otra Alternativa>

4. Descripcin Global del Producto

[Esta seccin proporciona una visin general de las capacidades del producto, interfaces con otras aplicaciones y
configuraciones de sistema. Esta seccin normalmente consta de tres subsecciones:

Perspectiva del Producto

Funciones del Producto

Supuestos y dependencias]

4.1 Perspectiva del Producto

[Esta subseccin del documento visin pone el producto en perspectiva a otros productos relacionados y al entorno
del usuario. Si el producto es totalmente autnomo e independiente, estado aqu. Si el producto es un componente
de un sistema mayor, esta subseccin necesita relatar cmo estos sistemas interactan y necesita identificar las
interfaces pertinentes entre los sistemas. Una forma fcil de mostrar los componentes principales del sistema
mayor, interconexiones y interfaces externas es con un diagrama de bloques]
4.2 Resumen de Caractersticas
[Resumen de las principales ventajas y caractersticas que proporcionar el producto. Por ejemplo, el documento
Confidencial

, 2015

Pg. 8

Nombre del Proyecto

Visin
<Nombre Fsico del Documento>

Versin:
<1.0>
Fecha: <dd/mmm/aa>

Visin sirve de apoyo al cliente ya que puede utilizar esta parte de la documentacin para revisar problemas de
direccin, enrutamiento y estatus sin mencionar en cantidad el detalle que cada una de estas funciones requiere.
Organizar las funciones en una lista que sea comprensible para el cliente o para cualquier otra persona al leer el
documento por primera vez. Una simple lista en la tabla con las principales ventajas y funciones de apoyo podra
ser suficiente. Por ejemplo:]
Table 4-1 Customer Support System
Beneficio para el Cliente
Funciones de Apoyo
New support staff can quickly Knowledge base assists support
get up to speed.
personnel in quickly identifying known
El nuevo personal de apoyo
fixes and workarounds.
puede ponerse al da
La Base de conocimiento ayuda al
rpidamente
personal de apoyo en la rpida
identificacin de soluciones y
correcciones conocidas.
Customer satisfaction is
Problems are uniquely itemized,
improved because nothing
classified and tracked throughout the
falls through the cracks.
resolution process. Automatic
La satisfaccin del cliente se
notification occurs for any aging
mejora
issues.
Los problemas son nicamente
detallados, clasificados y se realiza un
seguimiento durante todo el proceso de
resolucin. Notificacin automtica se
produce algn problema de caducidad.
Management can identify
problem areas and gauge
staff workload.
El Gestor puede identificar
reas problemticas y medir
la carga de trabajo de
personal.
Distributed support teams
can work together to solve
problems.
Equipos de apoyo distribuidos
pueden trabajar juntos para
resolver problemas.

Trend and distribution reports allow

high level review of problem status.

Customers can help

themselves, lowering support
costs and improving response
time.

Knowledge base can be made available

over the Internet. Includes hypertext
search capabilities and graphical query
engine.

Informes de tendencia y distribucin

permiten la revisin de alto nivel del
estado del problema
Replication server allows current
database information to be shared
across the enterprise.
El Servidor de replicacin permite
compartir en toda la empresa la
informacin de base de datos actual

4.3 Suposiciones y Dependencias

[Lista de cada uno de los factores que afectan las funciones descritas en el presente documento de visin. Enumere
los supuestos que, si cambia, alterar el documento de visin. Por ejemplo, puede indicar a una suposicin de que
un sistema operativo especfico estar disponible para el hardware para el producto de software. Si el sistema
operativo no est disponible, el documento de visin tendr que cambiar.]

Confidencial

, 2015

Pg. 9

Nombre del Proyecto

Visin
<Nombre Fsico del Documento>

Versin:
<1.0>
Fecha: <dd/mmm/aa>

4.4 Costo y Precio

[Para los productos vendidos a clientes externos y para muchas aplicaciones en la empresa, cuestiones de costos y
fijacin de precios pueden afectar directamente a la definicin de la aplicacin y ejecucin. En esta seccin,
registro de todas las limitaciones de costos y precios que sean pertinentes. Por ejemplo, los costes de distribucin,
(nmero de disquetes, # de CD-ROM, el dominio de CD) u otro costo de las mercancas vendidas limitaciones
(manuales, embalaje) puede ser importante para el xito de los proyectos, o irrelevante, dependiendo de la
naturaleza de la solicitud.]
4.5 Licencia e Instalacin
[Problemas de instalacin y licencias pueden afectar directamente el esfuerzo de desarrollo. Por ejemplo, la
necesidad de apoyar la serializacin, seguridad de contrasea o licencias de red crear requisitos adicionales del
sistema que debe considerarse en el esfuerzo de desarrollo.
Requisitos de instalacin tambin pueden afectar la codificacin o crear la necesidad de software de instalacin
independiente.]

5. Caractersticas del Producto

[Enumerar y describir brevemente las caractersticas del producto. Caractersticas son las capacidades de alto
nivel del sistema que son necesarias para ofrecer beneficios a los usuarios. Cada funcin es un servicio externo
deseado que normalmente requiere una serie de insumos para lograr el resultado deseado. Por ejemplo, una
caracterstica de un problema en el sistema de seguimiento podra ser la capacidad de proporcionar informes de
tendencias. El modelo de caso de uso toma forma, actualizar la descripcin para referirse a los casos de uso.
Debido a que el documento Visin es revisado por una gran variedad de personal involucrado, el nivel de detalle
debe ser lo suficientemente general para que todos lo puedan entender. Sin embargo, debe estar disponible con
suficiente detalle para proporcionar al equipo la informacin que necesitan para crear un modelo de casos de uso.
Para gestionar eficazmente la complejidad de aplicacin, se recomienda para cualquier sistema nuevo, o un
incremento a un sistema existente, capacidades de abstraccin de un nivel lo suficientemente alto para 25-99
caractersticas. Estas caractersticas constituyen la base fundamental para la definicin del producto, gestin del
alcance y gestin de proyectos. Cada funcin se ampliar en mayor detalle en el modelo de casos de uso.
En esta seccin, cada funcin ser perceptible desde el exterior por los usuarios, los operadores u otros sistemas
externos. Estas caractersticas necesitan incluir una descripcin de la funcionalidad y los problemas de usabilidad
pertinentes que deben abordarse. Las instrucciones siguientes se aplican:

Evitar el diseo. Mantener las descripciones de funciones a nivel general. Concentrarse en las capacidades
necesarias y por qu (no cmo) que deben aplicarse.

Si est utilizando el kit de herramientas de Rational RequisitePro, todos deben ser seleccionados como los
requisitos de tipo para facilitar la consulta y el seguimiento.]
5.1 <Una Caracterstica>
5.2 <Otra Caracterstica>

6. Restricciones
[Note any design constraints, external constraints or other dependencies.]

7. Rangos de Calidad
[Define the quality ranges for performance, robustness, fault tolerance, usability, and similar characteristics that
are not captured in the Feature Set.]

Confidencial

, 2015

Pg. 10

Nombre del Proyecto

Visin
<Nombre Fsico del Documento>

Versin:
<1.0>
Fecha: <dd/mmm/aa>

8. Precedencia y Prioridad
[Define the priority of the different system features.]

9. Otros Requisitos del Producto

[At a high level, list applicable standards, hardware or platform requirements, performance requirements, and
environmental requirements.]
9.1 Estndares Aplicables
[List all standards with which the product must comply. These can include legal and regulatory (FDA, UCC)
communications standards (TCP/IP, ISDN), platform compliance standards (Windows, UNIX, and so on), and
quality and safety standards (UL, ISO, CMM).]
9.2 Requisitos de Sistema
[Define any system requirements necessary to support the application. These can include the supported host
operating systems and network platforms, configurations, memory, peripherals, and companion software.]
9.3 Requisitos de Desempeo
[Use this section to detail performance requirements. Performance issues can include such items as user load
factors, bandwidth or communication capacity, throughput, accuracy, and reliability or response times under a
variety of loading conditions.]
9.4 Requisitos de Entorno
[Detail environmental requirements as needed. For hardware- based systems, environmental issues can include
temperature, shock, humidity, radiation, and so forth. For software applications, environmental factors can include
usage conditions, user environment, resource availability, maintenance issues, and error handling and recovery.]

10. Requisitos de Documentacin

[This section describes the documentation that must be developed to support successful application deployment.]
10.1
Manual de Usuario
[Describe the purpose and contents of the User Manual. Discuss desired length, level of detail, need for index,
glossary of terms, tutorial versus reference manual strategy, and so on. Formatting and printing constraints must
also be identified.]
10.2
Ayuda en Lnea
[Many applications provide an online help system to assist the user. The nature of these systems is unique to
application development as they combine aspects of programming (hyperlinks, and so forth) with aspects of
technical writing, such as organization and presentation. Many have found the development of an online help system
is a project within a project that benefits from up-front scope management and planning activity.]
10.3
Guas de Instalacin, Configuracin, y Fichero Lame
[A document that includes installation instructions and configuration guidelines is important to a full solution
offering. Also, a Read Me file is typically included as a standard component. The Read Me file can include a
"What's New With This Release section, and a discussion of compatibility issues with earlier releases. Most users
also appreciate documentation defining any known bugs and workarounds in the Read Me file.]
10.4
Etiquetado y Empaquetado
[Today's state-of-the-art applications provide a consistent look and feel that begins with product packaging and
manifests 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 forth.]

Atributos de las Caractersticas

[Features are given attributes that can be used to evaluate, track, prioritize, and manage the product items proposed
Confidencial

, 2015

Pg. 11

Nombre del Proyecto

Visin
<Nombre Fsico del Documento>

Versin:
<1.0>
Fecha: <dd/mmm/aa>

for implementation. All requirement types and attributes need to be outlined in the Requirements Management Plan,
however, you may wish to list and briefly describe the attributes for features that have been chosen. The following
subsections represent a set of suggested feature attributes.]
A.1
Estado
[Set after negotiation and review by the project management team. Tracks progress during definition of the project
baseline.]
Propuesta

[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.]

Aprobada

[Capabilities that are deemed useful and feasible, and have been
approved for implementation by the official channel.]

Incorporada

[Features incorporated into the product baseline at a specific point

in time.]

A.2
Beneficio
[Set by Marketing, the product manager or the business analyst. All requirements are not created equal. Ranking
requirements by their relative benefit to the end user opens a dialog with customers, analysts, and members of the
development team. Used in managing scope and determining development priority.]

Critica

[Essential features. Failure to implement means the system will not

meet customer needs. All critical features must be implemented in the
release or the schedule will slip.]

Important
e

[Features important to the effectiveness and efficiency of the system for

most applications. The functionality cannot be easily provided in some
other 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.]

til

[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 or customer satisfaction impact can be
expected if such an item is not included in a release.]

A.3
Esfuerzo
[Set by the development team. 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 set expectations of what can and cannot be accomplished in a given time frame. Used in managing
scope and determining development priority.]
A.4
Riesgo
[Set by development team based on the probability 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, is sufficient, although finer gradations are possible. Risk can often be indirectly assessed by measuring the
uncertainty (range) of the projects teams schedule estimate.]

Confidencial

, 2015

Pg. 12

Nombre del Proyecto

Visin
<Nombre Fsico del Documento>

Versin:
<1.0>
Fecha: <dd/mmm/aa>

A.5
Estabilidad
[Set by the analyst and development team, this is based on the probability that features will change or the teams
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.]
A.6
Release que la Incluir
[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. When 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.]
A.7
Asignacin
[In many projects, features will be assigned to "feature teams" responsible for further elicitation, writing the
software requirements, and implementation. This simple pull-down list will help everyone on the project team to
understand responsibilities better.]
A.8
Justificacin
[This text field is used to track the source of the requested feature. Requirements 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 review.]

Confidencial

, 2015

Pg. 13