8. Descubrimiento inicial de casos de uso

8.1 Introducción

El descubrimiento inicial de casos de uso consiste en identificar, de manera ordenada, qué objetivos podrán lograr los actores mediante el sistema. Es una etapa de exploración: todavía no se redactan todos los detalles, pero se construye una primera lista razonable de funcionalidades.

Esta actividad ayuda a pasar de una idea general, como "necesitamos un sistema de turnos", a un conjunto más claro de casos de uso: Solicitar turno, Cancelar turno, Consultar disponibilidad, Administrar agenda, Registrar paciente y otros.

El objetivo no es acertar todo desde el primer intento, sino obtener una base inicial que pueda revisarse, corregirse y completar con usuarios y responsables del negocio.

8.2 Punto de partida

Para descubrir casos de uso conviene tener algunos elementos previos:

• Una descripción breve del problema que se quiere resolver.
• El alcance inicial del sistema.
• El límite del sistema.
• Una lista preliminar de actores.
• Objetivos conocidos de esos actores.
• Procesos de negocio relacionados.
• Reglas o restricciones importantes ya conocidas.

Si estos elementos todavía no están claros, el descubrimiento de casos de uso puede servir para hacer visibles las dudas.

8.3 Método básico de descubrimiento

Una forma práctica de descubrir casos de uso es avanzar desde los actores hacia sus objetivos. Primero se identifican los actores externos; luego se pregunta qué necesita lograr cada uno con el sistema; finalmente se transforman esos objetivos en candidatos a casos de uso.

8.4 Preguntar por cada actor

Una técnica simple consiste en tomar cada actor y hacer preguntas concretas:

• ¿Qué necesita consultar?
• ¿Qué necesita registrar?
• ¿Qué necesita modificar?
• ¿Qué necesita cancelar o eliminar?
• ¿Qué información espera recibir?
• ¿Qué decisiones toma usando el sistema?
• ¿Qué tareas realiza hoy de manera manual?
• ¿Qué errores o demoras quiere evitar?

Las respuestas no siempre son casos de uso definitivos, pero permiten generar una lista inicial para revisar.

8.5 Ejemplo con sistema de turnos médicos

Supongamos que los actores iniciales son Paciente, Recepcionista, Médico y Administrador. Podemos preguntar qué necesita lograr cada uno:

8.6 Buscar eventos externos

Otra forma de descubrir casos de uso es buscar eventos que llegan desde fuera del sistema. Un evento externo es algo que ocurre en el entorno y exige una respuesta del sistema.

Ejemplos:

• Un paciente solicita un turno.
• Un paciente cancela una reserva.
• Un médico modifica su disponibilidad.
• Una obra social responde una validación de cobertura.
• Un administrador crea una nueva agenda.
• Un servicio externo informa que una notificación no pudo enviarse.

Cada evento puede revelar un caso de uso, un flujo alternativo o una excepción.

8.7 Revisar procesos actuales

Muchas veces los casos de uso se descubren observando cómo se trabaja actualmente. Si el proceso ya existe de forma manual, por teléfono, por planillas o mediante sistemas antiguos, esas tareas pueden mostrar objetivos importantes.

Por ejemplo, si una recepcionista hoy anota turnos en una planilla, llama a pacientes para confirmar y revisa la agenda de cada médico, el sistema podría necesitar casos de uso relacionados con registrar turnos, enviar confirmaciones y consultar disponibilidad.

No todo proceso actual debe automatizarse tal como existe. El análisis debe distinguir qué tareas aportan valor y cuáles podrían simplificarse o eliminarse.

8.8 Usar entrevistas y talleres

Las entrevistas con usuarios y los talleres de trabajo son herramientas muy útiles para descubrir casos de uso. Permiten escuchar necesidades, detectar diferencias entre áreas y validar si los objetivos identificados tienen sentido.

Algunas preguntas útiles son:

• ¿Qué tareas realiza con mayor frecuencia?
• ¿Qué tareas generan más errores?
• ¿Qué información necesita para tomar decisiones?
• ¿Qué situaciones excepcionales ocurren?
• ¿Qué tareas deberían ser más rápidas?
• ¿Qué controles o autorizaciones son necesarios?
• ¿Qué reportes o comprobantes se necesitan?

8.9 Candidatos, no casos definitivos

Durante el descubrimiento inicial conviene hablar de casos de uso candidatos. Esto significa que todavía deben revisarse. Algunos candidatos se confirmarán, otros se dividirán, otros se unirán y otros se descartarán.

