<Nombre de proyecto>

Visión

 

Versión <1.0>

 

 

[Nota: la siguiente plantilla se proporciona para utilizarla con Rational Unified Process. Se incluye texto encerrado entre corchetes y que se muestra en cursivas azules (style=InfoBlue) para proporcionar orientación al autor y debe suprimirse antes de publicar el documento. Un párrafo que se entre después de este estilo se establecerá automáticamente como normal (style=Body Text).]

 


Historial de revisiones

Fecha

Versión

Descripción

Autor

<dd/mmm/aa>

<x.x>

<detalles>

<nombre>

 

 

 

 

 

 

 

 

 

 

 

 

 


Tabla de contenido

1.       Introducción          

1.1     Finalidad      

1.2     Ámbito      

1.3     Definiciones, acrónimos y abreviaturas      

1.4     Referencias      

1.5     Visión general      

2.       Posicionamiento          

2.1     Oportunidad empresarial      

2.1.1     Posición actual 

2.1.2     Justificación del cambio

2.2     Indicación del problema      

2.3     Indicación de posición del producto     

3.       Descripciones de interesados y usuarios  

3.1     Demografía de mercados     

3.2     Resumen de interesados     

3.3     Resumen de usuarios     

3.4     Entorno de usuario     

3.5     Perfiles de interesados     

3.5.1     <Nombre de interesado>           

3.6     Perfiles de usuarios     

3.6.1     <Nombre de usuario>           

3.7     Necesidades clave de interesado o usuario     

3.8     Alternativas y competencia     

3.8.1     <unCompetidor>           

3.8.2     <otroCompetidor>           

3.9      Estudio de alternativas de desarrollo

4.       Visión general del producto      

4.1     Perspectiva del producto     

4.2     Resumen de funciones     

4.3     Suposiciones y dependencias     

4.4     Coste y precio     

4.5     Licencias e instalación     

5.       Características del producto         

5.1     Características     

5.1.1       <unaCaracterística>

5.1.2       <otraCaracterística>

5.2     Casos operativos

5.3       Suministro de soporte    

6.       Restricciones         

7.       Rangos de calidad

8.       Precedencia y prioridad

9.       Otros requisitos de producto

9.1     Estándares aplicables     

9.2     Requisitos del sistema     

9.3     Requisitos de rendimiento     

9.4     Requisitos de entorno   

9.5       Requisitos físicos  

10.            Requisitos de documentación               

10.1     Manual de usuario     

10.2     Ayuda en línea     

10.3     Guías de instalación, configuración y archivo readme     

10.4     Etiquetado y empaquetado     

A.                 Atributos de característica               

   


Visión

1.                   Introducción

[La finalidad de este documento es la de recopilar, analizar y definir necesidades y características de alto nivel del <<Nombre de sistema>>. Se centra en las funciones que necesitan los interesados y los usuarios de destino y en el porqué de que existan estas necesidades. Los detalles de cómo <<Nombre de sistema>> satisface estas necesidades se detallan en las especificaciones de guión de uso y en las suplementarias. Nota: esta plantilla de Visión intenta abarcar todas las clases de desarrollos, desde productos de envasado al vacío, desarrollado de forma especulativa para una necesidad que se ha percibido en el mercado, hasta sistemas únicos, desarrollados bajo contrato para los requisitos de un cliente específico. En consecuencia, las palabras 'producto' y 'sistema' pueden utilizarse sin realizar una distinción cuidadosa, en sustitución de 'cosa que se va a desarrollar'. Cabría esperar que la personalización de documentos concretase esto para una aplicación específica.]

 [La introducción del documento de Visión proporciona una visión general de todo el documento. Debería incluir la finalidad, ámbito, definiciones, acrónimos, abreviaturas, referencias y visión general de este documento de Visión.]

1.1               Finalidad

[Especifique la finalidad de este documento de Visión.]

1.2               Ámbito

[Una descripción breve del ámbito de este documento de Visión; con qué proyecto(s) está asociado y cualquier otra cosa que esté afectada o influida por este documento.]

1.3               Definiciones, acrónimos y abreviaturas

[Este subapartado proporciona las definiciones de todos los términos, acrónimos y abreviaturas necesarios para interpretar correctamente el documento de Visión. Esta información puede proporcionarse en referencia al Glosario del proyecto.]

1.4               Referencias

