23. Flujos alternativos y decisiones del usuario
23.1 Introducción
El flujo principal describe el camino normal de un caso de uso, pero en la práctica no todos los usuarios siguen exactamente el mismo recorrido. A veces el actor toma una decisión diferente, elige otra opción válida o el sistema ofrece una variante del proceso.
Los flujos alternativos documentan esas variantes válidas. No son errores necesariamente; son caminos diferentes que pueden completar el objetivo o llegar a un resultado aceptable.
Documentarlos permite que el equipo comprenda mejor el comportamiento esperado y evita que solo se diseñe y pruebe el camino ideal.
23.2 Qué es un flujo alternativo
Un flujo alternativo es una secuencia de pasos que se aparta del flujo principal en un punto determinado, porque ocurre una condición válida o una decisión del usuario, y luego puede volver al flujo principal o finalizar con otro resultado aceptado.
Por ejemplo, en Solicitar turno, el flujo principal puede buscar turnos por especialidad. Un flujo alternativo podría permitir buscar directamente por profesional.
23.3 Diferencia con excepción
Un flujo alternativo describe una variante esperada y válida. Una excepción describe una situación problemática, de error o interrupción que impide continuar normalmente o requiere recuperación.
Ejemplo de alternativa: el paciente busca por profesional en lugar de buscar por especialidad. Ejemplo de excepción: el turno seleccionado ya no está disponible al momento de confirmar.
23.4 Relación con el flujo principal
Un flujo alternativo debe indicar desde qué paso del flujo principal se activa, qué condición lo produce y qué ocurre después. Puede regresar al flujo principal o terminar con un resultado propio.
23.5 Decisiones del usuario
Muchas alternativas aparecen porque el usuario puede decidir entre opciones válidas. En esos casos, la especificación debe mostrar qué cambia según la decisión tomada.
Ejemplos:
- El paciente busca por especialidad o por profesional.
- El cliente retira un producto en sucursal o solicita envío a domicilio.
- El usuario paga con tarjeta o por transferencia.
- El administrador guarda cambios o cancela la edición.
- El médico consulta la agenda diaria o la agenda semanal.
23.6 Condiciones del sistema
También pueden existir flujos alternativos activados por condiciones del sistema que no son errores. Por ejemplo, si el paciente ya tiene datos completos, el sistema puede avanzar directamente; si faltan datos administrativos, puede solicitar completarlos antes de continuar.
La clave es identificar si la condición representa una variante normal del negocio o una situación excepcional.
23.7 Cómo nombrar un flujo alternativo
Conviene nombrar cada flujo alternativo con una frase breve que explique la variante. Algunos ejemplos:
- Búsqueda por profesional.
- Paciente modifica la fecha seleccionada.
- Pago por transferencia.
- Retiro en sucursal.
- Cancelación antes de confirmar.
El nombre debe ayudar a reconocer rápidamente qué diferencia introduce el flujo.
23.8 Estructura recomendada
Un flujo alternativo puede documentarse con esta estructura:
Punto de inicio: paso N del flujo principal.
Condición: situación que activa la alternativa.
Pasos: secuencia alternativa.
Resultado: vuelve al paso X, continúa en otro punto o finaliza el caso de uso.
23.9 Ejemplo: búsqueda por profesional
En el caso de uso Solicitar turno, el flujo principal puede indicar que el paciente selecciona una especialidad. Un flujo alternativo podría ser:
Punto de inicio: paso 3 del flujo principal.
Condición: el paciente elige buscar directamente por profesional.
1. El paciente ingresa o selecciona el nombre del profesional.
2. El sistema muestra los horarios disponibles de ese profesional.
Resultado: continúa en el paso donde el paciente selecciona un horario.
23.10 Ejemplo: cambiar fecha antes de confirmar
Otro flujo alternativo puede aparecer cuando el paciente revisa el resumen y decide cambiar la fecha antes de confirmar.
Punto de inicio: paso donde el sistema muestra el resumen de la reserva.
Condición: el paciente decide modificar la fecha seleccionada.
1. El paciente solicita cambiar la fecha.
2. El sistema vuelve a mostrar criterios de búsqueda.
3. El paciente selecciona una nueva fecha.
4. El sistema muestra horarios disponibles para la nueva fecha.
Resultado: continúa en la selección de horario.
23.11 Alternativas que finalizan el caso
No todos los flujos alternativos vuelven al flujo principal. Algunos terminan el caso de uso con un resultado válido distinto.
Por ejemplo, si el paciente decide cancelar la operación antes de confirmar, el caso de uso puede finalizar sin registrar turno. No es un error: es una decisión válida del usuario.
Condición: el paciente decide no continuar con la solicitud.
Resultado: el sistema no registra ningún turno y vuelve a la pantalla inicial de turnos.
23.12 Evitar alternativas innecesarias
No toda pequeña variación necesita documentarse como flujo alternativo. Si una diferencia no cambia el comportamiento funcional, puede no ser necesario registrarla.
Por ejemplo, si el usuario puede ordenar una lista ascendente o descendente, quizá baste con mencionarlo en una regla de interfaz o en un prototipo, salvo que tenga importancia funcional para el caso de uso.
23.13 Alternativas y reglas de negocio
Muchas alternativas dependen de reglas de negocio. Por ejemplo, un paciente puede cancelar un turno solo hasta 24 horas antes. Si intenta cancelar dentro de ese plazo restringido, puede activarse un flujo alternativo que solicita autorización de recepción o muestra una política de cancelación.
Conviene referenciar la regla de negocio cuando la alternativa depende de ella.
23.14 Alternativas y pruebas
Cada flujo alternativo importante debe tener pruebas asociadas. Si el paciente puede buscar por profesional, debe existir una prueba que verifique ese camino. Si puede cancelar antes de confirmar, debe verificarse que no se registre una reserva.
Documentar alternativas mejora la cobertura de pruebas y reduce la posibilidad de que el sistema solo funcione en el camino ideal.
23.15 Tabla de ejemplos
Algunos ejemplos de flujos alternativos son:
| Caso de uso | Flujo alternativo | Resultado |
|---|---|---|
| Solicitar turno | Buscar por profesional. | El sistema muestra horarios del profesional seleccionado. |
| Realizar compra | Retirar en sucursal. | El pedido queda preparado para retiro. |
| Realizar pago | Pagar por transferencia. | El sistema registra el pago como pendiente de acreditación. |
| Registrar usuario | Completar registro con cuenta externa. | El sistema registra al usuario con datos provistos por otro servicio. |
23.16 Errores frecuentes
Al documentar flujos alternativos, suelen aparecer estos errores:
- Confundir alternativas con errores o excepciones.
- No indicar desde qué paso del flujo principal se activan.
- No aclarar si vuelven al flujo principal o finalizan el caso.
- Documentar variaciones mínimas que no aportan claridad.
- Olvidar decisiones importantes del usuario.
- No relacionar alternativas con reglas de negocio.
- No derivar pruebas para las alternativas relevantes.
23.17 Lista de revisión
Antes de cerrar los flujos alternativos, conviene revisar:
- ¿Cada alternativa tiene una condición clara?
- ¿Se indica el punto del flujo principal donde aparece?
- ¿La alternativa representa una variante válida?
- ¿Se sabe si vuelve al flujo principal o termina?
- ¿El nivel de detalle es suficiente?
- ¿Las alternativas importantes tienen pruebas?
- ¿No se mezclaron excepciones con alternativas?
23.18 Qué debes recordar de este tema
- Los flujos alternativos describen variantes válidas del flujo principal.
- Pueden originarse por decisiones del usuario o condiciones del sistema.
- Deben indicar punto de inicio, condición, pasos y resultado.
- Pueden volver al flujo principal o finalizar el caso de uso.
- No toda variación pequeña necesita documentarse como alternativa.
- Las alternativas deben distinguirse de las excepciones.
- Cada alternativa relevante debe poder probarse.
23.19 Conclusión
Los flujos alternativos permiten documentar caminos válidos que se apartan del flujo principal. Son esenciales para representar decisiones del usuario y variantes reales del negocio.
Una especificación que incluye alternativas importantes es más completa, más fácil de validar y más útil para pruebas. En el próximo tema estudiaremos excepciones, errores y recuperación.