Talently
Talently
Analista Funcional

Analista Funcional

Traduce las necesidades del negocio en requerimientos precisos que el equipo técnico puede implementar sin ambigüedad.

Un Analista Funcional es el puente entre el negocio y el equipo técnico. Su trabajo es comprender en profundidad los procesos, necesidades y objetivos del negocio para traducirlos en requerimientos funcionales claros, completos y verificables que guíen el diseño y desarrollo de soluciones tecnológicas. Identifica las brechas entre los procesos actuales y los deseados, documenta los flujos de negocio, y valida que las soluciones implementadas resuelven realmente el problema original. Trabaja en estrecha colaboración con stakeholders de negocio, PMs, arquitectos, desarrolladores y QA en todos los tipos de proyectos: nuevos desarrollos, implementaciones de sistemas y transformaciones de procesos.

RequerimientosBPMNCasos de usoHistorias de usuarioSQLModelado de procesos

Recluta al mejor Analista Funcional aquí

Empieza ahora

Responsabilidades Principales

  • •Elicitar requerimientos mediante entrevistas, talleres, observación y análisis de documentación existente con los stakeholders del negocio.
  • •Documentar los requerimientos funcionales y no funcionales con el nivel de detalle necesario para que el equipo técnico los implemente sin ambigüedad.
  • •Modelar los procesos de negocio actuales (AS-IS) y los procesos futuros (TO-BE) para comunicar el cambio y sus implicaciones.
  • •Validar con los stakeholders que los requerimientos documentados reflejan correctamente sus necesidades antes de que comience el desarrollo.
  • •Colaborar con el equipo de QA en la definición de criterios de aceptación y casos de prueba derivados de los requerimientos.
  • •Gestionar el ciclo de vida de los requerimientos: trazabilidad, control de cambios y verificación de que cada requerimiento fue implementado correctamente.

Habilidades Clave

Technical Skills

  • Modelado de procesos con BPMN 2.0 para documentar flujos de negocio AS-IS y TO-BE de forma estandarizada
  • Redacción de requerimientos funcionales, historias de usuario y criterios de aceptación con el nivel de precisión adecuado al contexto
  • Casos de uso y diagramas UML (actividad, secuencia, casos de uso) para documentar la interacción entre actores y el sistema
  • SQL básico para consultas de análisis de datos que soporten el levantamiento de requerimientos y la validación de implementaciones
  • Herramientas de gestión de requerimientos: Confluence, JIRA, Azure DevOps o herramientas especializadas como Jama o IBM DOORS
  • Técnicas de elicitación: entrevistas estructuradas, talleres de requerimientos, prototipado, análisis de documentos y observación directa

Soft Skills

  • Escucha activa para entender las necesidades reales detrás de las soluciones que los stakeholders proponen
  • Capacidad de hacer las preguntas incómodas que revelan supuestos no documentados o contradicciones entre requerimientos
  • Pensamiento analítico para descomponer procesos complejos en sus componentes y flujos alternativos
  • Comunicación precisa y adaptativa: el mismo requerimiento debe comunicarse de forma distinta al CEO, al desarrollador y al usuario final
  • Neutralidad para facilitar la reconciliación de requerimientos conflictivos entre stakeholders con intereses distintos
  • Persistencia para obtener los detalles necesarios de stakeholders con poco tiempo disponible sin generar fricción

Casos de uso reales

Contexto

El levantamiento de requerimientos es la fase más crítica de cualquier proyecto. Los requerimientos mal levantados producen soluciones que no resuelven el problema real del negocio.

Ejemplos reales

  • Talleres de requerimientos con usuarios clave de cada área impactada por el nuevo sistema
  • Entrevistas en profundidad con el process owner para entender los objetivos de negocio detrás de la solicitud
  • Análisis de los procesos actuales identificando ineficiencias, excepciones y variaciones no documentadas
  • Prototipado de baja fidelidad para validar el entendimiento de los requerimientos antes de documentarlos formalmente

Contexto

En entornos ágiles, el analista funcional colabora con el Product Owner para mantener un backlog bien refinado con historias de usuario que el equipo puede implementar en el siguiente sprint.