[Este subapartado proporciona una lista completa de todos los documentos referenciados en otro lugar en el documento de Visión. Identifique cada documento por su título, número de informe (si es pertinente), fecha y organización que lo ha publicado. Especifique las fuentes de las que pueden obtenerse las referencias. Esta información puede proporcionarse en referencia a un apéndice o a otro documento.]

1.5               Visión general

[Este subapartado describe lo que contiene el resto del documento de Visión y explica cómo está organizado el documento.]

2.                  Posicionamiento

2.1               Oportunidad empresarial

[Describa en pocas palabras la oportunidad empresarial que satisface este proyecto.]

2.1.1     Posición actual

[En este subapartado, describa el contexto, la finalidad y el ámbito del sistema o la circunstancial empresarial existente, incluyendo, según corresponda, las políticas pertinentes, las funciones del sistema actual, los interesados implicados y los asuntos relativos al soporte.]

2.1.2     Justificación del cambio

[En este subapartado, describa las nuevas circunstancias o necesidades que hayan surgido, en sentido empresarial u operativo, que garanticen un cambio. Identifique en pocas palabras los cambios propuestos y rechazados y la lógica asociada. Si se han realizado estudios comerciales (sobre las necesidades de cambio), puede que dispongan de referencias.]

2.2               Indicación del problema

[Proporcione una frase que resuma el problema que este proyecto soluciona. Puede utilizarse el formato siguiente:]

El problema de

[describa el problema]

afecta a

[los interesados a los que les afecta el problema]

el impacto del mismo es

[¿cuál es el impacto del problema?]

una solución satisfactoria sería

[liste algunas ventajas clave de una solución satisfactoria]

2.3               Indicación de posición del producto

[Indique de forma general un resumen, en el nivel máximo, de la posición única que el producto aspira a ocupar en el mercado. Puede utilizarse el formato siguiente:]

Para

[cliente destino]

Quién

[indicación de la necesidad u oportunidad]

El producto (nombre del producto)

es [categoría del producto]

Que

[indicación de la ventaja clave; o sea, el motivo decisivo para comprarlo]

A diferencia de

[alternativa competitiva principal]

Nuestro producto

[indicación de la distinción principal]

[Una frase sobre la posición del producto o del sistema que comunica la finalidad del sistema y la importancia del proyecto para todo el personal implicado.]

3.                  Descripciones de interesados y usuarios

[Para proporcionar de forma efectiva productos y servicios que satisfacen las necesidades reales de los interesados y los usuarios, es preciso implicar a todos los interesados 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 de forma adecuada. Esta sección proporciona un perfil de los interesados y usuarios implicados en el proyecto y los problemas clave que perciben que debe resolver la solución propuesta. No describe sus solicitudes o requisitos específicos, ya que éstos se encuentran en un artefacto de solicitudes de interesados distinto, sino que proporciona el contexto y la justificación de la razón de que sean necesarios esos requisitos.]

3.1               Demografía de mercados

[Resuma los datos demográficos de mercado clave que motivan sus decisiones sobre productos. Describa y posicione los segmentos de mercado de destino. Calcule el tamaño y el crecimiento del mercado mediante el número de usuarios potenciales, o la cantidad de dinero que sus clientes gastarán tratando de satisfacer las necesidades que satisfará su producto o mejora. Revise las tendencias y tecnologías principales de la industria. Responda a estas preguntas estratégicas:

?          ¿Cuál es la reputación de su organización en estos mercados?

?          ¿Cuál le gustaría que fuese?

?          ¿Cómo da soporte este producto o servicio a sus objetivos?]

3.2               Resumen de los interesados

[Hay varios interesados en el desarrollo y no todos ellos son usuarios. Presente una lista de resumen de estos interesados que no son usuarios. (Los usuarios están resumidos en la sección 3.3.)]

Nombre

Descripción

Responsabilidades

[Indique el tipo de interesado.]

[Describa en pocas palabras al interesado.]

[Resuma las responsabilidades clave del interesado respecto al sistema que se está desarrollando; es decir, cuál es su interés como persona interesada. Por ejemplo, este interesado:

- asegura que el sistema podrá mantenerse

- asegura que habrá una demanda en el mercado para las características del producto

- supervisa el progreso del proyecto

- aprueba la financiación]

3.3               Resumen de usuarios

