Ingenieria de Requisitos

Al proceso de establecer los servicios que el cliente requiere de un sistema y los límites bajo los cuales opera y se desarrolla, se conoce como Ingeniería de: Servicios. Software. Requisitos.

Cuando el equipo de desarrollo se asegura que el software satisface los requisitos especificados, se conoce como: Validación. Verificación. Requerimiento.

Los requerimientos no funcionales se los puede clasificar en: Usuario y sistema. Producto y organización. Producto, organización y externos.

A la actividad que tiene que ver con el punto de vista del cliente, asegurándose que las necesidades del cliente se cumplan, se lo conoce como: Validación. Verificación. Requerimiento.

Cuando al requerimiento es posible cuantificarlo, entonces es un requerimiento: Factible. Necesario. Verificable.

Cuando al prescindir de un requerimiento, provoca deficiencias en el sistema a construir, entonces el requerimiento es: Factible. Necesario. Verificable.

"Se utilizará RUP como metodología, para el desarrollo del sistema", es un ejemplo de requisito de: Producto. Organización. Externo.

"El sistema debe permitir al usuario registrar los datos de clientes nuevos”, es un ejemplo de requerimiento: Funcional de usuario. Funcional de sistema. No funcional.

“El sistema debe permitir al usuario buscar un empleado por nombre, cédula o código”, es un ejemplo de requerimiento: Funcional de usuario. Funcional de sistema. No funcional.

"El sistema debe permitir a los usuarios buscar el producto por nombre o código de barras”, es un ejemplo de requerimiento: Funcional de usuario. Funcional de sistema. No funcional.

Aquellos requisitos que describen detalladamente los requerimientos funcionales y no funcionales que el software debe cumplir para satisfacer las necesidades del negocio y usuario, se conoce como requerimientos de: Negocio. Usuario. Software.

A los requisitos que determinan el comportamiento del producto obtenido, se los conoce como requisitos de: Producto. Organización. Externo.

Cuando se describen las tareas que los usuarios necesitan llevar a cabo con el software y las características de calidad necesarias del software, se hace referencia a requerimientos de: Negocio. Usuario. Software.

. Cuando se han definido requerimientos que no reflejan las necesidades reales de los clientes, se debe a: Documentos mal redactados. La metodología de desarrollo no es la apropiada. No se ha recolectado la información necesaria.

Los riesgos se deben clasificar de acuerdo a: Su probabilidad y su impacto. La cantidad. El impacto del proyecto.

Para el riesgo "Poco interés de la secretaria de titulación", una estrategia de mitigación sería: Realizar reuniones para informar del nuevo proceso. Hacer un taller para determinar los casos de uso de negocio. Enviar documento de visión.

Un riesgo es CRITICO cuando la probabilidad y el impacto es: Bajo. Medio. Alto.

Un riesgo es INSIGNIFICANTE cuando, la probabilidad e impacto respectivamente es: Ato y bajo. Baja y alto. Baja y bajo.

Cuando se ha detectado el grado en que el riesgo afecta negativamente al proceso de requisitos, entonces se habla de: Estrategia. Probabilidad. Impacto.

Cuando se a detectado el riesgo “Expectativas poco realistas de los clientes”, la mejor alternativa para mitigar sería: Crear la visión del producto. Priorizar requerimientos. Formalizar el documento de visión.

En un taller, la primera actividad que se debe realizar es: Identificar las reglas. Conducir la reunión. Determinar el propósito y los participantes.

A los que conocen las reglas del negocio que deben ser incorporadas dentro del software, se los conoce como: Usuarios. Consejeros. Patrocinador.

El patrocinador esta en la categoría de: Cliente. Usuario. Otros.

Aquellos que están en contacto con el software o son afectados por éste de alguna manera, se los conoce como: Clientes. Proveedores. Usuarios.

Cuando se crea una lista de fuentes de requerimientos se lo realiza en función de: Requerimientos. Interesados. Personas, documentos específicos y fuentes externas.

Para obtener información general sobre las necesidades de los interesados, es conveniente realizar: Entrevista. Prototipos. Mapa de relación.

En el enfoque pasivo de la observación, el ingeniero de requisitos: Se involucra en las tareas, pasando a formar parte del equipo de trabajo. Realiza el análisis en base a notas, videos, etc. Realiza el análisis en base a documentos.

Se desea empezar a obtener los requerimientos de forma adecuada, ¿Qué actividad se debe empezar a realizar?. Establecer metas, expectativas y preparar. Elicitar los requerimientos. Elegir y planificar las técnicas de elicitación de requerimientos.

Al SRI (Servicio de Rentas Internas), con respecto a un sistema de facturación se lo puede catalogar como: Cliente. Usuario. Consejero.

El vicerrector académico de modalidad a distancia de la UTPL, es un interesado cuya responsabilidad es: Detallar los casos de uso. Especificar requerimientos de software. Aprobar el proyecto.

El estudiante con respecto al EVA, es un: Usuario directo. Usuario Indirecto. Cliente.

Los documentos de procesos que dispone una organización, sirven de: Fuentes de requerimientos. Categorización de interesados. Perfiles de interesados.

La tabla de actores, permite: Identificar interesados. Identificar y clasificar a los usuarios del sistema en términos de sus funciones y responsabilidades. Establecer una correspondencia entre actores y detalle de casos de uso.

A los dominios que responden a los acontecimientos en constante cambio para almacenar datos y actuar en función de su estado en un punto en el tiempo, a estos dominios se los conoce como: Dinámicos. Transaccionales de negocio. Estructurales.

Consiste en la generación de nuevo conocimiento en base a unas reglas que cumplen con ciertas condiciones. A estas reglas se las conoce como: Restricciones. Hechos. Inferencias.

A los diagramas que muestran al sistema en su entorno, con las entidades externas que proporcionan y reciben información o material desde y hacia el sistema, se los conoce como: Mapa de procesos. Mapa de relación. Diagramas de contexto.

Cuando el caso de uso base invoca explícitamente al caso de uso añadido y su comportamiento depende de él, pero ninguno de los dos tiene acceso a los atributos del otro, se refiere a la: Inclusión. Extensión. Generalización.

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

Los modelos de análisis de requerimientos se los representa mediante: Algoritmos. Casos de uso de negocio. Diagramas y/o texto estructurado.

Incrementar las ventas en un 40% en el presente año, es un ejemplo de: Objetivos del negocio. Políticas de negocio. Reglas de negocio.