Ingeniería de Requisitos

El análisis dentro de un proyecto de desarrollo de software responde a la pregunta “¿Cómo se va a hacer?”. Verdadero. Falso.

¿Cuál de las siguientes etapas se encarga de traducir los requisitos en una solución técnica específica?. Análisis. Pruebas. Diseño. Mantenimiento.

El mantenimiento en el ciclo de vida del software incluye solo la corrección de errores. Verdadero. Falso.

¿Cuál de las siguientes etapas NO forma parte del desarrollo típico de un proyecto software?. Análisis. Depuración. Diseño. Implementación.

El objetivo principal del análisis es entender el problema desde el punto de vista del usuario. Verdadero. Falso.

¿Qué etapa del proceso de desarrollo software se encarga de verificar que el producto cumple con los requisitos especificados?. Diseño. Mantenimiento. Pruebas. Implementación.

¿Qué etapa del desarrollo permite adaptar el sistema a nuevos requisitos después de su entrega?. Pruebas. Mantenimiento. Implementación. Diseño.

La implementación es la etapa en la que se traduce el diseño en código ejecutable. Verdadero. Falso.

¿Cuál de las siguientes opciones refleja mejor la motivación detrás de un desarrollo de software en el marco de un proyecto?. Reducir costos de hardware. Automatizar todas las tareas. Conectar el dominio del problema con el dominio de la solución y garantizar la calidad. Eliminar completamente el mantenimiento.

¿Qué se busca lograr al garantizar la calidad del desarrollo dentro de un proyecto software?. Que el software sea el más barato. Que el software funcione en todos los dispositivos. Que el producto cumpla con los requisitos definidos y funcione de manera confiable. Que el software se complete rápidamente.

Según Frederick Brooks, la parte más difícil de construir un sistema software es programarlo correctamente. Verdadero. Falso.

¿Cuál es la afirmación central de Frederick Brooks sobre el desarrollo de software?. Programar correctamente es lo más complejo del proceso. Corregir errores de diseño es sencillo con herramientas modernas. Establecer detalladamente los requisitos técnicos es lo más difícil y crítico. Las pruebas aseguran que el producto no tenga fallos.

Según el texto, los errores cometidos en los requisitos afectan menos al resultado final que los errores de implementación. Verdadero. Falso.

¿Por qué afirma Brooks que es tan importante definir correctamente los requisitos en un proyecto software?. Porque ayuda al equipo a ahorrar tiempo en el mantenimiento. Porque los errores en esta fase son fáciles de corregir. Porque afecta directamente al resultado final y es difícil de rectificar. Porque acelera la fase de implementación.

¿Qué parte del desarrollo de software, según Brooks, tiene un mayor coste si se realiza de forma incorrecta?. El diseño de interfaces gráficas. La implementación de algoritmos. La definición de requisitos técnicos. Las pruebas de sistema.

Brooks sostiene que establecer los requisitos es una tarea sencilla gracias a la experiencia de los ingenieros de software. Verdadero. Falso.

¿Qué aspecto del desarrollo de software destaca Brooks como especialmente difícil de corregir si se hace mal desde el inicio?. El código fuente. Las herramientas de programación. Los errores en la definición de requisitos. Los errores tipográficos en la documentación.

La comunicación en un proyecto software depende exclusivamente del contenido verbal. Verdadero. Falso.

¿Cuál de los siguientes factores no se menciona como influyente en la comunicación en el desarrollo de software?. Contexto. Entonación. Lenguaje no verbal. Velocidad de la red.

Una de las principales dificultades en el desarrollo de software es la complejidad inherente a la comunicación entre personas. Verdadero. Falso.

¿Por qué la comunicación humana se considera compleja en el contexto del desarrollo de software?. Porque los lenguajes de programación son difíciles de aprender. Porque se utilizan muchos protocolos de red. Porque influyen múltiples variables más allá del contenido verbal. Porque los equipos no tienen acceso a herramientas de comunicación.

Una buena comunicación en un proyecto puede lograrse simplemente utilizando herramientas como el correo electrónico. Verdadero. Falso.

