FEATURES (CARACTERISTICAS DEL PRODUCTO) EL DESARROLLO DEL DOCUMENTO DE VISIÓN: El documento Visión debe contener la información esencial sobre el sistema.

Presentación del tema: "FEATURES (CARACTERISTICAS DEL PRODUCTO) EL DESARROLLO DEL DOCUMENTO DE VISIÓN: El documento Visión debe contener la información esencial sobre el sistema."— Transcripción de la presentación:

1 FEATURES (CARACTERISTICAS DEL PRODUCTO) EL DESARROLLO DEL DOCUMENTO DE VISIÓN: El documento Visión debe contener la información esencial sobre el sistema en desarrollo. Además de las lista de todas las características, debe contener una descripción del producto, una descripción del usuario, un resumen de las capacidades del sistema, y otra información que pueda ser necesaria para comprender el sistema y objetivo, de igual manera los documentos deben de ser comprobables, sin redundancia y claridad.

2 LAS CARACTERÍSTICAS SE DERIVAN DE LAS NECESIDADES

3 Algunas partes de la Visión se crean al principio, incluso antes de empezar a suscitar requisitos de los interesados. Ejemplos: Una descripción del problema a resolver Identificación de los usuarios / clientes / actores LAS CARACTERÍSTICAS SE DERIVAN DE LAS NECESIDADES

4 DESARROLLO DE UNA VISIÓN DOCUMENTO: El documento de Visión es uno de los tres documentos más importantes, creados en RequisitePro., los otros dos son los casos de uso y los documentos complementarios. EL DOCUMENTO DE VISIÓN CONTIENE LO SIGUIENTE: Una descripción del problema a resolver por el nuevo sistema Una descripción de alto nivel de la solución Una lista de las principales características del sistema El documento de visión puede servir como un contrato entre un cliente y los desarrolladores.

5 FEATURES (CARACTERISTICAS DEL PRODUCTO) EL PROPÓSITO DEL DOCUMENTO VISIÓN ES: Definir los límites del sistema Identificar las limitaciones impuestas en el sistema Ganancia de acuerdo con el cliente sobre el alcance del proyecto Crear una base para definir los casos de uso y especificaciones suplementarias documentos

6 STRQ1: El usuario deberá ser capaz de comparar precios de vuelos desde otros aeropuertos cercanos. Este requisito es redundante con STRQ11. Se pueden combinar en un solo requisito: FEAT1 El usuario deberá ser capaz de comparar precios de vuelos desde otros aeropuertos, en las proximidades (por vuelo de ida y vuelta). FEATURES (CARACTERISTICAS DEL PRODUCTO)

7 STRQ2 se muestra en las fechas el dd / mm / aaaa. Este requisito es incompatible con STRQ 16, que pide al dd / mm / aaaa. Requisito STRQ2 vino por parte del usuario en Francia, y STRQ16 fue suministrada por el usuario en el EE.UU. Los requisitos STRQ2 y STRQ16 se sustituye por el texto siguiente: FEAT2 las fechas se muestran de acuerdo con el formato almacenado en el navegador web FEATURES (CARACTERISTICAS DEL PRODUCTO)

8 STRQ3 En las pantallas de entrada de datos, el sistema indicará que los campos son obligatorios. En algún momento la decisión será tomada en cuanto a cómo los campos obligatorios se indican como los campos obligatorios. Esta decisión se puede tomar cuando se crea un requisito función, o un poco más tarde, cuando los requisitos adicionales que se derivan de las características. Supongamos que queremos hacer esta ahora, por lo que aplicamos una explicación para crear una hazaña: FEAT3 En la entrada de datos pantallas el sistema indicará que los campos son obligatorios por colocando una estrella al lado del campo. FEATURES (CARACTERISTICAS DEL PRODUCTO)

