tema 2, gemini

¿Qué actividad se encarga de trabajar con los stakeholders para identificar sus necesidades?. Clasificación de requisitos. Descubrimiento de requisitos. Validación de requisitos.

¿Cuál es un problema habitual de los stakeholders en el proceso de requisitos?. Dificultad para verbalizar sus expectativas y necesidades. Exceso de conocimiento técnico sobre el sistema. Desinterés por el coste final del producto.

¿Qué caracteriza a los "Requisitos del Sistema" frente a los de usuario?. Son descripciones generales en lenguaje natural. Son versiones extendidas, completas y detalladas para los ingenieros. Están dirigidos exclusivamente al cliente final.

¿Qué técnica de especificación es intuitiva pero puede ser vaga y ambigua?. Especificaciones estructuradas. Lenguaje natural. Casos de uso.

¿Qué asegura la uniformidad en las "Especificaciones Estructuradas"?. El uso de plantillas y constructos de programación. La redacción libre por parte del analista. El uso de diagramas de flujo de datos.

¿Cómo deben documentarse los "Casos de Uso"?. Solo mediante código fuente. Con una descripción textual y un diagrama de alto nivel (UML). Únicamente con una lista de requisitos funcionales.

¿Cuál es el objetivo principal de la "Validación de Requisitos"?. Escribir el código del sistema. Comprobar que los requisitos definan lo que realmente quiere el cliente. Estimar el tiempo de desarrollo de cada módulo.

La comprobación de "Consistencia" en la validación busca que: Los requisitos no se contradigan entre sí. El sistema sea rápido. Todos los requisitos sean fáciles de leer.

¿Qué significa que un requisito sea "Verificable"?. Que el cliente ha firmado su aprobación. Que se puede comprobar mediante pruebas que el sistema lo satisface. Que el código ya ha sido escrito.

¿Cuál es la diferencia entre "Requisitos de Usuario" y "Requisitos de Sistema"?. Los de usuario son para ingenieros y los de sistema para clientes. Los de usuario son generales y los de sistema detallan la implementación. No hay diferencia, son sinónimos.

¿Qué técnica de validación analiza sistemáticamente el documento en busca de errores?. Creación de prototipos. Revisión de requisitos. Generación de casos de prueba.

¿Qué ventaja ofrece el "Prototipado" en la validación?. Permite a los usuarios evaluar un modelo ejecutable del sistema. Reduce el número de programadores necesarios. Sustituye por completo al documento de requisitos.

¿Qué actividad del proceso de requisitos organiza los requisitos en grupos coherentes?. Clasificación y organización. Adquisición y análisis. Negociación.

¿Para qué se diseñan "Casos de Prueba" durante la validación?. Para enseñar al usuario a programar. Para ayudar a detectar problemas en los requisitos. Para definir el sueldo de los analistas.

¿Qué es un "Stakeholder" según el proceso de requisitos?. Solo el jefe del proyecto. Cualquier entidad o persona afectada por el desarrollo del sistema. Un programa de software externo únicamente.

En la validación, la comprobación de "Completitud" asegura que: Los requisitos definan todas las funciones y restricciones demandadas. El sistema no tenga errores de sintaxis. El proyecto se haya terminado a tiempo.

¿Qué técnica de adquisición ayuda a descubrir requisitos "implícitos"?. Entrevistas. Observación de cómo se trabaja en la organización. Cuestionarios por correo.

¿Qué característica del lenguaje natural lo hace apto para los requisitos de usuario?. Es expresivo, intuitivo y universal. Es matemáticamente preciso. Evita cualquier tipo de interpretación errónea.

¿Qué debe incluir la "Especificación de Requisitos del Sistema"?. Una especificación detallada de todo el sistema para los diseñadores. Solo el presupuesto del proyecto. Un resumen breve de dos páginas.

¿Cuál es el propósito de la "Priorización" de requisitos?. Eliminar todos los requisitos difíciles. Establecer el orden de preferencia de los requisitos. Decidir quién va a escribir cada requisito.

La "Viabilidad" en el proceso de requisitos considera: Si los requisitos se pueden implementar con el presupuesto y plazos existentes. Si el sistema es estéticamente bonito. Si el código es fácil de leer.

¿Qué actividad sigue al análisis y precede a la validación?. Adquisición. Especificación/Documentación. Mantenimiento.

¿Qué técnica se usa para documentar requisitos antes de validarlos?. Lenguaje natural. Código binario. Ensamblador.

¿Quiénes participan típicamente en las "Entrevistas" de adquisición?. Solo los programadores. Los analistas y los stakeholders. Los auditores externos únicamente.

¿Qué ayuda a resolver la "Negociación de Requisitos"?. Posibles conflictos entre las necesidades de los stakeholders. La falta de ordenadores en la oficina. El lenguaje de programación a elegir.

¿Qué describe la interacción temporal entre componentes (UML)?. Diagrama de clases. Diagrama de secuencia. Diagrama de casos de uso.

La comprobación de "Validez" asegura que: Los requisitos reflejan las necesidades reales incluso tras cambios. El requisito está escrito sin faltas de ortografía. El requisito es corto.

¿Qué se busca al "Clasificar y Organizar" los requisitos?. Agruparlos siguiendo criterios coherentes. Borrar los requisitos que no gusten al programador. Cambiar el nombre de los stakeholders.

¿Qué técnica se combina a menudo con la "Observación"?. Auditoría. Creación de prototipos. Programación extrema.

¿Por qué los analistas tienen dificultades en el proceso de requisitos?. Por la dificultad de entender los requisitos expresados por stakeholders. Porque no saben usar procesadores de texto. Porque los stakeholders siempre están de acuerdo en todo.