La especificación textual de un caso de uso comienza con campos simples, pero muy importantes: identificador, nombre, resumen y actor principal. Estos datos permiten reconocer el caso de uso, comprender su propósito y saber para quién existe la funcionalidad.
Si estos campos están mal definidos, todo lo que sigue puede quedar confuso. Un identificador poco consistente dificulta la trazabilidad. Un nombre débil oculta el objetivo. Un resumen ambiguo no ayuda a validar el alcance. Un actor principal incorrecto cambia el sentido del caso de uso.
En este tema veremos cómo escribir estos campos con claridad y cómo usarlos como base para el resto de la especificación.
Estos cuatro campos funcionan como la portada funcional del caso de uso. Antes de leer precondiciones, flujos y excepciones, una persona debería poder entender de qué trata el caso de uso, quién lo necesita y qué objetivo general persigue.
También ayudan a organizar documentación, relacionar requisitos, planificar trabajo y derivar pruebas. Por eso deben redactarse con cuidado, aunque parezcan datos administrativos.
El identificador es un código único que permite referirse al caso de uso sin ambigüedad. Suele usar un prefijo y un número, por ejemplo CU-01, CU-02 o UC-01.
El identificador es útil para trazabilidad. Permite relacionar el caso de uso con requisitos, historias de usuario, casos de prueba, incidencias, tareas de desarrollo y documentos de diseño.
Ejemplos:
La ficha inicial reúne los datos que identifican y resumen el caso de uso. En el ejemplo, el identificador CU-01 permite referenciarlo, el nombre Solicitar turno expresa el objetivo, el resumen describe el propósito y el actor principal indica quién busca obtener el resultado.
Para que los identificadores sean útiles, conviene aplicar algunas reglas:
El nombre del caso de uso debe expresar el objetivo del actor principal. Conviene usar un verbo en infinitivo más un objeto significativo: Solicitar turno, Registrar paciente, Consultar agenda, Cancelar reserva.
El nombre debe ser breve, claro y orientado al valor. No debe describir una pantalla, un botón ni una operación técnica interna.
| Nombre débil | Nombre recomendado |
|---|---|
| Pantalla de turnos | Consultar turnos |
| Presionar confirmar | Confirmar reserva |
| Cargar formulario | Registrar paciente |
| Enviar request | Validar cobertura |
El resumen es una descripción breve del propósito del caso de uso. Debe explicar qué permite hacer el sistema y qué resultado general se espera, sin entrar todavía en todos los pasos.
Ejemplo:
Un buen resumen ayuda a validar rápidamente si el caso de uso está dentro del alcance y si su objetivo es comprensible.
Para redactar un buen resumen, conviene:
El resumen debe orientar, no reemplazar el desarrollo completo del caso de uso.
El actor principal es quien busca lograr el objetivo central del caso de uso. Identificarlo correctamente ayuda a redactar el nombre, el resumen y el flujo principal desde la perspectiva adecuada.
En el caso Solicitar turno, el actor principal suele ser el Paciente. En Consultar agenda diaria, puede ser el Médico. En Configurar horarios de atención, puede ser el Administrador.
Muchas veces el actor principal inicia el caso de uso, pero no siempre. Lo más importante es identificar quién obtiene el valor principal del caso de uso.
Por ejemplo, un recordatorio automático puede iniciarse por una tarea programada del sistema, pero el actor beneficiado puede ser el Paciente. En ese caso, la especificación debe aclarar muy bien el disparador y el actor que recibe valor.
Un encabezado claro para el caso de uso Solicitar turno podría ser:
Con solo leer estos datos, ya se comprende el propósito general antes de avanzar al detalle del flujo.
El identificador permite conectar el caso de uso con otros elementos del proyecto. Por ejemplo:
Sin identificadores estables, estas relaciones se vuelven difíciles de mantener.
El nombre y el resumen ayudan a validar si el caso de uso pertenece al alcance del sistema. Si el resumen describe tareas manuales o responsabilidades de otro sistema, puede ser una señal de que el caso de uso está mal ubicado.
Por ejemplo, si un sistema de turnos tiene un caso llamado Realizar diagnóstico médico, probablemente ese caso no pertenece al sistema de turnos, sino a un proceso clínico más amplio o a otro sistema.
Al completar estos campos, suelen aparecer estos errores:
Antes de avanzar con el resto de la especificación, conviene revisar:
Identificador, nombre, resumen y actor principal forman la base de la especificación textual. Aunque son campos breves, orientan todo el análisis posterior.
Cuando estos elementos están bien definidos, el caso de uso se entiende más rápido, se relaciona mejor con otros documentos y se valida con mayor facilidad. En el próximo tema estudiaremos interesados, necesidades y garantías del caso de uso.