Si en nuestra anterior entrega desentrañamos los Diagramas de Casos de Uso (DCU) y cómo nos ayudan a visualizar las funcionalidades del sistema desde la perspectiva del actor, hoy vamos a dar un paso más: la Descripción de Casos de Uso.

Introducción

La descripción de casos de uso es un documento esencial en el desarrollo de software. El diagrama UML de los casos de uso te da una idea general de quién interactuará y cómo con nuestro sistema. La descripción va más allá, detallando todo lo que necesitamos saber sobre ese quién (actor), ese cómo (requerimientos para poder ejecutar una funcionalidad) y lo que se espera que nuestro sistema haga (qué resultados se esperan).

En este artículo, explicaremos:

• Qué es y para qué sirve.
• Estructura paso a paso con ejemplos reales.
• Errores comunes y cómo integrarla con metodologías ágiles.

Una Descripción de Caso de Uso es un documento técnico que amplía la información de los diagramas de casos de uso del diagrama UML. Proporciona una narrativa estructurada de cómo un actor interactúa con el sistema para lograr un objetivo específico. Mientras el diagrama muestra relaciones visuales, la descripción detalla:

• Condiciones previas y posteriores: qué debe ocurrir antes de iniciar el caso y qué debe haber sucedido después de haberse ejecutado.
• Secuencia de eventos y flujos de interacción que suceden entre el usuario y el sistema.
• Flujos alternativos, si los hubiera.
• Excepciones (qué pasa si algo falla).

Ejemplo:
Para un sistema de reservas de hotel, el diagrama muestra «Reservar habitación», y la descripción explica cómo se hace: desde buscar disponibilidad hasta confirmar el pago.

Estructura de una Descripción de Casos de Uso

En realidad no existe un estándar único, sin embargo la mayoría de descripciones usadas comparten cierta estructura común. Aquí te muestro las secciones más habituales y cruciales.

Cabecera del documento

1. Identificador (ID) del Caso de Uso:
   • Qué es: Un código único para identificar y referenciar el caso de uso de forma inequívoca.
   • Ejemplo: CU_001, SRes_01.
   • Clave: Mantén una nomenclatura consistente en todo el proyecto.
2. Nombre del Caso de Uso:
   • Qué es: Un nombre descriptivo y conciso, generalmente una frase verbal en infinitivo o presente. Debe coincidir con el nombre en el diagrama.
   • Ejemplo: Reservar Habitación, Consultar Saldo de Cuenta.
   • Clave: Claro, orientado a la acción y al objetivo del actor.
3. Actores:
   • Qué es: Lista de los actores que participan en el caso de uso.
     • Actor Primario: Quien inicia el caso de uso para lograr su objetivo.
     • Actores Secundarios: Otros actores que interactúan con el sistema durante la ejecución del caso de uso (p.ej., un sistema externo de pagos).
   • Ejemplo: Primario: Cliente; Secundario: Sistema de Pasarela de Pago.
   • Clave: Identifica claramente el rol principal.
4. Descripción Breve (Resumen):
   • Qué es: Un par de frases que resumen el propósito y el objetivo principal del caso de uso.
   • Ejemplo: «Este caso de uso permite a un cliente buscar disponibilidad y formalizar la reserva de una habitación de hotel para unas fechas específicas.»
   • Clave: Directo al grano.

Cuerpo principal

5. Precondiciones:
   • Qué es: Condiciones que deben cumplirse antes de que el caso de uso pueda iniciarse. El sistema debe garantizar que se cumplen.
   • Ejemplo: «El cliente debe estar autenticado en el sistema.» «El sistema de inventario de habitaciones está operativo.»
   • Clave: Define el estado inicial necesario.
6. Postcondiciones:
   • Qué es: Condiciones que deben ser verdaderas después de que el caso de uso haya finalizado con éxito (o fracasado).
     • Éxito: Estado del sistema si todo fue bien.
     • Fracaso: Estado del sistema si algo falló (pero el sistema sigue estable).
   • Ejemplo (Éxito): «La reserva se ha registrado en el sistema.» «Se ha enviado un email de confirmación al cliente.» «La disponibilidad de la habitación se ha actualizado.»
   • Ejemplo (Fracaso): «No se ha realizado ninguna reserva.» «El sistema registra el intento fallido.»
   • Clave: Define el resultado observable y el estado final.
7. Flujo Principal (o Básico / Camino Feliz):
   • Qué es: La secuencia de pasos numerados que describe la interacción normal y exitosa entre el actor y el sistema para lograr el objetivo del caso de uso. Es el escenario más común, sin errores ni desviaciones.
   • Ejemplo:
     1. El Cliente selecciona la opción «Reservar Habitación».
     2. El Sistema muestra el formulario de búsqueda de disponibilidad.
     3. El Cliente introduce fechas y tipo de habitación y pulsa «Buscar».
     4. … (y así sucesivamente).
   • Clave: Pasos claros, concisos, y secuenciales. Actor-Sistema, Actor-Sistema.
   • Puedes usar como plantilla la siguiente tabla:

