Las entrevistas de business analyst testean cómo levantas requisitos, manejas stakeholders en desacuerdo, y conviertes la ambigüedad en algo que un equipo pueda construir. Aquí están las preguntas más comunes con respuestas modelo.
Cada pregunta viene con una respuesta modelo con la que puedes comparar la tuya.
1
¿Cuál es la diferencia entre requisitos funcionales y no funcionales?
Respuesta
Los requisitos funcionales describen qué debe hacer el sistema — un usuario puede resetear su contraseña, una factura se puede exportar. Los requisitos no funcionales describen qué tan bien debe hacerlo: tiempo de respuesta, usuarios concurrentes, disponibilidad, seguridad, accesibilidad. Los requisitos no funcionales son los que los equipos olvidan escribir y los más propensos a forzar una reescritura arquitectónica cuando se descubren tarde.
2
¿Cómo escribes una user story? ¿Qué son los criterios de aceptación?
Respuesta
Una user story sigue "como rol, quiero una acción, para lograr un beneficio" — la última cláusula importa más porque captura el por qué, lo que deja al equipo proponer mejores soluciones. Los criterios de aceptación definen terminado en términos testeables, a menudo en forma Given-When-Then cubriendo el camino feliz, casos límite, y errores. Una story sin criterios es una invitación para que tres personas la interpreten de tres formas.
3
¿Qué técnicas de levantamiento de requisitos usas?
Respuesta
Las entrevistas profundizan en la perspectiva de una persona, los workshops sacan a la superficie conflictos entre stakeholders temprano, la observación revela lo que la gente realmente hace en vez de lo que dice, el análisis de documentos captura reglas existentes, y los prototipos obtienen feedback concreto que la discusión abstracta nunca produce. La elección depende de qué tan bien se entiende el dominio — cuanto menos cierto el problema, más te apoyas en observación y prototipos.
4
¿Qué haces cuando los stakeholders dan requisitos conflictivos?
Respuesta
Haz el conflicto explícito en vez de elegir un lado calladamente: documenta ambas posiciones, el razonamiento detrás de cada una, y el trade-off. Luego junta a los stakeholders con datos — números de uso, costo, riesgo — y obtén una decisión de quien sea dueño del resultado. El modo de fallo es resolverlo en privado, porque el stakeholder que pierde lo descubre en la entrega y el trabajo se rechaza.
5
¿Qué es la priorización MoSCoW? Da un ejemplo.
Respuesta
MoSCoW ordena los requisitos en Must have, Should have, Could have, y Won't have esta vez. Los items Must son aquellos sin los cuales el release no tiene valor; Won't es la categoría más útil porque hace explícitas las exclusiones y detiene el scope creep silencioso. Una disciplina común es limitar Must a alrededor del sesenta por ciento de la capacidad para que haya espacio para lo que el descubrimiento inevitablemente revela.
6
¿Qué diagramas UML has usado? ¿Cuándo usas un use case versus un diagrama de secuencia?
Respuesta
Un diagrama de use case muestra qué actores interactúan con qué capacidades del sistema — bueno para conversaciones de alcance con stakeholders de negocio. Un diagrama de secuencia muestra los mensajes ordenados entre componentes a través del tiempo y está dirigido a desarrolladores diseñando una interacción. Los diagramas de actividad y BPMN están entre ellos para flujo de proceso, y un diagrama de estado es la herramienta correcta cuando una entidad tiene un ciclo de vida como una orden o un reclamo.
7
¿Qué son BRD, FRD y SRS? ¿En qué se diferencian?
Respuesta
Un BRD captura necesidades y objetivos de negocio en lenguaje de negocio — el por qué. Un FRD traduce eso a comportamientos específicos del sistema — el qué. Un SRS es la especificación completa incluyendo requisitos funcionales y no funcionales, restricciones, e interfaces, a menudo para una audiencia técnica. Muchos equipos Agile reemplazan los tres con un backlog de producto más documentos de soporte livianos, manteniendo specs formales solo donde el compliance lo requiere.
8
¿Cómo validas que los requisitos son claros para el equipo de desarrollo?
Respuesta
La señal más fuerte son las preguntas hechas durante el refinement — el silencio usualmente significa que el equipo no se ha involucrado en vez de que todo esté claro. Las verificaciones prácticas son hacer que un desarrollador repita la story con sus propias palabras, revisar los criterios de aceptación con QA antes de que empiece el desarrollo, y usar un prototipo o una sesión de example mapping para sacar a la superficie suposiciones ocultas. Cualquier cosa descubierta aquí es mucho más barata que después de la implementación.