1. ¿Qué es un caso de uso?
1.1 Introducción
Un caso de uso describe una forma concreta en que un actor utiliza un sistema para lograr un objetivo. No se centra en cómo estará programado el sistema, ni en la base de datos, ni en los botones exactos de una pantalla. Se centra en la interacción observable entre alguien o algo externo y el sistema que se desea construir.
Por ejemplo, en un sistema de turnos médicos, un paciente puede necesitar solicitar un turno. Ese objetivo puede describirse mediante un caso de uso llamado Solicitar turno. Allí se explica qué hace el paciente, qué responde el sistema, qué datos se necesitan, qué validaciones existen y qué ocurre si no hay horarios disponibles.
Los casos de uso ayudan a transformar necesidades generales en comportamientos claros, ordenados y verificables. Por eso son una técnica muy utilizada durante el análisis de requisitos y la comunicación con usuarios, clientes, analistas, diseñadores, desarrolladores y testers.
1.2 Una definición simple
Podemos definir un caso de uso de la siguiente manera:
Esta definición contiene cuatro ideas importantes:
- Interacción: hay un intercambio entre el actor y el sistema.
- Actor: existe alguien o algo externo que inicia o participa en el uso del sistema.
- Sistema: hay un límite que separa lo que se está construyendo de su entorno.
- Objetivo: la interacción no es casual; busca obtener un resultado útil.
1.3 Imagen sugerida: actor, sistema y objetivo
La siguiente imagen puede representar a un usuario externo frente a un sistema, con una flecha que indique el objetivo que desea lograr. Por ejemplo: un paciente interactuando con un sistema de turnos para reservar una consulta médica. La imagen debe dejar claro que el caso de uso no describe el código interno, sino la interacción visible entre actor y sistema.
1.4 Actor y sistema
En un caso de uso, el actor es cualquier entidad externa que interactúa con el sistema. Puede ser una persona, otro sistema informático, una organización, un dispositivo o un servicio externo. Lo importante es que el actor está fuera del sistema que se analiza.
El sistema es aquello que se desea construir, modificar o estudiar. Para trabajar correctamente con casos de uso, primero debe quedar claro cuál es el límite del sistema. Todo lo que queda dentro del límite es responsabilidad del sistema; todo lo que queda fuera puede actuar como actor o como parte del entorno.
Ejemplos de actores:
- Cliente: compra productos en una tienda en línea.
- Administrador: gestiona usuarios y permisos.
- Pasarela de pago: confirma si una operación fue aprobada o rechazada.
- Sensor: informa una medición a un sistema de monitoreo.
- Sistema contable externo: recibe información de facturación.
1.5 El objetivo del actor
Un caso de uso debe estar asociado a un objetivo. Esto significa que no conviene nombrarlo como una acción técnica aislada, sino como una meta comprensible para el actor. El nombre debe expresar qué intenta conseguir el actor al usar el sistema.
Por ejemplo, Ingresar número de documento no suele ser un buen caso de uso, porque describe un paso pequeño. En cambio, Registrar cliente sí puede ser un caso de uso, porque representa un objetivo completo y con valor.
| Nombre débil | Nombre más claro | Motivo |
|---|---|---|
| Hacer clic en botón pagar | Realizar pago | Describe el objetivo, no un detalle de interfaz. |
| Cargar formulario | Solicitar inscripción | Indica qué quiere lograr el usuario. |
| Validar contraseña | Iniciar sesión | La validación es un paso dentro de un objetivo mayor. |
| Mostrar grilla | Consultar reservas | Se enfoca en la necesidad del actor. |
1.6 Qué describe y qué no describe un caso de uso
Un caso de uso describe el comportamiento esperado del sistema desde el punto de vista de sus interacciones externas. Sirve para responder preguntas como: quién usa el sistema, qué busca lograr, qué información entrega, qué respuesta espera y qué alternativas pueden ocurrir.
Un caso de uso no debería convertirse en una explicación de implementación. No corresponde detallar allí clases, tablas, consultas SQL, frameworks, estructuras internas ni algoritmos, salvo que el curso o la organización usen una plantilla especial con campos técnicos adicionales.
1.7 Límite del sistema
El límite del sistema separa lo que pertenece al software que se analiza de todo lo que queda fuera de él. En el ejemplo, el sistema de turnos médicos contiene casos de uso como reservar consulta, consultar turnos y cancelar consulta, mientras que Paciente, Médico, Recepcionista y Administrador son actores externos que se comunican con el sistema para utilizar esas funcionalidades.
1.8 Ejemplo inicial: solicitar un turno médico
Supongamos que se desea construir un sistema para gestionar turnos médicos. Uno de los objetivos principales de un paciente es reservar una consulta con un profesional. Ese objetivo puede representarse mediante el caso de uso Solicitar turno.
Una descripción inicial podría ser:
Actor principal: Paciente
Objetivo: reservar un turno disponible con un profesional médico.
Resultado esperado: el sistema registra el turno y entrega una confirmación al paciente.
En temas posteriores veremos cómo redactar el flujo principal, los flujos alternativos, las excepciones, las precondiciones y las postcondiciones. Por ahora alcanza con comprender que el caso de uso representa una unidad de comportamiento con sentido para el usuario.
1.9 Elementos habituales de un caso de uso
Un caso de uso puede documentarse con distintos niveles de detalle. Una especificación completa suele incluir varios elementos:
- Identificador: código breve para reconocerlo, por ejemplo CU-01.
- Nombre: frase con verbo en infinitivo, por ejemplo Registrar pedido.
- Actor principal: actor que busca lograr el objetivo.
- Actores secundarios: otros participantes externos que colaboran o reciben información.
- Descripción breve: resumen del propósito del caso de uso.
- Precondiciones: condiciones que deben cumplirse antes de iniciar.
- Flujo principal: secuencia normal de pasos entre actor y sistema.
- Flujos alternativos: variantes válidas del proceso normal.
- Excepciones: situaciones de error o interrupción.
- Postcondiciones: estado esperado después de finalizar.
- Reglas de negocio: restricciones o políticas que deben respetarse.
1.10 Caso de uso como texto y como diagrama
Cuando se habla de casos de uso, muchas personas piensan primero en el diagrama UML. El diagrama es útil porque permite ver rápidamente actores, casos de uso y relaciones. Sin embargo, el diagrama por sí solo suele ser insuficiente para comprender todos los detalles.
Por eso conviene distinguir dos formas complementarias de trabajo:
- Diagrama de casos de uso: muestra una vista general del sistema, sus actores y los servicios principales que ofrece.
- Especificación textual: explica paso a paso cómo se desarrolla cada caso de uso, incluyendo condiciones, alternativas y errores.
El diagrama ayuda a organizar y comunicar el alcance general. El texto ayuda a precisar el comportamiento esperado.
1.11 Diagrama y especificación
Un mismo caso de uso puede representarse mediante una vista gráfica y una vista textual. El diagrama UML muestra de forma general qué actor interactúa con qué funcionalidad del sistema; en este ejemplo, el actor Paciente se relaciona con el caso de uso Solicitar turno. La especificación textual agrega el detalle necesario para comprender el caso de uso: nombre, actor principal, objetivo y resultado esperado. Ambas vistas se complementan, porque el diagrama resume la interacción y la ficha explica el comportamiento con mayor precisión.
1.12 Por qué son importantes
Los casos de uso son importantes porque ayudan a ordenar conversaciones que, de otro modo, pueden quedar demasiado generales. Un cliente puede decir "necesito un sistema de reservas", pero esa frase todavía no explica quién reserva, qué se reserva, qué datos se requieren, qué restricciones existen, qué confirmación se entrega o qué ocurre si no hay disponibilidad.
Al trabajar con casos de uso, el equipo puede descubrir requisitos omitidos, detectar ambigüedades y validar expectativas antes de construir la solución. También puede derivar pruebas, identificar interfaces necesarias, estimar esfuerzo y planificar entregas por funcionalidades significativas.
Además, los casos de uso favorecen la comunicación porque usan un lenguaje cercano al negocio. Esto permite que personas no técnicas participen en la revisión y validación de lo que se construirá.
1.13 Diferencia con una función aislada
Una función aislada puede ser una operación pequeña del sistema, como validar un dato, calcular un total o enviar un correo. Un caso de uso, en cambio, describe una interacción más completa que permite alcanzar un objetivo.
Por ejemplo, calcular total puede ser una función interna dentro del caso de uso Realizar compra. El comprador no entra al sistema solamente para que se calcule un número; entra para seleccionar productos, confirmar datos, pagar y obtener una confirmación.
1.14 Errores frecuentes al comenzar
Cuando se empieza a trabajar con casos de uso, suelen aparecer algunos errores:
- Confundir actores con cargos internos del sistema, módulos o tablas.
- Nombrar casos de uso como pantallas, botones o formularios.
- Crear casos de uso demasiado pequeños, sin valor propio para el actor.
- Crear casos de uso demasiado grandes, mezclando muchos objetivos distintos.
- Describir detalles técnicos en lugar de comportamiento observable.
- Olvidar los flujos alternativos y las excepciones.
- Usar diagramas sin especificación textual cuando el comportamiento requiere precisión.
- Redactar el caso de uso sin validarlo con usuarios o representantes del negocio.
1.15 Qué debes recordar de este tema
- Un caso de uso describe cómo un actor interactúa con un sistema para lograr un objetivo.
- El actor está fuera del sistema y puede ser una persona, otro sistema, una organización o un dispositivo.
- El caso de uso debe expresar valor para el actor o para la organización.
- El límite del sistema permite separar responsabilidades internas y externas.
- El diagrama de casos de uso muestra una vista general, pero la especificación textual permite explicar el comportamiento con mayor precisión.
- Un caso de uso no debe confundirse con una pantalla, un botón, una tabla o una función interna aislada.
- Los casos de uso ayudan a descubrir, comunicar, validar y probar requisitos funcionales.
1.16 Conclusión
Un caso de uso es una herramienta de análisis que permite comprender el comportamiento esperado de un sistema desde la perspectiva de sus usuarios y otros actores externos. Su valor principal está en expresar objetivos reales, ordenar interacciones y facilitar la comunicación entre quienes necesitan el sistema y quienes lo construirán.
En los próximos temas profundizaremos en la utilidad de los casos de uso dentro de la Ingeniería de Software, su relación con los requisitos funcionales, la identificación de actores, el límite del sistema y la construcción de diagramas UML claros.