IS Tema 4: Análisis de requisitos.

¿Qué describe un requisito?. Una utilidad del usuario. Una propiedad/restricción general del sistema. Una restricción al desarrollo del sistema. Todas son correcta.

Tipos de requisitos: Requisitos de usuario. Requisitos del sistema. Requisitos de interfaz. Lo son todas, leelas en moodle!.

¿Para qué se utilizan los requisitos de usuario?. Para calcular el calendario del proyecto. Para ayudar a identificar y gestionar los riesgos del proyecto software. Para negociar el coste del proyecto software. Para definir y entender qué es lo que debe hacer el sistema y validar el sistema desarrollado.

Tipos de requisitos del sistema: Requisitos funcionales. Requisitos no funcionales. Requisitos de dominio. Son todas! Leelas en moodle!.

¿Por qué otro nombre se pueden conocer los requisitos no funcionales?. De organización. De restricción. De operación. De relación.

Tipos de requisitos no funcionales: Requisitos del producto. Requisitos organizacionales. Requisitos externos. Son todas! Leelas en moodle!.

Los Requisitos no Funcionales: Surgen de las necesidades del usuario. Suelen ser más críticos que los requisitos funcionales. Si no son satisfechos, el sistema no resulta útil. Son declaraciones de los servicios que debe proporcionar el sistema. Todas excepto la de "Son declaraciones de los servicios que debe proporcionar el sistema". Todas excepto la de "Suelen ser más críticos que los requisitos funcionales". Todas.

Tras la identificación de los requisitos, éstos deben ser. Incluidos en un Catálogo. Analizados, con el objetivo de detectar inconsistencias, ambigüedades, duplicidad o escasez de información. Validados por los clientes/usuarios. Validados por el director del proyecto. Especificar los requisitos. Todas excepto "Especificar los requisitos.". Todas excepto "Validados por el director del proyecto.". Todas excepto "Validados por los clientes/usuarios.".