8. Flujos Alternativos (o Excepciones):
   • Qué es: Describen secuencias alternativas o manejo de errores que pueden ocurrir durante el flujo principal. Cada flujo alternativo se ramifica desde un punto específico del flujo principal.
   • Ejemplo (Alternativo): «Si no hay habitaciones disponibles para las fechas seleccionadas, el sistema informa al cliente y ofrece fechas alternativas.»
   • Ejemplo (Excepción): «Si el sistema de pago externo no responde, el sistema informa al cliente y guarda la reserva como ‘pendiente de pago’.»
   • Clave: Cubre las desviaciones importantes y cómo el sistema debe reaccionar.

Pie del documento (Opcional)

8. Frecuencia de Uso (Opcional):
   • Qué es: Estimación de cuántas veces se espera que se ejecute este caso de uso en un periodo determinado.
   • Ejemplo: «Alto (varias veces por hora)», «Medio (unas 10 veces al día)».
   • Clave: Ayuda a priorizar y a diseñar pensando en el rendimiento.
9. Prioridad (Opcional):
   • Qué es: Indica la importancia del caso de uso para el negocio o el proyecto.
   • Ejemplo: «Alta», «Media», «Baja».
   • Clave: Útil para la planificación de sprints o iteraciones.
10. Requisitos No Funcionales Asociados (Opcional), otros comentarios o notas adicionales:
    • Qué es: Cualquier otra información relevante, como reglas de negocio específicas, requisitos de rendimiento, seguridad, usabilidad, etc., que apliquen a este caso de uso.
    • Ejemplo: «La respuesta a la búsqueda de disponibilidad debe ser inferior a 2 segundos.» «Los datos de pago deben ser encriptados.»
    • Clave: No dejes información importante fuera.

Plantilla para tu Descripción de Caso de Uso 📝

Aquí tienes una plantilla básica que puedes adaptar. Usar un formato de tabla en tus documentos (Word, Confluence, etc.) suele ser muy práctico:

Ejemplo Real: Sistema de Reservas de Hotel

Diagrama de Casos de Uso en PlantUML

@startuml
left to right direction
actor Cliente as C
actor "Pasarela de Pago" as PP
rectangle Hotel {
  (Reservar habitación) as reservar
  (Buscar disponibilidad) as buscar
  (Pagar reserva) as pagar
}
C --> reservar
reservar .> buscar : include
reservar -l-> pagar : extends
pagar --> PP

@enduml

Descripción Detallada del Caso de Uso «Reservar Habitación»

Cabecera

• Identificador: CU_HOTEL_001
• Nombre: Reservar Habitación
• Actores:
  • Primario: Cliente
  • Secundarios: Sistema de Pasarela de Pago
• Breve descripción: Permite a un cliente buscar habitaciones disponibles según criterios (fechas, tipo de habitación, nº de personas) y formalizar una reserva pagando el importe correspondiente.

Cuerpo

• Precondiciones:
  • El Cliente está autenticado en el sistema (opcional, podría permitirse reserva a invitados).
  • El sistema de reservas está operativo.
• Postcondiciones (Éxito):
  • La reserva se ha registrado con estado «Confirmada».
  • La disponibilidad de la habitación seleccionada se ha actualizado.
  • Se ha enviado un email de confirmación de reserva al Cliente.
  • Se ha registrado la transacción de pago.
• Postcondiciones (Fracaso):
  • No se crea ninguna reserva (o se crea con estado «Fallida/Cancelada»).
  • La disponibilidad de habitaciones no se modifica.
  • Se informa al cliente del motivo del fallo.

Flujos

• Flujo Principal
  1. El Cliente selecciona la opción «Buscar y Reservar Habitación».
  2. El Sistema muestra el formulario de búsqueda con campos: Fecha de Entrada, Fecha de Salida, Tipo de Habitación, Número de Huéspedes.
  3. El Cliente introduce los criterios y pulsa «Buscar».
  4. El Sistema valida los criterios (CU_ValidarDisp).
  5. El Sistema muestra las habitaciones disponibles que cumplen los criterios, con sus precios.
  6. El Cliente selecciona una habitación y pulsa «Reservar».
  7. El Sistema muestra un resumen de la reserva (habitación, fechas, precio total) y solicita confirmación y posibilidad de pago.
  8. El Sistema registra la reserva como «Confirmada».
  9. El Sistema actualiza la disponibilidad de la habitación.
  10. El Sistema envía un email de confirmación al Cliente (CU_Confirm).
  11. El Sistema muestra un mensaje de confirmación de reserva al Cliente con el localizador.
