13. Interfaces externas y dependencias con otros sistemas

13.1 Introducción

Un sistema de software rara vez trabaja completamente aislado. Normalmente interactúa con usuarios, otros sistemas, bases de datos, servicios externos, dispositivos, archivos, proveedores o plataformas de terceros. A estos puntos de contacto los llamamos interfaces externas.

Las interfaces externas son importantes en requerimientos porque definen qué información entra y sale del sistema, con quién se comunica, bajo qué condiciones, con qué formato y qué ocurre si la comunicación falla.

Si estas interfaces no se identifican a tiempo, pueden aparecer dependencias ocultas, errores de integración, demoras, problemas de seguridad y cambios costosos.

13.2 ¿Qué es una interfaz externa?

Una interfaz externa es un punto de interacción entre el sistema que se está especificando y algo que está fuera de sus límites.

Una interfaz externa define cómo el sistema se comunica con personas, sistemas, dispositivos, archivos o servicios que no forman parte directa de la solución.

Ejemplos:

  • Una pantalla usada por un cliente para consultar un pedido.
  • Una API para consultar stock en otro sistema.
  • Un archivo enviado diariamente al sistema contable.
  • Una pasarela de pagos que confirma o rechaza transacciones.
  • Un lector de código de barras conectado al sistema.
  • Un servicio de correo utilizado para enviar notificaciones.

13.3 Tipos de interfaces externas

Las interfaces externas pueden clasificarse según el tipo de interacción.

Tipo Descripción Ejemplo
Interfaz de usuario Interacción entre personas y sistema. Pantalla de registro de reclamos.
Interfaz con sistemas Comunicación con aplicaciones, servicios o plataformas externas. Consulta de stock al sistema de inventario.
Interfaz de datos Intercambio mediante archivos, bases de datos o mensajes. Importación diaria de clientes desde un archivo CSV.
Interfaz con dispositivos Comunicación con hardware o equipos físicos. Lector de tarjetas, impresora fiscal o sensor.
Interfaz con servicios externos Uso de proveedores o servicios de terceros. Pasarela de pagos, envío de SMS o servicio de mapas.

13.4 Interfaces y límites del sistema

Las interfaces externas ayudan a definir los límites del sistema. Si algo está fuera de la solución pero se comunica con ella, debe identificarse como actor, sistema externo, servicio o dispositivo externo.

Por ejemplo, si un sistema de ventas consulta stock en un sistema de inventario, el inventario no forma parte del sistema de ventas. Sin embargo, la comunicación entre ambos es una dependencia que debe especificarse.

Definir estos límites evita confundir responsabilidades. El sistema puede depender de datos externos, pero no necesariamente controlar cómo se generan esos datos.

13.5 Dependencias con otros sistemas

Una dependencia existe cuando el sistema necesita que otro componente, servicio, proveedor o sistema externo funcione correctamente para cumplir un requerimiento.

Ejemplos de dependencias:

  • El sistema necesita consultar el padrón de clientes antes de registrar un pedido.
  • La confirmación de compra depende de la respuesta de una pasarela de pagos.
  • El envío de notificaciones depende de un servicio de correo externo.
  • La generación de facturas depende de un sistema fiscal o contable.
  • La consulta de disponibilidad depende de un sistema de reservas existente.

Las dependencias deben analizarse porque pueden introducir riesgos de disponibilidad, rendimiento, seguridad y planificación.

13.6 Información que debe especificarse

Para cada interfaz externa conviene documentar información mínima:

  • Nombre del sistema, servicio, actor o dispositivo externo.
  • Propósito de la interacción.
  • Datos que se envían y datos que se reciben.
  • Formato de intercambio.
  • Frecuencia de uso o momento en que ocurre.
  • Responsable de cada lado de la interfaz.
  • Condiciones de error y recuperación.
  • Requerimientos de seguridad.
  • Restricciones técnicas o contractuales.
  • Ambiente de pruebas disponible.

Esta información evita que la integración quede definida solo de manera informal.

13.7 Datos intercambiados

Una interfaz externa debe aclarar qué datos se intercambian. No basta con decir "integrarse con el sistema contable"; hay que saber qué información viaja, cuándo y con qué significado.

Ejemplo para una factura enviada al sistema contable:

  • Número de factura.
  • Fecha de emisión.
  • Cliente.
  • Importes netos.
  • Impuestos.
  • Total.
  • Estado.
  • Forma de pago.

También es importante definir qué sistema es dueño de cada dato y cuál es la fuente confiable de información.

13.8 Formatos y protocolos

