23. Escenarios, flujos principales y flujos alternativos

23.1 Introducción

Los escenarios, flujos principales y flujos alternativos ayudan a describir cómo se comporta un sistema en situaciones concretas. Son útiles para aclarar requerimientos, descubrir excepciones y preparar pruebas.

Un requerimiento puede decir "el sistema debe permitir registrar un pedido", pero todavía falta entender cómo ocurre ese registro, qué pasos sigue el usuario, qué validaciones se aplican y qué pasa si algo falla.

Describir escenarios permite pasar de una función general a un comportamiento más preciso.

23.2 ¿Qué es un escenario?

Un escenario es una descripción concreta de una situación de uso del sistema. Muestra cómo un actor interactúa con el sistema para lograr un objetivo bajo ciertas condiciones.

Ejemplo simple: un cliente consulta el estado de un reclamo ingresando su número de reclamo y correo electrónico. El sistema valida los datos y muestra el estado actual.

23.3 ¿Para qué sirven los escenarios?

Los escenarios sirven para:

• Aclarar cómo se ejecuta una función.
• Descubrir pasos faltantes.
• Identificar datos necesarios.
• Detectar reglas de negocio.
• Encontrar excepciones y errores posibles.
• Validar comprensión con usuarios.
• Preparar criterios de aceptación y pruebas.
• Mejorar la comunicación entre negocio y equipo técnico.

Son especialmente útiles cuando un requerimiento tiene varias variantes o condiciones.

23.4 Flujo principal

El flujo principal describe la secuencia normal o esperada de pasos para completar una tarea correctamente. También se lo suele llamar flujo básico o camino feliz.

Ejemplo para registrar un pedido:

1. El vendedor selecciona el cliente.
2. El sistema muestra los datos principales del cliente.
3. El vendedor agrega productos y cantidades.
4. El sistema calcula el total.
5. El vendedor confirma el pedido.
6. El sistema valida stock disponible.
7. El sistema registra el pedido en estado confirmado.
8. El sistema muestra el número de pedido generado.

El flujo principal no debe ignorar validaciones esenciales, pero se concentra en el caso esperado.

23.5 Flujos alternativos

Los flujos alternativos describen variantes válidas del flujo principal. No son errores necesariamente; son caminos diferentes que también pueden ocurrir.

Ejemplos en el registro de pedidos:

• El vendedor guarda el pedido como borrador en lugar de confirmarlo.
• El cliente tiene condiciones comerciales especiales.
• El vendedor aplica un descuento autorizado.
• El pedido requiere aprobación de un supervisor.
• El cliente solicita entrega en una dirección alternativa.

Los flujos alternativos ayudan a cubrir situaciones reales que no siguen el camino más simple.

23.6 Flujos de excepción

Los flujos de excepción describen situaciones donde algo impide completar la tarea normalmente: datos inválidos, falta de permisos, errores de integración, reglas incumplidas o fallas técnicas.

Ejemplos:

• El cliente seleccionado está bloqueado.
• No hay stock suficiente para un producto.
• La pasarela de pagos rechaza la operación.
• El usuario no tiene permiso para confirmar el pedido.
• El sistema externo de inventario no responde.

Estos flujos son importantes porque muchos defectos aparecen en casos no normales.

23.7 Precondiciones

Una precondición es una condición que debe cumplirse antes de iniciar un escenario o flujo.

Ejemplos:

• El usuario debe haber iniciado sesión.
• El cliente debe existir en el sistema.
• El curso debe estar publicado.
• El período de inscripción debe estar habilitado.
• El sistema de pagos debe estar disponible.

Las precondiciones ayudan a evitar que el flujo tenga que explicar situaciones previas que ya se dan por cumplidas.

23.8 Postcondiciones

Una postcondición es una condición que debe cumplirse después de completar un escenario.

Ejemplos:

• El pedido queda registrado en estado confirmado.
• El stock queda reservado.
• El reclamo queda asignado a un responsable.
• La inscripción queda confirmada y se envía una notificación.
• La operación queda auditada con usuario, fecha y hora.

Las postcondiciones aclaran el resultado esperado del flujo.

23.9 Estructura básica de un escenario

Un escenario puede documentarse con una estructura simple:

• Nombre del escenario.
• Objetivo.
• Actor principal.
• Precondiciones.
• Flujo principal.
• Flujos alternativos.
• Flujos de excepción.
• Postcondiciones.
• Reglas relacionadas.
• Datos utilizados.

No todos los escenarios necesitan el mismo nivel de detalle. Depende de la complejidad y criticidad.

23.10 Ejemplo: consulta de reclamo

23.11 Ejemplo: inscripción a curso

Flujo principal:

1. El alumno consulta cursos disponibles.
2. El sistema muestra cursos con cupo, horario y fecha de inicio.
3. El alumno selecciona un curso.
4. El sistema muestra detalle y condiciones.
5. El alumno confirma la inscripción.
6. El sistema valida cupo y período habilitado.
7. El sistema registra la inscripción.
8. El sistema envía confirmación por correo.

