Nombre de la Empresa.

<Nombre del Proyecto>

Visión

Versión <1.0>

[Nota: La siguiente plantilla es provista para el uso con el Rational Unified Process. El texto encerrado en
paréntesis cuadrados y desplegado en azul itálico (Estilo=InfoBlue) esta incluido para ser una guía al
autor y debe ser borrado antes de publicar el documento. Un párrafo introducido siguiendo este estilo se
establecerá como normal (Estilo=Body Text).]
[Para personalizar los campos automáticos (los cuales despliegan un fondo gris cuando se seleccionan),
seleccione Archivo>Propiedades y reemplace los campos de Título, Asunto y Organización con la
información apropiada para este documento. Después de cerrar el dialogo, los campos automáticos deben
ser actualizados a través del documento al seleccionar Edición->Seleccionar todo (o Ctrl_E) y luego se
debe oprimir la tecla F9 o simplemente click sobre cada uno de los campos y presione F9. Esto debe
hacerse separadamente para encabezados y pie de página. Alt-F9 cambiar entre el despliegue del nombre
del campo y su contenido. Consultar la ayuda de Word para mayor información para trabajar con
campos. ]
<Nombre del Proyecto> Versión: <1.0>
Visión Fecha: <dd/mmm/yy>
<identificador del documento> ***FISC VISION # GRUPO

Historial de Revisiones
Fecha Versión Descripción Autor
<dd/mmm/yy> <x.x> <detalles> <nombre>

Confidential ¡Error!Nombre desconocido de ii

propiedad de documento., 2002
<Nombre del Proyecto> Versión: <1.0>
Visión Fecha: <dd/mmm/yy>
<identificador del documento> ***FISC VISION # GRUPO

Tabla de Contenidos
1. Introducción 2
1.1 Propósito 2
1.2 Alcance 2
1.3 Definiciones, Acrónimos y Abreviaturas 2
1.4 Referencias 2
1.5 Resumen 2

2. Posicionamiento del Producto 2

2.1 Oportunidades del Negocio 2
2.2 Informe del Problema 2
2.3 Informe del Posicionamiento del Producto 2

3. Patrocinadores y Descripciones de Usuarios 2

3.1 Demografía del Mercado 2
3.2 Resumen de los Patrocinadores 2
3.3 Resumen de usuarios 2
3.4 Ambiente del usuario 2
3.5 Perfiles de los patrocinadores 2
3.5.1 <Nombre del participante> 2
3.6 Perfiles de usuario 2
3.6.1 <Nombre del Usuario> 2
3.7 Patrocinadores Principales / Necesidades de Usuario 2
3.8 Alternativas y Competiciones 2
3.8.1 <UnCompetidor> 2
3.8.2 <OtroCompetidor> 2

4. Resumen del Producto 2

4.1 Perspectiva del producto 2
4.2 Resumen de capacidades 2
4.3 Supuestos y Dependencias 2
4.4 Costo y precios 2
4.5 Licenciamiento e Instalación 2

5. Características del Producto 2

5.1 <UnaCaracterística> 2
5.2 <Otra Característica> 2

6. Restricciones 2

7. Rangos de calidad 2

8. Precedencia y prioridad 2

9. Otros requerimientos del producto 2

9.1 Estándares aplicables 2
9.2 Requerimientos del Sistema 2
9.3 Requerimientos de Ambiente 2
Confidential ¡Error!Nombre desconocido de iii
propiedad de documento., 2002
<Nombre del Proyecto> Versión: <1.0>
Visión Fecha: <dd/mmm/yy>
<identificador del documento> ***FISC VISION # GRUPO

9.4 Requerimientos de ambiente 2

10. Requerimientos de Documentación 2

10.1 Manual de Usuario 2
10.2 Ayuda en línea 2
10.3 Guías de instalación, configuración y archivos Léame 2
10.4 Etiquetando y empaquetando 2