Ejemplos reales

  • Redacción de historias de usuario con criterios de aceptación testables usando el formato Gherkin
  • Sesiones de refinement con el equipo para aclarar dudas y descomponer historias complejas
  • Gestión de las dependencias entre historias de usuario para garantizar una secuencia de implementación coherente
  • Validación de que las historias implementadas cumplen los criterios de aceptación antes de cerrarlas

Contexto

En proyectos de transformación o implementación de sistemas, entender el proceso actual es el punto de partida para diseñar el proceso futuro y comunicar el cambio a los afectados.

Ejemplos reales

  • Documentación del proceso AS-IS mediante BPMN con entrevistas y observación directa del trabajo real
  • Identificación de los pain points y las ineficiencias del proceso actual con datos de frecuencia e impacto
  • Diseño del proceso TO-BE con el negocio considerando las capacidades del nuevo sistema
  • Análisis de brechas que identifica los cambios de proceso, tecnología y personas necesarios para la transición

Contexto

Cuando se modifican sistemas en producción, el analista funcional evalúa cuántos procesos, usuarios e integraciones se ven afectados para dimensionar correctamente el proyecto.

Ejemplos reales

  • Matriz de trazabilidad que mapea los requerimientos con los módulos del sistema afectados
  • Análisis del impacto de un cambio de modelo de datos en los reportes, integraciones y procesos dependientes
  • Identificación de los usuarios y perfiles que requieren reentrenamiento ante un cambio de proceso
  • Documentación de los casos de regresión que deben incluirse en el plan de testing por el cambio

Contexto

El analista funcional cierra el ciclo entre el requerimiento y la implementación verificando que lo que se construyó resuelve lo que el negocio pidió.

Ejemplos reales

  • Revisión de la implementación contra los criterios de aceptación documentados antes del UAT
  • Facilitar el UAT con los usuarios de negocio asegurando que prueban los escenarios críticos
  • Documentación de las desviaciones entre lo implementado y lo requerido con su impacto en el negocio
  • Gestión de los defectos funcionales identificados en el UAT hasta su resolución y reverificación

Preguntas básicas

Los stakeholders frecuentemente proponen soluciones en lugar de describir problemas. Técnica del 'por qué' iterativo: preguntar por qué necesitan lo que piden hasta llegar al objetivo de negocio subyacente. Observar el proceso real en lugar de solo escuchar la descripción del stakeholder: lo que la gente hace frecuentemente difiere de lo que dice que hace. Contrastar con otros stakeholders del mismo proceso para identificar discrepancias. El requerimiento real raramente es la primera cosa que el stakeholder menciona en la primera reunión.
Un requerimiento funcional describe qué debe hacer el sistema: 'el sistema debe enviar un email de confirmación al usuario cuando complete el registro'. Un requerimiento no funcional describe cómo debe hacerlo: rendimiento, seguridad, disponibilidad, usabilidad. Los no funcionales son frecuentemente más difíciles de elicitar porque los stakeholders los dan por asumidos. Ambos son igualmente importantes: una funcionalidad implementada que tarda 30 segundos en responder puede ser inaceptable aunque funcione correctamente.
Primero, documentar ambos requerimientos con claridad y confirmar con cada stakeholder que los entendiste correctamente. Luego, facilitar una conversación conjunta donde ambos expliquen el objetivo de negocio detrás de su requerimiento, no la solución técnica que proponen. Frecuentemente, los requerimientos aparentemente contradictorios tienen objetivos compatibles que admiten una solución que satisface a ambos. Si el conflicto es real, presentarlo al PM o al sponsor con el impacto de cada alternativa para que se tome la decisión de prioridad.
Independent: puede implementarse sin depender de otras historias. Negotiable: el cómo se implementa es abierto a discusión. Valuable: aporta valor observable al usuario o al negocio. Estimable: el equipo tiene suficiente información para estimarla. Small: cabe en un sprint sin necesidad de dividirse durante la ejecución. Testable: tiene criterios de aceptación verificables. Una historia que falla en alguno de estos criterios generará problemas durante el sprint: bloqueos por dependencias, debates durante la implementación, o desacuerdos sobre si está completa.
Priorizar los requerimientos que corresponden a los procesos críticos del negocio y a las funcionalidades que el equipo de desarrollo necesita para comenzar. Los requerimientos del camino crítico del proyecto van primero. Los requerimientos de casos de uso frecuentes son más urgentes que los de excepciones. Los requerimientos con mayor impacto en la arquitectura de la solución deben clarificarse temprano para evitar retrabajo técnico costoso. El objetivo no es documentar todo desde el inicio sino tener suficiente claridad para que el equipo pueda comenzar sin retrabajo.
Revisar la implementación contra cada criterio de aceptación documentado en el requerimiento. Ejecutar los casos de prueba derivados del requerimiento, incluyendo los flujos alternativos y los de error, no solo el flujo principal. Si el requerimiento incluye reglas de negocio específicas, verificar con datos reales que la lógica implementada produce los resultados esperados. En caso de duda, validar con el stakeholder que solicitó el requerimiento que el resultado final resuelve su necesidad original.
Para el negocio: descripción narrativa del proceso en lenguaje de negocio, actores involucrados, entradas y salidas del proceso, y los casos de excepción más frecuentes. Para el equipo técnico: diagrama BPMN con los flujos de trabajo y las decisiones, las reglas de negocio que gobiernan cada decisión, los sistemas involucrados en cada paso, y los datos que se crean o modifican. La documentación dual no significa duplicar: el mismo diagrama BPMN sirve a ambas audiencias con distintos niveles de anotación.
Preparar las sesiones al máximo para aprovechar cada minuto disponible: enviar las preguntas por adelantado, presentar un borrador del proceso para corregir en lugar de empezar desde cero, y hacer las sesiones focalizadas en las decisiones que solo ese stakeholder puede tomar. Para el resto: complementar con análisis de documentación existente, observación directa del proceso, entrevistas con usuarios operativos que hacen el trabajo real, y revisión de datos del sistema actual. Adaptar el formato de validación al stakeholder: algunos prefieren revisar documentos por su cuenta y dar feedback escrito antes que reunirse.