• Flujos Alternativos/Excepciones
  • FP_1: Cliente decide pagar (se origina después del paso 7 si se elige pagar).
    1. El Cliente introduce sus datos de pago y confirma la reserva.
    2. El Sistema procesa el pago a través del Sistema de Pasarela de Pago (CU_Pago).
    3. El Sistema de Pasarela de Pago confirma el pago.
  • FA_1: No hay habitaciones disponibles (se origina en el paso 5 del Flujo Principal)
    1. El Sistema informa al Cliente que no hay habitaciones disponibles para los criterios seleccionados.
    2. El Sistema ofrece buscar con fechas alternativas o tipos de habitación diferentes.
    3. El caso de uso finaliza o el Cliente modifica la búsqueda (vuelve al paso 3 del Flujo Principal).
  • FP_2: Error en el procesamiento del pago (se origina en el paso 2 de FP_1)
    1. El Sistema de Pasarela de Pago devuelve un error (p.ej., tarjeta rechazada, fondos insuficientes).
    2. El Sistema informa al Cliente del error en el pago.
    3. El Sistema ofrece al Cliente la opción de reintentar con otros datos de pago o cancelar la reserva.
    4. Si el Cliente cancela o tras X intentos fallidos, la reserva no se formaliza (o se guarda como «Pendiente de Pago» temporalmente). El caso de uso finaliza.

Pie

• Frecuencia de Uso: Alta
• Prioridad: Crítica
• Notas adicionales y requerimientos no funcionales:
  • La respuesta de búsqueda de disponibilidad (paso 5) debe ser inferior a 3 segundos para el 95% de las peticiones.
  • Toda la comunicación con la Pasarela de Pago debe ser mediante HTTPS y los datos de tarjeta no se almacenan en el sistema de reservas.

Errores Comunes y Cómo Evitarlos

1. Demasiado Detalle de Interfaz de Usuario (UI):
   • Error: «El cliente hace clic en el botón verde ‘Reservar’ que está en la esquina superior derecha…»
   • Problema: La UI puede cambiar. Los casos de uso deben ser independientes del diseño específico de la interfaz.
   • Solución: Enfócate en la intención del actor y la respuesta del sistema, no en los widgets. «El Cliente solicita confirmar la reserva.»
2. Lenguaje Vago o Ambiguo:
   • Error: «El sistema procesa la información y muestra los resultados apropiados.»
   • Problema: ¿Qué información? ¿Cómo se procesa? ¿Qué son resultados apropiados?
   • Solución: Sé específico. «El sistema valida que las fechas sean lógicas (fecha de entrada anterior a fecha de salida) y que el número de huéspedes sea positivo.»
3. Confundir Flujos con Requisitos No Funcionales:
   • Error: Poner en un paso del flujo «El sistema debe responder rápido.»
   • Problema: «Rápido» es un RNF (rendimiento).
   • Solución: Detalla los RNF en su sección correspondiente o en notas.
4. Flujos Incompletos u Olvido de Excepciones Importantes:
   • Error: A veces solo documentamos el «camino feliz» y obviar qué pasa si el pago falla o no hay stock.
   • Problema: En este caso, el sistema no sabrá cómo comportarse en situaciones comunes pero no ideales.
   • Solución: Piensa en los «qué pasaría si…» y documenta los flujos alternativos y de excepción más relevantes.
5. No Mantener la Consistencia con el Diagrama:
   • Error: Nombres de casos de uso o actores diferentes en el diagrama y en la descripción.
   • Problema: Confusión y falta de trazabilidad.
   • Solución: Revisa y asegúrate de que coinciden.
6. Ignorar la priorización:
   • Error: Desarrollar funcionalidades secundarias antes que el MVP.
   • Solución: Usar matriz MoSCoW (Must, Should, Could, Won’t).

Conclusión

Una descripción de casos de uso bien elaborada es la brújula que guía a desarrolladores, testers y stakeholders. Al combinar claridad, detalle técnico y alineación con metodologías ágiles, aseguras que tu proyecto cumpla objetivos sin perder flexibilidad.

FAQ

• ¿Los casos de uso son solo para metodologías en cascada?: No, también se usan en ágil para complementar historias de usuario con detalles técnicos.
• ¿Qué herramienta recomiendas para diagramas UML?: PlantUML (gratis) o Visual Paradigm (pago).
• ¿Cómo priorizar casos de uso en un MVP?: Enfócate en los que resuelven problemas críticos del usuario (ej: «Reservar habitación» antes que «Ver reseñas»).