Las interfaces externas suelen requerir formatos y protocolos específicos. Estos aspectos pueden ser restricciones técnicas.

Ejemplos:

  • API REST con datos en formato JSON.
  • Archivos CSV separados por punto y coma.
  • Mensajes XML enviados por un servicio externo.
  • Transferencia de archivos mediante SFTP.
  • Conexión con base de datos compartida.
  • Integración mediante eventos o colas de mensajes.

Cuando el formato lo define un proveedor externo, debe obtenerse documentación actualizada y validarse con ejemplos reales.

13.9 Frecuencia y sincronización

Una integración puede ocurrir en tiempo real, en forma programada o mediante procesos manuales. Esta decisión afecta experiencia de usuario, rendimiento, complejidad y riesgo.

Forma Descripción Ejemplo
Tiempo real La comunicación ocurre inmediatamente durante la operación. Consultar autorización de pago al confirmar una compra.
Programada La comunicación ocurre en horarios o intervalos definidos. Importar clientes todas las noches.
Por evento La comunicación se dispara cuando ocurre algo relevante. Enviar notificación cuando cambia el estado de un reclamo.
Manual Una persona inicia la carga, descarga o envío de información. Exportar un archivo de ventas para cargarlo en otro sistema.

La frecuencia debe estar alineada con la necesidad del negocio. No todo requiere integración en tiempo real.

13.10 Errores y fallas de comunicación

Las interfaces externas pueden fallar. Un sistema externo puede no responder, devolver datos inválidos, cambiar su formato, estar en mantenimiento o rechazar una operación.

Por eso, los requerimientos deben aclarar qué ocurre ante errores:

  • ¿Se reintenta la operación?
  • ¿Cuántas veces y con qué intervalo?
  • ¿Se registra el error para soporte?
  • ¿Se informa al usuario?
  • ¿La operación queda pendiente?
  • ¿Se permite continuar sin respuesta del sistema externo?
  • ¿Quién revisa y corrige fallas de integración?

Ignorar fallas de integración puede producir datos inconsistentes o interrupciones importantes.

13.11 Seguridad en interfaces externas

Las interfaces externas deben considerar seguridad. Cuando se intercambian datos con otros sistemas, pueden existir riesgos de acceso no autorizado, exposición de información, manipulación de datos o suplantación.

Aspectos a revisar:

  • Autenticación entre sistemas.
  • Autorización para operaciones externas.
  • Cifrado de comunicaciones.
  • Protección de credenciales y claves.
  • Registro de operaciones.
  • Validación de datos recibidos.
  • Tratamiento de información sensible.

La seguridad de una integración debe definirse como parte de los requerimientos, no improvisarse durante la implementación.

13.12 Responsabilidades entre sistemas

Cuando dos sistemas se comunican, debe quedar claro quién es responsable de cada parte.

Preguntas útiles:

  • ¿Qué sistema genera el dato?
  • ¿Qué sistema valida el dato?
  • ¿Qué sistema conserva el dato como fuente principal?
  • ¿Qué sistema informa errores?
  • ¿Quién resuelve inconsistencias?
  • ¿Qué equipo mantiene cada integración?
  • ¿Quién debe avisar cambios en formatos o servicios?

Sin responsabilidades claras, los problemas de integración suelen quedar sin dueño.

13.13 Contratos de interfaz

Un contrato de interfaz define el acuerdo entre sistemas: qué se envía, qué se recibe, en qué formato, con qué reglas y qué respuestas son posibles.

Puede incluir:

  • Operaciones disponibles.
  • Parámetros de entrada.
  • Formato de respuesta.
  • Códigos de error.
  • Reglas de validación.
  • Tiempo máximo de respuesta esperado.
  • Política de versiones.
  • Condiciones de seguridad.

Los contratos de interfaz reducen ambigüedades y facilitan pruebas entre sistemas.

13.14 Versionado y cambios de interfaces

Las interfaces externas pueden cambiar. Un proveedor puede modificar una API, un sistema interno puede cambiar campos, o una regulación puede exigir nuevos datos.

Por eso conviene definir:

  • Cómo se comunicarán cambios de interfaz.
  • Qué versiones estarán soportadas.
  • Qué plazo habrá para adaptarse a una nueva versión.
  • Cómo se probarán cambios antes de producción.
  • Qué ocurre si una versión anterior deja de estar disponible.

El versionado es especialmente importante cuando existen varios sistemas o equipos involucrados.

13.15 Ejemplo de especificación de interfaz

