WorksheetsQuiz: Ingeniería de Requisitos
Total questions: 10
Worksheet time: 9mins
Durante las pruebas piloto, varios usuarios indican que tardan demasiado en completar el registro inicial y que necesitan ayuda para entender qué hacer en cada paso.
A partir de esta necesidad, el requisito identificado corresponde principalmente a:
Un requisito funcional, porque el problema está en el registro.
Un requisito no funcional asociado a la calidad del sistema.
Una restricción técnica del entorno.
Un requisito de proceso del equipo de desarrollo.
Un analista usa un Ishikawa para estudiar por qué muchos usuarios abandonan la compra antes de pagar.
Encuentra como causas principales que la confirmación del pago tarda demasiado y que los usuarios dudan al ingresar sus datos bancarios.
Con base en esto, ¿qué tipo de requisitos debería priorizar?
Requisitos funcionales relacionados con nuevos módulos.
Requisitos no funcionales asociados a atributos de calidad.
Requisitos de proceso para mejorar la recolección de información.
Restricciones organizacionales del negocio.
En un Impact Map, ¿qué pasa si se omite el nivel de “impacto”?
No pasa nada, porque los objetivos siguen siendo claros.
Se pierde la conexión entre lo que hacen los actores y cómo contribuye al objetivo.
Los entregables pueden modelarse sin problema.
El mapa se convierte en un diagrama de casos de uso.
¿Cuál de las siguientes situaciones representa un problema frecuente durante la elicitud de requisitos?
El analista valida con prototipos lo entendido.
El usuario explica cómo realmente realiza su trabajo.
El cliente omite información porque supone que ciertas reglas “se entienden solas”.
El analista formula preguntas abiertas para comprender el contexto.
En un caso de uso, la relación «include» significa que:
Una funcionalidad opcional se ejecuta solo en condiciones especiales
Un caso de uso reutiliza la lógica de otro de manera obligatoria
Los actores secundarios pueden sustituir al actor principal
La extensión ocurre bajo condiciones alternativas
¿Cuál es una diferencia importante entre una historia de usuario y una especificación detallada de caso de uso?
La historia de usuario describe paso a paso todos los escenarios y el caso de uso solo resume la necesidad.
La especificación de caso de uso detalla la interacción y los flujos, mientras la historia de usuario expresa la necesidad de forma breve.
Ambos artefactos son equivalentes y se usan con la misma profundidad.
La historia de usuario reemplaza completamente cualquier validación posterior.
Un analista diseña un diagrama de actividades para un flujo de registro de usuario. Incluye condiciones como “si el correo ya existe → rechazar”. ¿Qué elemento de UML debe usar para representarlo correctamente?
Un actor externo.
Un nodo de decisión (rombo).
Una elipse.
Un swimlane. (carril de natación)
El enunciado “El sistema debe permitir que los usuarios recuperen su contraseña mediante correo electrónico o SMS” corresponde a:
Requisito funcional
Requisito no funcional – seguridad
Requisito de proceso
Restricción técnica
El enunciado “El sistema debe estar desarrollado en Java y desplegarse en un servidor Tomcat” corresponde a:
Requisito funcional
Requisito no funcional – rendimiento
Restricción de diseño/tecnología
Requisito de negocio
En un diagrama de clases UML, ¿qué se representa principalmente?
El flujo de actividades del proceso
La estructura del sistema con clases y relaciones
La interacción entre actor y sistema
La secuencia temporal de mensajes
