Ing.Requisitos: Tema 1

¿Cuál es el objetivo principal de la Ingeniería de Requisitos (IR)?. Desarrollar el software lo más rápido posible. Conectar el dominio del problema con el dominio de la solución y garantizar la calidad del desarrollo. Escribir el código del software.

Según Frederick Brooks, ¿cuál es la parte más difícil en la construcción de un sistema software?. La implementación. Las pruebas. Decidir qué construir y establecer los requisitos técnicos de forma detallada.

Una de las motivaciones principales para la IR es la dificultad de especificar requisitos. ¿A qué se debe en gran parte esta dificultad?. A la falta de herramientas de software. A la complejidad de la comunicación humana. A la escasez de programadores calificados.

¿Qué fenómeno del lenguaje dificulta la buena comunicación y la correcta especificación de requisitos?. La sintaxis. La semántica. La ambigüedad.

¿Qué se recomienda para evitar la ambigüedad en la comunicación de requisitos?. Usar jerga técnica compleja. Realizar un glosario. Limitar la comunicación a un solo canal.

¿Cuál de los siguientes NO es un obstáculo común en la adquisición de requisitos?. Los usuarios consideran algunos requisitos como asumidos y no los expresan explícitamente. Los usuarios tienen una visión clara y completa de todas las necesidades. Los usuarios no saben expresar de manera precisa lo que quieren.

Según datos del Standish Group, ¿cuál es un motivo común del fracaso de un proyecto software relacionado con los requisitos?. Objetivos demasiado realistas. Requisitos completos y bien definidos. Requisitos incompletos o manejo deficiente de cambios.

¿Cómo se comporta el coste de corregir errores a medida que avanza el proyecto de software?. Disminuye linealmente. Se mantiene constante. Aumenta exponencialmente, siendo mucho mayor en la fase de operación.

¿Qué ofrece la Ingeniería de Requisitos para enfrentar los problemas en la especificación?. Técnicas para acelerar la codificación. Técnicas y herramientas para la adquisición, especificación consistente y gestión de cambios de requisitos. Métodos para eliminar la necesidad de comunicación con el cliente.

Según la definición, la Ingeniería de Requisitos es una rama de la Ingeniería del Software que trabaja con... Únicamente con el código fuente. Objetos del mundo real, servicios requeridos y restricciones, para especificar el comportamiento del sistema. Solo con la interfaz de usuario.

¿Cuál es la diferencia principal entre Verificación y Validación en el contexto de la fabricación de un producto?. La verificación es subjetiva y la validación es objetiva. La verificación se centra en el proceso de fabricación (si se hace correctamente), mientras que la validación se centra en el resultado (si es el producto correcto). No hay diferencia, son sinónimos.

Según la definición de la IEEE, un requisito es: Una solución técnica detallada. Una condición o capacidad exigida por el usuario para solucionar un problema o alcanzar un objetivo, o que debe poseer un sistema para satisfacer un contrato. Una preferencia estética del diseñador.

¿Qué es un 'Stakeholder' en el contexto de un sistema?. Solo el cliente final que usa el software. Una persona u organización que tiene interés en el sistema y puede afectarlo o ser afectado por él. El programador principal del proyecto.

Según Klaus Pohl, ¿cuáles son los tres tipos principales de requisitos?. Funcionales, de Calidad y de Rendimiento. Funcionales, de Calidad y Restricciones. De Usuario, de Sistema y de Negocio.

¿Qué describen los requisitos funcionales (RF)?. La eficiencia y la robustez del sistema. Cómo debe comportarse el sistema, es decir, las respuestas a determinadas entradas o situaciones. Las limitaciones tecnológicas para el desarrollo.

En el modelo EARS para la redacción de requisitos funcionales, ¿qué representa típicamente el 'sujeto'?. El usuario final. El sistema. El analista.

¿Cuáles son las tres perspectivas que deben considerarse en la redacción de requisitos funcionales?. Perspectiva del usuario, del desarrollador y del gestor. Perspectiva de datos, de comportamiento y funcional. Perspectiva de negocio, técnica y operativa.

¿Qué son los requisitos de calidad (o no funcionales)?. Las funciones específicas que el sistema debe realizar. Las limitaciones impuestas al sistema o al proceso de desarrollo. Características que describen la calidad de los servicios que el sistema debe ofrecer, como disponibilidad, eficiencia o usabilidad.

¿Cuál de los siguientes es un ejemplo de requisito de calidad?. El sistema deberá permitir al usuario registrarse. El sistema deberá responder a las peticiones en menos de 2 segundos. El sistema deberá almacenar la información del usuario.

¿Qué es una 'Restricción' en el contexto de los requisitos?. Una función que el sistema debe realizar. Una limitación impuesta al producto o al proceso de desarrollo (ej. tecnológicas, de tiempo, de recursos). Un requisito opcional que mejora la usabilidad.

En el ejercicio de clasificación de requisitos para un club VIP, ¿qué tipo de requisito es 'El sistema deberá estar disponible el 1 de Mayo de 2026'?. Funcional. Calidad (Disponibilidad). Restricción.

En el mismo ejercicio, ¿qué tipo de requisito es 'El sistema deberá almacenar los datos utilizando MySQL, versión 7.3 o posterior'?. Funcional. Calidad (Portabilidad). Restricción.

¿Cuál de las siguientes características es esencial para un buen requisito?. Ser ambiguo. Ser difícil de verificar. Ser completo y preciso.

¿Qué significa que un requisito sea 'Factible'?. Que se pueda implementar con la tecnología actual. Que sea fácil de entender para cualquier persona. Que se pueda implementar dentro de las capacidades y limitaciones conocidas del sistema y su entorno.

¿Por qué es importante 'Priorizar' los requisitos?. Para hacerlos más complejos. Para poder resolver conflictos entre requisitos y gestionar la implementación. Para eliminarlos si no son importantes.

¿Qué implica la 'Trazabilidad' en la gestión de requisitos?. La capacidad del sistema para seguir al usuario. La correspondencia entre un requisito y su diseño, código, pruebas, etc. La facilidad de uso de la interfaz.

¿Cuál es la diferencia entre 'Desarrollo de Requisitos' y 'Gestión de Requisitos'?. El desarrollo se hace al final del proyecto, la gestión al principio. El desarrollo se enfoca en la adquisición, análisis, especificación y validación, mientras que la gestión se enfoca en la trazabilidad y el control de cambios a lo largo del proyecto. Son lo mismo, solo cambian los nombres.

¿Qué perfil se requiere para el responsable del 'Desarrollo de Requisitos'?. Principalmente habilidades de negociación y gestión. Conocimientos y experiencia en ingeniería de software, técnicas de adquisición, especificación y análisis. Experiencia en marketing y ventas.

¿Qué perfil se requiere para el responsable de la 'Gestión de Requisitos'?. Conocimientos técnicos profundos de programación. Principalmente habilidades de gestión, organizativas y de negociación, con un perfil menos técnico. Experiencia en diseño gráfico y de interfaces.

Según el material, ¿cuántas posibilidades existen de no entenderse entre lo que se piensa y lo que se entiende?. Tres. Siete. Nueve.