VISIÓN

Historia de Cambios

FECHA VERSIÓN DESCRIPCIÓN AUTOR

<dd/mmm/aa> <1.0> <describir los cambios o <nombre del autor o
inclusiones en el documento> autores>

1. <Nombre del Sistema>

[Se indica el nombre del sistema a desarrollar]

2. Objetivos
[Los objetivos del sistema se describen con un propósito claro y se redactan en
infinitivo. Se pueden definir, luego de colectar, analizar y definir las necesidades y
características de alto nivel que el usuario tiene con respecto al producto. Se
concentra en las capacidades que el usuario destino necesita y porque estas
necesidades existen. Separar en generales y específicos]

3. Alcance o campo de acción

[Los alcances se describen brevemente, tomando en cuenta a los sistemas externos
o personas que están asociados o influenciados por el sistema a desarrollar. Se
describen los procesos que serán incluidos en el estudio y a aquellos que no van a
ser contemplados por alguna razón y que se quieran mencionar o resaltar a modo
de aclaración]

4. Referencias
Esta sección debe contener:
Proceso de Practicas PreProfesionales http://up.upeu.edu.pe/
❑ Una lista completa de todas las referencias citadas en cualquier parte de este
documento.
❑ Para cada documento, identificar título, número (si es aplicable), fecha y
organismo publicador.
❑ También especificar el origen de cada referencia o el documento (anexo) en donde
pueden ser ubicada.
5. Posicionamiento del sistema

5.1 Objeto de estudio

[Describir brevemente la organización en la cual se va a implantar el sistema. Sus
características en el mercado. Su posición frente a la compentencia, etc.]

5.2 Oportunidad de negocio

[Describir brevemente la oportunidad de negocio que representa para la
organización la implantación del Sistema propuesto, tanto al interior cómo en sus
relaciones con el exterior.]
5.3 Declaración del problema a resolver
[Proporcionar una declaración sumarizada del problema que será resuelto con el
proyecto. Puede existir más de uno por resolver. Usar el siguiente formato para
cada problema]
El problema de [describir el problema]
afecta [mencionar a los usuarios internos o externos
afectados]
El impacto está [mencionar el impacto del problema...las
consecuencias, las pérdidas]
Una solución adecuada [listar algunos beneficios clave de una solución
sería exitosa]

5.4 Declaración del Posicionamiento del Producto

[Proporcionar una declaración total sumarizada y de alto nivel acerca de la única
posición que el producto desea alcanzar en el mercado. El siguiente formato debe
ser usado:

Para [nombre del cliente destino]

Quién [declarar las necesidades u oportunidades que
busca el cliente destino]
El (producto) es un [categoría del producto. Ej Software de
Aplicación XX]
Que [declarar el beneficio clave; esto es, una razón
obligatoria para su compra.]
A diferencia de [mencionar alternativa de competencia principal]
Nuestro producto [mencionar la diferenciación o la ventaja
competitiva del producto]

[Una declaración de la posición del producto comunica la intención y el propósito de

su aplicación y la importancia del proyecto para todo el personal involucrado.].
6. Descripción de los Usuarios del Sistema
[Para proporcionar productos y servicios que satisfagan las necesidades reales los
usuarios del sistema, es necesario entender los problemas que enfrentan cuando
realizan sus tareas. Esta sección deberá presentar el perfil de los usuarios
planeados y los problemas clave que limitan su productividad. No se deberá usar
para declarar requerimientos específicos, en cambio, proporciona el background y
la justificación de porqué son necesarios los requerimientos].
6.1 Usuario / Demografía del mercado
Describir de manera resumida la demografía clave del mercado, que motiva las
decisiones acerca del sistema. Describir y posicionar los segmentos del mercado
destino. Estimar el tamaño y crecimiento del mercado mediante el uso del número
de usuarios potenciales y la cantidad de dinero que los clientes gastan tratando de
resolver las necesidades, que el producto o mejora va a satisfacer. Resumir las
mejores tendencias y tecnologías de la industria. Basarse en las respuestas a las
siguientes preguntas estratégicas:
❑ ¿Cuál es la reputación de la organización en estos mercados?
❑ ¿Cómo se desea que sea dicha reputación?
❑ ¿Cómo es que este producto o servicio brindará soporte a los objetivos de la
organización?]
6.2 Perfiles de Usuario
Describir cada tipo de usuario. Estos tipos pueden ser tan divergentes como
expertos y novatos. Por ejemplo un experto puede necesitar una herramienta
flexible pero sofisticada de soporte a la revisión de la plataforma en cambio un
novato puede necesitar una herramienta fácil de usar y que sea amigable. El perfil
debe cubrir los siguientes tópicos para cada tipo de usuario:

Nombre Responsa- Background Entregables Reporta a Problemas

Usuario bilidades Clave Técnico
(Rol)

6.3 Ambiente del Usuario

[Describir con detalle el ambiente de trabajo del usuario destino. Algunas
sugerencias:
❑ ¿Cuál es el número de personas involucradas en completar una tarea? ¿Está
cambiando (aumentando o disminuyendo?
❑ ¿Cuánto tiempo demora el ciclo de vida de la tarea? ¿Está cambiando? Describirlo
desde el punto de vista de la atención y cómo se ve perjudicada.
❑ Restricciones del ambiente como: es móvil, en espacio abierto, durante un vuelo,
etc.?
❑ ¿Qué plataformas de sistemas está en uso? ¿Existirán futuras plataformas?
 ❑ ¿Qué otras aplicaciones están en uso? ¿La aplicación a ser desarrollada necesita
ser integrada con la que ellos usan actualmente.
6.4 Alternativas y Competencias
[Identificar las alternativas que los usuarios y funcionarios han evaluado como
disponibles. Estas pueden incluir comprar un producto de la competencia,
desarrollar una solución progresiva hecha en casa, o simplemente mantener el
status quo. Listar cada alternativa competitiva que existe y que puede estar
disponible. Describir las debilidades y fortalezas tal y como son percibidas por el
usuario. Adjunte el benchmarking y presente el siguiente cuadro resumen.]

Alternativa Producto o Solución Fortalezas Debilidades

Competitiva

7. Resumen del Producto

Esta sección proporciona una vista de alto nivel de las capacidades, interfaces con
otras aplicaciones y configuración del sistema. Consiste de tres subsecciones:
❑ Perspectiva
❑ Funciones o Tareas a Automatizar
❑ Suposiciones y Dependencias

7.1 Perspectiva del Producto

[En esta subsección se debe presentar al producto en perspectiva con otros
productos y usuarios. Si el producto es independiente y es un paquete, declararlo
aquí. Si el producto es un componente de un sistema grande, en esta sección se
describen las interacciones. Una manera sencilla de describir las interacciones es
mediante un diagrama de bloques.]
7.2 Resumen de Capacidades
[Resumir los grandes beneficios y características de las funciones que el producto
tiene. Describir con profundidad las tareas o el ámbito de la implementación]
Organizar las funciones para que sean comprensible para el usuario final. Por
ejemplo:

Función Características Beneficios

Dar Soporte al ❑ Cuenta con una base de ❑ Nuevo staff de soporte
Sistema conocimiento que da asistencia que rápidamente toma
al personal de soporte en la decisiones y las ejecuta.
identificación rápida de ❑ La satisfacción del
soluciones y experiencias usuario se incrementa
anteriores. debido a que no hay
❑ Los problemas son enumerados, problemas de gran
clasificados y seguidos de severidad.
 manera única a través de un
proceso de resolución.
.... .... ...

7.3 Suposiciones, dependencies y riesgos

[Listar cada factor que afecta a diferentes características mencionadas. Listar las
suposiciones e hipótesis que si cambian, alterarán el contenido de la Visión.].

8. Características de los Atributos

[Las características o funciones del sistema deben tener atributos que pueden
usarse para evaluar, validar, priorizar y administrar los items propuestos para la
implementación. Enumerar las características que se estan evaluando y ponderando
en la lista de requerimientos].

9. Características del Producto

[Listar y describir las características del producto. Las características son las
capacidades de alto nivel del sistema que son necesarias para que el usuario tenga
beneficios. Cada característica tendrá una serie de inputs y outputs para alcanzar
el resultado deseado.
La visión debe de contener el nivel de detalle para que el equipo tenga la
información necesaria para crear un modelo use-case.
Para administrar efectivamente una aplicación compleja es necesario identificar y
desarrollar las características en un nivel muy alto para asegurar que 25-99
resulten. Cada característica se expandirá en mayor nivel de detalle en el modelo
de casos de uso.
Evitar el diseño. Conservar una descripción de nivel general. Focalizar en las
capacidades requeridas y porque (no en como).]
Cada característica debe ser redactada en infinitivo y descrita de manera que pueda
ser percibida externamente por usuario operadores y otros sistemas externos.
Aplicar el cuadro siguiente, tomando como base los requerimientos de la matriz.:

Nombre de la Descripción Inputs Outputs Usuario

Característica Responsable

10. Restricciones
[Anotar todas las restricciones de diseño, restricciones o parámetros externos y
otras dependencias.]

11. Otros Requerimientos

[Listar en un alto nivel, los estándares y requerimientos de plataforma de
hardware, rendimiento y ambiente.]
11.1 Estándares
 [Listar todos los estándares con los que el negocio debe cumplir. Pueden ser
legales, de comunicación (TCP/IP, ISDN), de plataformas (Windows, Unix, etc.), de
comercio electrónico, y de calidad (ISO, CMM).].
11.2 Requerimientos de la Implementación
[Definir los requerimientos de soporte a la aplicación: configuraciones, memoria,
periféricos, plataforma de redes, y licencias.] .
11.3 Requerimientos de Rendimiento
[Detallar los requerimientos de rendimiento, tiempos de respuesta, anchos de
banda, capacidad de comunicación y confiabilidad.].
11.4 Requerimientos del Medio Ambiente.
[Detallar los requerimientos de ambiente necesarios. Para el hardware pueden ser:
temperatura, humedad, tolerancia a fallas, radiación, etc. Para el software:
condiciones de uso, disponibilidad de recursos, mantenimiento, recuperación y
soporte a errores.].

12. Requerimientos de Documentación

[Esta sección describe los requerimientos de documentación que debe ser
desarrollada como soporte al desarrollo de la aplicación. ]
12.1 Manual de Usuario
[Describe el propósito y contenido del Manual de Usuario, longitud deseada, nivel
de detalle, glosario de términos, tutoriales. Requisitos de formato e impresión
también deben de describirse. ]
12.2 Ayuda en Línea
[Muchas aplicaciones proporcionan un sistema de ayuda en línea para asistir al
usuario. La naturaleza de estos sistemas son únicos y combinan aspectos de
programación (hipervínculos) con los de escritura técnica. (organización,
presentación). ]
12.3 Guías de Instalación
[Es un documento que incluye instrucciones para instalación y guías de
configuración y que es muy importante para completar la solución de un software.
También se utilizan los archivos “Read Me” como un componente estándar del
paquete. Este archivo incluye la sección “Lo nuevo de ésta versión es:” y una
discusión de la compatibilidad con otras versiones. ]
12.4 Paquetes
[El estado del arte hoy en día proporciona una consistencia en la presentación que
comienza con el paquete y se manifiesta a través de menús de instalación,
pantallas de notificación, sistemas de ayuda, diálogos, etc. Esta sección define la
necesidad de incluir el etiquetado en el código. Ejemplos: notificaciones de
copyrights y patentes, logos corporativos, íconos y gráficos estándar, etc.]