11. A1 Apéndice Uno – Atributos característicos 2

11.1 Estado 2
11.2 Beneficio 2
11.3 Esfuerzo 2
11.4 Riesgo 2
11.5 Estabilidad 2
11.6 Publicación de objetivos 2
11.7 Asignación a 2
11.8 Razón 2

Confidential ¡Error!Nombre desconocido de iv

propiedad de documento., 2002
<Nombre del Proyecto> Versión: <1.0>
Visión Fecha: <dd/mmm/yy>
<identificador del documento> ***FISC VISION # GRUPO

Visión
1. Introducción
[La introducción de la Visión debería proveer un resumen de todo el documento. Debería incluir el
propósito, alcance, definiciones, acrónimos, abreviaciones, referencias y el resumen de esta Visión.]

1.1 Propósito del documento

[Especifica el propósito de esta Visión.]

1.2 Alcance
[Una breve descripción del alcance de esta Visión; lo que se encuentra asociado con el Proyecto, y lo que
sea afectado o influenciado por este documento]

1.3 Definiciones, Acrónimos y Abreviaturas

[Esta sección debería proveer las definiciones de todos los términos, acrónimos, y abreviaturas requeridos
para interpretar apropiadamente la Visión. Esta información puede ser provista por referencia al
Glosario del proyecto.]

1.4 Referencias
[Esta sección debería proveer una lista completa de todos los documentos referenciados en la Visión.
Cada documento debería ser identificado por título, número de reporte (si aplica), fecha, y publicador.
Especifica los fuentes desde los cuales las referencias pueden ser obtenidas. Esta información puede ser
provista por referencia a un apéndice o a otro documento.]

1.5 Resumen
[Esta sección debería describir lo que contiene el resto de la Visión y explicar cómo está organizado el
documento.]

2. Posicionamiento del Producto

2.1 Oportunidades del Negocio
[Describe brevemente las oportunidades de negocio que se pueden encontrar con este proyecto.]

2.2 Informe del Problema

[Proveer un informe resumido del problema que va a ser resuelto por este proyecto. El siguiente formato
puede ser usado:]
El problema de (describe el problema)
Afecta a (los patrocinadores afectados por el
problema).
El impacto es (cuál es el impacto del problema).
Una solución exitosa (listar algunos beneficios claves de una
sería solución exitosa).

2.3 Informe del Posicionamiento del Producto

[Provee un informe resumido al más alto nivel, la posición única que el producto intenta llenar en el
mercado]

Confidencial ¡Error!Nombre desconocido de 1

propiedad de documento., 2000
<Nombre del Proyecto> Versión: <1.0>
Visión Fecha: <dd/mmm/yy>
<identificador del documento> ***FISC VISION # GRUPO

Para (cliente meta)

Quién (informe de necesidades u oportunidades)
El (nombre del producto) es un (categoría del producto)
Que (informe de beneficios claves)
A Diferencia (alternativa competitiva primaria)
Esta Aplicación (informe de diferenciación primaria)

[El informe de posicionamiento del producto comunica las intenciones de la aplicación y la importancia
del proyecto para todos los patrocinadores.]

3. Afectados y Descripciones de Usuarios (puede su equipo, usuario, depto.)

[Para suministrar efectivamente los productos y servicios que conocen las necesidades reales de sus
patrocinadores y usuarios, es necesario identificar e involucrar a todos los afectados como parte del
proceso de Modelaje de Requerimientos. Usted también debería identificar a la comunidad de los
patrocinadores asegurar de están representados adecuadamente. Esta sección proporciona un perfil de los
patrocinadores involucrados en el proyecto y los principales problemas que ellos perciben para ser
solucionados por la solución propuesta. Este apartado no describe los requerimientos o solicitudes
específicas (éstas son capturadas en un artefacto aparte de solicitudes de los patrocinadores). Mas bien
proporciona el fondo y la justificación por los cuales los requerimientos son necesarios.]

