ANALISIS/REQUERIMIENTOS Flashcards
(18 cards)
¿Qué es un requerimiento funcional?
Especifica una función o comportamiento que el sistema debe realizar (p. ej., “registrar usuarios”).
¿Qué es un requerimiento no funcional?
Define atributos de calidad o restricciones del sistema (p. ej., rendimiento, seguridad, usabilidad).
Ejemplo de requerimiento funcional vs no funcional.
Funcional: “El sistema enviará correos de confirmación”. No funcional: “El correo debe enviarse en < 60 s”.
Plantilla estándar de una historia de usuario.
“Como [rol], quiero [función] para [beneficio]”.
Tres componentes clave de una historia de usuario.
Rol, funcionalidad deseada, beneficio/valor.
¿Qué es una épica?
Historia de usuario grande que se divide en historias más pequeñas para planificar y entregar.
Definición de feature.
Conjunto coherente de funcionalidades relacionadas que satisfacen una necesidad de usuario.
¿Para qué sirven los criterios de aceptación?
Establecen condiciones comprobables que una historia debe cumplir para considerarse completa.
Acrónimo INVEST y qué evalúa.
Independent, Negotiable, Valuable, Estimable, Small, Testable — cualidades de buenas historias de usuario.
Significado de la priorización MoSCoW.
Must-have, Should-have, Could-have, Won’t-have-this-time.
Dos técnicas de elicitation de requisitos.
Entrevistas y prototipado (también válidas: workshops, observación, encuestas).
Propósito de la trazabilidad de requisitos.
Rastrear cada requisito desde su origen hasta diseño, implementación y pruebas para asegurar cobertura.
Documento SRS (Software Requirements Specification)
Describe completa y sistemáticamente todos los requisitos funcionales y no funcionales del proyecto.
Atributos que debe cumplir un buen requerimiento.
Correcto, completo, consistente, comprensible, verificable, trazable.
¿Qué es un backlog en contexto ágil?
Lista priorizada y dinámica de historias de usuario / requisitos que representan el trabajo pendiente.
Diferencia entre user story y caso de uso.
Story describe necesidad desde perspectiva de negocio
¿Para qué se usa un modelo de dominio durante análisis?
Para representar entidades, atributos y relaciones clave del problema antes del diseño.
Categorías comunes de requerimientos no funcionales.
Rendimiento, seguridad, confiabilidad, mantenibilidad, usabilidad, portabilidad.