[Presente una lista de resumen de todos los usuarios identificados.]

Nombre

Descripción

Responsabilidades

Interesado

[Indique el tipo de usuario.]

[Describa brevemente lo que representan respecto al sistema.]

[Liste las responsabilidades clave del usuario respecto al sistema que se está desarrollando; por ejemplo;

- captura detalles

- produce informes

- coordina el trabajo]

[Si el usuario no está representado directamente, identifique qué persona interesada es responsable de representar los intereses del usuario.]

 

3.4               Entorno de usuario

[Detalle el entorno de trabajo del usuario de destino. Estas son algunas sugerencias:

Aquí es donde pueden incluirse extractos del Modelo empresarial para describir la tarea y los trabajadores empresariales implicados, etc.]

3.5               Perfiles de los interesados 

[Describa aquí a cada uno de los interesados del sistema rellenando la tabla siguiente para cada interesado. Recuerde que los tipos de interesados pueden ser tan divergentes como usuarios, departamentos y desarrolladores técnicos. Un perfil detallado debe abarcar los temas siguientes para cada tipo de interesado.]

3.5.1          <Nombre de interesado>

Representante

[¿Quién es el representante del interesado en el proyecto? (Es opcional si está documentado en otro lugar.)  Aquí deben colocarse nombres.]

Descripción

[Descripción breve del tipo de interesado.]

Tipo

[Califique la experiencia del interesado, sus conocimientos técnicos y su grado de sofisticación, es decir, genio, experto, usuario ordinario, etc.]

Responsabilidades

[Liste las responsabilidades clave del interesado respecto al sistema que se está desarrollando, es decir, cuál es su interés como persona interesada.]

Criterios de éxito

[¿Cómo define el interesado el éxito?

¿Cómo se ve recompensado el interesado?]

Implicación

[¿Cómo está implicado el interesado en el proyecto? Relaciónelo cuando sea posible con roles de Rational Unified Process, es decir, revisor de requisitos, etc.]

Productos finales

[¿Hay productos finales adicionales que necesite el interesado? Pueden ser productos finales de proyecto o salidas del sistema en desarrollo.]

Comentarios/Cuestiones

[Aquí se colocan aquellos problemas que interfieran con el éxito y otras informaciones relevantes.]

 

3.6               Perfiles de usuario 

[Describa aquí a cada uno de los usuarios exclusivos del sistema rellenando la tabla siguiente para cada tipo de usuario. Recuerde que los tipos de usuario pueden ser tan divergentes como genios o novatos. Por ejemplo, un genio podría necesitar una herramienta sofisticada y flexible con soporte entre plataformas, mientras que un novato podría necesitar una herramienta fácil de utilizar y amigable. Un perfil detallado abarca los temas siguientes para cada tipo de usuario.]

3.6.1          <Nombre de usuario>

Representante

[¿Quién es el representante del usuario en el proyecto? (Es opcional  si está documentado en otro lugar.) Esto suele hacer referencias al interesado que represente el conjunto de usuarios, por ejemplo, Interesado: Interesado1.]

Descripción

[Una breve descripción del tipo de usuario.]

Tipo

[Califique la experiencia del usuario, sus conocimientos técnicos y su grado de sofisticación, es decir, genio, usuario ordinario, etc.]

Responsabilidades

[Liste las responsabilidades clave del usuario respecto al sistema que se está desarrollando, es decir, captura detalles, produce informes, coordina el trabajo, etc.]

Criterios de éxito

[¿Cómo define el usuario el éxito?

 ¿Cómo se ve recompensado el usuario?]

Implicación

[¿Cómo está implicado el usuario en el proyecto? Relaciónelo cuando sea posible con roles de Rational Unified Process, es decir, revisor de requisitos o similares.]

Productos finales

[¿Hay algún producto final que produzca el usuario y, en caso afirmativo, para quién?]

Comentarios/Cuestiones

[Aquí se colocan aquellos problemas que interfieran con el éxito y otras informaciones relevantes. Pueden incluir tendencias que faciliten o dificulten el trabajo del usuario.]

 

3.7               Necesidades clave de interesados o usuarios

[Liste los problemas clave con soluciones existentes tal como los percibe el interesado. Clarifique las cuestiones siguientes para cada problema:

?          ¿Cuáles son los motivos de este problema?

?          ¿Cómo se soluciona ahora?

?          ¿Qué soluciones desea el interesado o el usuario?]

