Sobre este programa
Antes de escribir una sola línea de código, alguien tiene que entender qué problema real se está resolviendo. Eso no es trivial: los equipos suelen confundir síntomas con causas, y los usuarios no siempre saben articular lo que necesitan.
Qué se hace en esta etapa
Se realizan entrevistas estructuradas con stakeholders, revisión de procesos existentes y análisis de documentación interna. El resultado es un documento de requisitos funcionales y no funcionales que sirve de contrato entre el área de negocio y el equipo técnico.
Los requisitos no funcionales -rendimiento, seguridad, escalabilidad- suelen ignorarse en esta fase y después aparecen como problemas en producción. Acá se trabajan desde el inicio.
Casos donde este trabajo marca diferencia
Sistemas de gestión interna con múltiples roles de usuario, integraciones con APIs externas, y productos con regulaciones legales específicas son los escenarios donde un análisis sólido evita meses de correcciones.
La duración varía según la complejidad del sistema y la cantidad de áreas involucradas.