¿Qué se puede concluir sobre la comunicación en el desarrollo de software?. Es irrelevante mientras el diseño esté claro. Se basa únicamente en documentos técnicos. Es una fuente importante de dificultades por su complejidad. Siempre es efectiva si se usan reuniones frecuentes.

La sinonimia se refiere a una palabra que tiene varios significados diferentes según el contexto. Verdadero. Falso.

¿Qué significa “polisemia”?. Uso de varias palabras para un mismo concepto. Palabras técnicas mal empleadas. Una misma palabra que tiene varios significados. Palabras con origen extranjero.

El uso de sinónimos para el mismo concepto mejora la claridad de los requisitos. Verdadero. Falso.

¿Cuál de las siguientes acciones se recomienda para mejorar la claridad del lenguaje en el desarrollo de software?. Usar sinónimos para enriquecer el lenguaje técnico. Incluir expresiones polisémicas bien contextualizadas. Elaborar un glosario para unificar términos. Redactar frases más informales para mayor comprensión.

La frase “Ayer vi a Juan paseando” es un ejemplo de ambigüedad. Verdadero. Falso.

¿Por qué es problemático el uso de expresiones polisémicas en documentos de requisitos?. Porque ralentizan la implementación. Porque requieren más espacio para ser explicadas. Porque pueden interpretarse de formas distintas según el lector. Porque hacen el texto más técnico.

Un glosario permite definir términos clave y evitar la ambigüedad en los requisitos. Verdadero. Falso.

Una causa frecuente de errores en los requisitos es que los usuarios a menudo omiten información que consideran obvia. Verdadero. Falso.

¿Cuál de las siguientes afirmaciones refleja un problema habitual durante la recolección de requisitos?. Los usuarios tienen un conocimiento técnico muy profundo. Los usuarios no tienen visión de conjunto del sistema. Los usuarios tienden a sobreespecificar los requisitos. Los usuarios siempre proporcionan ejemplos detallados.

Los usuarios generalmente saben expresar con precisión técnica lo que necesitan en un sistema. Verdadero. Falso.

¿Qué consecuencia puede tener el hecho de que los usuarios no sepan claramente lo que necesitan?. Requisitos completos pero innecesarios. Implementaciones más baratas. Requisitos incompletos, inconsistentes o contradictorios. Pruebas más eficientes.

Una forma de mitigar la ambigüedad y la falta de claridad en los requisitos es mediante la elaboración de un glosario. Verdadero. Falso.

¿Cuál es una recomendación útil para evitar malentendidos al recopilar requisitos de los usuarios?. Confiar únicamente en lo que el usuario dice en la primera reunión. Usar terminología técnica compleja para ganar precisión. Elaborar un glosario compartido de términos clave. Dejar que el usuario redacte los documentos técnicos.

Las dificultades en la expresión de los requisitos por parte del usuario no afectan significativamente al resultado final del sistema. Verdadero. Falso.

Según el Standish Group, uno de los principales motivos de fracaso en proyectos software es tener objetivos poco realistas. Verdadero. Falso.

¿Cuál de los siguientes factores NO se menciona como causa común de fracaso en proyectos software según el Standish Group?. Requisitos incompletos. Implicación insuficiente de los usuarios. Uso de tecnologías obsoletas. Mal manejo de los cambios en los requisitos.

La implicación activa de los usuarios no tiene un impacto significativo en el éxito de un proyecto software. Verdadero. Falso.

¿Qué problema relacionado con los requisitos puede llevar al fracaso de un proyecto según el Standish Group?. Documentación extensa. Requisitos incompletos. Lenguaje técnico excesivo. Pruebas demasiado frecuentes.

Los proyectos con objetivos ambiguos tienen mayor probabilidad de fracasar. Verdadero. Falso.

¿Qué factor relacionado con la gestión del proyecto puede generar problemas significativos si no se trata adecuadamente?. La longitud del código fuente. El número de programadores. El mal manejo de los cambios en los requisitos. La elección del lenguaje de programación.

El establecimiento de objetivos claros y realistas contribuye al éxito del proyecto software. Verdadero. Falso.

