[Nota: La siguiente plantilla se proporciona para su uso con Rational Unified Process. Texto entre
corchetes y que aparecen en cursiva azul (estilo = InfoBlue) se incluye para proporcionar orientación a
los del autor y debe ser eliminado antes de publicar el documento. Un párrafo introducido este estilo se
ajustará automáticamente a la normalidad (estilo = Cuerpo de texto).]

Historial de revisiones
Fecha Versión Descripción Autor
<dd/mmm/yy> <xx> <details> NOMBRE
 Tabla de contenidos
1.        Introducción
1.1      Propósito
1.2      Ámbito de aplicación
1.3      Definiciones, acrónimos y abreviaturas
1.4      Referencias
1.5      Información general

2.        Posicionamiento
2.1      Oportunidad de Negocio
2.2      Planteamiento del problema
2.3      Declaración de posición del producto

3.        Descripción de las partes interesadas y el Usuario

3.1      Mercado de Demografía
3.2      Resumen de las partes interesadas
3.3      Resumen del usuario
3.4      Del entorno de usuario
3.5      Perfiles de los interesados
3.5.1          <Nombre <Stakeholder
3.6      Perfiles de usuario
3.6.1          <nombre
3.7      Las partes interesadas clave o las necesidades del usuario
3.8      Alternativas y competencia
3.8.1          <aCompetitor>
3.8.2          <anotherCompetitor>

4.        Descripción del producto

4.1      Perspectiva del producto
4.2      Resumen de las Capacidades
4.3      Suposiciones y dependencias
4.4      Costo y precios
4.5      Concesión de licencias e instalación

5.        Características del producto

5.1      <aFeature>
5.2      <anotherFeature>

6.        Restricciones

7.        Rangos de Calidad

8.        Precedencia y prioridad

9.        Otros requisitos del producto

9.1      Normas aplicables
9.2      Requisitos del sistema
9.3      Requisitos de Desempeño
9.4      Requisitos ambientales
10.             Requisitos de documentación
10.1      Manual del usuario
10.2      Ayuda en línea
10.3      Guías de instalación, configuración y Léame Archivo
10.4      Etiquetado y embalaje

Característica A. Atributos
 Visión