Las características que debe tener un requisito son: Identificador, Autor, Tipo de requisito, Descripción, Prioridad (Alta/media/baja), Estado (propuesto/aprobado/incorporado) y Fecha de Creación/Revisión. Identificador, Tipo de requisito, Descripción, Prioridad (Alta/media/baja), Estado (propuesto/aprobado/incorporado) y Fecha de Creación/Revisión. Identificador, Autor, Tipo de requisito, Descripción, Prioridad (Alta/media/baja) y Estado (propuesto/aprobado/incorporado. Identificador, Autor, Tipo de requisito, Descripción, Prioridad (Alta/media/baja), Estado (propuesto/aprobado/eliminado) y Fecha de Creación/Revisión.

A un requisito se le puede asociar. Ninguna de las anteriores. Una prioridad y/o un estado. Una prioridad. Un estado.

Los requisitos se pueden organizar por: Tipo (funcional vs. no funcional). Subsistemas. Jerarquía numérica (1, 1.1, 1.1.1). Todas son posibles.

Los requisitos se deben organizar. Por Subsistemas. Por tipo (RFX / RNFX). Jerárquicamente (RF1 / RF1.1 / RF1.1.1). Por descripción. Todas excecepto "Por descripción".

Las actividades a realizar en el Análisis de Requisitos en orden de realización son: (Dímelas en orden). Elicitación de requisitos, análisis de requisitos, especificación de requisitos y validación de requisitos. Elicitación de requisitos, especificación de requisitos, análisis de requisitos y validación de requisitos. Estudio de viabilidad, obtención y análisis de requisitos y especificación. Especificación de requisitos, extracción de requisitos, análisis y validación.

El orden de las actividades de especificación de requisitos es: Extracción de requisitos, Especificación de requisitos, Análisis de requisitos, Validación de requisitos. Extracción de requisitos, Análisis de requisitos, Especificación de requisitos, Validación de requisitos. Extracción de requisitos, Análisis de requisitos, Especificación de requisitos, Validación de requisitos, Verificación de requisitos. Ninguna correcta.

: Acciones a realizar en la especificación de requisitos: Extracción de requisitos. Análisis de requisitos. Especificación de requisitos. Validación de requisitos.

La etapa que ayuda a controlar y hacer seguimiento de los requisitos y a sus cambios dentro del análisis de requisitos se conoce como: La negociación de Requisitos. Ninguna de las especificadas. La gestión de requisitos. La especificación de Requisitos.

Cuál no es una técnica de captura y análisis de requisitos: Entrevistas. Desarrollo conjunto de aplicaciones (JAD). Prototipado. Observación. Estudio de documentación. Adivinanza. Cuestionarios. Tormenta de ideas (Brainstorming). ETHIC (Effective Technical and Human Implementation of Computerbased System).

¿Cuáles de las siguientes técnicas son para capturar y analizar los requisitos?. Todas las especificadas. Estudio de documentación. Cuestionarios. Prototipado.

La estructura de una Especificación de Requisitos fue definida por: Durán y Bernárdez, 2002. Kotonya y Sommerville, 1998. G. Booch e I. Jacobson, 2000. Gone y Sarson, 1999.

Usuarios de una ERS: Clientes. Gestores. Desarrolladores. Encargados de Pruebas. Prensa. Encargados de Pruebas.

Los usuarios de una ERS fueron definidos por: Durán y Bernárdez, 2002. Kotonya y Sommerville, 1998. G. Booch e I. Jacobson, 2000. Gone y Sarson, 1999.

Según Kotonya y Sommerville (1998), ¿cuáles son los usuarios que utilizan la ERS?. Clientes, Desarrolladores, Encargados del Mantenimiento e Ingenieros de Pruebas. Clientes, Gestores, Desarrolladores, Ingenieros de Pruebas y Encargados del Mantenimiento. Clientes, Gestores, Desarrolladores e Ingenieros de Pruebas. Desarrolladores, Encargados del Mantenimiento, Ingenieros de Pruebas y Gestores.

Usuarios de una ERS: Clientes, Gestores, Desarrolladores, Encargados de Pruebas, Encargados de Mantenimiento. Clientes, Gestores, Desarrolladores, Encargados de Pruebas. Clientes, Director del Proyecto, Desarrolladores, Encargados de Pruebas, Encargados de Mantenimiento. Clientes, Gestores, Desarrolladores, Encargados de Diseño, Encargados de Mantenimiento.

¿Qué es una Historia de usuario?. Una descripción breve, de una funcionalidad software tal y como la percibe el usuario. Un post-it que se utiliza para escribir la especificación de requisitos. Una descripción de todo lo que tiene que hacer el software. Ninguna de las indicadas.

Indique cuáles de las siguientes respuestas son información que se tiene que incluir en una historia de usuario. Estimación. Prioridad. Descripción. Todas las especificadas.

Información en una Historia de Usuario: ID. Descripción. Estimación. Prioridad. Cantidad de elementos que intervienen.

¿Qué es una Epic?. La descripción de la parte de un trabajo que se ha de realizar para completar una historia de usuario. Una historia de usuario de mayor tamaño y mayor funcionalidad y tiene mayor alcance. Una historia de usuario de mayor tamaño y mayor funcionalidad, que sigue el mismo formato que un caso de uso. La descripción de un requisito software.

Ordene de mayor a menor: Temas, Epics, Historias de Usuario, Tareas. Epics, Historias de Usuario, Temas, Tareas. Temas, Tareas, Epics, Historia de Usuario. Historias de Usuario, Tareas, Temas, Epics.

Especificación de requisitos ágiles: Temas. Epic. Historias de usuario. Tareas. Anotaciones.

En la especificación de requisitos en procesos ágiles según su complejidad y cantidad de información, de mayor a menor, podemos distinguir los siguientes tipos: Temas, epics, historias de usuario y tareas. Epics, historias de usuario y tareas. Temas e historias de usuario. Historias de usuario, temas, tareas y epics.

Catalogue el siguiente requisito según la técnica EARS: "Mientras no se confirme el correo electrónico, la cuenta de usuario estará inactiva". Requisito guiado por evento. Requisito guiado por estado. Requisito ubicuo. Requisito de comportamiento inesperado.

Cuando el cliente indica que, "el sistema debe operar 24 horas del día, 7 días de la semana y 365 días del año", está hablando de un tipo de requisito: No funcional. Funcional. No es un requisito. De usuario.

"Seguridad de almacenamiento de una empresa" tipo de requisito. Funcional. No Funcional.

Dos jefes de una empresa estan en desacuerdo sobre escoger un requisito para la empresa. ¿Que se hará?. Ninguna es correcta. Elecitación de requisitos. Ese requisito no se validará nunca. Se negocia el requisito.

"El sistema debe permitir a los usuarios registrarse y iniciar sesión con sus credenciales de inicio de sesión.". Requisito de dominio y funcional. Requisito no funcional. Requisito de usuario. Requisito de dominio y no funcional.

"El sistema debe estar disponible el 99.99% del tiempo". Requisito de dominio y no funcional. Requisito de dominio y funcional. Requisito de interfaz. Requisito funcional.

"Los usuarios cualificados deben estar en condiciones de utilizar todas las funciones del sistema después de 2 horas de entrenamiento": Requisito no funcional verificable. Requisito no funcional. Requisito no funcional y de dominio. Requisito de usuario.

"El sistema debe mostrar una barra de navegación en la parte superior de cada página para permitir a los usuarios navegar fácilmente entre las diferentes secciones del sitio web.": Requisito de interfaz. Requisito de dominio. Requisito de sistema. Requisito de usuario.

"Los usuarios deben poder buscar y filtrar productos en la tienda en línea por precio, categoría y disponibilidad.": Requisito de usuario. Requisito funcional. Requisito de interfaz. Requisito no funcional.