Respuesta.

Historia de la pregunta:

Inicialmente, en los proyectos de TI, los analistas de sistemas se enfocaban principalmente en los requisitos empresariales, y las limitaciones técnicas eran transmitidas o ignoradas, lo que llevaba a soluciones no funcionales o excesivamente costosas.

Problema:

Las limitaciones técnicas no siempre son declaradas: el cliente puede no conocerlas, el desarrollo puede no tenerlas en cuenta, y el resultado puede contradecir las capacidades de la infraestructura o de los sistemas de integración.

Solución:

El analista de sistemas entrevista activamente a arquitectos, DevOps, QA, integradores:

• Determina los stacks tecnológicos, las dependencias empresariales e infrastructurales.
• Alinea los requisitos con los principios arquitectónicos: SLA, resiliencia, escalabilidad, restricciones de licencias o seguridad.
• Registra y valida los compromisos entre las capacidades y los deseos del negocio.
• Aplica enfoques de “Análisis basado en escenarios” y “Requisitos no funcionales”.

Características clave:

• Registro temprano de limitaciones y dependencias con todos los responsables.
• Documentación de compromisos y limitaciones implícitas.
• Comparación constante de las soluciones del proyecto con la arquitectura de la empresa.

Preguntas engañosas.

¿Se pueden ignorar las limitaciones técnicas implícitas si no se dicen directamente?

Correcto: No. Las limitaciones técnicas implícitas (por ejemplo, tiempos de espera en la integración, límite de tamaño de mensaje) siempre requieren ser trabajadas y documentadas, incluso si no se expresan claramente.

¿Debería el analista participar en llamadas/talleres arquitectónicos?

Correcto: Sí, el analista de sistemas es un vínculo entre el negocio y los arquitectos, transmite los requisitos a ambas partes y registra las decisiones.

¿Es suficiente recopilar solo los requisitos empresariales y no analizar las limitaciones heredadas?

Correcto: No es suficiente. El código heredado, licencias, integraciones (legacy) a veces dictan más limitaciones que los requisitos explícitamente establecidos.

Errores comunes y anti-patrones

• Subestimar las limitaciones ocultas y las dependencias de los sistemas antiguos.
• Ignorar las reglas de arquitectura “no escritas”.
• Fijar solo la parte empresarial sin tener en cuenta la viabilidad técnica.

Ejemplo de la vida real

Caso negativo: El analista registró la integración según el proceso empresarial, pero no preguntó sobre las limitaciones en la velocidad de transmisión de datos en la interfaz.

Pros: Implementación rápida de la especificación. Contras: El sistema no soportó la carga, el negocio perdió dinero y tiempo.

Caso positivo: El analista participó en sesiones arquitectónicas, identificó limitaciones (máximo de hilos = 100, integración 1 vez cada 10 segundos), y acordó con el negocio límites restrictivos.

Pros: Solución efectiva, integración estable. Contras: Se tuvo que recortar funcionalidad de manera compromisoria y justificarlo al cliente.