La Ingeniería de Requisitos proporciona herramientas únicamente para documentar los requisitos, pero no para extraerlos. Verdadero. Falso.

¿Cuál de las siguientes afirmaciones sí representa una aportación de la Ingeniería de Requisitos según el temario?. Mejora la interfaz gráfica del software final. Proporciona técnicas para que los usuarios programen directamente. Asegura que la especificación de requisitos sea consistente, correcta y completa. Sustituye el trabajo del analista funcional.

La Ingeniería de Requisitos permite una mejor gestión de los cambios en los requisitos a lo largo del proyecto. Verdadero. Falso.

¿Cuál es uno de los objetivos fundamentales de la Ingeniería de Requisitos?. Especificar el algoritmo de programación del sistema. Detectar errores de sintaxis en el código. Extraer, definir y gestionar los requisitos del sistema. Optimizar el rendimiento de la base de datos.

La Ingeniería de Requisitos asegura que los requisitos sean completos, pero no puede garantizar que sean correctos. Verdadero. Falso.

¿Qué problema puede ayudar a resolver directamente la Ingeniería de Requisitos?. El bajo rendimiento del equipo de desarrollo. La falta de documentación legal. El mal manejo de los cambios en los requisitos. La obsolescencia del hardware.

La Ingeniería de Requisitos forma parte de la Ingeniería del Software. Verdadero. Falso.

¿Cuál de los siguientes objetivos NO pertenece a la Ingeniería de Requisitos según la definición del temario?. Verificar y validar los requisitos antes del diseño. Garantizar que los requisitos no sean ambiguos. Programar los módulos funcionales del sistema. Trabajar con restricciones y servicios requeridos.

Uno de los propósitos de la Ingeniería de Requisitos es especificar el comportamiento esperado del sistema. Verdadero. Falso.

¿Cuál de estas características debe tener un buen requisito?. Que sea extenso y técnico. Que sea medible y sin ambigüedad. Que dependa del criterio del desarrollador. Que contenga lenguaje informal.

La Ingeniería de Requisitos se aplica únicamente una vez que ha comenzado la fase de diseño del proyecto. Verdadero. Falso.

¿Qué elementos forman parte del enfoque de trabajo de la Ingeniería de Requisitos?. Algoritmos de optimización. Restricciones del sistema, servicios requeridos y objetos del mundo real. Lenguajes de programación. Protocolos de red y estructuras de datos.

Según la definición del IEEE, ¿cuál de las siguientes opciones corresponde a un requisito?. Una función interna del compilador del sistema. Un algoritmo de ordenación usado durante la implementación. Una condición o capacidad que debe poseer un sistema para cumplir un contrato. Una sugerencia del programador durante la codificación.

Un requisito puede incluir detalles técnicos sobre el diseño o la implementación. Verdadero. Falso.

¿Cuál de los siguientes elementos NO forma parte de la definición IEEE de "requisito"?. Condición exigida por el usuario. Capacidad necesaria para alcanzar un objetivo. Instrucciones específicas de codificación. Requisitos impuestos por un estándar.

Un requisito describe una condición que relaciona el sistema con objetos del mundo real. Verdadero. Falso.

¿Cuál es una de las formas en las que IEEE define un requisito?. Una idea propuesta por el equipo de marketing. Una instrucción informal para el diseñador. Una condición o capacidad exigida por el usuario para alcanzar un objetivo. Una funcionalidad escrita en código de bajo nivel.

Un stakeholder es cualquier persona u organización que tiene interés en el sistema a desarrollar. Verdadero. Falso.

¿Cuál de los siguientes NO es un ejemplo típico de stakeholder?. Usuarios del sistema. Clientes que financian el proyecto. El hardware utilizado para ejecutar el software. Proveedores de componentes o servicios.

Los gobiernos y comunidades pueden ser considerados stakeholders porque pueden imponer legislación que afecta al sistema. Verdadero. Falso.

¿Qué caracteriza a un stakeholder?. Tiene interés en el sistema y puede afectarlo o ser afectado por él. Solo usa el sistema una vez finalizado el proyecto. Se encarga exclusivamente de la codificación del software. Es un componente hardware esencial para el sistema.

