I_R_II Bim

Cuándo se realiza eI análisis de requisitos, tanto eI cliente como el usuario participan : a. Aprobando los modelos de análisis , para su posterior implementación. b. Validando, corrigiendo y aclarando la especificación de requisitos si se encuentran errores o ambiguedades. c. Si es necesario cambiar la especificación de requisitos y se requiera de información adicional.

El objetivo del análisis de requisitos consiste en: a. Construir los mapas de procesos con el diagrama de contexto. b. Desarrollar los requisitos con la suficiente calidad y nivel de detalle. c. Escribir utilizando plantillas los requisitos funcionales y no funcionales.

El ciclo de análisis de requisitos consiste en realizar el: a. Modelado de negocio, definir el alcance, modelos al detalle y priorizar requisitos. b. Proceso de Obtenciôn, anàlisis , especificaciôn y validaciôn. c. Modelado del negocio y priorizar requisitos.

Para definir eI alcance deI proyecto se puede. a. Crear una combinación de modelos. b. Reunir a los interesados para negociar los requisitos. c. Definir los criterios para priorizar los requisitos.

Cuando en la descripción de los requisitos se hace referencia a un "verbo", el componente de análisis que podría expresar son: a. Actores. b. Procesos. c. Decisión.

Considerando el enfoque de modelo de usuario , qué diagrama permite conocer ¿Oué información entra y sale del sistema ?: a. Proceso. b. Estado. c. Contexto.

Para un contexto dinámico. eI modelo más adecuado es: a. Tabla evento-respuesta y diagramas de estado. b. Casos de uso. c. Actores.

Dada una gran cantidad de información dónde se desea obtener indicadores en base al análisis mediante algoritmos de minería de datos. Este caso corresponde al dominio: a. Dinámico. b. Estructural. c. Transaccion al de negocio.

Cuando existe un caso de uso padre del cual uno o más casos de uso hijos heredan sus características y especializan cierto comportamiento . se da una relación de: a. Inclusión. b. Generalización. c. Extensión.

Un ejemplo de regla de negocio es: a. Incrementar la cantidad de estudiantes nuevos en un 15'% en el próximo periodo. b. Ofrecer descuentos a los estudiantes en su matricula de acuerdo al período de tiempo en que realice la matrícula. c. A los estudiantes que pagan al contado su matrícula reciben un descuento del 10%.

EI "Documento de requerimientos de usuario", permite establecer un puente entre: a. Las necesidades del usuario y la especificación de requisitos de software. b. Las necesidades del usuario y la arquitectura de componentes. c. El visionamiento y las necesidades de los usuarios.

Una fuente para documentar los requisitos de usuario podría ser: a. Arquitectura candidata. b. Los modelos de análisis. c. La infraestructura tecnológica.

En eI documento de especificación de requerimientos se debe incluir, requisitos: a. Solo Funcionales. b. Funcionale s y No funcionales. c. Solo necesidades.

EI estándar que se recomienda para documentar los requisitos de software es: a. IEEE 830. b. IEEE 2120. c. IEEE 25000.

El responsable directo de Ia eIaboración deI documento "Especificación de Requerimientos de Software" es eI : a. Analista. b. Gerente del proyecto. c. Desarrollador.

Uno de los lectores deI documento de requerimientos de usuario es eI : a. Programador. b. Patrocinador del proyecto. c. Diseñador de la base de datos.

Las convenciones de interfaz de usuario a seguir cuando se mejora un producto existente, se describen en la ERS en la sección de: a. Suposiciones y dependencias. b. Características del sistema. c. Restricciones de diseño e implementación.

"Cualquiera que lea eI requisito llega a Ia misma interpretación que cualquier otro lector", es uno de los objetivos de: a. La estimación de actividades del proyecto. b. El desarrollo de requisitos. c. La redacción de los requisitos.

El requisito: "Si el producto no se encuentra en el almacén, el sistema deberá mostrar la disponibilidad del producto en las demás sucursales”, es una definición desde la perspectiva del: a. Sistema. b. Usuario. c. No es un requisito.

