VISION (PROYECTO PEQUEO)

1. Introduccin
[El propsito de este documento es recoger, analizar y definir las
necesidades y caractersticas 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 cmo el nombre Sistema satisface estas necesidades se detallan
en el caso de uso y especificaciones suplementarias.]
[La introduccin del documento Visin proporciona una visin general
de todo el documento. Incluye el propsito y las referencias de este
documento Visin.]
1.1.
Referencias
[Esta subseccin provee una lista completa de todos los documentos
referenciados en cualquier lugar en el documento Visin. Identifique
cada documento por ttulo, nmero de reporte si, fecha, organizacin
que publica aplicable. Especifique las fuentes de donde se pueden
obtener las referencias. Esta informacin puede ser proporcionada
por referencia a un apndice o para otro documento.]
2. Posicionamiento
2.1.
Declaracin del problema
[Proporcionar una declaracin que resume el problema a resolver por
este proyecto. Se puede utilizar el siguiente formato:]
El problema de
afecta
Cuyo impacto es
Una solucin exitosa
seria

[describa el problema]
[las partes interesadas afectadas por el
problema]
[Qu es el impacto del problema?]
[enumerar algunos de los beneficios clave de
una solucin exitosa]

2.2.
Declaracin de posicin del producto
[Proporcionar una resumir general de los estados, al ms alto nivel, la
posicin nica del producto tiene la intencin de llenar en el mercado.
El siguiente formato se puede utilizar:]
para
Quin
El
(nombre
producto)
Eso
A diferencia de
nuestro producto

[cliente objetivo]
[declaracin de la necesidad u oportunidad]
del

es un [categora de producto]
[declaracin de beneficio clave; es decir, la razn
de peso para comprar]
[alternativa competitiva primaria]
[declaracin de la diferenciacin primaria]

[Una declaracin de posicin producto se comunica la intencin de la

aplicacin y la importancia del proyecto a todo el personal en cuestin.]
3. Las partes interesadas y descripcin 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.
Tambin debe identificar a los usuarios del sistema y asegurarse de
que la comunidad de interesados los representa adecuadamente. En
esta seccin se ofrece un perfil de los interesados y usuarios
involucrados en el proyecto, y los principales problemas que perciben
ser abordado por la solucin propuesta. No describe sus peticiones o
requerimientos especficos ya que estos son capturados en una las
solicitudes de las partes interesadas artefacto separado. En su lugar,
se presentan los antecedentes y la justificacin de por qu se
necesitan los requisitos.]
3.1.
Resumen de las partes interesadas
[Hay una serie de grupos de inters con un inters 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 seccin
3.2.)]
NOMBRE
[Nombre del tipo de
las
partes
interesadas.]

DESCRIPCION
[Describa brevemente
la parte interesada.]

RESPONSABILIDADES
[Resumir las principales
responsabilidades de las
partes interesadas en
relacin con el sistema
en desarrollo; es decir,
su inters como parte
interesada. Por ejemplo,
este grupo de inters:
asegura que el sistema
ser mantenible
asegura que habr una
demanda de mercado de
las caractersticas del
producto
monitorea el progreso
del proyecto
aprueba la financiacin
y as sucesivamente]

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

DESCRIPCION

RESPONSABILI
DADES

RESUMEN

[Nombre
tipo
usuario.]

del
de

[Describa
revemente
lo
que representan
en relacin con
el sistema.]

[Enumere
las
principales
responsabilidade
s de los usuarios
en relacin con
el sistema en
desarrollo;
por
ejemplo:
capta detalles
produce informes
coordina
el
trabajo
etctera]

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

3.3.
Usuario medio ambiente
[Detalle del entorno de trabajo del usuario de destino. He aqu
algunas sugerencias:
Nmero de personas que participan en la realizacin de la tarea? Es
este cambio?
Cunto dura un ciclo de la tarea? Cantidad de tiempo que pas en
cada actividad? Es este cambio?
Cualquier limitaciones ambientales nicas: mviles, al aire libre,
durante el vuelo, y as sucesivamente?
Qu plataformas de sistema estn en uso hoy en da? Plataformas
futuras?
Qu otras aplicaciones estn en uso? Necesita su solicitud para
integrarse con ellos?
Aqu es donde los extractos del modelo de negocio podran 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
segn la percepcin de la parte interesada o el usuario. Aclarar las
siguientes cuestiones para cada problema:
Cules son las razones de este problema?
Cmo 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 solucin de cada problema. Clasificacin
y tcnicas de voto acumulativo indicar problemas que deben ser
resueltos frente cuestiones que les gustara abordar.
Complete el siguiente cuadro, si a travs de Rational RequisitePro
para captar las necesidades, esto podra ser un extracto o informe de
esa herramienta.]

Necesidad
Los mensajes
difusin

3.5.

Prioridad

Preocupaciones

Solucin
actual

Soluciones
Propuestas

de

Alternativas y Competencia

