Inicio › Business Analyst › Requirements

Preguntas de práctica Business Analyst: Requirements

Requirements vale 17% del examen Salesforce Certified Business Analyst. Cubre priorización, trazabilidad, requisitos no funcionales y control de cambios. Resuelve estas 9 preguntas gratis y abre cada respuesta para ver por qué cada opción es correcta o incorrecta.

Para un nuevo proceso de gestión de casos en Service Cloud en una empresa de servicios públicos, los stakeholders plantean dos necesidades: todas las páginas del portal deben cargar en 2 segundos o menos, y todo inicio de sesión debe exigir autenticación multifactor. ¿Cómo debe categorizar el BA estos dos requisitos?

Ambos son requisitos funcionales, ya que indican lo que el sistema debe hacer.
El tiempo de carga de página es un requisito técnico, mientras que la exigencia de MFA es un requisito de negocio.
Ambos son requisitos no funcionales, ya que expresan atributos de calidad de rendimiento y seguridad, no comportamientos específicos del sistema.
El tiempo de carga es no funcional, mientras que la exigencia de MFA es funcional porque el usuario realiza una acción.

Ver respuesta

Respuesta: C

A. Ambos son requisitos funcionales, ya que indican lo que el sistema debe hacer.Incorrecta. Los requisitos funcionales describen funciones o comportamientos específicos (p. ej., 'crear un caso al enviar el formulario'). El tiempo de carga y el MFA son restricciones de calidad y seguridad, por lo que son no funcionales.

B. El tiempo de carga de página es un requisito técnico, mientras que la exigencia de MFA es un requisito de negocio.Incorrecta. El tiempo de carga es un requisito de rendimiento y el MFA es un requisito de seguridad; ambos son no funcionales. No se dividen entre una categoría técnica y una de negocio.

C. Ambos son requisitos no funcionales, ya que expresan atributos de calidad de rendimiento y seguridad, no comportamientos específicos del sistema. ✓Correcta. Los NFR describen qué tan bien funciona el sistema, no qué funciones ofrece. El tiempo de carga de página (rendimiento) y el MFA (seguridad) son NFR clásicos que aplican a todo el sistema.

D. El tiempo de carga es no funcional, mientras que la exigencia de MFA es funcional porque el usuario realiza una acción.Incorrecta. El MFA es una restricción de seguridad definida a nivel de sistema u org. Define cómo debe comportarse la autenticación, no una función específica, por lo que también es no funcional.

Por qué: Los requisitos no funcionales describen atributos de calidad como rendimiento, seguridad, usabilidad y escalabilidad, no comportamientos específicos. Una carga de página de 2 segundos es un NFR de rendimiento; el MFA obligatorio es un NFR de seguridad. Clasificar bien los requisitos ayuda a dirigirlos a los equipos técnicos correctos.

Una implementación de Salesforce en una empresa de equipo para exteriores tiene 25 historias de usuario. En el sprint planning, el equipo estima en story points, pero tres historias se han discutido 20 minutos cada una sin llegar a una estimación acordada. ¿Cuál es la causa MÁS probable y cómo debe responder el BA?

Los desarrolladores necesitan más capacitación técnica antes de poder dimensionar historias complejas.
Las historias probablemente no cumplen el criterio Estimable de INVEST: pueden contener requisitos ambiguos, dependencias técnicas desconocidas o demasiado alcance para dimensionarlas con confianza. El BA debe aclararlas o dividirlas antes de devolverlas a estimación.
Asignar un valor alto de story points a las tres historias y seguir adelante para proteger la velocidad del sprint planning.
Eliminar definitivamente las tres historias del backlog porque no se pueden estimar.

Ver respuesta

Respuesta: B

A. Los desarrolladores necesitan más capacitación técnica antes de poder dimensionar historias complejas.Incorrecta. Las brechas de habilidades pueden afectar las estimaciones, pero la causa habitual son requisitos poco claros, no falta de capacitación. El BA debe revisar primero la calidad de los requisitos.