Los socios o propietarios del sistema son considerados stakeholders. Verdadero. Falso.

¿Cuál de los siguientes NO es una función de los stakeholders?. Afectar el desarrollo del sistema. Verse afectados directa o indirectamente por el sistema. Programar los módulos del sistema sin supervisión. Establecer requerimientos o estándares que deben cumplirse.

Según Klaus Pohl, ¿cuáles son los tres tipos de requisitos que se deben clasificar?. Requisitos funcionales, requisitos técnicos, requisitos de usuario. Requisitos funcionales, requisitos de calidad, restricciones. Requisitos de diseño, restricciones, requisitos de seguridad. Requisitos de implementación, requisitos legales, requisitos de rendimiento.

Los requisitos funcionales describen cómo debe comportarse el sistema. Verdadero. Falso.

Los requisitos de calidad se centran en la funcionalidad que el sistema debe ofrecer. Verdadero. Falso.

¿Cuál de las siguientes afirmaciones describe mejor una restricción según Klaus Pohl?. La funcionalidad de búsqueda de un libro. El límite de tiempo para que el sistema responda a una consulta. El diseño de la interfaz gráfica. El proceso de aprobación de requisitos por parte del cliente.

Las restricciones pueden referirse tanto al producto como al proceso de desarrollo. Verdadero. Falso.

En el ejemplo, ¿qué representa la frase "tardando menos de 5 segundos en dar la respuesta"?. Un requisito funcional. Una restricción. Un requisito de calidad. Una característica del diseño.

¿Cuál de las siguientes opciones describe un requisito funcional?. El sistema debe responder a las solicitudes en menos de 2 segundos. El sistema debe estar desarrollado usando Java. El sistema debe alertar a la empresa de seguridad si se rompe un cristal. El diseño debe tener un esquema de colores accesible.

Los requisitos funcionales se expresan desde el punto de vista del usuario final. Verdadero. Falso.

¿Cuál de las siguientes afirmaciones refleja un requisito funcional?. El sistema debe desarrollarse en 6 meses. El sistema debe mostrar un mensaje de error si el usuario introduce una contraseña incorrecta. La interfaz debe ser amigable e intuitiva. El sistema debe cumplir con la normativa ISO 25010.

Un requisito funcional especifica cómo debe comportarse el sistema en situaciones particulares. Verdadero. Falso.

¿Cuál de las siguientes afirmaciones NO representa un requisito funcional?. El sistema debe permitir que el usuario registre una nueva cuenta. El sistema debe estar disponible el 99.9% del tiempo. El sistema debe enviar un correo de confirmación tras completar una compra. El sistema debe permitir que el usuario cierre sesión.

¿Cuál de las siguientes perspectivas se enfoca en qué funciones realiza el sistema para cumplir su comportamiento esperado?. Perspectiva de datos. Perspectiva funcional. Perspectiva de comportamiento. Perspectiva estructural.

La perspectiva de comportamiento describe cómo interactúa el sistema con usuarios y sistemas externos. Verdadero. Falso.

¿Qué perspectiva se relaciona con clases conceptuales y atributos en el análisis de requisitos funcionales?. Perspectiva funcional. Perspectiva lógica. Perspectiva de datos. Perspectiva estructural.

La perspectiva funcional trata sobre cómo se presentan los datos al usuario. Falso. Verdadero.

¿Cuál es la relación correcta entre perspectiva y contenido?. Comportamiento → datos y estructuras internas. Datos → métodos y lógica de funciones. Funcional → interfaz de usuario. Datos → conceptos del sistema y atributos.

Las tres perspectivas (datos, comportamiento y funcional) ayudan a plasmar requisitos funcionales de forma completa. Verdadero. Falso.

¿Cuál de los siguientes requisitos de calidad mide la facilidad de probar un sistema para detectar errores?. Usabilidad. Portabilidad. Testabilidad. Confiabilidad.

La interoperabilidad se refiere a la capacidad del sistema de funcionar sin fallos durante un tiempo determinado. Verdadero. Falso.