[Identificar alternativas el interesado percibe como disponible. Estos

pueden incluir la compra de producto de la competencia, la
construccin de una solucin 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 segn la
percepcin de la parte interesada o el usuario final.]
4. Descripcin del producto
[En esta seccin se ofrece una visin de alto nivel de las capacidades
de los productos, interfaces con otras aplicaciones y configuraciones
del sistema. Esta seccin generalmente consta de dos subsecciones,
como sigue:
Perspectiva del producto
Suposiciones y dependencias]
4.1.

Producto Perspectiva

[Esta seccin del documento Visin pone el producto en una

perspectiva a ms productos y el entorno del usuario. Si el producto
es independiente y totalmente autnomo, indicar aqu. Si el producto
es un componente de un sistema ms grande, entonces esta
subseccin necesita relacionarse cmo estos sistemas interactan y
se necesita identificar las interfaces entre los sistemas pertinentes.
Una forma fcil de mostrar los componentes principales del sistema
ms grande, interconexiones, y con interfaces externas es un
diagrama de bloques.]
4.2.

Suposiciones y dependencias

[Lista de cada factor que afecta a las caractersticas indicadas en el

documento de la Visin. Lista de supuestos que, si cambia, alterarn
el documento Visin. Por ejemplo, una suposicin puede indicar que
un sistema operativo especfico estar disponible para el hardware
designado para el producto de software. Si el sistema operativo no
est disponible, el documento Visin tendr que cambiar.]
5. Caractersticas del producto
[Enumere y describa brevemente las caractersticas del producto. Las
caractersticas son las capacidades de alto nivel del sistema que son
necesarias para ofrecer beneficios a los usuarios. Cada caracterstica
es un servicio externamente deseado que requiere tpicamente una
serie de entradas para lograr el resultado deseado. Por ejemplo, una

caracterstica de un sistema de seguimiento de problemas podra ser

la capacidad de proporcionar informes de tendencias. Como el
modelo de casos de uso toma forma, actualizar la descripcin para
referirse a los casos de uso.
Debido a que el documento de la Visin 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 informacin que necesitan para crear un modelo de
casos de uso.
Para gestionar con eficacia la complejidad de aplicacin, 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 caractersticas
constituyen la base fundamental para la definicin del producto,
gestin del alcance, y gestin de proyectos. Cada caracterstica se
ampliar en mayor detalle en el modelo de casos de uso.
A lo largo de esta seccin, cada funcin ser externamente
perceptible por los usuarios, operadores, u otros sistemas externos.
Estas caractersticas deben incluir una descripcin de la funcionalidad
y las cuestiones de usabilidad relevantes que deben ser abordados.
Las siguientes directrices se aplican:
Evite el diseo. Mantenga descripciones de las caractersticas a
nivel general. Centrarse en las capacidades necesarias y por qu (no
cmo) 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 desempeo; y los requisitos
ambientales.
Definicin de los rangos de calidad para un rendimiento, robustez,
tolerancia a fallos, facilidad de uso y caractersticas similares que no
son capturados en el conjunto de caractersticas.
Anote cualquier restriccin de diseo, las restricciones externas, u
otras dependencias.
Definir los requisitos especficos de documentacin, incluyendo
manuales de usuario, ayuda en lnea, instalacin, 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 Documentacin
[Esta seccin describe la documentacin que debe ser desarrollado
para apoyar la implementacin 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
trminos, tutorial frente estrategia manual de referencia, y as
sucesivamente. Limitaciones de formato y la impresin tambin
deben ser identificados.]
7.2.

Ayuda en lnea

[Muchas aplicaciones ofrecen un sistema de ayuda en lnea para

ayudar al usuario. La naturaleza de estos sistemas es nica para el
desarrollo de aplicaciones, ya que combinan aspectos de la
programacin (hipervnculos, etctera) con los aspectos de redaccin
tcnica, tales como la organizacin y presentacin. Muchos han
encontrado el desarrollo de un sistema de ayuda en lnea es un
proyecto dentro de un proyecto que se beneficia de up-front de
gestin del alcance y de la actividad de planificacin.]
7.3.

Guas de Instalacin, configuracin y archivo Lame

[Un documento que incluye instrucciones de instalacin y las

instrucciones de configuracin es importante para una oferta de
soluciones completa. Adems, un archivo Read Me normalmente se
incluye como componente estndar. El archivo Read Me puede incluir
una "Novedades de esta versin" seccin, y una discusin de los
problemas de compatibilidad con versiones anteriores. La mayora de
los usuarios tambin valoran la documentacin que define cualquier
errores y soluciones conocidas en el archivo Lame.]

7.4.

Etiquetado y Embalaje

[Las aplicaciones actuales con tecnologa de ltima generacin

proporcionan un aspecto coherente que comienza con el embalaje del
producto y se manifiesta a travs de mens de instalacin, pantallas
de inicio, sistemas de ayuda, dilogos GUI, y as sucesivamente. Esta
seccin define las necesidades y los tipos de etiquetado para ser
incorporados en el cdigo. Los ejemplos incluyen los avisos de
copyright y patentes, logotipos corporativos, iconos estandarizados y
otros elementos grficos, etc.]