B. Las historias probablemente no cumplen el criterio Estimable de INVEST: pueden contener requisitos ambiguos, dependencias técnicas desconocidas o demasiado alcance para dimensionarlas con confianza. El BA debe aclararlas o dividirlas antes de devolverlas a estimación. ✓Correcta. Una historia que el equipo no puede dimensionar suele incumplir el criterio Estimable: requisitos ambiguos, enfoque poco claro o tamaño excesivo. El BA trabaja con el product owner y el equipo para resolver la ambigüedad, descubrir dependencias o dividir la historia en piezas más pequeñas y claras, y luego se vuelve a estimar.

C. Asignar un valor alto de story points a las tres historias y seguir adelante para proteger la velocidad del sprint planning.Incorrecta. Inflar las estimaciones distorsiona la capacidad del sprint y solo pospone el problema real. Las historias no estimables necesitan aclararse o dividirse antes de comprometerse.

D. Eliminar definitivamente las tres historias del backlog porque no se pueden estimar.Incorrecta. Que sea difícil estimar indica que hace falta refinamiento, no eliminación. Borrar las historias implica el riesgo de perder necesidades de negocio reales.

Por qué: La 'E' de INVEST significa Estimable. Las historias que no se pueden estimar tras una discusión larga casi siempre tienen problemas de requisitos: redacción vaga, alcance poco claro, enfoque técnico desconocido o dependencias ocultas. El BA aclara, saca a la luz las dependencias o divide la historia en lugar de adivinar un número o descartarla.

Un requisito en un proyecto de Salesforce de un fabricante de electrodomésticos dice: 'El sistema debe mejorar la experiencia del cliente.' El BA lo señala como de baja calidad. ¿Qué DOS deficiencias lo hacen inadecuado para desarrollo? (Elija 2)

Es vago: 'mejorar la experiencia del cliente' no es lo bastante preciso para diseñar, construir o probar una funcionalidad.
Impone una restricción técnica que requiere una revisión de seguridad adicional.
No es medible: no existe una métrica o criterio para que el equipo juzgue si la experiencia del cliente mejoró.
No indica qué producto de nube de Salesforce se usará para abordar la experiencia del cliente.

Ver respuesta

Respuesta: A, C

A. Es vago: 'mejorar la experiencia del cliente' no es lo bastante preciso para diseñar, construir o probar una funcionalidad. ✓Correcta. La vaguedad es la falla principal: la frase podría significar resolver casos más rápido, mejor autoservicio, comunicación más personalizada o muchísimas otras cosas. Sin especificidad, no se puede construir ni verificar nada.

B. Impone una restricción técnica que requiere una revisión de seguridad adicional.Incorrecta. El requisito no contiene ninguna restricción técnica ni aspecto de seguridad; esta deficiencia simplemente no aplica.

C. No es medible: no existe una métrica o criterio para que el equipo juzgue si la experiencia del cliente mejoró. ✓Correcta. Sin un criterio medible (p. ej., 'subir el CSAT de 3.8 a 4.2' o 'reducir 20% el tiempo promedio de resolución de casos'), nadie puede confirmar tras la salida a producción que la experiencia mejoró.

D. No indica qué producto de nube de Salesforce se usará para abordar la experiencia del cliente.Incorrecta. Elegir una nube de Salesforce es una decisión de diseño de la solución, no una deficiencia del requisito. Los requisitos expresan necesidades de negocio; el diseño decide qué producto las cubre.

Por qué: Un buen requisito es específico (indica exactamente qué debe hacer el sistema) y medible (tiene un criterio para verificar el éxito). 'Mejorar la experiencia del cliente' falla en ambos, así que el BA debe volver con el stakeholder para definir una mejora específica y medible.

Una empresa de equipo para exteriores está lanzando Salesforce Field Service. El BA reunió 80 requisitos de 12 grupos de stakeholders, y el product owner le pide explicar en qué se diferencia un 'requisito de negocio' de un 'requisito funcional' para que el equipo categorice correctamente el backlog. ¿Qué explicación es correcta?

Los requisitos de negocio describen comportamientos específicos del sistema; los requisitos funcionales describen los objetivos de alto nivel de la organización.
Los requisitos de negocio describen los objetivos y motivaciones organizacionales de alto nivel del proyecto; los requisitos funcionales describen los comportamientos o funciones específicos que el sistema debe ofrecer para alcanzar esos objetivos.
Los requisitos de negocio y los funcionales se escriben como historias de usuario y son intercambiables a nivel de backlog.
Los requisitos funcionales describen lo que los usuarios quieren hacer; los requisitos de negocio describen la implementación técnica necesaria para cubrir esas necesidades.