3.1 Demografía del Mercado

[Resume la demografía del mercado principal que motiva las decisiones de su producto. Describe y
posiciona los segmentos meta del producto. Estima el tamaño y el crecimiento del mercado mediante el uso
del número de usuarios potenciales, o la cantidad de dinero que sus clientes gastan tratando de conocer
las necesidades que su producto debe llenar. Revisa las principales tendencias y tecnologías de la
industria. Responde las siguientes preguntas estratégicas: ¿Cuál es la reputación de su organización en
este mercado?¿Qué le gustaría ser?¿Cómo alcanzará este producto o servicio sus metas?]

3.2 Resumen de los Afectados

[Presenta una lista resumen de todos los patrocinadores identificados:]
Solo cuadro de nombre y descripción
Nombre Representa Rol
Nombre del tipo de Describe brevemente qué representa Describe brevemente el papel que
patrocinador. con respecto al desarrollo. ellos están jugando en el desarrollo.
p.e. Asegura este….

3.3 Resumen de usuarios

[Presenta una lista resumen de todos los usuarios identificados:]
Nombre Descripción Patrocinador
Nombre del tipo de Describe brevemente qué representan con Lista cómo el usuario está
usuario. respecto al sistema. representado por el

Confidencial ¡Error!Nombre desconocido de 2

propiedad de documento., 2000
<Nombre del Proyecto> Versión: <1.0>
Visión Fecha: <dd/mmm/yy>
<identificador del documento> ***FISC VISION # GRUPO

patrocinador
p.e. Representado mediante
Patrocinador1

3.4 Ambiente del usuario Si se aplican las preguntas, se contestan y añado otras
[Detalla el ambiente de trabajo del usuario destino. Aquí hay algunas sugerencias:
 Número de personas involucradas en la realización de la tarea. ¿Está cambiando?
 ¿Cuán largo es el ciclo de la tarea? ¿Cantidad de tiempo requerido en cada actividad? ¿Está
cambiando?
 Cualquier restricción ambiental única: móvil, externa, etc.
 ¿Cuáles plataformas de sistemas se usan actualmente? ¿Plataformas futuras?
 ¿Qué otras aplicaciones están en uso?¿Su aplicación necesita integrarse con ellas?
Esto es un extracto del Modelo de Negocios el cual podría ser incluido para resaltar las tareas y los
usuarios involucrados, etc]

3.5 Perfiles de los patrocinadores

[Describe cada patrocinador del sistema mediante el llenado en la siguiente tabla para cada patrocinador.
Recuerde que los tipos de patrocinadores pueden ser tan distintos como los usuarios, estrategias
departamentales y desarrolladores técnicos. Un perfil minucioso debería cubrir los siguientes tópicos para
cada tipo de participante:]

3.5.1 <Nombre del participante>

Representate Quién es el participante representativo para el proyecto (opcional – si está
documentado en otra parte). Lo que queremos aquí son los nombres.
Descripción Breve descripción del tipo de participante.
Tipo Calificar la experticia de los patrocinadores
p.e. Guru, experto en el negocio, usuario casual, etc
p.e. Fondo técnico y grado de sofisticación.
Responsabilidades Lista las principales responsabilidades de los patrocinadores con respecto al sistema
que está siendo desarrollado (p.e. su interés como un participante).
Criterio de Éxito ¿Cómo define el éxito el participante? ¿Cuán satisfecho está el participante?
Involucrado en ¿Cómo está involucrado el participante en el proyecto – relacione donde sea posible
con los patrocinadores RUP (p.e. Verificador de requerimientos, etc.)
Entregables Cualquier requerimiento adicional entregable por el participante. Éstos podrían ser
entregables del proyecto o salidas del sistemas bajo desarrollo.
Comentarios / Problemas que interfieren con el éxito y cualquier otra información relevante.
Tópicos

3.6 Perfiles de usuario