1.                   Introducción
[El propósito de este documento es recoger, analizar y definir las necesidades de alto nivel y
características de la <<nombre>. Se centra en las capacidades requeridas por las partes interesadas y
los usuarios finales, y por quéestas necesidades existen. Los detalles de cómo el <<nombre> cumple con
estas necesidades se detallan en el caso de uso y especificaciones adicionales.]
[La introducción del documento de Visión ofrece una visión general de todo el documento. Debe incluir
el propósito, alcance, definiciones, acrónimos, abreviaturas, referencias, y visión general de este
documento Visión.]
1.1                Propósito
[Especifique el propósito de este documento Visión.]
1.2                Ámbito de aplicación
[Todo lo que más se ve afectada o influenciada por este documento una breve descripción del alcance de
este documento Visión, Proyecto lo (s) que está asociado con y.]
1.3                Definiciones, acrónimos y abreviaturas
[Esta sección provee las definiciones de los términos, acrónimos y abreviaturas requeridas para
interpretar apropiadamente el documento de Visión. Esta información puede ser proporcionada por
referencia al glosario del proyecto.]
1.4                Referencias
[Esta sección provee una lista completa de todos los documentos referenciados en cualquier lugar en el
documento Visión. Identifique cada documento por su título, número de informe (si procede), fecha y
organización que lo publica. Especificar las fuentes de donde las referencias se pueden obtener. Esta
información puede ser proporcionada por referencia a un apéndice oa otro documento.]
1.5                Información general
[Esta sección describe lo que el resto del documento contiene la visión y explica cómo se organiza el
documento.]
2.                   Posicionamiento
2.1                Oportunidad de Negocio
[Describa brevemente la oportunidad de negocio que se reunió por este proyecto.]
2.2                Planteamiento del problema
[Proporcionar una declaración que resuma el problema a resolver por este proyecto. El siguiente
formato puede ser utilizado:]
El problema de la [Describa el problema]
afecta [Los actores afectados por el problema]
cuyo impacto es [¿Cuál es el impacto del problema?]
una solución satisfactoria sería [Lista de algunos de los beneficios clave de una solución
exitosa]
2.3                Declaración de posición del producto
[Proporcionar una declaración general que resume, al más alto nivel, la posición única del producto
tiene la intención de llenar en el mercado. El siguiente formato puede ser utilizado:]
Por [Target del cliente]
¿Quién [Declaración sobre la necesidad o la oportunidad]
El (nombre del producto) es un producto [categoría]
Que [Estado de las principales ventajas, es decir, la razón de
peso para comprar]
A diferencia de [Principal alternativa competitiva]
Nuestro producto [Estado de diferenciación primaria]
[Una declaración de posición del producto se comunica la intención de la solicitud y la importancia del
proyecto a todo el personal en cuestión.]
3.                   Descripción de las partes interesadas y el Usuario
[Para efectivamente a disposición de los productos y servicios que satisfagan sus grupos de interés y
necesidades de los usuarios reales, es necesario 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 asegurar que la comunidad de interesados adecuadamente los representa. En esta sección se ofrece un
perfil de las partes interesadas y los usuarios involucrados en el proyecto, y los principales problemas
que ellos perciben que se abordarán en la solución propuesta. No describe sus solicitudes o requisitos
específicos ya que estos son capturados en un actor independiente artefacto peticiones. En su lugar, se
presentan los antecedentes y la justificación de por qué los requisitos son necesarios.]
3.1                Mercado de Demografía
[Resumen de los datos demográficos clave del mercado que motivan sus decisiones de
producto. Describir y posición de los segmentos de mercado objetivo. Estimar el tamaño de mercado y el
crecimiento mediante el número de usuarios potenciales, o la cantidad de dinero que gastan sus clientes
tratando de satisfacer las necesidades que su producto o la mejora cumpliría. Revisión de las principales
tendencias de la industria y las tecnologías. Responda a estas preguntas estratégicas:
• ¿Qué es la reputación de su empresa en estos mercados?
• ¿Qué se siente ser?
• ¿Cómo funciona este producto o servicio de soporte sus metas?]
3.2                Resumen de las partes interesadas
[Hay una serie de actores con 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.3.)]
Nombre Descripción Responsabilidades
[Nombre del tipo de [Describa brevemente las [Resumen de las principales
interés.] partes interesadas.] 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á
fácil de mantener
- Asegura que habrá una
demanda de mercado para las
características del producto
- Monitorea el progreso del
proyecto
- Aprueba la financiación
- Y así sucesivamente]

3.3                Resumen del usuario

[Presentar una lista resumida de todos los usuarios identificados.]
Nombre Descripción Responsabilidades Las partes interesadas

[Nombre del [Describa Lista [clave responsabilidades del [Si el usuario no está
tipo de brevemente lo usuario con respecto al sistema en directamente representado,
usuario.] que desarrollo, por ejemplo: identificar las partes interesadas
representan es responsable de representar los
- Captura los detalles
con respecto intereses del usuario.]
al sistema.] - Elabora informes
- Coordina el trabajo
- Y así sucesivamente]

3.4                Del entorno de usuario

