VISION (PROYECTO PEQUEÑO)

1. Introducción[El propósito de este documento es recoger, analizar y definir las necesidades y características del << Nombre sistema >>. Se centra en las capacidades requeridas por las partes interesadas y los usuarios de destino, y por qué existen estas necesidades. Los detalles de cómo el nombre Sistema satisface estas necesidades se detallan en el caso de uso y especificaciones suplementarias.][La introducción del documento Visión proporciona una visión general de todo el documento. Incluye el propósito y las referencias de este documento Visión.]

1.1.Referencias[Esta subsección provee una lista completa de todos los documentos referenciados en cualquier lugar en el documento Visión. Identifique cada documento por título, número de reporte si, fecha, organización que publica aplicable. Especifique las fuentes de donde se pueden obtener las referencias. Esta información puede ser proporcionada por referencia a un apéndice o para otro documento.]

2. Posicionamiento2.1.Declaración del problema

[Proporcionar una declaración que resume el problema a resolver por este proyecto. Se puede utilizar el siguiente formato:]

El problema de [describa el problema]afecta [las partes interesadas afectadas por el problema]Cuyo impacto es [¿Qué es el impacto del problema?]Una solución exitosa seria [enumerar algunos de los beneficios clave de una solución

exitosa]

2.2.Declaración de posición del producto[Proporcionar una resumir general de los estados, al más alto nivel, la posición única del producto tiene la intención de llenar en el mercado. El siguiente formato se puede utilizar:]

para [cliente objetivo]Quién [declaración de la necesidad u oportunidad]

El (nombre del producto) es un [categoría de producto]Eso [declaración de beneficio clave; es decir, la razón de peso para

comprar]A diferencia de [alternativa competitiva primaria]nuestro producto [declaración de la diferenciación primaria]

[Una declaración de posición producto se comunica la intención de la aplicación y la importancia del proyecto a todo el personal en cuestión.]

3. Las partes interesadas y descripción de usuarios [Para proporcionar efectivamente los productos y servicios que cumplen es necesario interesan en su negocio y necesidades de los usuarios reales para identificar e involucrar a todas las partes interesadas como parte del proceso de modelado de requisitos. También debe identificar a los usuarios del sistema y asegurarse de que la

comunidad de interesados los representa adecuadamente. En esta sección se ofrece un perfil de los interesados y usuarios involucrados en el proyecto, y los principales problemas que perciben ser abordado por la solución propuesta. No describe sus peticiones o requerimientos específicos ya que estos son capturados en una las solicitudes de las partes interesadas artefacto separado. En su lugar, se presentan los antecedentes y la justificación de por qué se necesitan los requisitos.]

3.1. Resumen de las partes interesadas[Hay una serie de grupos de interés con un interés 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 sección 3.2.)]

NOMBRE DESCRIPCION RESPONSABILIDADES[Nombre del tipo de las partes interesadas.]

[Describa brevemente la parte interesada.]

[Resumir las principales responsabilidades de las partes interesadas en relación con el sistema en desarrollo; es decir, su interés como parte interesada. Por ejemplo, este grupo de interés:asegura que el sistema será mantenibleasegura que habrá una demanda de mercado de las características del productomonitorea el progreso del proyectoaprueba la financiacióny así sucesivamente]

3.2.Resumen usuario[Presentar una lista de resumen de todos los usuarios identificados.]

NOMBRE DESCRIPCION RESPONSABILIDADES

RESUMEN

[Nombre del tipo de usuario.]

[Describa revemente lo que representan en relación con el sistema.]

[Enumere las principales responsabilidades de los usuarios en relación con el sistema en desarrollo; por ejemplo:capta detallesproduce informescoordina el trabajoetcétera]

[Si el usuario no está representado directamente, identificar qué partes interesadas es responsable de representar el interés del usuario.]

3.3.Usuario medio ambiente[Detalle del entorno de trabajo del usuario de destino. He aquí algunas sugerencias: Número de personas que participan en la realización de la tarea? ¿Es este cambio? ¿Cuánto dura un ciclo de la tarea? Cantidad de tiempo que pasó en cada actividad? ¿Es este cambio? Cualquier limitaciones ambientales únicas: móviles, al aire libre, durante el vuelo, y así sucesivamente? ¿Qué plataformas de sistema están en uso hoy en día? Plataformas futuras? ¿Qué otras aplicaciones están en uso? ¿Necesita su solicitud para integrarse con ellos? Aquí es donde los extractos del modelo de negocio podrían ser incluidos para delinear la tarea y los roles involucrado, y así sucesivamente.]

3.4. Resumen de las partes interesadas clave o necesidades de los usuarios

[Enumerar los principales problemas con las soluciones existentes según la percepción de la parte interesada o el usuario. Aclarar las siguientes cuestiones para cada problema:

• ¿Cuáles son las razones de este problema?

• ¿Cómo se resuelve ahora?

• ¿Qué soluciones quieren la parte interesada o usuario?]

[Es importante comprender la importancia relativa de los lugares interesados o usuarios en la solución de cada problema. Clasificación y técnicas de voto acumulativo indicar problemas que deben ser resueltos frente cuestiones que les gustaría abordar.

Complete el siguiente cuadro, si a través de Rational RequisitePro para captar las necesidades, esto podría ser un extracto o informe de esa herramienta.]

Necesidad Prioridad Preocupaciones Solución actual

Soluciones Propuestas

Los mensajes de difusión

3.5. Alternativas y Competencia

[Identificar alternativas el interesado percibe como disponible. Estos pueden incluir la compra de producto de la competencia, la construcción de una solución de cosecha propia, o simplemente mantener el status quo. Haga una lista de opciones competitivas conocidos que existen o que pueden estar disponibles. Incluya las principales fortalezas y debilidades de cada competidor según la percepción de la parte interesada o el usuario final.]