[Es importante entender la importancia relativa que el interesado o usuario pone en solucionar cada problema. Las técnicas de clasificación y votación acumulativa indican problemas que deben resolverse frente a cuestiones que deberían afrontarse.

Rellene la tabla siguiente. Cuando se utiliza Rational RequisitePro para capturar las necesidades, podría ser un extracto o un informe de esa herramienta.]

Necesidad

Prioridad

Preocupaciones

Solución actual

Soluciones propuestas

Mensajes de difusión

 

 

 

 

 

3.8               Alternativas y competencia

[Identifique alternativas que el interesado considere disponibles. Estas pueden incluir la compra de un producto de un competidor, crear una solución interna o simplemente mantener el statu quo. Liste las elecciones competitivas que existen o que pueden estar disponibles. Incluya las principales ventajas y puntos débiles de cada competidor tal como las percibe el interesado o el usuario.]

3.8.1          <unCompetidor>

3.8.2          <otroCompetidor>

3.9       Estudio de alternativas de desarrollo

[En este subapartado, describa las alternativas al producto propuesto que se han estudiado y los estudios comerciales asociados.]

4.                  Visión general del producto

[Este apartado proporciona una vista de alto nivel de las posibilidades del producto, interfaces con otros sistemas y configuraciones de sistemas.] 

4.1               Perspectiva de productos

[Este subapartado del documento de Visión pone el producto en perspectiva respecto a otros productos relacionados y el entorno del usuario. Si el producto es independiente y totalmente autocontenido, indíquelo aquí. Si el producto es un componente de un sistema mayor, este subapartado explica cómo interactúan estos sistemas e identifica las interfaces relevantes entre los sistemas. Una manera fácil de mostrar los componentes principales del sistema mayor, las interconexiones y las interfaces externas es con un diagrama de bloques. 

Identifique los impactos operativos, organizativos y de desarrollo en los interesados y en otros sistemas.]

4.2               Resumen de posibilidades

[Resuma las ventajas y características principales que proporcionará el producto. Por ejemplo, un documento de Visión para un sistema de soporte al cliente puede utilizar esta parte para afrontar la documentación de problemas, direccionamiento e informes de estado sin mencionar la cantidad de detalles que requiere cada una de estas funciones.

Organice las funciones de tal manera que la lista resulte comprensible para el cliente o para cualquier otra persona que lea el documento por primera vez. Puede bastar con una simple tabla que liste las ventajas clave y sus características de soporte. Por ejemplo:]

Tabla 4-1   Sistema de soporte al cliente

Ventajas del cliente

Características de soporte

El nuevo personal de soporte puede solucionar la situación con rapidez.

La base de conocimientos ayuda al personal de soporte a identificar rápidamente las soluciones provisionales y arreglos conocidos.

Mejora la satisfacción del cliente porque no hay nada que escape por resquicios.

Los problemas están identificados, clasificados y seguidos de manera exclusiva a lo largo del proceso de resolución. Para las cuestiones más antiguas se realiza una notificación automática.

La dirección puede identificar áreas problemáticas y calibrar la carga de trabajo del personal.

Los informes de tendencias y distribución permiten una revisión de alto nivel del estado de los problemas.

Los equipos de soporte distribuido pueden colaborar para solucionar problemas.

El servidor de réplica permite compartir información actual de bases de datos en toda la empresa.

Los clientes pueden ayudarse a sí mismos bajando los costes de soporte y mejorando el tiempo de respuesta.

La base de conocimientos puede estar disponible a través de Internet. Incluye posibilidades de búsqueda de hipertexto y un motor de consultas gráfico.

4.3               Suposiciones y dependencias

[Liste cada uno de los factores que afecta a las características indicadas en el documento de Visión. Liste las suposiciones que, si se modifican, alterarán el documento de Visión. Por ejemplo, la Visión se construye en el contexto de una empresa mayor y, si hay algún cambio en ese contexto, es posible que la Visión tenga que cambiar también. Esto puede incluir, por ejemplo, factores económicos, políticos, legales o medioambientales. La Visión también pueden tener dependencias sobre la disponibilidad de equipos, software u otros componentes de sistema, o la disponibilidad de conocimientos o habilidades especiales.]

4.4               Coste y precios