Ver respuesta

Respuesta: B

A. Los requisitos de negocio describen comportamientos específicos del sistema; los requisitos funcionales describen los objetivos de alto nivel de la organización.Incorrecta. Invierte las definiciones. Los requisitos de negocio son los objetivos y motivaciones (el 'por qué'); los funcionales son los comportamientos del sistema (el 'qué').

B. Los requisitos de negocio describen los objetivos y motivaciones organizacionales de alto nivel del proyecto; los requisitos funcionales describen los comportamientos o funciones específicos que el sistema debe ofrecer para alcanzar esos objetivos. ✓Correcta. Los requisitos de negocio responden '¿por qué hacemos esto?' (p. ej., reducir 30% el tiempo de programación de técnicos). Los funcionales responden '¿qué debe hacer el sistema?' (p. ej., asignar automáticamente al técnico disponible más cercano al crearse una orden de trabajo).

C. Los requisitos de negocio y los funcionales se escriben como historias de usuario y son intercambiables a nivel de backlog.Incorrecta. Los dos tipos son distintos. Los requisitos de negocio expresan objetivos organizacionales y no se escriben como historias de usuario; los funcionales pueden convertirse en historias, pero los tipos no son intercambiables.

D. Los requisitos funcionales describen lo que los usuarios quieren hacer; los requisitos de negocio describen la implementación técnica necesaria para cubrir esas necesidades.Incorrecta. Los requisitos funcionales describen lo que el sistema debe hacer, no lo que los usuarios quieren (eso es una necesidad del usuario). Los detalles de implementación técnica pertenecen a los requisitos técnicos/de sistema, no a los de negocio.

Por qué: Los requisitos de negocio capturan los objetivos y motivaciones de la organización: por qué existe el proyecto. Los requisitos funcionales capturan los comportamientos específicos del sistema que cumplen esos objetivos: qué debe hacer el sistema. Ambos se distinguen de los requisitos no funcionales (qué tan bien funciona) y de los técnicos (cómo se construye). Clasificar correctamente dirige cada elemento al equipo y nivel de detalle adecuados.

Al documentar requisitos para una implementación de Sales Cloud CPQ en un distribuidor de equipo industrial, el BA escucha a un stakeholder decir: 'Necesitamos que el sistema sea rápido.' ¿Cómo debe tratar el BA este requisito?

Registrar 'el sistema debe ser rápido' como requisito no funcional y continuar.
Pedir al stakeholder que defina 'rápido' en términos medibles, como un tiempo objetivo de carga de página o de generación de cotizaciones, y luego registrarlo como requisito no funcional de rendimiento.
Agregarlo al backlog como historia de usuario: 'Como usuario, quiero que el sistema sea rápido, para poder trabajar de forma eficiente.'
Ignorarlo, porque la optimización del rendimiento le corresponde al equipo de desarrollo y no puede capturarse como requisito de negocio.

Ver respuesta

Respuesta: B

A. Registrar 'el sistema debe ser rápido' como requisito no funcional y continuar.Incorrecta. Registrar una afirmación vaga tal cual no da nada accionable a los desarrolladores y no se puede probar. Un NFR necesita un umbral medible.

B. Pedir al stakeholder que defina 'rápido' en términos medibles, como un tiempo objetivo de carga de página o de generación de cotizaciones, y luego registrarlo como requisito no funcional de rendimiento. ✓Correcta. 'Rápido' no significa nada sin un umbral. El BA pregunta qué tiempo de respuesta es aceptable y cuál no; la respuesta (p. ej., 'las páginas de cotización cargan en 2 segundos') se convierte en el NFR de rendimiento medible.

C. Agregarlo al backlog como historia de usuario: 'Como usuario, quiero que el sistema sea rápido, para poder trabajar de forma eficiente.'Incorrecta. Poner una necesidad no medible en formato de historia de usuario no la mejora; la historia sigue sin criterios de aceptación comprobables. Primero debe hacerse medible.