9 STRQ4 La capacidad de cancelar una compra del billete debe estar disponible. Por coherencia, es mejor utilizar las construcciones estándar de las necesidades, tales como "deberá" en lugar de "debería". Usando diferentes palabras como "será", "hará ", "debería", y "podría" puede ser erróneamente interpretados como los diferentes niveles de necesidad. (Por ejemplo, "se" puede sonar más fuerte que "deberá", y "se" puede sonar más fuerte que "debería". Es necesaria una aclaración en cuanto a quién será capaz de cancelar la compra de boletos (usuario, cliente representante o administrador) y en qué etapa del proceso así lo exijan: FEAT4 El usuario será capaz de cancelar una compra del billete en cualquier momento antes de la confirmación final de la compra. FEATURES (CARACTERISTICAS DEL PRODUCTO)

10 STRQ5 El usuario será capaz de cancelar una reserva del coche o un hotel. Es hasta el analista de sistemas para decidir si un requisito específico es atómico. En este caso, decidió que la cancelación de un coche o reservar habitación de hotel puede ser considerado el mismo requisito, lo que no hay necesidad de dividir: FEAT5 El usuario será capaz de cancelar una reserva del coche o un hotel. FEATURES (CARACTERISTICAS DEL PRODUCTO)

11 STRQ6 La vuelos de salida y regreso serán ordenados por el menor número de paradas. Esta terminología es incompatible con STRQ11. El mismo concepto se denomina "vuelo de regreso" en STRQ6 y "vuelo de vuelta" en STRQ11. Supongamos que después de consultar con las autoridades, hemos decidido utilizar el término "vuelo de regreso". Sin embargo, ya han sido instalados STRQ11 con STRQ1 en FEAT1. Tenemos que volver a FEAT1 y cambiarlo por la coherencia: El usuario deberá ser capaz de comparar precios de vuelos desde otros aeropuertos cercanos (para salida idas y vueltas) y. FEAT1 Debido a que han cambiado FEAT1 para ser coherente con STRQ6, podemos volver a escribir STRQ6 en FEAT6: FEAT6 Los vuelos de salida y regreso serán ordenados por el menor número de paradas precios. de los Sin embargo, esto contradice STRQ18, que solicita que los vuelos serán ordenados por. Podemos acomodar las necesidades de una característica: el usuario podrá elegir si los vuelos serán seleccionados por el menor número de paradas o por precio. FEAT6 como puede ver, se derivan las características es un proceso iterativo, y algunos requisitos de necesidad de cambiar un par de veces hasta que sean coherentes y no redundante. FEATURES (CARACTERISTICAS DEL PRODUCTO)

12 Los atributos describen las propiedades de los requisitos. Ellos ayudan a organizar y analizar los requisitos en el proyecto. Podemos crear reglas para decidir, basándose en los atributos, que los requisitos para aplicar en la siguiente iteración, fase, o la liberación. Por ejemplo, usted puede decidir que en la elaboración que desea implementar todos los requisitos que tienen alto riesgo e importancia media o alta y todos los requisitos que tienen gran importancia y dificultad alta o media. Los atributos pueden ser de tipo lista (identificados por los conjuntos de valores predefinidos descriptivo como Alta, Media y Baja) o la entrada de tipo (texto, hora, fecha, número entero numérico, numérico real). LOS ATRIBUTOS DE LAS CARACTERÍSTICAS:

13 EL VALOR PREDETERMINADO DE LOS ATRIBUTOS DE LAS CARACTERÍSTICAS SON LAS SIGUIENTES: Prioridad (generalmente se usa para determinar el orden de aplicación) Estado (seguimiento del progreso del desarrollo-requisito propuesto, aprobado y validados) Dificultad (lo difícil es la aplicación de este requisito, los valores por defecto son de alta, Media y Baja) Estabilidad (la probabilidad de que la función no va a cambiar durante el proyecto) El riesgo (la probabilidad de que las cuestiones relacionadas con este requisito, con problemas de aplicación, incumplimiento de los plazos, y así sucesivamente) Planificación de iteración (por ejemplo, E1-la primera iteración en la fase de elaboración) Actual iteración Origen (fuente de la obligación) Nombre de contacto (por lo general la persona responsable de este requisito) Solicitud de mejora Defecto Autor Localización (documento en el que reside)