38. Revisión, validación y aprobación con usuarios

38.1 Introducción

Un caso de uso no está completo solo porque fue escrito por el analista. Debe ser revisado, validado y, cuando el proyecto lo requiera, aprobado por usuarios o responsables del negocio.

La revisión permite detectar errores de redacción, omisiones, contradicciones y detalles poco claros. La validación permite confirmar que el caso de uso representa una necesidad real. La aprobación deja constancia de que el contenido fue aceptado como base de trabajo.

Este proceso reduce el riesgo de construir una funcionalidad técnicamente correcta pero equivocada para el usuario.

38.2 Revisar no es lo mismo que validar

Revisar significa inspeccionar el caso de uso para mejorar su calidad: claridad, completitud, consistencia y formato. Puede hacerlo el equipo técnico, el analista, testers o pares de revisión.

Validar significa confirmar con usuarios o representantes del negocio que el caso de uso describe correctamente lo que se necesita.

38.3 Por qué aprobar casos de uso

La aprobación es útil cuando el caso de uso será usado como referencia para desarrollo, pruebas, contrato, alcance o entrega. No siempre requiere una firma formal; puede ser una aceptación registrada en una herramienta de trabajo, una reunión o un documento.

Lo importante es que quede claro quién aceptó el contenido, en qué versión y con qué observaciones.

38.4 Ciclo de revisión, validación y aprobación

El proceso suele ser iterativo. Primero se prepara una versión del caso de uso, luego se revisa internamente, se valida con usuarios, se ajusta según observaciones y finalmente se aprueba o queda listo para desarrollo. Si aparecen cambios importantes, el ciclo puede repetirse.

38.5 Quiénes deben participar

La revisión y validación pueden involucrar distintos roles:

• Usuarios finales: confirman si el flujo representa su trabajo real.
• Responsables del negocio: validan reglas, prioridades y alcance.
• Analistas: verifican claridad, consistencia y completitud.
• Desarrolladores: detectan dudas técnicas o integraciones omitidas.
• Testers: revisan si el caso permite derivar pruebas claras.
• Responsables de seguridad o calidad: revisan restricciones críticas.

38.6 Qué revisar en un caso de uso

Durante la revisión conviene verificar:

• Nombre orientado al objetivo.
• Actor principal correcto.
• Precondiciones claras.
• Flujo principal completo y ordenado.
• Flujos alternativos relevantes.
• Excepciones y recuperación.
• Postcondiciones verificables.
• Reglas de negocio y requisitos no funcionales relacionados.

38.7 Cómo validar con usuarios

Una forma efectiva de validar es recorrer el caso de uso como una historia concreta. En lugar de preguntar "¿está bien?", conviene leer el flujo paso a paso y pedir al usuario que confirme si representa su trabajo.

Preguntas útiles:

• ¿Este es el orden normal de trabajo?
• ¿Falta alguna decisión importante?
• ¿Qué ocurre si este dato no está disponible?
• ¿Qué reglas deben cumplirse?
• ¿Este mensaje sería claro para el usuario?
• ¿El resultado final es suficiente?

38.8 Validar con ejemplos

Los ejemplos concretos ayudan a descubrir ambigüedades. Para Solicitar turno, se puede validar con situaciones como:

• Paciente registrado reserva un turno disponible.
• No hay horarios disponibles para la fecha elegida.
• El paciente quiere buscar por profesional.
• El paciente cancela antes de confirmar.
• El horario fue tomado por otro paciente antes de confirmar.

Si el caso de uso no puede responder a estos ejemplos, necesita ajustes.

38.9 Revisión con prototipos

Cuando existe un prototipo de interfaz, puede usarse junto al caso de uso. El usuario revisa el flujo escrito y visualiza cómo podría realizarlo en la pantalla.

Esto ayuda a detectar datos faltantes, mensajes poco claros, pasos innecesarios o decisiones que no estaban documentadas.

38.10 Criterios de aprobación

Antes de aprobar un caso de uso, conviene definir criterios mínimos:

• El objetivo está claro.
• El actor principal fue validado.
• El flujo principal representa el camino esperado.
• Las alternativas y excepciones importantes están documentadas.
• Las reglas de negocio fueron confirmadas.
• Las postcondiciones son verificables.
• El caso puede usarse para derivar pruebas.

38.11 Registro de observaciones

Las observaciones de revisión deben registrarse. No conviene depender solo de memoria o conversaciones informales.

Una observación debe indicar qué parte del caso de uso se revisa, cuál es la duda o cambio solicitado y quién debe resolverlo.

38.12 Control de versiones

Cuando un caso de uso se revisa y aprueba, conviene mantener control de versiones. Esto permite saber qué versión fue aceptada y qué cambios ocurrieron después.

Ejemplo:

38.13 Aprobación no significa que nunca cambiará

La aprobación indica que el caso de uso fue aceptado en un momento determinado. No significa que nunca pueda cambiar. Los proyectos evolucionan y pueden aparecer nuevas necesidades.

Cuando cambia un caso aprobado, debe registrarse el cambio, analizar impacto y volver a validar si la modificación es importante.

38.14 Tabla de revisión

Una tabla simple puede ayudar a controlar observaciones:

38.15 Errores frecuentes

Al revisar y validar casos de uso, suelen aparecer estos errores:

• Pedir aprobación sin explicar el caso de uso.
• Validar solo con personal técnico y no con usuarios o negocio.
• Preguntar de forma demasiado general si "está bien".
• No registrar observaciones.
• No controlar versiones.
• Ignorar alternativas y excepciones durante la validación.
• No actualizar pruebas después de cambios aprobados.

38.16 Lista de revisión

Antes de aprobar un caso de uso, conviene revisar:

• ¿Fue revisado por el equipo?
• ¿Fue validado con usuarios o responsables del negocio?
• ¿Las reglas de negocio están confirmadas?
• ¿Las alternativas y excepciones importantes fueron discutidas?
• ¿Las observaciones fueron resueltas o registradas?
• ¿Existe una versión identificable?
• ¿Puede usarse como base para diseño, desarrollo y pruebas?

38.17 Qué debes recordar de este tema

• Revisar mejora la calidad del documento.
• Validar confirma que el caso representa la necesidad real.
• Aprobar deja constancia de aceptación en una versión determinada.
• La validación debe hacerse con ejemplos concretos.
• Usuarios, negocio, analistas, desarrolladores y testers pueden aportar miradas distintas.
• Los cambios posteriores deben registrarse y analizarse.
• Un caso aprobado debe servir como base confiable para trabajo posterior.

38.18 Conclusión

La revisión, validación y aprobación con usuarios convierte los casos de uso en acuerdos claros. Este proceso permite detectar errores antes de construir y aumenta la probabilidad de desarrollar la funcionalidad correcta.

Un caso de uso validado no elimina todos los cambios futuros, pero ofrece una base sólida para diseño, desarrollo y pruebas. En el próximo tema estudiaremos mantenimiento y evolución de los casos de uso.