26. Datos de entrada, datos de salida y mensajes del sistema

26.1 Introducción

En un caso de uso, actor y sistema intercambian información. El actor puede ingresar datos, seleccionar opciones o confirmar decisiones. El sistema puede mostrar resultados, solicitar correcciones, emitir comprobantes o informar errores.

Documentar datos de entrada, datos de salida y mensajes del sistema ayuda a precisar qué información participa en la interacción y qué debe comunicarse en cada momento importante.

Esto no significa diseñar la pantalla completa ni definir la base de datos. Significa aclarar qué información funcional es necesaria para cumplir el objetivo del caso de uso.

26.2 Datos de entrada

Los datos de entrada son datos que el actor, un sistema externo o un dispositivo entrega al sistema durante el caso de uso. Pueden ser escritos, seleccionados, enviados automáticamente o capturados desde otro medio.

Ejemplos en Solicitar turno:

• Especialidad médica.
• Profesional seleccionado.
• Fecha aproximada.
• Horario elegido.
• Datos de contacto del paciente.
• Confirmación de la reserva.

26.3 Datos de salida

Los datos de salida son datos que el sistema entrega al actor o a otra entidad externa. Pueden mostrarse en pantalla, enviarse por correo, entregarse como archivo, comunicarse por una integración o registrarse como comprobante.

Ejemplos:

• Lista de horarios disponibles.
• Resumen de la reserva.
• Número de turno o código de confirmación.
• Mensaje de operación exitosa.
• Comprobante de reserva.
• Notificación enviada al paciente.

26.4 Intercambio de información durante el caso de uso

Durante un caso de uso, los datos de entrada permiten al sistema procesar la solicitud y los datos de salida permiten al actor comprender el resultado. Los mensajes del sistema acompañan ese intercambio para guiar, confirmar o informar problemas.

26.5 Mensajes del sistema

Los mensajes del sistema comunican al actor qué ocurre, qué debe hacer o cuál fue el resultado. Pueden ser mensajes de confirmación, advertencia, error, solicitud de datos o información de estado.

Ejemplos:

• Turno reservado correctamente.
• No hay horarios disponibles para la fecha seleccionada.
• Debe completar un número de teléfono válido.
• El horario seleccionado ya no está disponible.
• Se enviará una confirmación al correo registrado.

26.6 No confundir datos con diseño de interfaz

Documentar datos no significa diseñar cada campo visual de la pantalla. El caso de uso debe indicar qué información se necesita, no necesariamente dónde aparece, de qué color es el botón o cómo se distribuye el formulario.

Por ejemplo, es válido indicar que el paciente debe seleccionar especialidad y fecha aproximada. No hace falta decidir en el caso de uso si esos datos aparecen en una lista desplegable, un calendario o una tarjeta visual, salvo que esa decisión sea funcionalmente relevante.

26.7 Datos obligatorios y opcionales

Al documentar datos de entrada, conviene distinguir cuáles son obligatorios y cuáles opcionales. Esto permite definir validaciones y mensajes claros.

Ejemplo:

26.8 Validaciones de datos

Los datos de entrada suelen estar asociados a validaciones. Algunas validaciones son simples, como formato o obligatoriedad. Otras dependen de reglas de negocio.

Ejemplos:

• La fecha no puede ser anterior al día actual.
• El correo electrónico debe tener formato válido.
• El horario seleccionado debe estar disponible.
• El paciente no debe tener otro turno activo con el mismo profesional en el mismo día.

26.9 Datos derivados

Algunos datos no los ingresa el actor directamente, sino que el sistema los calcula o deriva. Por ejemplo, el código de reserva, la fecha de creación, el estado inicial del turno o el usuario que realizó la operación.

Estos datos pueden ser importantes para la postcondición, auditoría o pruebas, aunque no sean datos de entrada del actor.

26.10 Datos enviados a sistemas externos

