Ingenieria de requisitos IB

Los requisitos son las especificaciones de lo que deben hacer. Las empresas. Los interesados. El software.

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

La imprecisión en la especificación de requisitos ocasiona que sean interpretados de diferente forma por: El software. Las computadoras. Los interesados.

La verificación de requisitos se asegura que el software satisface los requisitos especificados y representa el punto de vista del: Equipo de desarrollo. Cliente. Programador.

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

Obtener una comprensión precisa de los requisitos se realiza en la fase de. Captura. Analisis. Especificación.

Aprobar la lista tentativa de requisitos funcionales definidos por parte de los usuarios expertos en el dominio de la aplicación, se realiza en la fase de: Captura. Análisis. Especificación.

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.

Cuando se desea especificar lo que los desarrolladores necesitan construir, se refiere a los requerimientos de: Negocio. Usuario. Software.

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

El que traduce requerimientos de usuario a especificaciones, 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. Problemática. Glosario.

Cuando existe el riesgo de la falta de participación del usuario, una estrategia de mitigación sería: Crear la visión del producto. Usar técnicas de captura que atraigan a los usuarios al proceso. Desarrollar modelos de alcance.

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

El estudiante con respecto al EVA (Entorno Virtual de Aprendizaje), es un usuario: Directo. Indirecto. Otros.

El SRI (Servicio de Rentas Internas), con respecto al sistema de gestión académica, se lo cataloga como. Consejero. Proveedor. Product champion.

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: Entrevista. Entrevista. Cuestionario.

Son 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: Transaccionales de negocio. Estructurales. Dinámicos.

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

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 requisitos se los puede definir como la especificación de lo que debe hacer el software. v. f.

Definir un requisito de calidad involucra del 10 al 15% del costo total del proyecto. v. f.

La especificación de requerimientos no requiere que éstos sean verificables. f. v.

Los requisitos no funcionales describen las funciones que el software debe ejecutar. v. f.

Los requerimientos funcionales de usuario, establecen con detalle los servicios y restricciones del sistema. v. f.

“El sistema debe permitir al usuario buscar el producto por. Nombre, número de factura y/o código de barras”, esto es un ejemplo de: Requisito de usuario. f. v.

Un requisito externo es un requerimiento funcional que se deriva de las políticas y procedimientos tanto de la organización del cliente como de la del desarrollador. f. v.

“Para el desarrollo del proyecto se debe utilizar la metodología RUP”, es un ejemplo de Requisito de organización. f. v.

Los requerimientos de software son las descripciones detalladas de todos los requisitos funcionales y no funcionales. v. f.

Un requerimiento es completo cuando puede ser entendido de la misma manera por todos los interesados. v. f.

Un requerimiento es completo cuando no es necesario ampliar detalles en su redacción. f. v.

La gestión de requisitos consiste en: elicitación, análisis y especificación de requisitos. v. f.

La gestión de requisitos es un conjunto de actividades que ayudan al equipo de desarrollo a identificar, controlar y dar seguimiento a los cambios de los requisitos en cualquier momento. v. f.

A los interesados también se los conoce como Stakeholders. v. f.

Los únicos interesados de cualquier proyecto son los: clientes y usuarios. f. v.

El gerente del proyecto o del producto actúa como enlace entre el equipo de software y el administrador del negocio. v. f.

El analista asigna recursos para el proyecto. f. v.

El sponsor del proyecto selecciona técnicas de captura de requerimientos. f. v.

El experto en la materia resuelve conflictos en la priorización de requerimientos. f. v.

El desarrollador revisa toda la documentación de requerimientos. v. f.

El tester se asegura que los requerimientos puedan ser robados. v. f.

El analista en la fase de definición de requerimientos de negocio cumple el rol de Revisor. v. f.

Cuando se requiere aclarar términos se debe crear un glosario. v. f.

Con el visionamiento se logra que la definición de la problemática este alineada con las metas y objetivos del negocio. v. f.

El glosario permite ahorrar tiempo y esfuerzo durante el desarrollo de requerimientos. f. v.

Como actividad final en el proceso de construir un glosario, se debe reunir con los interesados para socializar, definir, revisar y aprobar los términos. v. f.

Los riesgos en los requerimientos son sucesos o condiciones que ponen en peligro el desarrollo satisfactorio del producto. v. f.

Durante la fase de especificación de requisitos los riesgos no pueden ser identificados. v. f.

En la clasificación de los riesgos se los analiza de acuerdo a su probabilidad e impacto. v. f.

Se puede decir que la probabilidad del riesgo es ALTO, cuando la probabilidad de que ocurra está entre 75% - 100%. v. f.

Cuando existe el riesgo de: “Requisitos poco claros o ambiguos”, una estrategia de mitigación sería: Crear una línea base y dar seguimiento a los requerimientos. v. f.

Comúnmente los clientes y usuarios no entienden como diseñar y desarrollar software. v. f.

El primer paso para obtener los requerimientos consiste en elegir y planificar las técnicas de captura más adecuadas. v. f.

Dado que los interesados a menudo están ocupados no es necesario desarrollar un plan de captura de requisitos por cada interesado. f. v.

Los proveedores son quienes diseñan y producen el software transformando los requerimientos en producto final. f. v.

Los consejeros tienen conocimiento sobre las reglas del negocio que deben ser consideradas en el software. v. f.

No es apropiado combinar técnicas de captura de requerimientos para evitar malos entendidos. f. v.

Las entrevistas no permiten descubrir conflictos en los requerimientos de software. f. v.