D. Ignorarlo, porque la optimización del rendimiento le corresponde al equipo de desarrollo y no puede capturarse como requisito de negocio.Incorrecta. El rendimiento es un NFR legítimo que el BA debe capturar con aportes de los stakeholders. Ignorarlo arriesga un sistema lento, baja adopción y stakeholders insatisfechos.

Por qué: Ante afirmaciones vagas como 'rápido', 'fácil de usar' o 'flexible', el BA hace preguntas de seguimiento hasta obtener una especificación medible y comprobable. 'Rápido' necesita un número (p. ej., 'las cotizaciones se generan en 3 segundos') antes de documentarse como NFR y probarse en UAT. Los requisitos no comprobables nunca deben aprobarse en la línea base.

Un BA de una empresa de calzado revisa la documentación de un proyecto anterior que usó el marco V2MOM para la alineación organizacional, y se lo explica a un colega nuevo. ¿Qué descripción explica con MAYOR precisión cómo se relaciona V2MOM con la documentación de requisitos?

V2MOM es una herramienta de configuración de Salesforce que genera requisitos automáticamente a partir de datos de procesos de negocio.
V2MOM (Vision, Values, Methods, Obstacles, Measures) es el marco de alineación organizacional de Salesforce. Los BA lo usan para asegurar que los requisitos estén anclados en la visión y las prioridades estratégicas de la organización, no solo en solicitudes tácticas de funcionalidades.
V2MOM es una plantilla de historias de usuario que reemplaza el formato estándar 'Como / Quiero / Para que'.
V2MOM se usa en UAT para confirmar que la solución entregada cumple con todos los requisitos documentados.

Ver respuesta

Respuesta: B

A. V2MOM es una herramienta de configuración de Salesforce que genera requisitos automáticamente a partir de datos de procesos de negocio.Incorrecta. V2MOM no es una herramienta de configuración; es un marco de planeación de negocio y definición de objetivos.

B. V2MOM (Vision, Values, Methods, Obstacles, Measures) es el marco de alineación organizacional de Salesforce. Los BA lo usan para asegurar que los requisitos estén anclados en la visión y las prioridades estratégicas de la organización, no solo en solicitudes tácticas de funcionalidades. ✓Correcta. Vision (lo que queremos), Values (lo que importa), Methods (cómo lo lograremos), Obstacles (qué podría impedirlo), Measures (cómo sabremos que lo logramos). Los BA lo usan para que los requisitos se tracen a la estrategia en lugar de volverse listas de deseos desconectadas.

C. V2MOM es una plantilla de historias de usuario que reemplaza el formato estándar 'Como / Quiero / Para que'.Incorrecta. Las historias de usuario usan 'Como / Quiero / Para que'. V2MOM opera a nivel de estrategia organizacional, muy por encima de las historias individuales.

D. V2MOM se usa en UAT para confirmar que la solución entregada cumple con todos los requisitos documentados.Incorrecta. UAT se basa en criterios de aceptación, casos de prueba y la matriz de trazabilidad de requisitos, no en V2MOM.

Por qué: V2MOM (Vision, Values, Methods, Obstacles, Measures) es el marco de alineación de Salesforce. En el examen de BA, los BA lo usan para mantener los requisitos alineados con la visión y la estrategia de la organización. Los requisitos que no se pueden trazar a ningún elemento del V2MOM pueden indicar scope creep o peticiones tácticas que no sirven a los objetivos estratégicos. V2MOM aporta el 'por qué' por encima de los requisitos.

Una empresa de calzado está cerrando una implementación grande de Salesforce, y el BA quiere cerrar formalmente los requisitos. ¿Qué actividades forman parte del cierre de requisitos? (Elija 2)

Confirmar que la matriz de trazabilidad de requisitos está completa y muestra que cada requisito de negocio se entregó y se verificó con casos de prueba aprobados.
Archivar el backlog de requisitos y todos los documentos relacionados en el repositorio con control de versiones para referencia futura y auditoría.
Eliminar toda la documentación de requisitos de la herramienta de backlog para no confundir a proyectos futuros.
Entregar todas las historias de usuario sin terminar al siguiente equipo de desarrollo disponible sin priorizarlas.