Preguntas técnicas

Gherkin usa la estructura Given-When-Then: Given (el contexto o estado inicial del sistema), When (la acción del usuario o el evento), Then (el resultado esperado observable). Ejemplo: Given que el usuario está autenticado y tiene saldo suficiente, When envía una transferencia de 100 euros a otro usuario, Then el saldo del remitente se reduce en 100 euros, el saldo del receptor aumenta en 100 euros, y ambos reciben una notificación de confirmación. Cada escenario debe ser independiente, específico y verificable sin ambigüedad. Los escenarios negativos son tan importantes como los positivos: Given que el usuario no tiene saldo suficiente, When intenta enviar 100 euros, Then recibe un mensaje de error específico y el saldo no cambia.
En BPMN, cada actor o sistema se representa en un lane dentro de un pool. Los flujos de actividad se diagraman con tareas (rectángulos redondeados), gateways para decisiones (rombos), y eventos de inicio y fin. Los flujos entre actores son message flows (líneas punteadas), no sequence flows. Documentar solo el nivel de detalle necesario para el propósito: un diagrama de alto nivel para comunicar el proceso al management, un diagrama detallado con reglas de negocio en los gateways para el equipo de desarrollo. Los subprocesos agrupan actividades relacionadas para mantener el diagrama principal legible. El error más frecuente es modelar el diagrama demasiado detallado desde el inicio, perdiendo la visión global.
La matriz de trazabilidad mapea cada requerimiento con su origen (el objetivo de negocio que lo justifica), su implementación (el componente del sistema o la historia de usuario que lo realiza), y su verificación (los casos de prueba que lo validan). Su valor: permite evaluar el impacto de un cambio de requerimiento (qué componentes y tests se afectan), verificar que todos los requerimientos tienen cobertura de testing, y confirmar en el cierre del proyecto que todos los requerimientos fueron implementados. En proyectos regulados o con contratos detallados, la trazabilidad es un entregable formal. En proyectos ágiles más ligeros, una versión simplificada sigue siendo valiosa para gestionar el cambio.
Las reglas de negocio son las políticas y condiciones que gobiernan el comportamiento del proceso. Para un proceso de crédito: técnica de tablas de decisión para capturar todas las combinaciones de condiciones y sus resultados (score mayor a X y ingresos mayores a Y → aprobado, en cualquier otro caso → rechazado o revisión manual). Validar cada regla con el responsable de negocio porque frecuentemente hay excepciones no documentadas. Verificar si las reglas tienen excepciones temporales o por perfil de cliente. Documentar la fuente de cada regla (política interna, regulación legal) para gestionar los cambios futuros correctamente.
Preparar una agenda estructurada con tiempos para cada tema. Comenzar con el objetivo común del proceso antes de entrar en los detalles. Usar técnicas de facilitación visual: diagramar el proceso en tiempo real en una pizarra o herramienta colaborativa para que todos vean el mismo modelo mientras se discute. Gestionar las personas que dominan la conversación: hacer preguntas directas a los participantes más callados. Documentar los acuerdos y los puntos abiertos en tiempo real para que todos salgan con el mismo entendimiento. Al final del taller, leer en voz alta los acuerdos y los puntos abiertos para confirmación explícita antes de cerrar.
Construir o consultar la matriz de trazabilidad para identificar todos los requerimientos afectados por esa regla. Revisar el código o la configuración del sistema para mapear dónde está implementada esa regla: puede estar en múltiples lugares si no fue centralizada. Identificar los reportes que usan datos generados bajo la regla actual: cambiar la regla puede afectar la comparabilidad histórica de los reportes. Evaluar el impacto en los datos históricos: ¿se aplica la nueva regla retroactivamente o solo a datos nuevos? Documentar el análisis de impacto completo para que el equipo técnico pueda estimar el esfuerzo con toda la información necesaria.
Documentar: los eventos o triggers que inician el intercambio de datos, la dirección del flujo (unidireccional o bidireccional), el formato y la estructura de los datos intercambiados con el mapeo de campos entre ambos sistemas, la frecuencia o latencia requerida (en tiempo real, batch diario), el comportamiento ante errores (reintento, notificación, almacenamiento temporal), y los volúmenes esperados. El mapeo de campos es frecuentemente el punto más complejo: el mismo concepto tiene nombres y formatos distintos en cada sistema. Una tabla de mapeo con el campo origen, la transformación si la hay, y el campo destino es el artefacto más valioso para el equipo técnico.
Documentar el cambio solicitado con precisión, incluyendo el requerimiento original y la nueva versión. Analizar el impacto: qué partes del sistema ya implementadas deben modificarse, qué tests deben reescribirse, cuál es el esfuerzo estimado y cuál es el impacto en el cronograma. Presentar el análisis al PM para gestión formal del cambio. Si el cambio se aprueba, actualizar la documentación del requerimiento, la matriz de trazabilidad y los casos de prueba afectados. Los cambios post-UAT son los más costosos del ciclo de vida: la documentación precisa del requerimiento original es lo que permite cuantificar ese costo con datos.