[Detalles sobre el medio ambiente de trabajo del usuario de destino. Aquí están algunas sugerencias:
 Número de personas involucradas en la realización de la tarea? ¿Es este cambio?
 ¿Cuánto dura un ciclo de la tarea? Cantidad de tiempo dedicado a cada actividad? ¿Es este
cambio?
 Cualquier restricciones únicas del medio ambiente: móviles, al aire libre, en vuelo, etc.?
  ¿Qué plataformas de sistemas están en uso hoy en día? plataformas de futuro?
 ¿Qué otras aplicaciones están en uso? ¿Su aplicación necesidad de integrar con ellos?
Aquí es donde extractos del modelo de negocio podría ser incluido para delinear la tarea y los
trabajadores de empresas que participan, etc.]
3.5                Perfiles de los interesados
[Describir cada uno de los interesados en el sistema aquí rellenando el siguiente cuadro para cada
actor. Recuerde que los tipos de partes interesadas puede ser tan divergentes como los usuarios,
departamentos, y desarrolladores técnicos. Un perfil completo abarcaría los siguientes temas para cada
tipo de partes interesadas.]
3.5.1            <Nombre <Stakeholder
Representante [¿Quién es el representante de los interesados en el
proyecto? (Opcional si documentado en otros lugares.) Lo que
queremos aquí es los nombres.]
Descripción [Breve descripción del tipo de interés.]
Tipo [Capacitar a los interesados los conocimientos, técnicas de fondo, y el
grado de sofisticación, es decir, el gurú, de negocios, expertos, usuarios
ocasionales, etc.]
Responsabilidades [Lista de las principales responsabilidades de las partes interesadas en
relación con el sistema en desarrollo, es decir, su interés como parte
interesada.]
Criterios de éxito [¿Cómo funciona el actor define el éxito?
¿Cómo es el actor premiado?]
Participación [¿Cómo es la parte interesada en el proyecto? Se refieren en lo posible
para Rational Unified funciones de proceso, es decir, los requisitos
autores, etc.]
Entregables [¿Existen prestaciones adicionales requeridos por las partes
interesadas? Estas podrían ser las prestaciones del proyecto o las
salidas del sistema en desarrollo.]
Comentarios / [Los problemas que interfieren con el éxito y cualquier otra información
Problemas pertinente ir aquí.]

3.6                Perfiles de usuario
[Describir cada usuario único del sistema de aquí rellenando el siguiente cuadro para cada tipo de
usuario. Recuerde que los tipos de usuarios pueden ser tan divergentes como los gurús y los
principiantes. Por ejemplo, un gurú puede ser que necesite una herramienta sofisticada y flexible con
soporte de plataformas cruzadas, mientras que un novato puede ser que necesite una herramienta que es
fácil de usar y fácil de usar. Un perfil completo abarca los siguientes temas para cada tipo de usuario.]
3.6.1            <nombre 
Representante [¿Quién es el representante de los usuarios al proyecto? (Opcional si
documentado en otros lugares.) A menudo, esto se refiere a las partes
interesadas que representa el conjunto de los usuarios, por ejemplo, las
partes interesadas. Stakeholder1]
Descripción [Una breve descripción del tipo de usuario.]
Tipo [Calificar al usuario de conocimientos, técnicas de fondo, y el grado de
sofisticación, es decir, el gurú, el usuario ocasional, etc.]
Responsabilidades [Lista de las responsabilidades claves del usuario en relación con el
sistema en desarrollo, es decir, captura los detalles, produce informes,
coordina el trabajo, etc.]
Criterios de éxito [¿Cómo funciona el usuario define el éxito?
¿Cómo es el usuario premiado?]
Participación [¿Cómo el usuario participa en el proyecto? Se refieren en lo posible
para Rational Unified funciones de proceso, es decir, los requisitos
autores, etc.]
Entregables [¿Hay resultados que el usuario produce y, de ser así, ¿para quién?]
Comentarios / Problemas [que interfieren con el éxito y cualquier otra información
Problemas pertinente ir aquí. Estos incluyen las tendencias que hacen que el
trabajo del usuario más fácil o más difícil.]

3.7                Las partes interesadas clave o las necesidades del usuario