[Para los productos vendidos a clientes externos y para muchos sistemas internos, las cuestiones relativas a costes y precios pueden tener un impacto directo en la definición e implementación del sistema. En este apartado, anote cualquier restricción de costes y precios que sea relevante. Por ejemplo, los costes de distribución (número de disquetes, número de CD-ROM o maestría de CD) u otros costes de restricciones sobre ventas de artículos (manuales, empaquetado) pueden ser material para el éxito de los proyectos o elementos irrelevantes, en función de la naturaleza del sistema.]

4.5               Licencias e instalación

[Las cuestiones sobre licencias e instalación también pueden tener un impacto directo en el esfuerzo de desarrollo. Por ejemplo, la necesidad de dar soporte a controles de acceso, serialización, seguridad de contraseñas o licencias de red creará requisitos adicionales del sistema que deben tenerse en cuenta en el esfuerzo de desarrollo.

Los requisitos de instalación también pueden afectar a la construcción de software o crear la necesidad de un software de instalación diferente. Los sistemas físicos también pueden imponer requisitos de instalación especiales, por ejemplo, si están sujetos a determinadas restricciones de seguridad o capacidad de supervivencia.]

5.                  Características de producto

[Liste y describa brevemente las características del producto. Las características son las posibilidades de alto nivel del sistema que son necesarias para proporcionar ventajas a los usuarios. Además, describa con cada característica cualquier característica de rendimiento asociada; indique cómo está realizándose algo a lo largo de alguna dimensión: por ejemplo, a lo largo de la dimensión de tiempo, tiempo de respuesta o velocidad de transacción. La palabra 'característica' no se elige para que tenga ninguna importancia especial; puede preferir 'posibilidad' o 'función', ya que todas describen algo que el sistema o el producto tiene que hacer. Cada característica es un servicio deseado de forma externa que habitualmente requiere una serie de entradas para alcanzar 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. A medida que el modelo de guión de uso tome forma, actualice la descripción para referirse a los guiones de uso.

Dado que el documento de Visión es revisado por una amplia variedad de personal implicado, el nivel de detalle tiene que ser lo bastante general para que lo entienda todo el mundo. No obstante, debe haber suficientes detalles disponibles para proporcionar al equipo la información que necesitan para crear un modelo de guión de uso.

Para gestionar la complejidad de forma eficaz, le recomendamos que en caso de tener un sistema nuevo, o un incremento de un sistema existente, las posibilidades se abstraigan a un nivel lo bastante alto para que se den 25-99 características como resultado. Estas características proporcionan la base fundamental de la definición de producto, gestión de ámbitos y gestión de proyectos. Cada característica se expandirá con más detalles en el modelo de guión de uso o en lenguaje natural si, por ejemplo, el proyecto elige no producir guiones de uso.

A lo largo de este apartado, cada característica será perceptible externamente por los usuarios, operadores u otros sistemas externos. Estas características deben incluir una descripción de funcionalidad y cualquier cuestión relevante sobre utilización que deba resolverse. Se aplican las directrices siguientes:

?          Evite el diseño. Mantenga las descripciones de características en un nivel general. Concéntrese en las posibilidades necesarias y en la razón (no la manera) por la que deben implementarse.

?          Si utiliza el kit de utilidades de Rational RequisitePro, todas tienen que seleccionarse como requisitos de tipo para facilitar su referencia y seguimiento.]

5.1               Características

5.1.1     <unaCaracterística>

5.1.2     <otraCaracterística>

5.2               Casos de ejemplo operativos

[Describa algunos usos del producto o sistema que ilustren interacciones interesantes o importantes entre el sistema y sus usuarios, su entorno y otros sistemas.]

5.3               Suministro de soporte

[En este subapartado, describa cómo, de forma conceptual, debe proporcionarse soporte, incluyendo descripciones de la organización de soporte, equipos, ciclos de mantenimiento y organización de suministros.]

6.                  Restricciones

[Anote las restricciones de diseño, restricciones externas u otras dependencias.]

7.                  Rangos de calidad

[Defina los rangos de calidad para el rendimiento, solidez, tolerancia de errores, utilización y características similares que no se hayan capturado en el Conjunto de características.]

8.                  Precedencia y prioridad

[Defina la prioridad de las distintas características del sistema.]

9.                  Otros requisitos de producto