Flujos alternativos y excepciones:

• Si el curso no tiene cupo, el sistema informa la situación y no registra la inscripción.
• Si el alumno ya está inscripto, el sistema evita duplicar la inscripción.
• Si el curso requiere correlativas, el sistema valida que estén aprobadas.
• Si falla el envío de correo, la inscripción se mantiene registrada y se deja pendiente la notificación.

23.12 Nivel de detalle adecuado

El nivel de detalle de un flujo debe ser suficiente para comprender el comportamiento, pero no tan bajo que describa decisiones internas innecesarias.

Conviene evitar pasos como:

• El usuario mueve el mouse.
• El sistema pinta un botón de color azul.
• El sistema ejecuta una consulta interna específica.

Salvo que esos detalles sean relevantes para el requerimiento, el flujo debe concentrarse en interacciones, decisiones, datos y resultados visibles.

23.13 Escenarios y criterios de aceptación

Los escenarios suelen ayudar a formular criterios de aceptación. Cada flujo importante puede convertirse en un criterio o caso de prueba.

Ejemplo:

• Escenario: inscripción con cupo disponible.
• Criterio: dado un curso con cupo, cuando el alumno confirma la inscripción, entonces el sistema registra la inscripción y descuenta un cupo.
• Prueba: ejecutar la inscripción y verificar registro, cupo y notificación.

Esta relación mejora la trazabilidad entre análisis y verificación.

23.14 Escenarios y reglas de negocio

Los escenarios ayudan a descubrir reglas de negocio. Cuando se recorre un flujo paso a paso, aparecen preguntas como:

• ¿Quién puede realizar esta acción?
• ¿Qué condiciones deben cumplirse?
• ¿Qué datos son obligatorios?
• ¿Qué estados permiten esta transición?
• ¿Qué ocurre si la regla no se cumple?
• ¿Hay excepciones autorizadas?

Por eso, los escenarios son una herramienta de análisis, no solo de documentación.

23.15 Escenarios y estados

Cuando una entidad tiene estados, los escenarios ayudan a entender cómo cambia de un estado a otro.

Ejemplo para un pedido:

• Borrador: el pedido puede modificarse o eliminarse.
• Confirmado: el pedido reserva stock.
• Preparado: el pedido fue armado por depósito.
• Entregado: el cliente recibió el pedido.
• Cancelado: el pedido no continuará.

Cada cambio de estado puede tener precondiciones, permisos y efectos.

23.16 Escenarios y prototipos

Los escenarios pueden usarse junto con prototipos. Un prototipo muestra una posible interacción; el escenario explica qué ocurre paso a paso.

Por ejemplo, al revisar un boceto de registro de reclamos, se puede pedir al usuario que recorra el escenario: "llega un reclamo telefónico de un cliente que no recuerda su número de cliente". Esto permite detectar qué datos, búsquedas o excepciones hacen falta.

La combinación de escenario y prototipo suele revelar problemas rápidamente.

23.17 Errores frecuentes

Al escribir escenarios y flujos, suelen aparecer estos errores:

• Describir solo el caso ideal y olvidar excepciones.
• Mezclar varios objetivos en un mismo flujo.
• Incluir detalles técnicos innecesarios.
• No indicar precondiciones ni postcondiciones.
• No identificar actor principal.
• No registrar reglas de negocio asociadas.
• No validar el flujo con usuarios reales.
• Confundir flujo alternativo con error.

23.18 Buenas prácticas

Algunas buenas prácticas son:

• Comenzar por el flujo principal y luego agregar alternativas.
• Usar pasos breves y claros.
• Identificar actor, objetivo, precondiciones y resultado.
• Preguntar por excepciones y casos poco frecuentes.
• Relacionar flujos con reglas, datos y criterios de aceptación.
• Validar escenarios con usuarios o expertos del dominio.
• No convertir el flujo en diseño técnico prematuro.
• Usar escenarios como base para pruebas.

23.19 Qué debes recordar de este tema

• Un escenario describe una situación concreta de uso.
• El flujo principal describe el camino normal para lograr un objetivo.
• Los flujos alternativos describen variantes válidas.
• Los flujos de excepción describen errores o condiciones que impiden continuar normalmente.
• Las precondiciones indican qué debe cumplirse antes de iniciar.
• Las postcondiciones indican qué debe quedar cumplido al finalizar.
• Los escenarios ayudan a descubrir reglas, datos, estados y pruebas.

23.20 Conclusión

Los escenarios, flujos principales y flujos alternativos permiten describir el comportamiento del sistema de manera concreta. Ayudan a pasar de requerimientos generales a situaciones reales que pueden analizarse, validarse y probarse.

Usarlos correctamente mejora la comprensión compartida y reduce omisiones en casos alternativos o excepcionales.

En el próximo tema veremos una introducción a los casos de uso dentro de los requerimientos, una forma más estructurada de describir interacciones entre actores y sistema.