En las entrevista la experiencia del entrevistador no es un factor de éxito. f. v.

Normalmente una entrevista debe durar entre 45 y 60 minutos. v. f.

Luego de preparar las preguntas para la entrevista es necesario programar la entrevista y organizar la logística para la reunión. v. f.

Para una mejor realización del taller es necesario enviar a los participantes la agenda con anticipación. v. f.

Los prototipos exploratorios son versiones parciales o preliminares del software para validar requerimientos. v. f.

El prototipo horizontal permite demostrar la viabilidad técnica de rendimiento, facilidad de uso y otros atributos de calidad. v. f.

Para realizar un prototipo escoja los requerimientos que están poco claros, contradictorios o que impliquen la interacción con el usuario. f. v.

Los grupos focales son entrevistas entre un moderador y un grupo de 6 a 12 personas. f. v.

La técnica de observación considera dos enfoques: el pasivo y activo. v. f.

La técnica de observación se utiliza especialmente cuando se tiene la intensión de mejorar el proceso en curso del proyecto. v. f.

En el cuestionario cada pregunta debe ser laborada de forma corta y en base al contexto. v. f.

Los cuestionarios nos permiten obtener información subjetiva de forma rápida pero a un alto costo. f. v.

Se preocupa por el punto de vista del cliente, asegurándose que las necesidades del cliente se cumplan. A esto se lo conoce como: Verificación. Validación. Requerimiento.

El sistema debe permitir al usuario registrar los datos de los nuevo clientes”, es un ejemplo de: Requerimientos funcionales de usuario. Requerimientos funcionales de sistema. Requerimientos no funcionales.

El sistema debe permitir al usuario conocer el estado del préstamo”, es un ejemplo de: Requerimientos funcionales de usuario. Requerimientos funcionales de sistema. Requerimientos no funcionales.

Son los requisitos que se derivan de los factores externos al sistema y de su proceso de desarrollo, se los conoce como. Requisitos de producto. Requisitos de organización. Requisitos externos.

El máximo espacio de almacenamiento que debe ocupar el sistema es de 10MB ya que debe ser instalado en un dispositivo móvil. Requisitos de producto. Requisitos de organización. Requisitos de organización.

La especificación de requerimientos de software debe realizarse de acuerdo a la metodología VOLERE. Requisitos de producto. Requisitos de organización. Requisitos externos.

“El sistema no debe revelar ninguna información de los clientes del banco”, es un caso de: Requisitos de producto. Requisitos de organización. Requisitos externos.

Son documentos que se los conocen como especificación de requisitos de software, especificación técnica o especificación funcional. Requerimientos del negocio. Requerimientos del usuario. Requerimientos de software.

Los requerimientos pueden ser entendidos de la misma manera por todas las partes interesadas con un mínimo de explicación complementaria. Se refiere a la característica. Completo. Correcto. Claro.

El requerimiento debe describir con exactitud la funcionalidad para ser construida, entonces cumple con la característica de: Completo. Correcto. Claro.

Cuando al prescindir de un requerimiento, provoca una deficiencia en el sistema a construir. Se refiere a la característica: Necesario. Verificable. Sin ambigüedad.

Un requerimiento se lo puede interpretar de una misma forma y por lo tanto el lenguaje usado en su definición no causa confusiones al lector. Se refiere a la característica: Necesario. Verificable. Sin ambigüedad.

Cuando un requerimiento puede ser cuantificado de manera que se pueden utilizar los métodos de verificación de inspección, análisis, demostración o pruebas. Se refiere a la característica de: Necesario. Verificable. Sin ambigüedad.

Identifica a las partes interesadas, la documentación y las fuentes externas de información sobre los requisitos. Son tareas de la fase: Elicitación. Análisis. Especificación.

Se refiere a la producción de un documento a su equivalente electrónico que pueda estar sistemáticamente repasado, evaluado y aprobado. Elicitación. Análisis. Especificación.

Se refiere al grado en que el riesgo afecta negativamente al proceso de requisitos. Probabilidadx. Impacto. Estrategia.

Cuando se a detectado el riego “Constante cambio de requerimientos”, la mejor alternativa para mitigar sería: Crear un plan de participación de interesados. Desarrollar modelos de alcance. Formalizar el documento de visión.

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

A los que son responsables de aceptar o pagar por el producto software, se los conoce como: Clientes. Usuarios. Proveedores.

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: Entrevista. Prototipo. Taller.

A las personas encargadas de investigar, desarrollar, diseñar, fabricar, aprovisionar, probar los productos en la organización, se los conoce como: Patrocinadores. Directores de portafolio. Gerentes operacionales.

A la persona o grupo de personas que financian el proyecto, se los conoce como: Patrocinadores. Directores de portafolio. Gerentes operacionales.

A los ejecutivos de la organización que manejan los proyectos se los conoce como: Patrocinadores. Directores de portafolio. Gerentes operacionales.

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: Transaccionales de negocio. Estructurales. Dinámicos.

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.

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

Son afirmaciones verdaderas acerca del negocio, describen asociaciones o relaciones entre los términos del negocio. A estas reglas se las conoce como: Restricciones. Hechos. Inferencias.

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.

Son reglas que sirven para limitar las acciones que el sistema o los usuarios deben realizar. Se las conoce como: Restricciones. Hechos. Inferencias.

Estas reglas se ejecutan usando fórmulas matemáticas o algorítmicas. Se las conoce como: Restricciones. Hechos. Cálculos.