¿Cuál de las siguientes opciones describe mejor el requisito de robustez?. Capacidad del sistema de resistir ataques externos. Capacidad del sistema de seguir funcionando ante entradas inválidas o condiciones inesperadas. Capacidad del sistema de ser usado en otros entornos operativos. Facilidad con la que un usuario aprende a manejar el sistema.

La mantenibilidad indica lo fácil que es corregir errores y modificar el sistema tras su puesta en marcha. Verdadero. Falso.

¿Qué requisito de calidad está relacionado con la capacidad de usar componentes de un sistema en otros sistemas distintos?. Portabilidad. Reusabilidad. Interoperabilidad. Eficiencia.

¿Cuál de los siguientes requisitos de calidad describe la facilidad para trasladar un sistema entre plataformas?. Portabilidad. Usabilidad. Flexibilidad. Reusabilidad.

La eficiencia mide el tiempo que el usuario necesita para aprender a usar el sistema. Verdadero. Falso.

¿Qué requisito de calidad se enfoca en la facilidad de extender el sistema con nuevas funcionalidades?. Testabilidad. Flexibilidad. Usabilidad. Robustez.

La integridad implica proteger el sistema contra accesos no autorizados o software malicioso. Verdadero. Falso.

¿Cuál de los siguientes requisitos de calidad se centra en la facilidad de uso del sistema?. Usabilidad. Eficiencia. Testabilidad. Confiabilidad.

La disponibilidad implica el porcentaje de tiempo durante el que el sistema está plenamente operativo. Verdadero. Falso.

¿Cuál de los siguientes requisitos de calidad se centra en la probabilidad del que el sistema funcione sin fallos?. Confiabilidad. Flexibilidad. Integridad. Robustez.

Un requisito de calidad puede descomponerse en varios requisitos más específicos, algunos de los cuales pueden ser funcionales. Verdadero. Falso.

¿Qué ocurre durante la descomposición de un requisito de calidad como “El sistema garantiza su propia seguridad”?. Se eliminan todos los requisitos de calidad. Se transforma en un requisito de diseño. Se identifican requisitos más específicos, funcionales o de calidad. Se convierte en un único requisito no funcional.

Todos los requisitos de calidad se mantienen como no funcionales después de ser descompuestos. Verdadero. Falso.

¿Cuál de las siguientes afirmaciones es correcta sobre los requisitos de calidad en fases tempranas del análisis?. Se especifican siempre con mucho detalle desde el inicio. Son ignorados hasta la fase de diseño. Comienzan como declaraciones generales y luego se refinan. Se consideran solamente si el cliente los menciona explícitamente.

¿Qué tipo de requisito sería el siguiente tras una descomposición del requisito “El sistema garantiza su propia seguridad”? “El sistema solicitará autenticación mediante usuario y contraseña antes de permitir el acceso.”. Requisito de calidad. Requisito funcional. Requisito legal. Requisito abstracto.

Las restricciones son condiciones opcionales que se pueden ignorar si el desarrollo del sistema lo requiere. Verdadero. Falso.

¿Cuál de los siguientes ejemplos representa una restricción en el desarrollo de software?. El sistema debe ofrecer un informe mensual de ventas. El sistema debe ejecutarse exclusivamente sobre Linux. El sistema debe mostrar un mensaje de error si no hay conexión. El sistema debe procesar datos personales de los usuarios.

Las restricciones pueden derivarse del contexto legal en el que funcionará el sistema. Verdadero. Falso.

¿Quién suele imponer las restricciones en un proyecto de desarrollo de software?. El equipo de marketing. Los usuarios finales. Los gestores de la organización o el entorno del sistema. El equipo de pruebas.

¿Cuál de las siguientes afirmaciones define mejor una restricción?. Describe una funcionalidad específica del sistema. Es un deseo opcional del cliente que puede implementarse más adelante. Es una condición que limita el desarrollo o el entorno operativo del sistema. Es un objetivo general del proyecto.

El origen de una restricción puede ser legal, cultural o estar impuesto por la organización. Verdadero. Falso.

¿Cuál de las siguientes opciones representa una restricción sobre el proceso de desarrollo?. El sistema debe encriptar las contraseñas. El proyecto debe completarse en un máximo de 6 meses. El sistema debe funcionar en dispositivos móviles. El usuario debe autenticarse antes de acceder.