[Describe cualquier usuario único del sistema llenando la siguiente tabla para cada tipo de usuario .
Recuerde que los tipos de usuarios pueden ser tan diferentes como los gurús y principiantes. Por ejemplo,
un gurú podría necesitar una herramienta flexible, sofisticada con soporte a través de la plataforma,
mientras un principiante podría necesitar una herramienta que sea fácil de usar y amigable. Un perfil
minucioso debería cubrir los siguientes tópicos:

Confidencial ¡Error!Nombre desconocido de 3

propiedad de documento., 2000
<Nombre del Proyecto> Versión: <1.0>
Visión Fecha: <dd/mmm/yy>
<identificador del documento> ***FISC VISION # GRUPO

3.6.1 <Nombre del Usuario>

Representante Quién es el usuario representativo al proyecto (opcional- si está documentado en
otra parte). Esto a menudo se refiere a el participante que representa el conjunto de
usuarios (p.e. Patrocinador: Patrocinador1)
Descripción Una breve descripción del tipo de usuario.

Tipo Calificar la experticia del usuario p.e. GURU, USUARIO CASUAL, etc.
p.e. Trasfondo técnico y grado de sofisticación.
Responsabilidades Lista de principales responsabilidades del usuario con respecto al sistema (p.e.
capturar detalles del cliente, reportes de producción, trabajo coordinado).
Criterios de Éxito ¿Cómo el usuario define el éxito? ¿Cuán satisfecho está el usuario?
Involucrado en Cuán involucrado está el usuario con el proyecto – relacione donde sea posible con
los patrocinadores RUP (p.e. Verificador de Requerimientos etc.)
Entregables Entregables que el usuario produce, y para quienes...

Comentarios/ Problemas que interfieren con el éxito y cualquier otra información relevante.
Tópicos Tendencia que hace el trabajo del usuario más fácil o difícil.

3.7 Patrocinadores Principales / Necesidades de Usuario

[Lista los principales problemas con soluciones existentes como son percibidas por el patrocinador.
Clarifica los siguientes tópicos para cada problema:

 ¿Cuáles son las razones para este problema?

 ¿Cómo se soluciona actualmente?
 ¿Cuáles soluciones desea el patrocinador?

Es importante entender la importancia relativa que el patrocinador pone en solucionar en cada problema.
Clasifique y acumule las técnicas votadas que indican problemas que deben ser resueltos versus los
puntos que ellos querían resolver.

Llene la siguiente tabla – si se están usando RequisitePro para capturar las Necesidades éstas podrían ser
un extracto/reporte de la herramienta.

Necesidad Prioridad Concierne Solución Actual Soluciones Propuestas

Mensajes emitidos

3.8 Alternativas y Competiciones

[Identifique alternativas que el patrocinador percibe como disponibles. Estas pueden incluir comprar un
producto del competidor, comprar una solución hecha a la medida o simplemente el estatus quo. Liste
cualquier elección competitiva conocida que exista o pueda llegar a estar disponible. Incluya las
principales fortalezas y debilidades de cada competidor como percibidas por el patrocinador.

Confidencial ¡Error!Nombre desconocido de 4

propiedad de documento., 2000
<Nombre del Proyecto> Versión: <1.0>
Visión Fecha: <dd/mmm/yy>
<identificador del documento> ***FISC VISION # GRUPO

3.8.1 <UnCompetidor>

3.8.2 <OtroCompetidor>

4. Resumen del Producto

[Esta sección proporciona una vista de alto nivel del producto, interfaces con otras aplicaciones y
configuraciones de sistemas. Esta sección usualmente consiste de tres subsecciones, como sigue:
 Perspectiva del producto
 Funciones del producto
 Supuestos y dependencias ]

4.1 Perspectiva del producto Es como el 2.1, pero la perspectiva es gráfica

[Esta sección de la Visión del documento debe colocar el producto en perspectiva a otros productos
relacionados y el ambiente del usuario. Si el producto es independiente y totalmente auto-contenido,
menciónelo aquí. Si el producto es un componente de un gran sistema, entonces, esa sección debería
mencionar como estos sistemas interactúan y deberían identificar las interfaces relevantes entre los
sistemas. Una manera fácil de desplegar los principales componentes de un gran sistema, interconexiones
e interfaces externas es mediante un diagrama de bloque.]

4.2 Resumen de capacidades del software

[Resume los principales beneficios y características que el producto proporcionará. Por ejemplo, un
documento de Visión para un sistema de soporte al cliente puede usar esta parte para guiar la
documentación del problema, dirigir y reportar el estado sin mencionar la cantidad de detalles que cada
una de esas funciones requiere.
Organice las funciones de manera que la lista sea entendible para el cliente o cualquier otra persona que
lea el documento por primera vez. Una simple tabla listando los principales beneficios y sus
características de soporte podría ser suficiente. Por ejemplo:]
En vez de un cuadro, se lista normalmente
Sistema de Soporte Al Cliente
Beneficio del Cliente Características de Soporte
El nuevo equipo de soporte puede La base de Conocimiento asiste al
aumentar rápidamente la velocidad. personal de soporte en la rápida
identificación de reparaciones conocidas y
los errores no solucionados.
La satisfacción del cliente aumenta Los problemas son clasificados por
debido a que nada deja de funcionar separado, clasificados y seguidos durante
por fallas del sistema. el proceso de resolución. La notificación
automática ocurre para cualquier asunto
anterior..
La Gerencia puede identificar las Los reportes de tendencia y distribución
áreas del problema y medir la carga permiten un alto nivel de revisión del
de trabajo del personal. estado del problema.
Los equipos de soporte distribuidos Los servidores de replicación permiten
pueden trabajar juntos para resolver actualizar la información de la base de
los problemas. datos compartida a través de la empresa
Los clientes pueden ayudarse ellos La base de Conocimiento puede hacerse
mismos, disminuyendo los costos de disponible a través de Internet. Incluye
soporte y mejorando el tiempo de capacidades de búsqueda de hipertexto y
respuesta. motores gráficos de consulta.
Confidencial ¡Error!Nombre desconocido de 5
propiedad de documento., 2000
<Nombre del Proyecto> Versión: <1.0>
Visión Fecha: <dd/mmm/yy>
<identificador del documento> ***FISC VISION # GRUPO

4.3 Supuestos y Dependencias

[Lista cada uno de los factores que afectan las características establecidas en el documento de Visión.
Lista los supuestos que, si cambiaran, alterarían el documento de Visión. Por ejemplo, un supuesto puede
establecer que un sistema operativo específico estará disponible para el hardware destinado para el
producto de software. Si el sistema operativo no está disponible el documento de Visión debería cambiar..]

4.4 Costo y precios

[Para productos vendidos para clientes externos y para muchas aplicaciones “en casa”, los asuntos de
costo y precio pueden impactar directamente la definición e implementación de las aplicaciones. En esta
sección, registre cualquier limitación de costo y precio que sea relevante. Por ejemplo, costos de
distribución, (número de disquetes y número de CD-ROMs) u otras limitaciones de costos de bienes
vendidos (manuales, empaquetamiento) puede ser material para el éxito de los proyectos o irrelevante
dependiendo de la naturaleza de la aplicación.]

4.5 Licenciamiento e Instalación Diferentes sistemas operativos que se necesitan

[Los asuntos de licenciamiento e instalación también pueden impactar directamente el esfuerzo de
desarrollo. Por ejemplo, la necesidad del soporte, seguridad con palabras de paso o el licenciamiento de
red crearán requerimientos adicionales del sistema que deben ser considerados en el esfuerzo de
desarrollo. Los requerimientos de instalación también pueden afectar la codificación o crear la necesidad
para instalación de software separado

5. Características del Producto

[Listar y describir brevemente las características del producto. Las características son las capacidades de
alto nivel del sistema que son necesarias para brindar beneficios a los usuarios. Cada característica es un
servicio externamente deseado que requiere típicamente una serie de entradas para lograr el resultado
deseado. Por ejemplo, una característica de un sistema de seguimiento de problemas podría ser la
habilidad de proporcionar reportes de tendencia. Como la figura del modelo de caso de uso toma forma,
actualiza la descripción para referir a los casos de uso.
Debido a que el Documento de Visión es revisado por una extensa variedad de personal involucrado, el
nivel de detalle debería ser más general para que cada persona lo entienda. No obstante, suficiente
detalle debería estar disponible para proporcionar al equipo de trabajo la información que ellos necesitan
para crear un modelo de caso de uso.
Para administrar eficientemente la complejidad de la aplicación recomendamos para cualquier nuevo
sistema o una actualización a un sistema existente, las capacidades son abstraídas a un nivel
suficientemente alto como características de resultado de 25-99.Estas características proporcionan la base
fundamental para la definición del producto, administración del alcance y administración del proyecto.
Cada característica será ampliada en mayor detalle en el modelo de casos-de-uso.
A lo largo de esta sección, cada característica debería ser percibible externamente por usuarios,
operadores y otros sistemas externos. Estas características deben incluir una descripción de las funciones
y de cualquier tema relevante de usabilidad que deba ser tratado. Los siguientes lineamientos se aplican:
 Permite el diseño. Mantiene descripciones de características a un nivel general. Se enfoca en las
capacidades necesarias y en el por qué, (no en el cómo) ellas deberían ser implementadas.
 Si usted está usando el conjunto de herramientas del Requisite Pro, todas deberían ser seleccionadas
como requerimientos del tipo para una fácil referencia y seguimiento]

Confidencial ¡Error!Nombre desconocido de 6

propiedad de documento., 2000
<Nombre del Proyecto> Versión: <1.0>
Visión Fecha: <dd/mmm/yy>
<identificador del documento> ***FISC VISION # GRUPO

5.1 <UnaCaracterística>

5.2 <Otra Característica>

6. Restricciones
[Anote cualquier restricción de diseño, restricción externa u otras dependencias.]

7. Rangos de calidad
[Define los rangos de calidad para desempeño, robustez, tolerancia a fallos, usabilidad y características
similares que no son capturadas en el Conjunto de Características.]

8. Precedencia y prioridad
[Define la prioridad de las diferentes características del sistema.]

9. Otros requerimientos del producto

[A un alto nivel, lista los estándares de aplicación, hardware o requerimientos de plataformas,
requerimientos de desempeño y requerimientos ambientales.]

9.1 Estándares aplicables

[Lista todos los estándares con los que el producto debe cumplir. Éstos pueden incluir estándares de
comunicación (TCP/IP, ISDN), legales y regulatorios (FDA, UCC), estándares que se adapten a los
estándares de plataformas de comunicación (Windows, Unix, etc), estándares de calidad y seguridad (UL,
ISO, CMM).]

9.2 Requerimientos del Sistema

[Define cualquier requerimientos de sistema necesario para soportar la aplicación. Éstos pueden incluir
sistemas operativos soportados en servidores y plataformas de red, configuraciones, memoria, y software
periférico.]

9.3 Requerimientos de Desempeño

[Use esta sección para detallar los requerimientos de desempeño. Entre los asuntos de desempeño se
pueden incluir aspectos como factores de carga, ancho de banda o capacidad de comunicación,
rendimiento, precisión, confiabilidad o tiempos de respuesta bajo una variedad de condiciones de carga .]

9.4 Requerimientos de ambiente

[Detalla los requerimientos de ambientes necesarios. Para los sistemas basados en hardware, los
cuestiones de ambiente pueden incluir temperatura, humedad, radiación, etc. Para las aplicaciones de
software, los factores ambientales pueden incluir condiciones de uso, ambientes de usuario, disponibilidad
de recursos, asuntos de mantenimiento, manejo de errores y recuperación]

10. Requerimientos de Documentación

[Esta sección describe la documentación que debe ser desarrollada para soportar la puesta en marcha
exitosa de la aplicación.]

10.1 Manual de Usuario

[Describe el propósito y contenidos del manual del usuario. Discute la longitud deseada, el nivel de

Confidencial ¡Error!Nombre desconocido de 7

propiedad de documento., 2000
<Nombre del Proyecto> Versión: <1.0>
Visión Fecha: <dd/mmm/yy>
<identificador del documento> ***FISC VISION # GRUPO

detalle, índices, glosario de términos, tutoriales versus la estrategia del manual de referencia, etc. Las
restricciones de formato e impresión deben ser también identificadas.]

10.2 Ayuda en línea

[Muchas aplicaciones proporcionan un sistema de ayuda en línea para asistir al usuario. La naturaleza de
estos sistemas es única para del desarrollo de aplicaciones ya que combinan aspectos de programación
(hiperligas, etc) así como aspectos de escritura técnica (organización, presentación). Muchos han
descubierto que el desarrollo de un sistema de ayuda en línea es un proyecto dentro de un proyecto que
beneficia desde la administración del alcance y planeación de actividades.]

10.3 Guías de instalación, configuración y archivos Léame

[Un documento que incluye instrucciones de instalación y guías de configuración, es importante para
ofrecer una solución completa. También, un archivo Léame es incluido normalmente como un componente
estándar. El Léame puede incluir una sección de “Que es lo nuevo en esta versión”, y los temas de
discusión de compatibilidad con versiones anteriores. La mayoría de usuarios también apreciarían
documentación que defina cualquier error conocido y los no solucionados.]

10.4 Etiquetando y empaquetando

[El estado del al arte de las aplicaciones de hoy proveen una apariencia consistente que inicia con
empaquetamiento del producto y se manifiesta a través de menús de instalación, despliegue de pantallas,
sistemas de ayuda, diálogos GUI, etc. Esta sección define las necesidades de etiquetado que deben ser
incorporadas en el código. Ejemplos: incluir derechos de autor, notas de patentes, logos corporativos,
íconos estándar y otros elementos gráficos., etc.]

11. A1 Apéndice Uno – Atributos característicos

[Las características podrían ser atributos dados que puedan ser usados para evaluar, dar seguimiento,
priorizar y administrar los ítemes del producto propuesto por la administración. Todos los tipos de
requerimientos y atributos podrían ser resaltados en el Plan de Administración de Requerimientos, sin
embargo podría desearse listar y describir brevemente los atributos para características que han sido
seleccionadas. Las siguientes subsecciones representan un conjunto de atributos característicos
sugeridos.]

11.1 Estado
[Se establece después de negociación y revisión por el equipo de administración del proyecto. Da
seguimiento al progreso durante la definición de la línea base del proyecto.]
Propuesto Usado para describir características que están bajo discusión pero
todavía no han sido revisadas y aceptadas por el ‘canal oficial’, tales
como un grupo de trabajo consistente de representantes del equipo
de trabajo, la administración del producto y la comunidad de clientes
y usuarios.
Aprobado Capacidades que son útiles y factibles y han sido aprobadas para
implementarlas por el canal oficial.

Incorporado Características incorporadas dentro de la versión original del

producto un punto específico en el tiempo.

11.2 Beneficio
[Se deben establecer por medio del administrador del producto o el analista del negocio. Los
requerimientos no son definidos de la misma manera. Se debe priorizar los requerimientos de acuerdo a su
Confidencial ¡Error!Nombre desconocido de 8
propiedad de documento., 2000
<Nombre del Proyecto> Versión: <1.0>
Visión Fecha: <dd/mmm/yy>
<identificador del documento> ***FISC VISION # GRUPO

beneficio relativo hacia el cliente final, de manera que exista un dialogo entre clientes, analistas y
miembros del grupo de desarrollo. La definición de beneficios se utiliza para manejar el alcance y
determinar las prioridades de desarrollo.]

Críticas Características esenciales. Los fallos que se produzcan al implementar

indican que el sistema no conoce plenamente las necesiades de los
clientes. Todas las características críticas deben ser implementadas en la
liberación del producto.
Importantes Características importantes para la eficacia y la eficacia del sistema para
la mayoría de las aplicaciones. Las funciones no se pueden proporcionar
fácilmente de una cierta u otra manera. La carencia de la inclusión de
una característica importante puede afectar la satisfacción del cliente o
del usuario, además, la liberación no será retrasada debido a la carencia
de ninguna característica importante.
Útiles Características que son útiles en la mayoría de las aplicaciones o las que
pueden ser usadas menos frecuentemente.
No producen impacto en la satisfacción del usuario/cliente si tal
característica no es incluida en esta versión

11.3 Esfuerzo
[Establecer el equipo de desarrollo. Debido a que algunas características requieren más tiempo y recursos
que otras, se debe estimar el número de personas o semanas por persona, líneas de código requeridas por
funcionamiento, por ejemplo, la mejor manera de calibrarla complejidad y las expectativas de lo que se
puede o no se puede hacer dado por un periodo de tiempo. Se utiliza para administrar el alcance y
determinar las prioridades de desarrollo.]

11.4 Riesgo
[El equipo del desarrollo se basó en la probabilidad de que el proyecto experimentará eventos no
deseados, tales como el costo sobreestimado, los retardos del horario o aún la cancelación. La mayoría
de los administradores de proyectos encuentran categorías de riesgos tales como suficiente alto, medio y
bajo, aunque gradaciones más finas son posibles. El riesgo puede ser evaluado a menudo indirectamente
midiendo la incertidumbre (el rango) de la estimación del horario de los equipos de proyectos.]

11.5 Estabilidad
[El conjunto del analista y del equipo del desarrollo se basó en la probabilidad de que la característica
cambiará o la comprensión del equipo de la característica cambiará. Ayudaban a establecer prioridades
del desarrollo y a determinar esos ítemes para los cuales la respuesta adicional es la siguiente acción
apropiada.]

11.6 Publicación de objetivos

[Registra las versión de producto en la cual se pretende que la característica aparezca por primera vez.
Este campo puede ser usado para colocar características desde el documento de Visión hacia un
entregable particular. Cuando es combinado con el campo de estado, su equipo puede proponer, registrar
y discutir varias características del entregable sin consignarlas al desarrollo.
Solo aquellas características cuyo estatus sea incorporado y aquellas en las que la liberación definida sea
Confidencial ¡Error!Nombre desconocido de 9
propiedad de documento., 2000
<Nombre del Proyecto> Versión: <1.0>
Visión Fecha: <dd/mmm/yy>
<identificador del documento> ***FISC VISION # GRUPO

implementada. Cuando se maneja el alcance, la liberación puede ser mejorada y su mejora de be ser
incluida en el documento de Visión dentro de un cronograma para su posterior liberación.]

11.7 Asignación a
[In muchos proyectos, las características pueden ser asignadas por equipos responsables de levantar los
requerimientos de software y su implementación. Esta ayudará a cada uno en el equipo de proyecto a
entender mejor las responsabilidades.

11.8 Razón
[Esta sección es utilizada para seguir la fuente de las características requeridas. Los requerimientos
existen por diversas razones. En esta sección se establece una explicación o una referencia a una
explicación. Por ejemplo, las referencias podrían ser a una página o línea de especificaciones de
productos o a entrevistas con los usuarios.]

Confidencial ¡Error!Nombre desconocido de 10

propiedad de documento., 2000