La declaración: "Tras el envío de la actualización del producto , el número de serie se actualizará en la línea del contrato”’, está escrito en voz. a. Pasiva. b. Activa. c. No se identifica.

A qué pregunta debe responder Ia Verificación, en eI proceso de desarrollo de requis itos: a. ¿ Estamos construyendo el producto correcto ?. b. ¿ Estamos construyendo el producto correctamente ?. c. ¿ Estamos construyendo el producto útil?.

El enfoque de revisión informaI ’”peer deskcheck", es eI que: a. Repite a un colega mirar por encima el producto de trabajo. b. Se invita a varios colegas a examinar simultáneamente una entrega. c. Donde el autor describe una entrega y solicita comentarios sobre ella.

EI producto principal de una revisión de requisitos formales: a. Las de claraciones de los requisitos que no cumplen con las características de calidad. b. Una Iista de revisores y el juicio del equipo de revisores. c. Un resumen de los defectos encontrados y los problemas planteados durante la revisión.

En una inspección. ¿Qué es lo que buscan todos los participantes ?. a. Los requisitos de software. b. Defectos y oportunidades de mejora. c. La linea base del proyecto.

¿ Ouiénes hacen Ia pIanificación de Ia inspección?. a. El autor y moderador. b. El revisor. c. El moderador.

El prototipo que está orientado a los desarrolladores , con el fin de comprobar la funcionalidad de los componentes de la solución que se está desarrollando , se conoce como requisito de: a. Interfaz de usuario. b. Rendimiento. c. Funcional.

En Ias pruebas de aceptación de usuario, con los requisitos que no superaron Ias pruebas se puede: a. Rechazar la implementación. b. Dar la prioridad más alta para su corrección. c. Proponer criterios de mejora.

Para crear Ios casos de prueba en Ia validación se parte de: a. El documento de visión. b. Los modelos de negocio. c. Los requisitos de software.

DesarroIIar una pantalla para Ia matrícuIa en I ínea donde eI usuario pueda vaIidar se conoce como: a. Matriz de requerimientos. b. Prototipo operacional. c. .Ayuda de usuario.

Cuando se requiere realizar pruebas de aceptación por parte deI usuario, se debe: a. Realizar pruebas sobre modelos de requerimientos. b. Crear pruebas de Validación. c. Mostrar partes del sistema.

31. En el proceso de gestión de requisitos todas las actividades permiten: a . Mantener la integridad, exactitud y coherencia de los acuerdos de los requisitos. b . Obtener, analizar y especificar los requisitos de software. c. Modelar el negocio , Definir el alcance y priorizar los requisitos.

EI responsable principal de Ia gestión de requisitos es eI : a . Gerente de producto. b. AnaIista de negocio. c. Patrocinador del proyecto.

Los requisitos funcionales una vez que se han aprobado y revisado se constituyen en: a . Funcionalidades del sistema. b . Características del sistema. c. Línea base de los requisitos.

Antes de la linea base, los requisitos. a. No cambian. b. Evolucionan. c. Se implementan.

Lo más conveniente para hacer eI controI de versisones de Ios requisitos es: a. Almacenar los requisitos en una herramienta de administración de requisitos. b . Elaborar un documento de Especificacion de Requisitos de Software. c. Utilizar UML para documentar requisitos.

Las herramientas de gestion de requis itos, para registrar los requisitos utilizan: a. Plantillas. b. Atributos. c. APIs.

¿Qué ocurre con los requisitos planificados a medida que se agregen nuevos requistos?. a . Cambiarán. b . Desechan. c. Implementan.

En una herramienta de gestión de requisitos, los requisitos etiminados y rechazados se deben: a . Eliminar de la herramienta. b . Manejarlos mediante un atributo de estado. c. Documentar en un archivo.

En lo referente a Ia gestión de requisitos, eI ERS sirve de: a . Prototipo. b. Linea base. c. Validador.

La relación de un requisito con otros requisitos y las diferentes instancias o artefados con que se relaciona, así como el ciclo de ida de un requisito, desde su origen, pasando por su desarrollo y especificación y finalizando con su despliegue, se conoce como. a. Gestón. b. Analisis. c. Trazabilidad.