Una restricción que obliga al sistema a adaptarse a una determinada función interna es un ejemplo de restricción sobre el proceso. Verdadero. Falso.

¿Cuál de los siguientes NO es un origen típico de una restricción?. Gestión del proyecto. Cultura organizacional. Creatividad del desarrollador. Normativas legales.

¿Qué elementos se usan para caracterizar una restricción?. Nivel de urgencia y presupuesto disponible. Origen y objeto de la restricción. Tipo de requisito funcional asociado. Lenguaje de programación utilizado.

Un requisito verificable es aquel que puede comprobarse si se ha implementado correctamente. Verdadero. Falso.

¿Cuál de las siguientes características implica que un requisito NO contradice otros requisitos y refleja fielmente una necesidad real del sistema?. Completo. Correcto. Factible. Priorizado.

Un requisito que no se puede implementar con la tecnología actual sigue siendo válido si es necesario para el usuario. Verdadero. Falso.

¿Qué característica asegura que un requisito esté libre de ambigüedades y se entienda de la misma manera por todos los stakeholders?. Preciso. Verificable. Priorizado. Completo.

¿Qué significa que un requisito esté priorizado?. Que está documentado en primer lugar en la lista. Que se puede comprobar su cumplimiento. Que tiene un nivel de importancia establecido respecto a otros requisitos. Que está libre de contradicciones.

Un requisito se considera completo cuando: Se refiere a todos los stakeholders. Cubre todas las posibles implementaciones técnicas. No deja aspectos esenciales sin definir. No entra en conflicto con otros requisitos.

Un requisito puede considerarse "completo" aunque falte información esencial, siempre que esté redactado de forma clara. Verdadero. Falso.

¿Cuál de las siguientes afirmaciones describe mejor un requisito completo?. Tiene una longitud suficiente para su comprensión. Está redactado con tecnicismos para garantizar su precisión. Describe toda la funcionalidad necesaria sin omisiones. Está redactado por el equipo de diseño.

¿Qué significa la sigla "TBD" en un documento de requisitos?. To Be Designed. Time Before Delivery. To Be Determined. Total Business Definition.

Antes de entregar los requisitos para su desarrollo, es recomendable buscar las apariciones de las siglas "TBD" o "PD" para asegurarse de que no falte información. Verdadero. Falso.

¿Cuál es el principal motivo para usar etiquetas como "TBD" o "PD" en los requisitos?. Aumentar el número de requisitos. Indicar que el requisito ya fue aprobado. Señalar que el requisito es opcional. Marcar que falta información que debe definirse más adelante.

Un requisito es correcto si proviene de una fuente autorizada, como un usuario, un estándar o un sistema externo. Verdadero. Falso.

¿Cuál de los siguientes factores determina la corrección de un requisito?. Que esté bien redactado. Que sea técnicamente factible. Que provenga de una fuente autorizada. Que esté implementado en el sistema.

Un requisito que entra en conflicto con otro requisito de “orden superior” puede seguir considerándose correcto. Verdadero. Falso.

¿Cuál de los siguientes requisitos podría considerarse incorrecto?. Proviene de un usuario clave del sistema. Está alineado con un estándar de la industria. Contradice un requisito ya validado por la dirección del proyecto. Refleja una necesidad impuesta por la ley.

¿Cuál es un ejemplo de fuente legítima para un requisito correcto?. La intuición del desarrollador. Un documento informal compartido por WhatsApp. Un reglamento técnico oficial. Suposiciones basadas en sistemas anteriores.

Un requisito es factible si puede ser realizado con las capacidades y limitaciones actuales del sistema y su entorno operativo. Verdadero. Falso.

¿Cuál es el rol del analista en la gestión de requisitos no factibles?. Ignorar los requisitos imposibles y seguir adelante. Informar a los clientes sobre requisitos técnicamente inalcanzables o muy costosos. Implementar todos los requisitos sin cuestionar. Cambiar el entorno operativo para cumplir todos los requisitos.