[En un nivel alto, liste los estándares aplicables, requisitos de hardware o plataforma, requisitos de rendimiento y requisitos medioambientales.]

9.1               Estándares aplicables

[Liste todos los estándares que el producto debe cumplir. Pueden incluir estándares de comunicaciones legales y de regulaciones (FDA, UCC) (TCP/IP, RDSI), estándares de conformidad de plataformas (Windows, UNIX, etc.) y estándares de calidad y seguridad (UL, ISO, CMM).]

9.2               Requisitos de sistema

[Para el desarrollo de sistemas de software, defina los requisitos de sistema necesarios para dar soporte a la aplicación. Pueden incluir los sistemas operativos host soportados y plataformas de red, configuraciones, memoria, periféricos y software incluido.]

9.3               Requisitos de rendimiento

[Utilice este apartado para detallar requisitos de rendimiento. Las cuestiones sobre rendimiento pueden incluir elementos tales como factores de carga de usuario, capacidad de ancho de banda o comunicaciones, productividad, precisión y fiabilidad o tiempos de respuesta bajo diversas condiciones de carga.]

9.4               Requisitos medioambientales

[Detalle los requisitos medioambientales según sea necesario. Para los sistemas físicos, las cuestiones medioambientales pueden incluir la temperatura, impactos, humedad, radiaciones, etc. Para los sistemas de software, los factores medioambientales pueden incluir las condiciones de uso, entorno de usuario, disponibilidad de recursos, cuestiones de mantenimiento y manejo y recuperación de errores.]

9.5        Requisitos físicos

[Si hay requisitos físicos como, por ejemplo, el peso o límites de masa o tamaño, descríbalos en este subapartado.]

10.             Requisitos de documentación

[Este apartado describe la documentación que se debe desarrollar para dar soporte a un despliegue satisfactorio del sistema.]

10.1            Manual de usuario

[Describa la finalidad y el contenido del manual de usuario. Describa la longitud deseada, nivel de detalle, necesidad de incluir un índice, glosario de términos, estrategia de guía de aprendizaje frente a manual de consulta, etc. También deben identificarse las restricciones de formato e impresión.]

10.2            Ayuda en línea

[Muchos sistemas proporcionan ayuda en línea para asistir al usuario. La naturaleza de estos sistemas es poco común, ya que combinan aspectos de programación (hiperenlaces, etc.) con aspectos de la redacción técnica como, por ejemplo, la organización y la presentación. Muchos han encontrado que el desarrollo del sistema de ayuda en línea es un proyecto dentro de otro proyecto que beneficia desde a la gestión de ámbitos abierta a la actividad de planificación.]

10.3            Guías de instalación, configuración y archivo readme