[Lista de los principales problemas con las soluciones existentes de vista de los interesados. Aclarar los
siguientes aspectos para cada problema:
• ¿Cuáles son las razones de este problema?
• ¿Cómo se resuelve ahora?
• ¿Qué soluciones tiene el actor o el usuario quiere?]
[Es importante entender la importancia relativa o el usuario coloca las partes interesadas en la solución
de cada problema. Clasificación y técnicas de votación acumulativa indican los problemas
que deben resolverse en comparación con las cuestiones que les gustaría abordar.
Rellene el siguiente] de tabla si se utiliza Rational RequisitePro para capturar las necesidades, esto
podría ser un certificado o un informe de esa herramienta.
 ¿Necesitas Prioridad Las Solución actual Soluciones
preocupacione propuestas
s
Transmitir mensajes

3.8                Alternativas y competencia
[Identificar alternativas de la parte interesada percibe como disponible. Estos pueden incluir la compra
de productos de la competencia, la creación de una solución de cosecha propia o simplemente mantener
el status quo. Haga una lista de opciones conocidas competitivas que existen o puedan estar
disponibles. Incluye las principales fortalezas y debilidades de cada competidor según la percepción del
usuario final o las partes interesadas.]
3.8.1            <aCompetitor>
3.8.2            <anotherCompetitor>
4.                   Descripción del producto
[Esta sección proporciona una vista de alto nivel de las capacidades del producto, interfaces con otras
aplicaciones y configuraciones de sistemas. Esta sección consta de tres apartados, como sigue:
• Perspectiva del producto
• Funciones del producto
• Supuestos y] las dependencias
4.1                Perspectiva del producto
[Esta sección del documento Visión pone el producto en el punto de vista de otros productos
relacionados y usuario el medio ambiente. Si el producto es independiente y totalmente autónomo,
estado aquí. Si el producto es un componente de un sistema mayor, a continuación, este apartado cuenta
cómo estos sistemas interactúan y se identifican las interfaces entre los sistemas pertinentes. Una forma
fácil de mostrar los componentes principales del sistema más grande, las interconexiones, y las
interfaces externas es con un diagrama de bloques.]
4.2                Resumen de las Capacidades
[Resumen de las principales ventajas y características del producto le. Por ejemplo, un documento
de visión para un sistema de atención al cliente puede utilizar esta parte para hacer frente a problemas
de documentación, enrutamiento y los informes de estado, sin mencionar la cantidad de detalles cada
una de estas funciones requiere.
Organizar las funciones de lo que la lista sea comprensible para el cliente o para cualquier otra persona
de leer el documento por primera vez. Una simple tabla lista las principales ventajas y sus funciones de
apoyo podría ser suficiente. Por ejemplo:]
 Tabla 4.1 Sistema de Soporte al Cliente