¿Cuál de las siguientes opciones indica un requisito no factible?. Un requisito que el sistema actual puede cumplir con una actualización menor. Un requisito que exige una tecnología aún no desarrollada. Un requisito que puede realizarse con recursos adicionales. Un requisito que cumple con las normas vigentes.

El costo de implementar un requisito no afecta a su factibilidad, solo a la prioridad. Verdadero. Falso.

Para evitar requisitos no factibles, el analista debe: Confirmar que todos los requisitos son técnicamente posibles o discutir los límites con el cliente. Añadir todos los requisitos sin restricción. Cambiar el alcance del proyecto para evitar problemas. Ignorar la opinión del cliente sobre la factibilidad.

Un requisito preciso es aquel que se expresa de manera clara y sin ambigüedad para que todos los lectores puedan entenderlo. Verdadero. Falso.

¿Qué acción se recomienda para mejorar la precisión de los requisitos?. Usar sinónimos para evitar repeticiones. Añadir un glosario con términos especializados o poco comunes. Escribir requisitos de forma vaga para ser flexibles. Dejar que cada lector interprete a su manera.

Es recomendable usar sinónimos para expresar un mismo concepto en diferentes requisitos para enriquecer el texto. Verdadero. Falso.

¿Qué problema genera la ambigüedad en los requisitos?. Facilita la interpretación del requisito. Provoca malentendidos y errores en el desarrollo. Reduce el tiempo de desarrollo. Mejora la comunicación entre equipos.

¿Cuál de los siguientes es un ejemplo de término ambiguo que debería evitarse para mantener la precisión?. “Alta disponibilidad” sin definir qué significa “alta”. “El sistema debe permitir la autenticación”. “El usuario debe poder guardar sus datos”. “El sistema se reiniciará cada 24 horas”.

Asignar prioridades a los requisitos ayuda a resolver conflictos y valorar su corrección. Verdadero. Falso.

¿Cuál es el principal beneficio de priorizar los requisitos?. Reducir el número total de requisitos. Facilitar la toma de decisiones cuando hay conflictos entre requisitos. Eliminar requisitos redundantes. Acelerar la fase de pruebas.

La priorización de requisitos solo es útil durante la fase de diseño del software. Verdadero. Falso.

¿Qué puede ocurrir si no se asignan prioridades a los requisitos?. Se optimiza el tiempo de desarrollo. No hay conflictos entre requisitos. Puede ser difícil decidir qué requisitos implementar primero. Se elimina la necesidad de pruebas.

¿Cuál de los siguientes es un criterio común para asignar prioridades a los requisitos?. Complejidad técnica. Popularidad del usuario. Impacto en el negocio o usuario final. Cantidad de líneas de código.

Un requisito es verificable si existe alguna forma objetiva de probar que ha sido correctamente implementado. Verdadero. Falso.

¿Qué significa que un requisito sea verificable?. Que sea fácil de entender. Que se pueda comprobar mediante pruebas o métodos objetivos. Que sea barato de implementar. Que sea prioritario para el cliente.

Un requisito que no puede ser probado ni medido no es verificable. Verdadero. Falso.

¿Cuál de las siguientes características ayuda a que un requisito sea verificable?. Ser ambiguo para permitir flexibilidad. Definir criterios claros y medibles para su cumplimiento. Incluir muchos detalles técnicos. Ser muy general para cubrir muchos casos.

¿Por qué es importante que un requisito sea verificable?. Porque garantiza que se pueda validar su cumplimiento durante el proyecto. Porque facilita la creación de la documentación del proyecto. Porque acelera la fase de diseño. Porque reduce el coste de desarrollo.

El desarrollo de requisitos requiere un perfil técnico con conocimientos en ingeniería de software. Verdadero. Falso.

El responsable de la gestión de requisitos necesita principalmente habilidades de negociación y organización, y no necesariamente conocimientos técnicos profundos. Verdadero. Falso.

¿Cuál es una diferencia clave entre el perfil del responsable de desarrollo y el de gestión de requisitos?. El responsable de desarrollo tiene experiencia en marketing. El responsable de gestión debe dominar técnicas de análisis técnico. El responsable de desarrollo debe tener experiencia técnica en ingeniería de software. Ambos perfiles requieren el mismo nivel técnico.