Preguntas avanzadas

Comenzar con el modelo operativo deseado a nivel estratégico antes de bajar al detalle de cada proceso. Identificar los procesos transversales que cruzan múltiples áreas: son los más complejos y los que generan más conflictos de requerimientos. Para cada proceso, usar una combinación de talleres con múltiples áreas (para los procesos transversales) y entrevistas individuales (para los procesos específicos de cada área). Mapear explícitamente las dependencias entre requerimientos de distintas áreas. Establecer un comité de alineación con un representante de cada área para resolver los conflictos de requerimientos a nivel de proceso antes de llevarlos al equipo técnico.
Revisión estructurada de los requerimientos con una checklist: ¿es completo (no hay información faltante)? ¿es consistente (no contradice otros requerimientos)? ¿es verificable (puede comprobarse si fue implementado)? ¿es viable (el equipo técnico puede implementarlo con los recursos disponibles)? Inspección formal con el equipo técnico para detectar ambigüedades desde su perspectiva: lo que es claro para el analista puede ser ambiguo para el desarrollador. Prototipado o mockup para validar la comprensión con los stakeholders antes del desarrollo. La inversión en revisión de requerimientos antes del desarrollo es sistemáticamente más barata que el retrabajo técnico por requerimientos incompletos.
Los requerimientos de sistemas de ML tienen características distintas a los de software determinista. En lugar de 'el sistema debe hacer X para la entrada Y', los requerimientos describen: el objetivo de negocio que el modelo debe optimizar, las métricas de éxito aceptables (precisión mínima, tasa de falsos positivos máxima), los datos necesarios para el entrenamiento y la validación, los criterios de monitoreo del modelo en producción, y los umbrales de intervención humana para casos donde la confianza del modelo es baja. Los criterios de aceptación incluyen tanto el rendimiento técnico del modelo como su impacto medible en la métrica de negocio que justificó su desarrollo.
Establecer un repositorio centralizado de requerimientos accesible para todos los equipos del programa. Definir una jerarquía de requerimientos: objetivos de negocio del programa, epics por área funcional, historias de usuario por equipo. La trazabilidad debe funcionar verticalmente (de objetivo de negocio a historia a test) y horizontalmente (identificar qué historias de distintos equipos dependen del mismo requerimiento). Proceso de change impact analysis: cualquier cambio de requerimiento debe evaluarse contra todos los proyectos que lo implementan. Un analista funcional por dominio de negocio, con un coordinador de requerimientos a nivel de programa para gestionar las interdependencias.
Volver al objetivo de negocio que justificó el requerimiento, no solo al texto del requerimiento documentado. Mapear cómo la solución propuesta resuelve ese objetivo en la práctica con ejemplos concretos del proceso real. Identificar los casos de uso que el stakeholder realizará con la solución: ¿puede el usuario completar su tarea con menos pasos? ¿el proceso es más rápido, más fiable o menos propenso a error? Si la solución técnica es correcta según el texto del requerimiento pero no resuelve el problema de negocio, el requerimiento original estaba mal especificado: mejor detectarlo antes de implementar que después del UAT.
La transición no es binaria: el nivel de documentación adecuado depende del tipo de proyecto, el perfil del cliente y los requisitos de compliance. Los proyectos regulados con auditorías requieren documentación más formal que los proyectos internos. La documentación just-in-time no significa documentación insuficiente: significa documentar lo necesario en el momento que se necesita, no todo al inicio del proyecto. El analista funcional en un modelo ágil sigue siendo responsable de la claridad y completitud de los requerimientos; cambia el formato (historias de usuario en lugar de especificaciones funcionales extensas) y el timing (refinement continuo en lugar de una fase de análisis al inicio). La calidad del requerimiento sigue siendo el estándar, independientemente del formato.