Campo Ejemplo
Nombre Consulta de stock
Sistema externo Sistema de inventario
Propósito Verificar disponibilidad antes de confirmar un pedido.
Datos enviados Código de producto y depósito solicitado.
Datos recibidos Stock disponible, stock reservado y fecha de última actualización.
Frecuencia En tiempo real durante el registro del pedido.
Error esperado Si el sistema de inventario no responde, el pedido queda en estado pendiente de validación.
Seguridad Autenticación entre sistemas mediante credencial técnica autorizada.

13.16 Interfaces de usuario como límite externo

Las interfaces de usuario también son interfaces externas, porque conectan el sistema con personas. En requerimientos no es necesario diseñar cada pantalla al detalle desde el inicio, pero sí conviene identificar tareas, datos, roles y condiciones de uso.

Ejemplos de requerimientos relacionados:

  • El cliente debe poder consultar el estado de su pedido ingresando número de pedido y correo electrónico.
  • El operador debe poder registrar un reclamo durante una llamada telefónica sin abandonar la pantalla de atención.
  • El administrador debe poder revisar errores de integración desde una vista de seguimiento.

Estas descripciones ayudan a comprender interacciones sin convertir los requerimientos en diseño visual prematuro.

13.17 Interfaces con dispositivos

Algunos sistemas interactúan con dispositivos físicos: lectores, sensores, impresoras, terminales de pago, cámaras, balanzas o equipamiento industrial.

En estos casos deben definirse aspectos como:

  • Modelo o tipo de dispositivo compatible.
  • Datos que envía o recibe.
  • Condiciones de conexión.
  • Errores posibles.
  • Responsabilidad de instalación y mantenimiento.
  • Pruebas necesarias con hardware real.

Las interfaces con dispositivos suelen requerir validación temprana porque pueden depender de hardware específico.

13.18 Riesgos frecuentes

Las interfaces externas suelen introducir riesgos importantes:

  • Documentación incompleta del sistema externo.
  • Ambientes de prueba no disponibles.
  • Diferencias entre datos esperados y datos reales.
  • Cambios de formato sin aviso.
  • Respuestas lentas o interrupciones del servicio externo.
  • Responsabilidades poco claras entre equipos.
  • Errores de seguridad en credenciales o permisos.
  • Dependencia de proveedores externos con tiempos propios.

Estos riesgos deben considerarse en planificación, pruebas y gestión de cambios.

13.19 Errores frecuentes

Al especificar interfaces externas, suelen aparecer errores como:

  • Decir "integrarse con otro sistema" sin especificar datos ni propósito.
  • No definir qué ocurre si el sistema externo falla.
  • No identificar quién es dueño de cada dato.
  • No consultar documentación técnica actualizada.
  • No considerar seguridad de la comunicación.
  • No prever ambientes de prueba.
  • Suponer que los datos externos siempre serán correctos.
  • No registrar dependencias con proveedores o equipos externos.

13.20 Buenas prácticas

Algunas buenas prácticas son:

  • Identificar interfaces externas desde la definición de alcance.
  • Documentar propósito, datos, formato, frecuencia, errores y responsables.
  • Obtener ejemplos reales de datos intercambiados.
  • Validar contratos de interfaz con equipos técnicos involucrados.
  • Definir manejo de fallas y reintentos.
  • Considerar seguridad y auditoría de integraciones.
  • Planificar pruebas con sistemas externos o simuladores.
  • Registrar dependencias y riesgos asociados.
Una integración mal definida puede parecer un detalle técnico, pero suele afectar alcance, tiempos, pruebas y operación.

13.21 Qué debes recordar de este tema

  • Las interfaces externas son puntos de comunicación con elementos fuera del sistema.
  • Pueden involucrar usuarios, sistemas, archivos, servicios, dispositivos o proveedores.
  • Las dependencias externas deben identificarse temprano.
  • Una interfaz debe especificar datos, formato, frecuencia, errores, seguridad y responsables.
  • Los contratos de interfaz reducen ambigüedades entre sistemas.
  • Las fallas de integración deben estar previstas en los requerimientos.
  • Las interfaces externas suelen introducir riesgos de planificación, seguridad y calidad.

13.22 Conclusión

Las interfaces externas y dependencias con otros sistemas son una parte crítica de los requerimientos. Definen cómo el sistema se conecta con su entorno y qué condiciones deben cumplirse para que esa comunicación sea confiable.

Especificarlas con claridad evita suposiciones técnicas, reduce riesgos de integración y ayuda a construir una solución que funcione dentro del ecosistema real de la organización.

En el próximo tema estudiaremos los datos requeridos por el sistema, incluyendo qué información debe capturarse, almacenarse, validarse, consultarse y protegerse.