Beneficio para el cliente Funciones de apoyo
personal de apoyo de Nueva Base de conocimiento ayuda a personal de apoyo en
rápidamente puede ponerse al día. la rápida identificación de soluciones conocidos y
soluciones.
La satisfacción del cliente se mejora Los problemas son especialmente detallada,
porque nada cae a través de las grietas. clasificada y seguimiento de todo el proceso de
resolución. Notificación automática se produce para
todas las cuestiones del envejecimiento.
La gerencia puede identificar las áreas y distribución de informes de tendencias permitir
problemáticas y medir la carga de una revisión de alto nivel de la condición de
trabajo del personal. problema.
Distribuidos los equipos de apoyo Replication Server permite que la información base
pueden trabajar juntos para resolver de datos actual para ser compartido en toda la
problemas. empresa.
Los clientes pueden ayudarse a sí Base de conocimiento puede ponerse a disposición a
mismos, la reducción de costos de través de Internet. Incluye capacidades de búsqueda
soporte y mejorar el tiempo de de hipertexto y el motor gráfico de consultas.
respuesta.
4.3                Suposiciones y dependencias
[Lista de cada uno de los factores que afecta a las características mencionadas en el
documento Visión. Lista de supuestos que, si se le cambia, se altera el documento Visión. Por ejemplo,
un supuesto puede afirmar que un sistema operativo específico estará disponible para el equipo
designado para el producto de software. Si el sistema operativo no está disponible, el
documento Visión tendrá que cambiar.]
4.4                Costo y precios
[Para los productos vendidos a clientes externos y para muchas aplicaciones en la empresa, cuestiones
de costos y fijación de precios pueden afectar directamente a la definición de la aplicación y
ejecución. En esta sección, registro de todas las limitaciones de costos y precios que sean
pertinentes. Por ejemplo, los costes de distribución (número de disquetes, # de CD-ROM, el dominio de
CD) u otro costo de las mercancías vendidas limitaciones (manuales, embalaje) puede ser importante
para el éxito de los proyectos, o irrelevante, dependiendo de la naturaleza de la solicitud. ]
4.5                Concesión de licencias e instalación
[Concesión de licencias y problemas de instalación también puede directamente el impacto del esfuerzo
de desarrollo. Por ejemplo, la necesidad de apoyar la serialización, la contraseña de seguridad o de
concesión de licencias de red va a crear necesidades adicionales del sistema que deben ser considerados
en el esfuerzo de desarrollo.
Requisitos de instalación también puede afectar a un código o crear la necesidad de un software de
instalación por separado.]
5.                   Características del producto
Lista [y describir brevemente las características del producto. Las características son las capacidades
de alto nivel del sistema que son necesarios para ofrecer beneficios a los usuarios. Cada función es un
servicio externo que desee que normalmente requiere una serie de insumos para lograr el resultado
deseado. Por ejemplo, una característica de un sistema de seguimiento de problemas podría ser la
capacidad de presentar informes de tendencias.Como el modelo de casos de uso se configura, actualiza
la descripción para referirse a los casos de uso.
Debido a que el documento de Visión es revisada por una gran variedad de personal involucrado, el
nivel de detalle debe ser lo suficientemente general para que todos puedan entender. Sin embargo, con
suficiente detalle debe estar disponible para proporcionar el equipo con la información que necesitan
para crear un modelo de casos de uso.
Para gestionar eficazmente la complejidad de aplicación, se recomienda para cualquier sistema nuevo, o
un incremento a un sistema existente, las capacidades son abstracciones de un nivel lo suficientemente
alto para 25-99 resultado de la cuenta. Estas características constituyen la base fundamental para la
definición del producto, gestión del alcance y gestión de proyectos. Cada función se ampliará en mayor
detalle en el modelo de casos de uso.
A lo largo de esta sección, cada característica se externamente perceptible por los usuarios, los
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 directrices se
aplicarán las siguientes:
• Evite el diseño. Mantenga función de las descripciones a nivel general. Centrarse en las capacidades
necesarias y por qué (no técnicos) 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                <aFeature>
 
5.2                <anotherFeature>
6.                   Restricciones
[Tenga en cuenta las posibles limitaciones de diseño, la restricción externa o de otras dependencias.]
7.                   Rangos de Calidad
[Definición de los rangos de calidad para el rendimiento, robustez, tolerancia a fallos, facilidad de uso y
características similares que no son capturados en el conjunto de características.]
8.                   Precedencia y prioridad
[Definición de la prioridad de las características del sistema diferentes.]
9.                   Otros requisitos del producto
[En un alto nivel, las normas aplicables lista, los requisitos de hardware o de la plataforma, los
requisitos de desempeño, y los requisitos ambientales.]
9.1                Normas aplicables
[Lista de todas las normas que el producto debe cumplir. Estos pueden incluir estándares de
comunicación legal y regulatorio (FDA, UCC) (TCP / IP, RDSI),] el cumplimiento de estándares de la
plataforma (Windows, UNIX, etc), y las normas de calidad y seguridad (UL, ISO, CMM).
9.2                Requisitos del sistema
[Definir los requisitos del sistema necesarios para apoyar la solicitud. Estos pueden incluir los sistemas
de acogida apoyo operativos y plataformas de red, configuraciones de memoria, periféricos y software
de compañía.]
9.3                Requisitos de Desempeño
[Use esta sección para detallar los requisitos de desempeño. Los problemas de rendimiento pueden
incluir elementos tales como factores de carga de usuarios, la capacidad de ancho de banda o la
comunicación, el rendimiento, la precisión, fiabilidad y tiempos de respuesta o bajo una variedad de
condiciones de carga.]
9.4                Requisitos ambientales
[Detalle de los requisitos ambientales, según sea necesario. Para los sistemas basados en hardware, los
problemas medioambientales pueden incluir la temperatura, golpes, humedad, radiación, etc. Para
aplicaciones de software, los factores ambientales pueden incluir las condiciones de uso, el entorno del
usuario, la disponibilidad de recursos, problemas de mantenimiento, y manejo y recuperación de
errores.]
10.              Requisitos de documentación
[Esta sección describe la documentación que debe ser desarrollada para apoyar el despliegue exitoso de
aplicaciones.]
10.1             Manual del usuario
[Describir el propósito y contenido del manual de usuario. Discutir la longitud deseada, el nivel de
detalle, la necesidad de índice, glosario de términos, frente a la estrategia tutorial manual de referencia,
y así sucesivamente. Dar formato e imprimir las restricciones deben ser identificados también.]
10.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 combina aspectos de la programación
(hipervínculos, etc) con los aspectos de redacción técnica, como la organización y presentación. Muchos
han encontrado el desarrollo del sistema de ayuda en línea es un proyecto dentro de un proyecto que se
beneficia de la gestión del alcance inicial y la actividad de planificación.]
10.3             Guías de instalación, configuración y Léame Archivo
[Un documento que incluye instrucciones de instalación y guías de configuración es importante para una
solución completa que ofrece. Además, un archivo Read Me normalmente se incluye como un
componente estándar. El archivo Read Me puede incluir un "¿Qué hay de nuevo en esta versión"
sección, y una discusión de problemas de compatibilidad con versiones anteriores. La mayoría de los
usuarios también apreciarán documentación que establece que ninguna de errores conocidos y
soluciones en el archivo Léame.]
10.4             Etiquetado y embalaje
solicitudes [de hoy el estado de la técnica proporcionan un aspecto coherente que comienza con el
empaque del producto y se manifiesta a través de menús de instalación, pantallas de inicio, los sistemas
de ayuda, cuadros de diálogo de interfaz gráfica de usuario, y así sucesivamente. Esta sección define las
necesidades y tipos de etiquetado para ser incorporado en el código. Los ejemplos incluyen los derechos
de autor y avisos de patentes, logotipos corporativos, iconos normalizados y otros elementos gráficos,
etc.]
Característica A. Atributos
Características [se dan los atributos que se pueden utilizar para evaluar, seguir, priorizar y administrar
los elementos del producto propuesto para su aplicación. Todos los tipos de requisitos y atributos se
describen en el Plan de gestión de los requisitos, sin embargo es posible que desee enumerar y describir
brevemente los atributos de las características que han sido elegidos. Los apartados siguientes
representan un conjunto de atributos de rasgo sugirió.]
A.1             Condición Jurídica y Social
[Juego después de la negociación y la revisión por el equipo de gestión de proyectos. Seguimiento del
progreso durante la definición de la línea base del proyecto.]
Propuesto [Se utiliza para describir las características que están bajo
discusión, pero aún no se han revisado y aceptado por el "canal
oficial", tal como un grupo de trabajo integrado por representantes
del equipo de proyecto, gestión de productos, y el usuario o la
comunidad de clientes.]
Aprobado [Las capacidades que se consideran útiles y factibles, y han sido
aprobados para su ejecución por el canal oficial. ]
Incorporated [Características incorporadas en la línea de base del producto en un
punto específico en el tiempo.]