Si el caso de uso involucra un sistema externo, conviene indicar qué información se envía y qué respuesta se espera.

Por ejemplo, para enviar una confirmación de turno, el sistema puede enviar al servicio de mensajería: destinatario, fecha, hora, profesional y texto del mensaje. La salida esperada puede ser confirmación de envío o aviso de falla.

26.11 Mensajes de confirmación

Los mensajes de confirmación informan que una operación se completó correctamente. Deben ser claros y contener la información necesaria para que el actor entienda el resultado.

Ejemplo:

26.12 Mensajes de error

Los mensajes de error deben explicar el problema y, cuando sea posible, orientar la recuperación. No deben limitarse a códigos técnicos incomprensibles.

Ejemplo poco útil:

Ejemplo más claro:

26.13 Mensajes de advertencia

Las advertencias informan una condición importante antes de que el actor continúe. No necesariamente bloquean la operación.

Ejemplos:

• Está por cancelar un turno dentro de las próximas 24 horas.
• La confirmación se enviará al correo registrado.
• El profesional seleccionado solo atiende en la sede central.

26.14 Datos y privacidad

Cuando el caso de uso maneja datos personales, médicos, financieros o sensibles, debe considerarse qué información se muestra, quién puede verla y qué se envía a sistemas externos.

Por ejemplo, un recepcionista quizá pueda ver datos administrativos del turno, pero no información clínica sensible. Estas restricciones pueden documentarse como reglas de negocio, requisitos no funcionales o políticas de acceso.

26.15 Relación con pruebas

Los datos de entrada y salida ayudan a diseñar pruebas. Cada dato obligatorio debe probarse. Cada validación importante debe verificarse. Cada mensaje crítico debe comprobarse.

Por ejemplo, si la fecha no puede ser anterior al día actual, debe existir una prueba con una fecha inválida. Si el sistema debe mostrar un código de reserva, la prueba debe verificar que ese código exista y corresponda al turno creado.

26.16 Errores frecuentes

Al documentar datos y mensajes, suelen aparecer estos errores:

• No indicar qué datos son obligatorios.
• Confundir especificación funcional con diseño visual completo.
• Olvidar validaciones importantes.
• No documentar datos enviados a sistemas externos.
• Usar mensajes de error técnicos o poco útiles.
• No considerar privacidad o permisos sobre datos sensibles.
• No derivar pruebas a partir de datos y mensajes críticos.

26.17 Lista de revisión

Antes de cerrar esta parte del caso de uso, conviene revisar:

• ¿Están identificados los datos de entrada principales?
• ¿Se distinguen datos obligatorios, opcionales y condicionales?
• ¿Están claras las validaciones relevantes?
• ¿Se describen los datos de salida esperados?
• ¿Los mensajes del sistema son comprensibles?
• ¿Se consideran datos enviados a sistemas externos?
• ¿Los datos sensibles tienen restricciones adecuadas?
• ¿Los datos y mensajes pueden verificarse mediante pruebas?

26.18 Qué debes recordar de este tema

• Los datos de entrada son información que el actor o un sistema externo entrega al sistema.
• Los datos de salida son información que el sistema devuelve o comunica.
• Los mensajes del sistema guían, confirman, advierten o informan errores.
• No hay que confundir datos funcionales con diseño visual detallado.
• Las validaciones deben documentarse cuando afectan el comportamiento.
• Los mensajes de error deben ayudar al actor a comprender y recuperarse.
• Datos y mensajes son una base importante para pruebas.

26.19 Conclusión

Datos de entrada, datos de salida y mensajes del sistema completan la comprensión de la interacción entre actor y sistema. Permiten saber qué información se necesita, qué resultado se comunica y cómo se orienta al usuario durante el caso de uso.

Documentarlos con claridad mejora la especificación, ayuda al diseño de interfaces y facilita las pruebas. En el próximo tema estudiaremos los requisitos no funcionales relacionados con casos de uso.