¿Cuál de las siguientes tareas corresponde típicamente a la gestión de requisitos?. Especificación detallada de requisitos. Análisis técnico de requisitos. Negociación con stakeholders para acordar prioridades. Implementación del sistema.

Las tareas de desarrollo y gestión de requisitos siempre deben ser realizadas por la misma persona. Verdadero. Falso.

¿Cuál de las siguientes tareas forma parte del desarrollo de requisitos?. Supervisar el presupuesto del proyecto. Identificar los conceptos conceptuales que formarán parte del software. Planificar la estrategia de marketing del producto. Gestionar los recursos humanos.

La adquisición de necesidades individuales de cada usuario es una tarea propia del desarrollo de requisitos. Verdadero. Falso.

En el desarrollo de requisitos, ¿qué se debe hacer con la información recibida de los usuarios?. Analizarla y distinguir requisitos funcionales, no funcionales y reglas de negocio. Ignorar los requisitos no funcionales. Enviarla directamente al equipo de marketing. Rechazarla si no está en formato digital.

Negociar prioridades de implementación es una tarea que corresponde al desarrollo de requisitos. Verdadero. Falso.

¿Qué se hace después de trasladar las necesidades de usuario a documentos de especificación de requisitos?. Comenzar la codificación sin revisión previa. Revisar los documentos para asegurar comprensión y corregir problemas. Publicar los documentos en la web sin autorización. Ignorar el feedback de los usuarios.

¿Cuál es la función principal de una “línea base” (baseline) en la gestión de requisitos?. Es una especificación de requisitos aprobada y no modificable hasta que se cree una nueva versión. Es un documento de marketing para los clientes. Es un plan de desarrollo de software. Un informe que detalla errores en el código.

Revisar los cambios propuestos en los requisitos y evaluar su impacto antes de aprobarlos es una tarea de gestión de requisitos. Verdadero. Falso.

¿Cuál de las siguientes tareas NO corresponde a la gestión de requisitos?. Llevar control de versiones de requisitos. Supervisar la trazabilidad entre requisitos y casos de prueba. Implementar directamente el código del sistema. Incorporar cambios aprobados de forma controlada.

El seguimiento del estado y cambios en los requisitos se realiza solo durante las fases iniciales del proyecto. Verdadero. Falso.

¿Qué implica la trazabilidad en la gestión de requisitos?. Relacionar requisitos con diseño, código, y pruebas para asegurar coherencia. Documentar únicamente los requisitos iniciales. Crear informes financieros del proyecto. Planificar el calendario de entregas.

¿Qué debe hacerse cuando se aprueba un cambio en los requisitos?. Ignorar el cambio hasta la siguiente versión del software. Incorporar el cambio de manera controlada en el proyecto. Implementar el cambio sin revisión previa. Eliminar los requisitos anteriores sin más.

La gestión de requisitos incluye la evaluación del impacto que un cambio propuesto puede tener en el proyecto. Verdadero. Falso.

¿Cuál es una ventaja de mantener un control de versiones en los requisitos?. Permite modificar requisitos sin ninguna aprobación. Facilita el seguimiento de cambios y mantiene una línea base estable. Elimina la necesidad de pruebas posteriores. Mejora la velocidad de codificación.

La trazabilidad de los requisitos ayuda a garantizar que todos los requisitos se implementen y prueben adecuadamente. Verdadero. Falso.

¿Qué rol requiere más habilidades organizativas y de negociación dentro de la gestión de requisitos?. Responsable del desarrollo de requisitos. Responsable de la gestión de requisitos. Programador. Tester.

La gestión de requisitos solo es importante durante la fase inicial del proyecto. Verdadero. Falso.

¿Cuál es el propósito principal de revisar los documentos de requisitos?. Detectar errores y asegurar la comprensión antes del desarrollo. Reducir el número de usuarios del sistema. Crear más requisitos funcionales. Planificar la gestión de recursos.

La gestión de requisitos implica la aprobación formal de cambios antes de su implementación. Verdadero. Falso.