A.2             Beneficio
[Fijado por la comercialización, el gerente de producto o el analista de negocios. Todos los requisitos
no son iguales. Ranking de las necesidades por sus prestaciones en relación con el usuario final se abre
un diálogo con los clientes, analistas y miembros del equipo de desarrollo. ] Se utiliza en la gestión de
alcance y determinar la prioridad del desarrollo.
 Crítica [Características esenciales. La falta de aplicación, el sistema no
responda a las necesidades del cliente. Todas las funciones críticas
deben ser implementadas en la liberación o el calendario de
deslizamiento.]
Importante [Características importantes para la eficacia y la eficiencia del sistema
para la mayoría de las aplicaciones. La funcionalidad no puede ser
proporcionada de forma sencilla de alguna otra manera. La falta de
inclusión de un aspecto importante puede afectar a los clientes o la
satisfacción del usuario, e incluso los ingresos, pero su libertad no se
retrasará debido a la falta de alguna de las funciones importantes.]
Útiles Características [que son útiles en aplicaciones menos típicos se utilizan
con menos frecuencia o para los que soluciones razonablemente
eficiente se puede lograr. No hay ingresos importantes o impacto de la
satisfacción del cliente se puede esperar si tal producto no está incluido
en un comunicado.]

A.3             Esfuerzo
[Definido por el equipo de desarrollo. Dado que algunas funciones requieren más tiempo y recursos que
otros, la estimación del número de personas del equipo o semanas, las líneas de código necesario o
puntos de función, por ejemplo, es la mejor forma de medir las expectativas de la complejidad y el
conjunto de lo que puede y no se puede lograr en un momento determinado marco. ] Se utiliza en la
gestión de alcance y determinar la prioridad del desarrollo.
A.4             Riesgo
[Juego por el equipo de desarrollo basado en la probabilidad de que el proyecto experimentará efectos
adversos, tales como los excesos de costes, retrasos en los plazos o incluso la cancelación. La mayoría
de los jefes de proyecto encontrar riesgos clasificar como alta, media y baja es suficiente, aunque más
sutiles gradaciones son posibles. Riesgo, a menudo puede ser evaluado indirectamente mediante la
medición de la incertidumbre (rango) de la estimación de programar el equipo de proyectos de.]
A.5             Estabilidad
[Fijado por el analista y el equipo de desarrollo basado en la probabilidad de que la función va a
cambiar o la comprensión del equipo de la característica de cambio. ] Se utiliza para ayudar a
establecer las prioridades de desarrollo y determinar los elementos para los que elicitación adicional es
la siguiente acción apropiada.
A.6             Objetivo del estreno
[Documentos de la versión del producto propuesto, de que la primera característica aparecerá. Este
campo puede ser utilizado para asignar las características de un documento de visión en un comunicado
de línea de base en particular. Cuando se combina con el campo de estado, su equipo puede proponer,
registrar y analizar las diversas características de la puesta en libertad sin incurrir en ellos para el
desarrollo. Sólo las funciones de estado se establece en Incorporated y cuyo destino se define de
lanzamiento se llevará a cabo. Cuando se produce la gestión del alcance, el objetivo Release Number
puede ser aumentado por lo que el tema se mantendrá en el documento devisión, pero será programado
para una versión posterior.]
A.7             Asignado a
[En muchos proyectos, las características se le asignará a la "función de los equipos de" responsable de
la obtención adicional, por escrito los requisitos de software e implementación. Esta sencilla lista
desplegable le ayudará a todos en el equipo del proyecto para comprender mejor las responsabilidades.]
A.8             Razón
[Este campo de texto se utiliza para rastrear la fuente de la función solicitada. Requisitos existen por
razones específicas. Este campo registra una explicación o una referencia a una explicación. Por
ejemplo, la referencia podría ser un número de página y la línea de una especificación de requisitos del
producto o de un marcador de minutos en un vídeo de una revisión importante de los clientes.]