INGENIERÍA DE REQUISITOS

Cuando se dice, que las especificaciones deben ser verificables, se refiere a la característica de: Los requisitos. El sponsor. Los interesados.

Cuando se tienen que realizar cambios sobre los requisitos ya definidos, esto resulta ser: Fácil. Confuso. Costoso.

Al proceso de establecer los servicios que el cliente requiere de un sistema y los límites bajo los cuales operará y se desarrollará, se denomina: . Ingeniería de requisitos. Ingeniería del software. Gestión del cambio.

La validación de requerimientos se asegura que las necesidades del cliente se cumpla y representa el punto de vista del: Cliente. Programador. Equipo de desarrollo.

Al especificar: “Cada tipo de archivo se representará con un ícono específico”, es una declaración de un requisito: . No funcional. De sistema. De usuario.

Cuando se desea especificar lo que los usuarios podrían hacer con el producto, se refiere a los requerimientos de: Usuario. Software. Negocio.

Se conoce y entiende sobre el dominio de la aplicación en la fase de: Análisis. Especificación. Captura.

Cuando el requerimiento puede ser entendida de la misma manera por todas las partes interesadas, nos referimos a que debe ser: Claro. Necesario. Correcto.

Se obtiene una comprensión precisa de los requisitos en la fase de: Captura. Análisis. Especificación.

“Identificar: los interesados, la documentación y las fuentes externas de información para solicitar información de los requisitos”, son actividades de la fase de: Captura. Especificación. Análisis.

Para definir los requisitos de alto nivel desde la perspectiva del dominio se utiliza el documento de: Requisitos del sistema. Definición del sistema. Requisitos de software.

Para realizar “una descripción completa de las necesidades y funcionalidades del sistema que se va a desarrollar así como para determinar el alcance del sistema y la forma en que se realizarán las funcionales basados en los requerimientos funcionales y no funcionales”, se utiliza el documento de: Requisitos del sistema. Definición del sistema. Requisitos de software.

Las actividades que ayudan al equipo a desarrollar, identificar, controlar y seguir los requisitos, se denomina: Gestión de requisitos. Desarrollo de requisitos. Validación de requisitos.

Cuando existe un constante cambio de requerimientos, se debe; . Crear una línea base y establecer mecanismos de control de cambios. Desarrollar modelos de alcance. Formalizar el documento de visión.

Al que asigna recursos (personal, materiales y fondos) para el proyecto, se lo conoce como. Sponsor del proyecto. Gerente del proyecto. Analista.

Al que define o aprueba la visión y alcance del producto, se lo conoce como: . Sponsor del proyecto. Gerente del proyecto. Analista.

Al encargado de verificar que requerimientos son necesarios, correctos, completos y consistentes, se lo conoce como: Sponsor del proyecto. Gerente del proyecto. Analista.

La descripción del estado del negocio y como los usuarios se beneficiarán cuando el proyecto termine, se conoce como: Visionamiento. Glosario. Problemática.

Para permitir a los dueños del negocio informar al personal técnico acerca de importantes conceptos del negocio, se utiliza: Glosario. Problemática. Visionamiento.

Para evitar los malos entendidos de lo que realmente significan los conceptos del negocio se utiliza . Glosario. Problemática. Visionamiento.

Cuando necesite identificar las fuentes de los requerimientos, se debe: Categorizar a los interesados. Definir los perfiles de los interesados. Crear una lista de fuentes de requerimientos.

Al que autoriza o legitima el desarrollo del producto contratando o pagando el proyecto, se lo conoce como: . Sponsor. Product Champion. Proveedores.

Al que asegura que el software cumple con las necesidades de múltiples comunidades de usuarios, se lo conoce como: Proveedores. Product Champion. Sponsor.

Al riesgo estimado para causar un problema, se lo conoce como: Probabilidad. Requerimiento. Impacto.

A los que poseen cierto conocimiento acerca del producto o un interés en su desarrollo o mantenimiento, se los conoce como: Usuarios. Clientes. Otros interesados.

El estudiante de la asignatura de Ingeniería de requisitos con respecto al EVA (Entorno Virtual de Aprendizaje), es un usuario: . Directo. Indirecto. Otros.

Para obtener información general sobre las necesidades de los interesados, se realiza: La entrevista. Prototipos. Mapas de relación.

A la reunión de las partes interesadas cuidadosamente seleccionadas que trabajan juntas bajo la guía de un experto neutral que produce y documenta modelos de requerimientos, se la conoce como. Taller. Entrevista. Cuestionario.

Para obtener información subjetiva de forma rápida, a un bajo costo, de forma remota a un gran grupo de personas, se utiliza la técnica de . Cuestionario. Taller. Entrevista.

Existen para almacenar y analizar datos, tales como: sistemas de minería de datos, generar consultas e informes; a estos modelos se los conoce como. Estructurales. Dinámicos. Transaccionales de negocio.

Manejan procesos y tareas tales como: operaciones y administración, procesamiento de pedidos y gestión de inventario, a estos dominios se los conoce como: Transaccionales de negocio. Estructurales. Dinámicos.

Evalúan las condiciones para tomar medidas o decisiones como la logística, la detección de fraudes, la configuración del producto y el diagnostico. A estos dominios se los conoce como: Orientados al control. Estructurales. Transaccionales de negocio.

Cuando se desea modelar el negocio, se debe: Combinar entre mapa de relaciones y/o mapa de procesos. Priorizar requerimientos. Construir mapas de diálogo.

Para entender el alcance del proyecto se debe: Combinar entre diagramas de contexto, tablas evento-respuesta y/o reglas de negocio. Priorizar requerimientos. Combinar entre mapa de relaciones y/o mapa de procesos.

Al utilizar un mapa de relaciones y en el diagrama existe la misma entrada o salida, o similar utilizada en múltiples funciones, se hace referencia a: Repetición. Múltiples interfaces externas. Funciones sobrecargadas.

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 relación. Diagramas de contexto. Mapa de procesos.

Permite mostrar la secuencia de pasos, entradas y salidas necesarias para manejar un proceso de negocio a través de múltiples funciones, organizaciones o roles de trabajo. A estos modelos se los conoce como: Mapa de procesos. Mapa de relación. Diagramas de contexto.

Incrementar las ventas en un 25%, es un ejemplo de: Objetivos del negocio. Políticas de negocio. Reglas de negocio.

Al modelo que permite identificar y clasificar a los usuarios del sistema en términos de sus funciones y responsabilidades, se denomina: Tabla de actores. Tabla evento-respuesta. Casos de uso.

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: Hechos. Inferencias. Restricciones.