Errores comunes en entrevistas

Un analista que solo transcribe lo que los stakeholders dicen sin cuestionar, validar y completar los requerimientos no está haciendo análisis funcional. Los stakeholders no siempre saben lo que necesitan, no siempre lo pueden articular claramente, y frecuentemente omiten casos de excepción que son críticos para el sistema. El valor del analista está en su capacidad de revelar lo que no está dicho.
Si el analista no puede explicar claramente qué cambia entre el proceso actual y el futuro, no ha completado el análisis. El TO-BE no es solo el AS-IS con un sistema nuevo: implica cambios en quién hace qué, cuándo, con qué información y con qué reglas de negocio. Los entrevistadores preguntan específicamente por los casos de excepción y las diferencias entre ambos procesos.
Una historia de usuario sin criterios de aceptación precisos es un requerimiento incompleto. Los desarrolladores no pueden estimar con confianza, QA no puede verificar y el stakeholder no puede aceptar el resultado. Los entrevistadores piden al candidato que escriba los criterios de aceptación de un requerimiento simple para evaluar si sabe hacerlos concretos y verificables.
Los requerimientos no funcionales son frecuentemente los que determinan la viabilidad técnica y el costo real de la solución. Un análisis que solo documenta los requerimientos funcionales produce soluciones que técnicamente funcionan pero que son inaceptablemente lentas, inseguras o no disponibles cuando el negocio las necesita.
Los requerimientos cambian en todos los proyectos. Un analista que no tiene un proceso claro de gestión del cambio (cómo se solicita, cómo se evalúa el impacto, cómo se aprueba y cómo se actualiza la documentación) produce proyectos con scope creep no controlado y documentación desactualizada que genera confusión en el equipo técnico.
Aunque los roles se superponen en algunos contextos, tienen responsabilidades distintas. El Product Owner tiene autoridad para priorizar el backlog y representa la visión del producto. El Business Analyst tiene un foco más estratégico en el impacto de negocio. El Analista Funcional se especializa en la documentación precisa de requerimientos y procesos. Un candidato que no puede articular dónde está su responsabilidad específica genera dudas sobre su claridad de rol.