Ver respuesta

Respuesta: A, B

A. Confirmar que la matriz de trazabilidad de requisitos está completa y muestra que cada requisito de negocio se entregó y se verificó con casos de prueba aprobados. ✓Correcta. Una RTM completa al cierre demuestra que cada requisito de negocio se entregó y se probó, confirmando que el alcance se cubrió por completo.

B. Archivar el backlog de requisitos y todos los documentos relacionados en el repositorio con control de versiones para referencia futura y auditoría. ✓Correcta. Archivar mantiene disponible el historial de requisitos para mejoras futuras que necesiten la línea base original, para auditorías o revisiones de cumplimiento y para lecciones aprendidas. Es un entregable estándar de cierre.

C. Eliminar toda la documentación de requisitos de la herramienta de backlog para no confundir a proyectos futuros.Incorrecta. Eliminar la documentación destruye un historial valioso que necesitarán los proyectos futuros que modifiquen estas funcionalidades. Debe archivarse.

D. Entregar todas las historias de usuario sin terminar al siguiente equipo de desarrollo disponible sin priorizarlas.Incorrecta. Las historias sin terminar deben revisarse, despriorizarse o pasarse formalmente a un backlog de mantenimiento posterior al lanzamiento con acuerdo de los stakeholders, no reasignarse a ciegas.

Por qué: El cierre de requisitos incluye (1) confirmar que la RTM está completa (cada requisito entregado y probado) para demostrar que se cubrió el alcance, y (2) archivar toda la documentación de requisitos en el repositorio con control de versiones. Juntas, aportan evidencia formal de cierre y preservan el conocimiento para mejoras futuras, auditorías y lecciones aprendidas.

Un BA de una empresa de equipo para exteriores está por entregar los requisitos terminados al equipo de desarrollo para el primer sprint. ¿Qué debe contener la entrega para que los desarrolladores empiecen de inmediato y construyan correctamente? (Elija 2)

Historias de usuario listas para el sprint, cada una con criterios de aceptación completos y específicos.
Todo el código fuente de proyectos anteriores como ejemplos de referencia para los desarrolladores.
Un documento breve de contexto que explique los objetivos de negocio detrás de las historias del sprint, para que los desarrolladores entiendan el 'por qué' de lo que construyen.
Una lista de todos los requisitos de fases futuras fuera del sprint actual, para que los desarrolladores diseñen pensando en la extensibilidad futura.

Ver respuesta

Respuesta: A, C

A. Historias de usuario listas para el sprint, cada una con criterios de aceptación completos y específicos. ✓Correcta. Las historias con criterios de aceptación completos son el artefacto central de la entrega del BA; le dicen al equipo exactamente qué construir y cómo luce 'terminado' para cada historia.

B. Todo el código fuente de proyectos anteriores como ejemplos de referencia para los desarrolladores.Incorrecta. El código antiguo puede ser una referencia técnica, pero no es un artefacto de entrega de requisitos ni un entregable del BA.

C. Un documento breve de contexto que explique los objetivos de negocio detrás de las historias del sprint, para que los desarrolladores entiendan el 'por qué' de lo que construyen. ✓Correcta. Saber por qué se necesita una funcionalidad ayuda a los desarrolladores a tomar decisiones técnicas alineadas con la intención del negocio, sobre todo cuando los criterios de aceptación dejan margen de interpretación.

D. Una lista de todos los requisitos de fases futuras fuera del sprint actual, para que los desarrolladores diseñen pensando en la extensibilidad futura.Incorrecta. Entregar ahora los requisitos de fases futuras fomenta la sobreingeniería. Los desarrolladores deben construir lo que necesita el sprint actual, no extender para un alcance futuro no confirmado.

Por qué: Una buena entrega del BA al equipo de desarrollo incluye (1) historias listas para el sprint con criterios de aceptación completos y específicos (qué construir y qué significa 'terminado') y (2) contexto de negocio que explique por qué importa el trabajo del sprint. Juntos permiten al equipo construir con precisión y tomar decisiones técnicas alineadas. Los requisitos futuros y el código antiguo no son elementos adecuados para la entrega.