[Un documento que incluya instrucciones de instalación y directrices de configuración es importante para una oferta de solución completa. Además, suele incluirse un archivo readme como componente estándar. El archivo readme puede incluir un apartado de "Novedades de este release y una descripción de cuestiones de compatibilidad con releases anteriores. La mayoría de usuarios también valora que la documentación describa los errores conocidos y las soluciones provisionales en el archivo readme.]

10.4            Etiquetado y empaquetado

[Los sistemas modernos se esfuerzan por proporcionar un aspecto coherente que empiece por el empaquetado del producto y se manifieste a lo largo de los menús de instalación, pantallas iniciales, sistemas de ayuda, diálogos de la GUI, etc. Este apartado define las necesidades y tipos de etiquetado que deben incluirse en el sistema. Entre los ejemplos se encuentran avisos de copyright y patentes, logotipos corporativos, iconos estandarizados y otros elementos gráficos, etc.]

A.          Atributos de característica

[Las características son atributos determinados que pueden utilizarse para evaluar, realizar un seguimiento, priorizar y gestionar los elementos del producto propuestos para su implementación. Todos los tipos de requisito y atributos se esbozan en el Plan de gestión de requisitos; no obstante, tal vez desee listar y describir con brevedad los atributos de las características que ha elegido. Los subapartados siguientes representan un conjunto de atributos de característica sugeridos.]

A.1            Estado

[Defina esto después de que el equipo de gestión de proyectos lo haya negociado y revisado. Realiza el seguimiento del progreso durante la definición de la línea base del proyecto.]

Propuestas

[Se utiliza para describir las características que se están estudiando pero no han sido revisadas y aceptadas todavía por el "canal oficial" como, por ejemplo, un grupo de trabajo que se compone de representantes del equipo de proyectos, la gestión de productos y la comunidad de usuarios o clientes.]

Aprobadas

[Las posibilidades que se consideran útiles y viables y que el canal oficial ha aprobado para su implementación. ]

Incluidas

[Las características incluidas en la línea base del producto en un momento específico.]

A.2            Ventajas

[Definido por el departamento de marketing, el gestor de productos o el analista empresarial. No todos los requisitos se crean iguales. Establecer una clasificación de requisitos según su ventaja relativa para el usuario abre un diálogo con clientes, analistas y miembros del equipo de desarrollo. Se utiliza en la gestión del ámbito y la determinación de las prioridades de desarrollo.]

Críticas

[Características esenciales. Si no se implementan, quiere decir que el sistema no satisfará las necesidades de los clientes. Todas las características críticas deben implementarse en el release o se modificará la planificación.]

Importantes

[Las características importantes para la eficacia y eficiencia del sistema para la mayoría de usos. La funcionalidad no puede proporcionarse fácilmente de otra manera. La omisión de una característica importante puede afectar a la satisfacción de los clientes o usuarios, o incluso a los ingresos, pero el release no se demorará a causa de la falta de una característica importante.]

Útiles

[Las características que admiten un uso poco habitual y, por consiguiente, se utilizará con menor frecuencia, o para las que pueden lograrse soluciones alternativas razonablemente eficaces. No se espera ningún impacto significativo en los ingresos o en la satisfacción de los clientes si uno de estos elementos no es incluido en un release.]

 

A.3            Esfuerzo

[Definido por el equipo de desarrollo. Dado que algunas características requieren más tiempo y recursos que otras, estimar el número de semanas por equipo o por persona, o alguna medida de tamaño que se correlacione con el esfuerzo (como, por ejemplo, las líneas de código necesarias o los puntos de función para el software), es la mejor manera de medir la complejidad y establecer expectativas de lo que se puede conseguir y lo que no en un periodo de tiempo determinado. Se utiliza al gestionar el ámbito y determinar las prioridades de desarrollo.]

A.4            Riesgo

[Definido por el equipo de desarrollo en función de la probabilidad de que el proyecto experimente sucesos no deseados como, por ejemplo, desbordamientos de costes, retardos en la planificación o incluso su cancelación. La mayoría de gestores de proyectos piensan que la clasificación en categorías de los riesgos como altos, medios y bajos es suficiente, aunque es posible realizar gradaciones más precisas. A menudo, el riesgo se puede valorar indirectamente midiendo la incertidumbre (rango) de la estimación de la planificación del equipo de proyectos.]

A.5            Estabilidad

[Definido por el equipo de analistas y desarrollo en función de la probabilidad de que esta característica cambie o que cambie la idea que el equipo tiene de ella. Se utiliza para ayudar a establecer prioridades de desarrollo y determine aquéllos elementos para los que una elucidación adicional es la siguiente acción adecuada.]

A.6            Release de destino

[Registra la versión de producto prevista en la que aparecerá la característica por primera vez. Este campo puede utilizarse para asignar características de un documento de Visión a un release de línea base determinado. Cuando se combina con el campo de estado, el equipo puede proponer, registrar y analizar diversas características del release sin confirmarlas al equipo de desarrollo. Sólo se implementarán aquellas características cuyo Estado se establezca como Incluido y cuyo Release de destino se haya definido. Cuando se realiza la gestión de ámbitos, puede aumentarse el Número de versión del Release de destino para que el elemento permanezca en el documento de Visión pero se planifique para un release posterior.]

A.7            Asignado a

[En muchos proyectos, las características se asignarán a "equipos de características" responsables de realizar el estudio posterior, capturar y perfeccionar los requisitos y llevar a cabo la implementación. Esta simple lista desplegable ayudará a todos los miembros del equipo de proyectos a entender mejor sus responsabilidades.]

A.8            Motivo

[Este campo de texto se utiliza para realizar un seguimiento del origen de la característica solicitada. Los requisitos existen por motivos específicos. En este campo se anota una explicación o una referencia a una explicación. Por ejemplo, podría hacerse referencia a un número de página y de línea de una especificación de requisito de producto, o a un marcador de minutaje en un vídeo de un informe importante de un cliente.]