4. Descripción del producto

[En esta sección se ofrece una visión de alto nivel de las capacidades de los productos, interfaces con otras aplicaciones y configuraciones del sistema. Esta sección generalmente consta de dos subsecciones, como sigue:

• Perspectiva del producto

• Suposiciones y dependencias]

4.1. Producto Perspectiva

[Esta sección del documento Visión pone el producto en una perspectiva a más productos y el entorno del usuario. Si el producto es independiente y totalmente autónomo, indicar aquí. Si el producto es un componente de un sistema más grande, entonces esta subsección necesita relacionarse cómo estos sistemas interactúan y se necesita identificar las interfaces entre los sistemas pertinentes. Una forma fácil de mostrar los componentes principales del sistema más grande, interconexiones, y con interfaces externas es un diagrama de bloques.]

4.2. Suposiciones y dependencias

[Lista de cada factor que afecta a las características indicadas en el documento de la Visión. Lista de supuestos que, si cambia, alterarán el documento Visión. Por ejemplo, una suposición puede indicar que un sistema operativo específico estará disponible para el hardware designado para el producto de software. Si el sistema operativo no está disponible, el documento Visión tendrá que cambiar.]

5. Características del producto

[Enumere y describa brevemente las características del producto. Las características son las capacidades de alto nivel del sistema que son necesarias para ofrecer 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 capacidad de proporcionar informes de tendencias. Como el modelo de casos de uso toma forma, actualizar la descripción para referirse a los casos de uso.

Debido a que el documento de la Visión es revisada por una amplia variedad de personal involucrado, el nivel de detalle debe ser lo suficientemente general para que todos puedan entender. Sin embargo, el detalle suficiente debe estar disponible para proveer al equipo con la información que necesitan para crear un modelo de casos de uso.

Para gestionar con eficacia la complejidad de aplicación, se recomienda para cualquier nuevo sistema, o un incremento de un sistema existente, capacidades abstraerse a un nivel suficientemente alto de modo 25-99 dispone resultado. Estas características constituyen la base fundamental para la definición del producto, gestión del alcance, y gestión de proyectos. Cada característica se ampliará en mayor detalle en el modelo de casos de uso.

A lo largo de esta sección, cada función será externamente perceptible por los usuarios, operadores, u otros sistemas externos. Estas características deben incluir una descripción de la funcionalidad y las cuestiones de usabilidad relevantes que deben ser abordados. Las siguientes directrices se aplican:

• Evite el diseño. Mantenga descripciones de las características a nivel general. Centrarse en las capacidades necesarias y por qué (no cómo) que deben ser implementadas.

• Si está utilizando el kit de herramientas de Rational RequisitePro, todos necesitan ser seleccionado como requisitos de tipo para facilitar la consulta y el seguimiento.]

[Definir la prioridad de las diferentes funciones del sistema. Incluya, si es útil, atributos tales como la estabilidad, beneficio, esfuerzo y riesgo.]

6. Otros Requisitos del producto

[A un alto nivel, la lista de las normas aplicables, hardware o requisitos de la plataforma; requisitos de desempeño; y los requisitos ambientales.

Definición de los rangos de calidad para un rendimiento, robustez, tolerancia a fallos, facilidad de uso y características similares que no son capturados en el conjunto de características.

Anote cualquier restricción de diseño, las restricciones externas, u otras dependencias.

Definir los requisitos específicos de documentación, incluyendo manuales de usuario, ayuda en línea, instalación, etiquetado y envasado.

Definir la prioridad de estos otros requisitos del producto. Incluya, si es útil, atributos tales como la estabilidad, beneficio, esfuerzo y riesgo.]

7. Requisitos de Documentación

[Esta sección describe la documentación que debe ser desarrollado para apoyar la implementación de aplicaciones con éxito.]

7.1. Manual del usuario

[Describir la finalidad y el contenido del Manual de Usuario. Discuta la longitud deseada, nivel de detalle, la necesidad de índice, glosario de términos, tutorial frente estrategia manual de referencia, y así sucesivamente. Limitaciones de formato y la impresión también deben ser identificados.]

7.2. Ayuda en línea

[Muchas aplicaciones ofrecen un sistema de ayuda en línea para ayudar al usuario. La naturaleza de estos sistemas es única para el desarrollo de aplicaciones, ya que combinan aspectos de la programación (hipervínculos, etcétera) con los aspectos de redacción técnica, tales como la organización y presentación. Muchos han encontrado el desarrollo de un sistema de ayuda en línea es un proyecto dentro de un proyecto que se beneficia de up-front de gestión del alcance y de la actividad de planificación.]

7.3. Guías de Instalación, configuración y archivo Léame

[Un documento que incluye instrucciones de instalación y las instrucciones de configuración es importante para una oferta de soluciones completa. Además, un archivo Read Me normalmente se incluye como componente estándar. El archivo Read Me puede incluir una "Novedades de esta versión" sección, y una discusión de los problemas de compatibilidad con versiones anteriores. La mayoría de los usuarios también valoran la documentación que define cualquier errores y soluciones conocidas en el archivo Léame.]

7.4. Etiquetado y Embalaje

[Las aplicaciones actuales con tecnología de última generación proporcionan un aspecto coherente que comienza con el embalaje del producto y se manifiesta a través de menús de instalación, pantallas de inicio, sistemas de ayuda, diálogos GUI, y así sucesivamente. Esta sección define las necesidades y los tipos de etiquetado para ser incorporados en el código. Los ejemplos incluyen los avisos de copyright y patentes, logotipos corporativos, iconos estandarizados y otros elementos gráficos, etc.]