Un proyecto de Sales Cloud en una tienda regional de bicicletas llegó a la aprobación formal (sign-off) de requisitos, y estos se mantienen bajo control de versiones en Confluence. Dos semanas después, un stakeholder solicita un nuevo campo en el objeto Account. ¿Qué pasos debe seguir el BA antes de modificar el documento de requisitos? (Elija 2)

Analizar el impacto del nuevo campo de Account en los procesos, informes e historias de usuario relacionados.
Editar de inmediato el documento de requisitos en Confluence para incluir el nuevo campo.
Canalizar el cambio mediante el proceso formal de solicitud de cambio y obtener la aprobación del patrocinador del proyecto o del comité de control de cambios antes de actualizar los requisitos.
Pedir a los desarrolladores que creen el nuevo campo de inmediato para demostrarle al stakeholder que el equipo responde rápido.

Ver respuesta

Respuesta: A, C

A. Analizar el impacto del nuevo campo de Account en los procesos, informes e historias de usuario relacionados. ✓Correcta. Un nuevo campo de Account puede afectar objetos relacionados, Validation Rules, flujos, informes e historias de usuario. Sin un análisis de impacto, el BA no puede explicar al equipo y al patrocinador el tamaño real del cambio.

B. Editar de inmediato el documento de requisitos en Confluence para incluir el nuevo campo.Incorrecta. Una línea base de requisitos versionada no se edita antes de revisar y aprobar el cambio; hacerlo se salta el control de cambios e introduce alcance no aprobado en el registro oficial.

C. Canalizar el cambio mediante el proceso formal de solicitud de cambio y obtener la aprobación del patrocinador del proyecto o del comité de control de cambios antes de actualizar los requisitos. ✓Correcta. Presentar una solicitud de cambio y obtener la aprobación del patrocinador o del comité garantiza que el cambio se evalúe, priorice y autorice antes de entrar al alcance.

D. Pedir a los desarrolladores que creen el nuevo campo de inmediato para demostrarle al stakeholder que el equipo responde rápido.Incorrecta. Construir un cambio no aprobado evade por completo el control de cambios. Los desarrolladores no deben trabajar en alcance no aprobado, por simple que parezca.

Por qué: Una vez aprobados los requisitos, cualquier cambio sigue un camino controlado: primero un análisis de impacto para ver todo lo que el cambio afecta y después una solicitud de cambio formal aprobada por el patrocinador o el comité de control de cambios. Solo entonces se actualiza la línea base de requisitos, lo que mantiene confiables el documento versionado y el alcance del proyecto.

Descubre si estás listo para aprobar

Haz el diagnóstico gratis de Business Analyst: 20 preguntas, sin cuenta. Después desbloquea las 180 preguntas, los exámenes de práctica completos y la guía de estudio.

Hacer el diagnóstico gratis Ver planes

Preguntas de práctica Business Analyst: Requirements

Un requisito en un proyecto de Salesforce de un fabricante de electrodomésticos dice: 'El sistema debe mejorar la experiencia del cliente.' El BA lo señala como de baja calidad. ¿Qué DOS deficiencias lo hacen inadecuado para desarrollo? (Elija 2)

Al documentar requisitos para una implementación de Sales Cloud CPQ en un distribuidor de equipo industrial, el BA escucha a un stakeholder decir: 'Necesitamos que el sistema sea rápido.' ¿Cómo debe tratar el BA este requisito?

Un BA de una empresa de calzado revisa la documentación de un proyecto anterior que usó el marco V2MOM para la alineación organizacional, y se lo explica a un colega nuevo. ¿Qué descripción explica con MAYOR precisión cómo se relaciona V2MOM con la documentación de requisitos?

Una empresa de calzado está cerrando una implementación grande de Salesforce, y el BA quiere cerrar formalmente los requisitos. ¿Qué actividades forman parte del cierre de requisitos? (Elija 2)

Un BA de una empresa de equipo para exteriores está por entregar los requisitos terminados al equipo de desarrollo para el primer sprint. ¿Qué debe contener la entrega para que los desarrolladores empiecen de inmediato y construyan correctamente? (Elija 2)

Descubre si estás listo para aprobar

Otras secciones de este examen