Por ejemplo, Gestionar turnos puede aparecer como candidato inicial, pero luego dividirse en Solicitar turno, Modificar turno, Cancelar turno y Consultar turnos. En cambio, Seleccionar fecha puede descartarse como caso independiente porque es solo un paso dentro de Solicitar turno.

8.10 Refinar la lista inicial

Una vez generada la lista inicial, hay que revisarla con criterios claros:

• ¿Cada caso de uso tiene un actor principal reconocible?
• ¿Cada caso de uso expresa un objetivo con valor?
• ¿Hay nombres demasiado técnicos?
• ¿Hay casos demasiado pequeños que son solo pasos?
• ¿Hay casos demasiado grandes que mezclan varios objetivos?
• ¿Faltan actores o sistemas externos?
• ¿Hay funcionalidades fuera del alcance definido?

8.11 Agrupar por actor o por área

Cuando aparecen muchos casos de uso, conviene agruparlos para entender mejor el alcance. Se pueden organizar por actor, por área funcional, por proceso de negocio o por prioridad.

Ejemplo de agrupación por actor:

• Paciente: Solicitar turno, Consultar turnos, Cancelar turno.
• Recepcionista: Registrar turno presencial, Modificar turno, Registrar paciente.
• Médico: Consultar agenda diaria.
• Administrador: Administrar agenda, Registrar profesional, Configurar horarios.

Esta organización facilita detectar huecos y revisar si cada actor tiene cubiertos sus objetivos principales.

8.12 Detectar sistemas externos

Durante el descubrimiento inicial también hay que buscar sistemas externos. Si el sistema depende de una pasarela de pago, un servicio de identidad, una obra social, un sistema contable o un servicio de notificaciones, esas interacciones pueden afectar los casos de uso.

Por ejemplo, si Solicitar turno requiere validar cobertura médica, puede aparecer un actor secundario llamado Obra social o Sistema de cobertura. Esa dependencia puede generar flujos alternativos si la validación falla o no responde.

8.13 Priorización inicial

No todos los casos de uso tienen la misma importancia. Después de descubrirlos, conviene asignar una prioridad inicial según valor, frecuencia, riesgo, urgencia y dependencia con otros casos.

En un sistema de turnos, Solicitar turno y Consultar disponibilidad probablemente sean más prioritarios que Generar estadísticas mensuales. La prioridad puede cambiar, pero una primera clasificación ayuda a planificar el trabajo.

8.14 Errores frecuentes

Al descubrir casos de uso suelen aparecer estos errores:

• Empezar por pantallas en lugar de objetivos de actores.
• Confundir pasos pequeños con casos de uso completos.
• Usar nombres demasiado generales, como Gestionar todo o Administrar sistema.
• Olvidar actores secundarios y sistemas externos.
• Incluir funcionalidades fuera del alcance.
• No validar la lista inicial con usuarios o responsables del negocio.
• Intentar redactar detalles completos antes de tener una lista razonable.

8.15 Resultado esperado del descubrimiento inicial

Al finalizar esta etapa, el equipo debería contar con:

• Una lista preliminar de actores.
• Una lista de casos de uso candidatos.
• Una relación básica entre actores y casos de uso.
• Una idea inicial de prioridades.
• Dudas pendientes para consultar con usuarios o responsables.
• Casos que requieren mayor detalle en una etapa posterior.

Este resultado no es definitivo, pero permite avanzar hacia diagramas, especificaciones textuales y validación.

8.16 Qué debes recordar de este tema

• El descubrimiento inicial busca identificar casos de uso candidatos.
• Un buen punto de partida son los actores y sus objetivos.
• Los eventos externos también ayudan a descubrir funcionalidades.
• Los procesos actuales permiten detectar tareas que el sistema podría apoyar o automatizar.
• La lista inicial debe revisarse para eliminar casos demasiado pequeños, grandes o fuera de alcance.
• Los sistemas externos pueden revelar actores secundarios y flujos alternativos.
• El resultado debe validarse con usuarios y responsables del negocio.

8.17 Conclusión

Descubrir casos de uso es una actividad de análisis que combina preguntas, observación, conversación y revisión. No se trata de inventar funcionalidades, sino de comprender qué objetivos necesitan lograr los actores dentro del alcance del sistema.

Una buena lista inicial de casos de uso permite ordenar el trabajo posterior: diagramar, especificar, priorizar, validar y derivar pruebas. En el próximo tema estudiaremos cómo nombrar correctamente los casos de uso para que expresen intención y claridad.