17. Especificación textual de un caso de uso
17.1 Introducción
El diagrama de casos de uso muestra una vista general del sistema, pero no alcanza para explicar el comportamiento completo. Para describir con precisión qué ocurre en una funcionalidad se utiliza la especificación textual del caso de uso.
La especificación textual detalla el objetivo, los actores, las condiciones, el flujo principal, las alternativas, las excepciones y los resultados esperados. Es el documento que permite pasar de una elipse en un diagrama a una comprensión clara de cómo debe comportarse el sistema.
Este tipo de especificación es útil para analistas, usuarios, desarrolladores, testers y responsables del proyecto, porque convierte una funcionalidad en una descripción revisable y verificable.
17.2 Qué es una especificación textual
Una especificación textual es una descripción ordenada de un caso de uso. Explica cómo interactúan el actor y el sistema para lograr un objetivo, qué condiciones deben cumplirse y qué resultados deben obtenerse.
No es una novela, ni una lista desordenada de comentarios. Debe tener una estructura clara para que diferentes personas puedan leerla, validarla y usarla como base de trabajo.
17.3 Por qué complementa al diagrama
El diagrama permite ver que un actor participa en un caso de uso, pero no explica los detalles. Por ejemplo, una elipse llamada Solicitar turno no dice qué datos ingresa el paciente, cómo se valida la disponibilidad, qué ocurre si no hay horarios o cómo se confirma la reserva.
La especificación textual completa esa información. El diagrama ayuda a entender el alcance general; la especificación permite comprender el comportamiento concreto.
17.4 Estructura básica de una especificación
Una especificación textual suele organizarse como una ficha con campos definidos. No todas las organizaciones usan exactamente la misma plantilla, pero los campos más importantes suelen repetirse: identificador, nombre, actor principal, objetivo, precondiciones, flujo principal, flujos alternativos, excepciones y postcondiciones.
17.5 Campos habituales
Una plantilla completa puede incluir los siguientes campos:
- Identificador: código único, por ejemplo CU-01.
- Nombre: objetivo del caso de uso, por ejemplo Solicitar turno.
- Actor principal: actor que busca lograr el objetivo.
- Actores secundarios: otros actores o sistemas externos que participan.
- Descripción breve: resumen del propósito.
- Precondiciones: condiciones necesarias antes de iniciar.
- Disparador: evento que inicia el caso de uso.
- Flujo principal: secuencia normal de interacción.
- Flujos alternativos: variantes válidas del flujo principal.
- Excepciones: errores o situaciones que impiden continuar normalmente.
- Postcondiciones: estado final esperado.
- Reglas de negocio: restricciones que deben cumplirse.
17.6 Ejemplo resumido
Un ejemplo básico para el caso de uso Solicitar turno podría ser:
Nombre: Solicitar turno
Actor principal: Paciente
Objetivo: reservar un turno disponible con un profesional médico.
Precondición: el paciente está registrado en el sistema.
Resultado esperado: el turno queda reservado y el paciente recibe una confirmación.
Este ejemplo todavía no desarrolla todos los flujos, pero muestra cómo la especificación agrega información que el diagrama no contiene.
17.7 Flujo principal
El flujo principal describe el camino normal o más esperado para completar el caso de uso. Se redacta como una secuencia de pasos numerados donde alternan acciones del actor y respuestas del sistema.
Ejemplo:
2. El sistema muestra especialidades disponibles.
3. El paciente selecciona una especialidad y una fecha aproximada.
4. El sistema muestra horarios disponibles.
5. El paciente selecciona un horario.
6. El sistema registra la reserva y muestra la confirmación.
17.8 Flujos alternativos
Los flujos alternativos describen variantes válidas del flujo principal. No son errores necesariamente; son caminos distintos que también permiten cumplir el objetivo o llegar a un resultado aceptable.
Por ejemplo, el paciente puede buscar por profesional en lugar de buscar por especialidad. Ese comportamiento puede documentarse como alternativa si modifica el camino normal de interacción.
17.9 Excepciones
Las excepciones describen problemas que impiden completar el caso de uso de la manera esperada o que requieren una respuesta especial del sistema.
Ejemplos en Solicitar turno:
- No hay horarios disponibles.
- El paciente no está registrado.
- El turno seleccionado fue tomado por otro paciente antes de confirmar.
- El servicio externo de notificaciones no responde.
17.10 Precondiciones y postcondiciones
Las precondiciones indican qué debe ser verdadero antes de iniciar el caso de uso. Las postcondiciones indican qué debe ser verdadero cuando termina correctamente.
Ejemplo:
| Elemento | Ejemplo |
|---|---|
| Precondición | El paciente está registrado y habilitado para solicitar turnos. |
| Postcondición | El turno queda reservado y ya no aparece como disponible. |
17.11 Nivel de detalle adecuado
La especificación debe tener suficiente detalle para evitar ambigüedades, pero no debe convertirse en una descripción de implementación. No conviene incluir consultas SQL, nombres de clases, detalles de framework o decisiones internas que pertenecen al diseño técnico.
El nivel adecuado depende de la complejidad del caso de uso. Un caso simple puede requerir una especificación breve. Un proceso con reglas, excepciones e integraciones necesita más detalle.
17.12 Redacción clara
La redacción debe ser precisa y fácil de revisar. Conviene usar frases cortas, evitar ambigüedades y separar claramente lo que hace el actor de lo que responde el sistema.
En lugar de escribir "se cargan los datos y se guarda", es mejor escribir "El paciente ingresa los datos solicitados" y luego "El sistema valida los datos y registra la reserva".
17.13 Relación con pruebas
Una especificación textual bien escrita facilita la creación de pruebas. El flujo principal puede convertirse en pruebas de camino exitoso. Los flujos alternativos y excepciones pueden convertirse en pruebas adicionales.
Por ejemplo, si la especificación dice que el sistema debe informar cuando no hay horarios disponibles, debe existir una prueba que verifique ese comportamiento.
17.14 Relación con requisitos
La especificación textual también ayuda a derivar y organizar requisitos funcionales. Cada comportamiento importante del sistema puede convertirse en un requisito verificable.
Por ejemplo, del caso de uso Solicitar turno pueden derivarse requisitos como mostrar horarios disponibles, impedir reservas duplicadas, registrar confirmación y enviar aviso al paciente.
17.15 Errores frecuentes
Al escribir especificaciones textuales, suelen aparecer estos errores:
- Copiar solo el nombre del caso de uso sin desarrollar comportamiento.
- Describir pantallas en lugar de interacciones.
- Mezclar pasos del actor y del sistema en la misma frase.
- Olvidar flujos alternativos y excepciones.
- Incluir detalles técnicos de implementación.
- No indicar precondiciones ni resultados esperados.
- No validar la especificación con usuarios o responsables del negocio.
17.16 Lista de revisión
Antes de considerar completa una especificación, conviene revisar:
- ¿El objetivo está claramente definido?
- ¿El actor principal está identificado?
- ¿El flujo principal permite lograr el objetivo?
- ¿Las alternativas importantes están documentadas?
- ¿Las excepciones relevantes están consideradas?
- ¿Las precondiciones y postcondiciones son verificables?
- ¿La redacción evita detalles de implementación?
- ¿El caso de uso puede servir como base para pruebas?
17.17 Qué debes recordar de este tema
- El diagrama muestra alcance; la especificación textual detalla comportamiento.
- Una especificación textual describe actor, objetivo, condiciones, flujos y resultados.
- El flujo principal representa el camino normal para cumplir el objetivo.
- Los flujos alternativos describen variantes válidas.
- Las excepciones describen situaciones problemáticas o interrupciones.
- La especificación debe ser clara, verificable y libre de detalles técnicos innecesarios.
- Una buena especificación ayuda a diseñar, desarrollar y probar.
17.18 Conclusión
La especificación textual convierte un caso de uso en una descripción precisa del comportamiento esperado. Es el complemento natural del diagrama y una herramienta fundamental para reducir ambigüedades.
Cuando está bien escrita, permite validar requisitos con usuarios, orientar el diseño, implementar con mayor claridad y derivar pruebas. En el próximo tema estudiaremos con más detalle el identificador, el nombre, el resumen y el actor principal.