18. Identificador, nombre, resumen y actor principal

18.1 Introducción

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.

18.2 Por qué estos campos son importantes

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.

Un buen encabezado de caso de uso permite responder rápidamente: cuál es, cómo se llama, qué propósito tiene y quién busca lograrlo.

18.3 Identificador

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:

  • CU-01: Solicitar turno.
  • CU-02: Cancelar turno.
  • CU-03: Consultar agenda diaria.
  • CU-04: Administrar agenda.

18.4 Ficha inicial del caso de uso

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.

Ficha inicial de un caso de uso con identificador, nombre, resumen y actor principal

18.5 Buenas prácticas para identificadores

Para que los identificadores sean útiles, conviene aplicar algunas reglas:

  • Usar un formato consistente en todo el proyecto.
  • No repetir identificadores.
  • No cambiar identificadores sin necesidad cuando el caso de uso ya está referenciado.
  • Evitar identificadores demasiado largos.
  • Separar por módulos solo si el proyecto lo necesita, por ejemplo CU-TUR-01.
  • No confiar en el número para expresar prioridad, salvo que esa regla esté definida explícitamente.

18.6 Nombre

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

18.7 Resumen

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:

El paciente solicita un turno con un profesional médico. El sistema muestra disponibilidad, registra la reserva seleccionada y entrega una confirmación.

Un buen resumen ayuda a validar rápidamente si el caso de uso está dentro del alcance y si su objetivo es comprensible.

18.8 Cómo redactar un buen resumen

Para redactar un buen resumen, conviene:

  • Mencionar al actor principal.
  • Explicar el objetivo en una o dos frases.
  • Indicar el resultado esperado de forma general.
  • Evitar detalles de interfaz.
  • Evitar detalles técnicos de implementación.
  • No duplicar todo el flujo principal.

El resumen debe orientar, no reemplazar el desarrollo completo del caso de uso.

18.9 Actor principal

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.

18.10 Actor principal no siempre es quien inicia

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.

18.11 Ejemplo completo de encabezado

Un encabezado claro para el caso de uso Solicitar turno podría ser:

Identificador: CU-01
Nombre: Solicitar turno
Resumen: El paciente consulta disponibilidad, selecciona un horario y confirma una reserva con un profesional médico.
Actor principal: Paciente

Con solo leer estos datos, ya se comprende el propósito general antes de avanzar al detalle del flujo.

18.12 Relación con trazabilidad

El identificador permite conectar el caso de uso con otros elementos del proyecto. Por ejemplo:

  • Requisitos funcionales asociados a CU-01.
  • Casos de prueba que verifican CU-01.
  • Historias de usuario relacionadas con CU-01.
  • Prototipos de interfaz vinculados con CU-01.
  • Defectos encontrados durante la prueba de CU-01.

Sin identificadores estables, estas relaciones se vuelven difíciles de mantener.

18.13 Relación con alcance

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.

18.14 Errores frecuentes

Al completar estos campos, suelen aparecer estos errores:

  • Usar identificadores inconsistentes o repetidos.
  • Cambiar identificadores cuando ya están referenciados en pruebas o requisitos.
  • Nombrar casos de uso como pantallas, botones o tareas técnicas.
  • Escribir resúmenes demasiado vagos.
  • Copiar el flujo completo dentro del resumen.
  • Elegir como actor principal a quien administra el sistema, aunque no sea quien busca el objetivo.
  • No validar el nombre y el resumen con usuarios o responsables del negocio.

18.15 Lista de revisión

Antes de avanzar con el resto de la especificación, conviene revisar:

  • ¿El identificador es único?
  • ¿El nombre expresa un objetivo claro?
  • ¿El nombre usa lenguaje comprensible para el negocio?
  • ¿El resumen explica propósito y resultado esperado?
  • ¿El resumen evita detalles técnicos innecesarios?
  • ¿El actor principal es quien busca obtener el valor central?
  • ¿Estos datos son coherentes con el diagrama de casos de uso?

18.16 Qué debes recordar de este tema

  • El identificador permite referenciar y trazar el caso de uso.
  • El nombre debe expresar el objetivo del actor principal.
  • El resumen describe brevemente propósito y resultado esperado.
  • El actor principal es quien busca lograr el objetivo central.
  • Estos campos deben ser claros antes de redactar flujos detallados.
  • Un mal encabezado suele anticipar problemas en toda la especificación.
  • La claridad inicial facilita validación, desarrollo y pruebas.

18.17 Conclusión

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.