29. Casos de uso breves, casuales y completamente vestidos
29.1 Introducción
No todos los casos de uso necesitan el mismo nivel de documentación. Algunos pueden describirse en pocas líneas, otros requieren una explicación moderada y otros necesitan una especificación completa con precondiciones, flujos, alternativas, excepciones y garantías.
Una clasificación útil distingue entre casos de uso breves, casos de uso casuales y casos de uso completamente vestidos. Cada formato tiene un propósito distinto.
Elegir el nivel adecuado evita dos problemas: documentar demasiado casos simples o documentar demasiado poco casos importantes.
29.2 Por qué existen distintos formatos
Durante un proyecto, los casos de uso pasan por etapas. Al principio puede alcanzar con una descripción breve para identificar funcionalidades. Luego, algunos casos necesitan más detalle para ser validados, diseñados y probados.
Si se intenta escribir todos los casos de uso con máximo detalle desde el inicio, el equipo puede perder tiempo en funcionalidades poco prioritarias. Si todo queda demasiado breve, los casos críticos pueden quedar ambiguos.
29.3 Tres niveles de documentación
Los casos de uso breves, casuales y completamente vestidos representan tres niveles de detalle. El formato breve sirve para descubrir y listar; el casual sirve para comprender sin demasiada formalidad; el completamente vestido sirve para especificar con precisión casos importantes o complejos.
29.4 Caso de uso breve
Un caso de uso breve describe la funcionalidad en una o pocas frases. Suele incluir el nombre, el actor principal y una descripción corta del objetivo.
Ejemplo:
Este formato es útil para una lista inicial de casos de uso o para funcionalidades simples que no requieren mucho detalle.
29.5 Cuándo usar casos breves
Conviene usar casos de uso breves cuando:
- Se está descubriendo el alcance inicial.
- El caso todavía no está priorizado.
- La funcionalidad es simple o conocida.
- Solo se necesita una descripción para conversar.
- El equipo quiere armar una lista rápida de funcionalidades candidatas.
29.6 Caso de uso casual
Un caso de uso casual tiene más detalle que uno breve, pero no usa una plantilla completa. Describe el flujo principal en lenguaje natural y puede mencionar algunas alternativas importantes.
Ejemplo:
Este formato es útil cuando se necesita explicar el comportamiento sin formalizar todos los campos.
29.7 Cuándo usar casos casuales
Conviene usar casos casuales cuando:
- El caso tiene algo de complejidad, pero no requiere una plantilla completa.
- Se necesita validar el comportamiento con usuarios.
- El equipo aún está explorando alternativas.
- La documentación formal puede esperar.
- Se desea comunicar el flujo de manera rápida y comprensible.
29.8 Caso de uso completamente vestido
Un caso de uso completamente vestido utiliza una plantilla detallada. Incluye identificador, nombre, actor principal, interesados, precondiciones, disparador, garantías, flujo principal, flujos alternativos, excepciones, reglas de negocio, datos y requisitos no funcionales.
Este formato se usa cuando el caso de uso es importante, complejo, riesgoso o contractual.
29.9 Ejemplo de estructura completa
Un caso completamente vestido puede incluir:
Nombre: Solicitar turno
Actor principal: Paciente
Interesados: Paciente, médico, clínica, recepción
Precondiciones: paciente registrado y agenda configurada
Disparador: el paciente selecciona Solicitar turno
Flujo principal: pasos numerados
Flujos alternativos: búsqueda por profesional, cambio de fecha
Excepciones: horario no disponible, servicio externo no responde
Postcondiciones: turno reservado y confirmación generada
29.10 Cuándo usar casos completamente vestidos
Conviene usar este formato cuando:
- El caso de uso es crítico para el negocio.
- Existen muchas reglas de negocio.
- Hay varios flujos alternativos o excepciones.
- Participan sistemas externos.
- El caso se usará para contratos, pruebas o aprobación formal.
- Un error puede generar impacto económico, legal o operativo.
29.11 Comparación general
La siguiente tabla resume las diferencias:
| Formato | Nivel de detalle | Uso recomendado |
|---|---|---|
| Breve | Muy bajo | Descubrimiento inicial y lista de funcionalidades. |
| Casual | Medio | Conversación, validación rápida y comprensión general. |
| Completamente vestido | Alto | Casos críticos, complejos o que requieren aprobación y pruebas detalladas. |
29.12 Evolución de un caso de uso
Un caso de uso puede comenzar como breve, pasar a casual y luego convertirse en completamente vestido. Esto es normal. El nivel de documentación puede aumentar a medida que el caso gana prioridad o se descubren detalles importantes.
Por ejemplo, Solicitar turno puede empezar como una frase en una lista inicial. Luego se describe en un párrafo casual. Finalmente, si será parte central del sistema, se especifica con una plantilla completa.
29.13 No documentar todo al máximo
Documentar todos los casos de uso con máximo detalle puede generar mucho trabajo de bajo valor. No todas las funcionalidades tienen la misma complejidad ni el mismo riesgo.
Una buena práctica es priorizar: detallar más los casos críticos y mantener más simples los casos secundarios o muy conocidos.
29.14 No dejar críticos demasiado breves
El error contrario también es peligroso. Un caso crítico no debería quedar en una descripción de dos líneas si tiene reglas, excepciones, integraciones o riesgos importantes.
Cuando un caso será base para desarrollo, pruebas y validación formal, necesita suficiente detalle para evitar interpretaciones diferentes.
29.15 Ejemplo aplicado a sistema de turnos
En un sistema de turnos médicos, podríamos decidir:
- Solicitar turno: completamente vestido, porque es central y tiene reglas, alternativas y excepciones.
- Consultar agenda diaria: casual, si el comportamiento es simple.
- Ver datos de la sede: breve, si solo muestra información básica.
- Cancelar turno: completamente vestido si hay reglas de cancelación y auditoría.
29.16 Criterios para elegir el formato
Para elegir el nivel de documentación, conviene preguntar:
- ¿Qué tan importante es este caso para el negocio?
- ¿Cuántas reglas de negocio intervienen?
- ¿Hay integraciones externas?
- ¿Existen riesgos de seguridad, privacidad o dinero?
- ¿Cuántas alternativas y excepciones aparecen?
- ¿El caso será usado para pruebas formales?
- ¿Los usuarios necesitan aprobarlo explícitamente?
29.17 Errores frecuentes
Al elegir el formato de documentación, suelen aparecer estos errores:
- Usar casos breves para procesos complejos.
- Usar plantillas completas para funcionalidades triviales.
- No actualizar un caso breve cuando se vuelve importante.
- Creer que un caso casual reemplaza pruebas o reglas detalladas.
- Documentar por costumbre y no por necesidad real.
- No acordar con el equipo qué formato se usará en cada situación.
29.18 Qué debes recordar de este tema
- Los casos de uso pueden documentarse con distintos niveles de detalle.
- El formato breve sirve para identificar y listar.
- El formato casual sirve para explicar comportamiento de manera rápida.
- El formato completamente vestido sirve para casos críticos o complejos.
- Un caso puede evolucionar de breve a completo.
- No conviene documentar todo con el máximo nivel.
- La documentación debe ajustarse al valor, riesgo y complejidad del caso.
29.19 Conclusión
Los formatos breve, casual y completamente vestido permiten ajustar el esfuerzo de documentación a la necesidad real. Esta flexibilidad es importante para mantener documentación útil y sostenible.
El objetivo no es llenar plantillas, sino comunicar comportamiento con el nivel de detalle necesario. En el próximo tema estudiaremos la granularidad: cuándo dividir o unir casos de uso.