2. Para qué sirven los casos de uso en Ingeniería de Software
2.1 Introducción
Los casos de uso sirven para comprender, ordenar y comunicar qué debe permitir hacer un sistema. Su valor principal está en describir el comportamiento esperado desde el punto de vista de los actores que interactúan con el software.
En Ingeniería de Software, muchas fallas no aparecen porque el equipo no sepa programar, sino porque se construye algo distinto de lo que el usuario necesitaba. Los casos de uso reducen ese riesgo porque obligan a analizar objetivos, actores, escenarios, reglas y resultados esperados antes de avanzar hacia el diseño o la construcción.
Un buen conjunto de casos de uso funciona como un puente entre la necesidad del negocio y el trabajo técnico del equipo. Ayuda a que clientes, usuarios, analistas, diseñadores, desarrolladores y testers puedan conversar sobre el mismo comportamiento con un lenguaje común.
2.2 Comunicación entre personas técnicas y no técnicas
Una de las funciones más importantes de los casos de uso es mejorar la comunicación. Un usuario puede no conocer términos técnicos como arquitectura, API, base de datos, componente, servicio o patrón de diseño, pero sí puede explicar qué necesita lograr con el sistema.
Cuando el equipo documenta casos de uso, puede revisar con el usuario frases como estas:
- El paciente solicita un turno con un profesional.
- El sistema muestra los horarios disponibles.
- El paciente selecciona un horario.
- El sistema registra la reserva y envía una confirmación.
Estas frases son comprensibles para una persona del negocio y también son útiles para el equipo técnico. Permiten validar si el flujo describe correctamente la necesidad real antes de invertir tiempo en la implementación.
2.3 Los casos de uso como puente de comunicación
Un caso de uso conecta dos mundos que suelen expresarse de manera diferente. Del lado del usuario aparecen necesidades, objetivos, reglas del trabajo y excepciones. Del lado del equipo técnico aparecen requisitos, interfaces, módulos, pruebas y decisiones de diseño. El caso de uso ayuda a que ambos lados hablen sobre una misma funcionalidad sin perder de vista el propósito original.
2.4 Descubrir requisitos funcionales
Los casos de uso ayudan a descubrir requisitos funcionales, es decir, comportamientos que el sistema debe ofrecer. Al analizar cada objetivo del actor, surgen preguntas que permiten detectar funciones necesarias.
Por ejemplo, si el caso de uso es Solicitar turno, pueden aparecer requisitos como:
- El sistema debe permitir buscar profesionales por especialidad.
- El sistema debe mostrar horarios disponibles.
- El sistema debe impedir reservar turnos en horarios ya ocupados.
- El sistema debe registrar los datos del paciente.
- El sistema debe enviar una confirmación de la reserva.
- El sistema debe permitir cancelar una solicitud antes de confirmarla.
Sin el análisis del caso de uso, varios de estos requisitos podrían quedar implícitos, incompletos o mal entendidos.
2.5 Aclarar el alcance del sistema
Otro uso importante es definir el alcance. El alcance indica qué funcionalidades serán parte del sistema y cuáles quedan fuera. Esto evita confusiones sobre responsabilidades, entregas y expectativas.
Por ejemplo, un sistema de turnos médicos podría incluir la reserva, consulta y cancelación de turnos, pero no incluir la liquidación de honorarios profesionales ni la historia clínica completa. Esa decisión debe quedar clara para que todos entiendan qué se construirá en esta etapa.
2.6 Organizar el alcance mediante casos de uso
Una vista de alcance permite ubicar los casos de uso dentro del sistema y relacionarlos con los actores que los necesitan. Esta organización ayuda a detectar funcionalidades faltantes, funcionalidades duplicadas y responsabilidades que pertenecen a otros sistemas o procesos externos.
2.7 Validar requisitos con usuarios
Los casos de uso son útiles para validar requisitos porque se pueden revisar como historias concretas de interacción. En lugar de preguntar al usuario si una lista técnica de requisitos es correcta, el analista puede recorrer un escenario paso a paso.
Por ejemplo:
2. El sistema solicita especialidad, profesional o fecha aproximada.
3. El paciente elige una opción de búsqueda.
4. El sistema muestra horarios disponibles.
5. El paciente selecciona un horario.
6. El sistema registra el turno y muestra la confirmación.
Al leer este flujo, el usuario puede detectar problemas: quizá falte confirmar la obra social, quizá haya que validar pagos pendientes, quizá algunos profesionales requieran derivación previa. Esa revisión temprana evita errores costosos en etapas posteriores.
2.8 Encontrar alternativas y excepciones
Un proceso real rara vez tiene un único camino perfecto. Los casos de uso ayudan a pensar qué ocurre cuando aparecen alternativas o errores.
En el caso de uso Solicitar turno, algunas situaciones posibles son:
- No hay turnos disponibles para la fecha solicitada.
- El paciente no está registrado.
- El profesional no atiende la especialidad indicada.
- El sistema externo de cobertura médica no responde.
- El paciente abandona la operación antes de confirmar.
- El turno seleccionado fue tomado por otra persona segundos antes.
Documentar estas situaciones permite diseñar respuestas más claras y preparar pruebas más completas.
2.9 Apoyar el diseño del sistema
Aunque los casos de uso no describen la implementación interna, sí aportan información muy valiosa para el diseño. Al conocer los flujos, datos, reglas y actores, el equipo puede identificar pantallas, servicios, entidades del dominio, integraciones y permisos.
Por ejemplo, si un caso de uso indica que el paciente debe recibir una confirmación, el diseño deberá considerar algún mecanismo de notificación. Si el caso de uso requiere validar cobertura médica con un sistema externo, el diseño deberá prever una integración.
De esta manera, el caso de uso no reemplaza al diseño técnico, pero lo alimenta con información funcional organizada.
2.10 Derivar pruebas de aceptación
Los casos de uso también sirven como base para las pruebas. Cada flujo principal, flujo alternativo y excepción puede convertirse en uno o más casos de prueba.
| Parte del caso de uso | Pregunta de prueba | Ejemplo |
|---|---|---|
| Precondición | ¿El sistema verifica que se cumpla antes de iniciar? | El paciente debe estar registrado para confirmar el turno. |
| Flujo principal | ¿El camino normal termina con el resultado esperado? | El sistema registra el turno y muestra la confirmación. |
| Flujo alternativo | ¿El sistema permite una variante válida? | El paciente busca por especialidad en lugar de buscar por profesional. |
| Excepción | ¿El sistema responde correctamente ante un problema? | No hay horarios disponibles y el sistema ofrece modificar la búsqueda. |
| Postcondición | ¿El estado final es correcto? | El turno queda reservado y no aparece como disponible para otros pacientes. |
2.11 Relación entre caso de uso, diseño y pruebas
Un caso de uso bien redactado puede acompañar varias etapas del desarrollo. Primero ayuda a comprender la necesidad. Luego orienta el diseño de pantallas, servicios, datos e integraciones. Finalmente permite derivar pruebas para verificar que el sistema cumple lo acordado.
2.12 Planificar y priorizar entregas
Los casos de uso permiten organizar el trabajo por funcionalidades con valor. En lugar de planificar solamente por capas técnicas, como base de datos, interfaz o servicios, el equipo puede planificar por objetivos de usuario.
Por ejemplo, una primera entrega de un sistema de turnos podría incluir:
- Consultar turnos disponibles.
- Solicitar turno.
- Cancelar turno.
Una entrega posterior podría incluir recordatorios automáticos, integración con cobertura médica, reportes administrativos y gestión avanzada de agendas. Esta forma de planificación facilita entregar valor de manera incremental.
2.13 Detectar riesgos temprano
Al recorrer un caso de uso, el equipo puede identificar riesgos antes de construir. Algunos riesgos son funcionales, como reglas de negocio ambiguas. Otros son técnicos, como integraciones difíciles, volumen alto de usuarios o necesidad de respuesta inmediata.
Por ejemplo, si muchos pacientes pueden intentar reservar el mismo turno al mismo tiempo, el equipo debe considerar problemas de concurrencia. Si la confirmación depende de un sistema externo, debe prever qué hacer cuando ese sistema no responde.
Cuanto antes se detectan estos riesgos, más opciones tiene el equipo para resolverlos de manera ordenada.
2.14 Mantener trazabilidad
La trazabilidad permite conectar necesidades, casos de uso, requisitos, diseño, código y pruebas. Esto es útil cuando el sistema cambia, porque ayuda a entender qué partes pueden verse afectadas.
Si cambia una regla del caso de uso Solicitar turno, el equipo puede revisar qué requisitos dependen de esa regla, qué pantallas la implementan, qué servicios la aplican y qué pruebas deben actualizarse.
2.15 Cuándo son especialmente útiles
Los casos de uso son especialmente útiles cuando:
- Hay varios tipos de usuarios con objetivos distintos.
- El sistema tiene reglas de negocio importantes.
- Existen muchos flujos alternativos o excepciones.
- Es necesario validar requisitos con personas no técnicas.
- El equipo necesita derivar pruebas de aceptación.
- Se requiere documentar el alcance funcional de forma clara.
- El proyecto involucra integraciones con sistemas externos.
2.16 Límites de los casos de uso
Los casos de uso son muy útiles, pero no resuelven todo. No reemplazan al modelado de dominio, al diseño de arquitectura, a los prototipos de interfaz, a las historias de usuario, a los criterios de aceptación ni a la documentación técnica detallada cuando esta es necesaria.
Tampoco conviene usarlos como una formalidad vacía. Un documento largo, desactualizado y no validado puede generar más confusión que ayuda. El valor aparece cuando los casos de uso se mantienen claros, revisables y conectados con decisiones reales del proyecto.
2.17 Qué debes recordar de este tema
- Los casos de uso sirven para comprender y comunicar el comportamiento esperado del sistema.
- Ayudan a descubrir requisitos funcionales a partir de objetivos de los actores.
- Permiten aclarar el alcance y separar lo que pertenece al sistema de lo que queda fuera.
- Facilitan la validación con usuarios porque describen escenarios concretos.
- Sirven como base para diseño, pruebas, planificación y trazabilidad.
- Son especialmente útiles cuando hay reglas de negocio, alternativas, excepciones e integraciones.
- No reemplazan otras técnicas, pero se integran muy bien con ellas.
2.18 Conclusión
Los casos de uso son una herramienta central para transformar necesidades en comportamiento funcional comprensible. Su utilidad no se limita a documentar: ayudan a conversar, preguntar, descubrir, validar, diseñar, probar y planificar.
En el próximo tema estudiaremos la relación entre casos de uso, requisitos funcionales e historias de usuario, tres formas muy utilizadas para expresar lo que un sistema debe permitir hacer.