🔍 Obtención, análisis, priorización y validación de requerimientos

1. Según la Guía SWEBOK V3.0 del IEEE, ¿cuál de las siguientes es una técnica de elicitación (obtención) de requerimientos reconocida dentro del área de conocimiento 'Software Requirements'?

1. Entrevista con los interesados del proyecto
2. Refactorización del código fuente
3. Integración continua del sistema
4. Compilación cruzada del software

SWEBOK V3.0 enumera entrevistas, escenarios, prototipos, reuniones facilitadas, observación e historias de usuario como técnicas de elicitación; las otras opciones son actividades de construcción de software, no de obtención de requerimientos. (Guide to the Software Engineering Body of Knowledge (SWEBOK) V3.0, IEEE Computer Society, KA 'Software Requirements', 3.3 'Elicitation Techniques')

2. Un analista de requerimientos prepara una lista fija de preguntas que aplicará en el mismo orden a todos los usuarios entrevistados, sin desviarse del guion. ¿Qué tipo de entrevista está utilizando?

1. Observación participante
2. Entrevista estructurada
3. Tormenta de ideas (brainstorming)
4. Entrevista no estructurada

La entrevista estructurada usa un cuestionario fijo aplicado de manera uniforme a todos los entrevistados; la no estructurada permite explorar libremente temas emergentes según las respuestas. (Guide to SWEBOK V3.0, KA 'Software Requirements', 3.3; Wiegers & Beatty, 'Software Requirements', 3a ed., Microsoft Press (2013))

3. El único patrocinador del proyecto, quien tiene la autoridad final para definir el alcance y el presupuesto, dispone de apenas 45 minutos para reunirse con el equipo. El analista necesita profundizar en sus prioridades de negocio mediante preguntas de seguimiento según las respuestas que reciba. ¿Qué técnica de elicitación conviene aplicar?

1. Taller JAD
2. Cuestionario estructurado
3. Entrevista individual
4. Observación en el sitio de trabajo

Con un único interesado clave y tiempo limitado para ahondar dinámicamente en sus respuestas, la entrevista individual es la técnica adecuada; el taller JAD requiere múltiples participantes y el cuestionario no permite profundizar en tiempo real. (Guide to SWEBOK V3.0, KA 'Software Requirements', 3.3 'Elicitation Techniques')

4. ¿Cuál es la característica principal de un taller de Diseño Conjunto de Aplicaciones (JAD, Joint Application Design)?

1. Es un documento formal que certifica la aprobación final de la especificación de requerimientos
2. Se basa en el envío masivo de formularios escritos para recolectar opiniones individuales
3. Consiste en observar en silencio a un solo usuario mientras realiza su trabajo cotidiano
4. Reúne en sesiones facilitadas a los interesados para definir requerimientos de forma colaborativa e intensiva

El taller JAD (reunión facilitada) congrega a los interesados en sesiones intensivas y colaborativas para elicitar y consensuar requerimientos; las demás opciones describen otras técnicas (cuestionario, observación) o artefactos distintos. (Guide to SWEBOK V3.0, KA 'Software Requirements', 3.3 'Elicitation Techniques' (reuniones facilitadas))

5. Un proyecto tiene varios departamentos (ventas, finanzas y logística) con visiones distintas y a veces contradictorias sobre cómo debe funcionar un nuevo módulo de facturación. El equipo cuenta con un facilitador capacitado y necesita llegar a un consenso en una sola sesión intensiva de trabajo. ¿Qué técnica de elicitación conviene aplicar?

1. Taller JAD con representantes de cada departamento
2. Cuestionario individual enviado a cada departamento
3. Observación pasiva de un empleado de logística
4. Entrevista uno a uno con cada gerente por separado

El taller JAD, facilitado y con participación simultánea de todos los interesados, está diseñado para resolver visiones divergentes y lograr consenso en una sola sesión; las entrevistas separadas no generan ese consenso conjunto. (Guide to SWEBOK V3.0, KA 'Software Requirements', 3.3)

6. A diferencia de una serie de entrevistas individuales, ¿qué ventaja distintiva ofrece un taller JAD para la obtención de requerimientos?

1. Documenta los requerimientos exclusivamente mediante diagramas de flujo de datos
2. Permite negociar y resolver conflictos entre interesados en tiempo real durante la misma sesión
3. Prioriza automáticamente los requerimientos según el método MoSCoW
4. Sustituye la necesidad de un facilitador capacitado por un moderador improvisado

La reunión facilitada permite que los interesados negocien y resuelvan discrepancias en el momento; esto no ocurre con entrevistas separadas, y el JAD no prioriza automáticamente ni elimina la figura del facilitador. (Guide to SWEBOK V3.0, KA 'Software Requirements', 3.3)

7. ¿En qué situación resulta más apropiado utilizar un cuestionario como técnica de elicitación de requerimientos?

1. Cuando se requiere profundizar de inmediato en una respuesta ambigua mediante preguntas de seguimiento
2. Cuando es indispensable observar directamente el comportamiento del usuario en su lugar de trabajo
3. Cuando se necesita recolectar información de un grupo grande y geográficamente disperso de usuarios finales
4. Cuando el objetivo es lograr consenso inmediato entre interesados con posturas opuestas

El cuestionario es eficiente para recabar información estandarizada de muchos usuarios distantes entre sí; no permite el seguimiento dinámico propio de la entrevista ni el consenso en tiempo real propio del taller JAD. (Guide to SWEBOK V3.0, KA 'Software Requirements', 3.3)

8. Una empresa con 500 usuarios de un sistema de recursos humanos, distribuidos en 12 sucursales del país, necesita conocer de forma cuantificable qué tan satisfechos están con las funciones actuales del sistema antes de definir requerimientos para una nueva versión. El presupuesto y el tiempo disponibles son limitados. ¿Cuál técnica de elicitación resulta más costo-efectiva para este caso?

1. Taller JAD presencial con los 500 usuarios
2. Entrevista individual con cada uno de los 500 usuarios
3. Observación directa en cada una de las 12 sucursales
4. Cuestionario estructurado con escalas de respuesta cerradas

El cuestionario permite recolectar datos cuantificables de una población grande y dispersa con bajo costo y tiempo; entrevistar u observar a 500 usuarios, o reunirlos a todos en un taller, resulta impráctico. (Guide to SWEBOK V3.0, KA 'Software Requirements', 3.3)

9. Dentro del diseño de un cuestionario para elicitar requerimientos, ¿qué distingue a una pregunta cerrada de una pregunta abierta?

1. La pregunta cerrada restringe la respuesta a opciones predefinidas, mientras que la abierta permite responder con las palabras del propio usuario
2. La pregunta cerrada solo se aplica en talleres JAD, mientras que la abierta solo se usa en entrevistas individuales
3. La pregunta cerrada se limita a requerimientos no funcionales, mientras que la abierta se limita a los funcionales
4. La pregunta cerrada siempre requiere observación directa del usuario, mientras que la abierta no requiere observación alguna

Por definición, las preguntas cerradas restringen la respuesta a opciones fijas (facilitan el análisis cuantitativo) y las abiertas permiten respuestas libres; las demás opciones inventan restricciones que no corresponden a la técnica. (Práctica estándar de diseño de cuestionarios en ingeniería de requerimientos; SWEBOK V3.0, KA 'Software Requirements', 3.3)

10. ¿Cuál es la principal ventaja de la técnica de observación (o etnografía) para la obtención de requerimientos?

1. Facilita la construcción de la matriz de trazabilidad entre requerimientos y casos de prueba
2. Revela tareas y conocimiento tácito que los usuarios no siempre pueden explicar verbalmente
3. Acelera la negociación y el consenso entre interesados con posturas opuestas
4. Permite recolectar respuestas cuantificables de un gran número de usuarios en poco tiempo

La observación directa del trabajo real del usuario permite descubrir conocimiento tácito y procedimientos implícitos; la opción de consenso corresponde al taller JAD y la de respuestas cuantificables al cuestionario. (Guide to SWEBOK V3.0, KA 'Software Requirements', 3.3 'Elicitation Techniques' (observación))

11. Un analista necesita documentar cómo los operadores de una línea de producción manejan excepciones y 'atajos' no documentados en el manual de procedimientos, mismos que ellos consideran obvios y no mencionan al ser entrevistados. ¿Qué técnica de elicitación es más adecuada para descubrir estos procedimientos implícitos?

1. Cuestionario con preguntas cerradas
2. Entrevista telefónica estructurada
3. Observación directa en el sitio de trabajo
4. Taller JAD con los supervisores de planta

Cuando el conocimiento es tácito y los usuarios no lo verbalizan por considerarlo obvio, la observación directa es la técnica indicada, pues revela el comportamiento real más allá de lo declarado en entrevistas o cuestionarios. (Guide to SWEBOK V3.0, KA 'Software Requirements', 3.3)

12. ¿Qué significa la categoría 'Must have' dentro de la técnica de priorización MoSCoW?

1. Un requerimiento que fue descartado definitivamente por el equipo del proyecto
2. Un requerimiento deseable que se implementará solo si sobra tiempo y presupuesto
3. Un requerimiento opcional que se pospone para una versión futura sin fecha definida
4. Un requerimiento obligatorio, sin el cual la solución no puede considerarse exitosa ni aceptable

'Must have' designa los requerimientos obligatorios e indispensables para el éxito de la entrega; 'Should have' corresponde a lo deseable y 'Won't have this time' a lo pospuesto, categorías distintas a la descrita. (DSDM Agile Project Framework (Dynamic Systems Development Method), Consorcio DSDM — técnica MoSCoW)

13. De las siguientes, ¿cuál NO es una de las cuatro categorías de la técnica de priorización MoSCoW?

1. Nice to have
2. Should have
3. Could have
4. Must have

Las cuatro categorías oficiales de MoSCoW son Must have, Should have, Could have y Won't have (this time); 'Nice to have' es un término coloquial que no forma parte del acrónimo MoSCoW. (DSDM Agile Project Framework, Consorcio DSDM)

14. En un proyecto de comercio electrónico con plazo fijo e inamovible de entrega, el equipo clasificó 'permitir pago con tarjeta de crédito' como un requerimiento sin el cual el sistema no puede lanzarse, y 'permitir pago con criptomonedas' como una función que se agregará solo si el tiempo lo permite, sin comprometer la fecha de entrega. Según MoSCoW, ¿cómo deben clasificarse respectivamente estos dos requerimientos?

1. Should have y Won't have
2. Must have y Could have
3. Could have y Must have
4. Must have y Should have

El pago con tarjeta es indispensable para el lanzamiento (Must have) y el pago con criptomonedas es una mejora que se incluye solo si sobra tiempo, sin comprometer el plazo (Could have); 'Should have' implicaría una importancia mayor a la descrita. (DSDM Agile Project Framework, Consorcio DSDM)

15. Un equipo de proyecto clasificó el 90% de los requerimientos del sistema como 'Must have' bajo la técnica MoSCoW. ¿Cuál es el principal problema de negociación y planeación que genera esta clasificación?

1. Se incrementa de forma directa el valor de negocio total de cada requerimiento clasificado como obligatorio
2. Se elimina automáticamente la necesidad de aplicar cualquier otra técnica de priorización complementaria
3. Se pierde la utilidad de la técnica, pues casi no quedan requerimientos negociables si el tiempo o el presupuesto se reducen
4. Se garantiza que el proyecto se entregará exactamente en la fecha planeada sin ningún riesgo

MoSCoW funciona como herramienta de negociación de alcance; si casi todo es 'Must have', no queda margen para ajustar el alcance ante restricciones de tiempo o presupuesto, contradiciendo el propósito de la técnica. (DSDM Agile Project Framework, Consorcio DSDM (principio de fijar el tiempo y ajustar el alcance))

16. En la técnica de priorización por valor/costo, un equipo asignó a cuatro requerimientos los siguientes porcentajes relativos de valor para el cliente y de costo de implementación: R1 (valor 40%, costo 10%), R2 (valor 30%, costo 30%), R3 (valor 20%, costo 50%) y R4 (valor 10%, costo 10%). Calculando la razón valor/costo de cada uno, ¿cuál requerimiento debe priorizarse primero?

1. R2, porque su valor relativo absoluto es el segundo más alto después de R1
2. R4, porque tiene el menor costo relativo de implementación
3. R3, porque tiene el mayor costo relativo de implementación
4. R1, porque su razón valor/costo es la más alta de los cuatro requerimientos

La razón valor/costo de R1 es 40/10=4.0, superior a la de R2 (30/30=1.0), R3 (20/50=0.4) y R4 (10/10=1.0); el error común es comparar el valor absoluto o el costo por separado en vez de calcular la razón. (Karlsson & Ryan, 'A Cost-Value Approach for Prioritizing Requirements', IEEE Software, vol. 14, no. 5 (1997))

17. En la matriz de priorización valor/esfuerzo, un requerimiento clasificado en el cuadrante de alto valor para el cliente y bajo costo de implementación corresponde a:

1. Una victoria rápida (quick win) que debe implementarse con prioridad alta
2. Un proyecto mayor (major project) que requiere una inversión considerable
3. Un requerimiento de relleno (fill-in) que se implementa solo si sobra capacidad
4. Una tarea ingrata (thankless task) que conviene evitar o posponer

El cuadrante de alto valor y bajo costo corresponde a las 'victorias rápidas', de mayor prioridad; las tareas ingratas son de bajo valor y alto costo, los proyectos mayores de alto valor y alto costo, y los de relleno de bajo valor y bajo costo. (Matriz de priorización valor vs. esfuerzo (cuadrantes: quick wins, major projects, fill-ins, thankless tasks), técnica de uso común en gestión ágil de producto)

18. Un equipo evaluó dos requerimientos con la técnica valor/costo: R5 tiene un valor relativo de 25% y un costo relativo de 5%; R6 tiene un valor relativo de 45% y un costo relativo de 45%. Considerando la razón valor/costo de cada uno, ¿cuál requerimiento ofrece mayor valor por unidad de costo invertido?

1. Ambos son equivalentes, porque la suma de valor y costo es igual en los dos casos
2. R5, porque su razón valor/costo es mayor que la de R6
3. R6, porque su valor relativo absoluto es mayor que el de R5
4. R6, porque su mayor costo relativo indica un mayor beneficio esperado

La razón valor/costo de R5 es 25/5=5.0, mientras que la de R6 es 45/45=1.0; el error común es comparar el valor absoluto o suponer que mayor costo implica mayor beneficio, en vez de calcular la razón. (Karlsson & Ryan, 'A Cost-Value Approach for Prioritizing Requirements', IEEE Software, vol. 14, no. 5 (1997))

19. A diferencia de la técnica MoSCoW, que clasifica los requerimientos en categorías discretas de importancia, ¿qué aporta específicamente el enfoque de priorización por valor/costo?

1. Una clasificación en cuatro categorías idénticas a las de MoSCoW, pero con nombres distintos
2. La garantía de que todos los requerimientos 'Must have' se implementarán antes que cualquier otro
3. Una estimación cuantificable de valor y costo que permite ordenar los requerimientos en una escala continua
4. La eliminación total de la necesidad de negociar el alcance del proyecto con los interesados

El valor/costo aporta una escala cuantitativa continua, basada en estimaciones relativas de valor y costo, para ordenar requerimientos, mientras que MoSCoW usa categorías discretas; no sustituye la negociación de alcance ni coincide con las categorías de MoSCoW. (Karlsson & Ryan, 'A Cost-Value Approach for Prioritizing Requirements', IEEE Software, vol. 14, no. 5 (1997); DSDM Agile Project Framework)

20. Según la ISO/IEC/IEEE 29148:2018, la trazabilidad de requerimientos debe ser bidireccional. ¿Qué significa esto?

1. Que cada requerimiento debe documentarse en dos idiomas distintos para facilitar su comprensión por los interesados
2. Que cada requerimiento debe ser aprobado por dos interesados diferentes antes de incorporarse a la línea base
3. Que cada requerimiento debe clasificarse de forma simultánea como requerimiento funcional y como no funcional
4. Que debe rastrearse en ambos sentidos: del requerimiento hacia el diseño y las pruebas, y de estos artefactos de regreso al requerimiento

La trazabilidad bidireccional implica rastreo hacia adelante (requerimiento hacia diseño/código/pruebas) y hacia atrás (artefacto hacia su requerimiento origen), documentado típicamente en una Matriz de Trazabilidad de Requerimientos (RTM). (ISO/IEC/IEEE 29148:2018; Guide to SWEBOK V3.0, KA 'Software Requirements')

21. Durante una auditoría de calidad se necesita verificar que un caso de prueba específico corresponde efectivamente a un requerimiento aprobado en la línea base, y que no fue agregado sin respaldo. ¿Qué herramienta documental permite realizar esta verificación de manera sistemática?

1. La matriz de trazabilidad de requerimientos (RTM)
2. El diagrama de flujo de datos del sistema
3. El diccionario de datos de la base de datos
4. El plan de gestión de riesgos del proyecto

La RTM vincula cada requerimiento con los artefactos derivados (diseño, código, casos de prueba) y permite verificar hacia atrás que cada caso de prueba tiene un requerimiento origen documentado. (ISO/IEC/IEEE 29148:2018; Guide to SWEBOK V3.0, KA 'Software Requirements' (trazabilidad))

22. Un equipo descubre que un módulo de código fue implementado, pero al revisar la documentación no logra identificar a qué requerimiento de la especificación corresponde dicho módulo. ¿Qué tipo de trazabilidad falló en este caso?

1. Trazabilidad hacia adelante, desde el requerimiento hacia el diseño y el código
2. Trazabilidad hacia atrás, desde el artefacto de código hacia su requerimiento origen
3. Validación de requerimientos mediante prototipos
4. Verificación de requerimientos mediante inspecciones formales

Rastrear desde un artefacto de código hasta su requerimiento origen es trazabilidad hacia atrás; la trazabilidad hacia adelante va del requerimiento hacia los artefactos derivados, en el sentido opuesto al descrito en el caso. (ISO/IEC/IEEE 29148:2018; Guide to SWEBOK V3.0, KA 'Software Requirements')

23. ¿Cuál de las siguientes opciones NO es un beneficio típico de mantener actualizada una matriz de trazabilidad de requerimientos durante el proyecto?

1. Ayudar a detectar requerimientos huérfanos que no fueron implementados ni probados
2. Facilitar el análisis de impacto cuando un requerimiento cambia
3. Determinar automáticamente la categoría MoSCoW de cada requerimiento
4. Verificar que cada requerimiento cuente con al menos un caso de prueba asociado

La matriz de trazabilidad vincula requerimientos con artefactos de diseño, código y prueba para el análisis de impacto y la detección de huérfanos, pero no asigna categorías de priorización MoSCoW, que es una técnica independiente. (ISO/IEC/IEEE 29148:2018; Guide to SWEBOK V3.0, KA 'Software Requirements' (trazabilidad); DSDM Agile Project Framework)

24. Dentro de las técnicas de obtención (elicitación) de requerimientos, ¿cuál es el propósito principal de construir un prototipo durante las primeras etapas del proyecto?

1. Permitir que el usuario interactúe con una representación tangible del sistema para validar y aclarar sus necesidades antes de construir el producto final.
2. Sustituir por completo la especificación formal de requerimientos, ya que ese artefacto se convierte en el único documento de referencia del proyecto.
3. Medir el desempeño de la base de datos de producción bajo condiciones de carga real antes de liberar el sistema.
4. Certificar el cumplimiento de los estándares de codificación del equipo de desarrollo antes de iniciar las pruebas unitarias.

El prototipado permite a usuarios y stakeholders experimentar con una versión preliminar del sistema, reduciendo la ambigüedad de requerimientos poco claros; no reemplaza la especificación formal ni sirve para medir desempeño de bases de datos o estándares de código. (Guide to SWEBOK V3.0, IEEE Computer Society, KA 'Software Requirements', 3.3 'Elicitation Techniques')

25. Según la Guía SWEBOK V3.0 (IEEE), ¿cuál de las siguientes opciones corresponde a un conjunto de técnicas reconocidas para la elicitación (obtención) de requerimientos?

1. Compilación cruzada del código fuente, refactorización de módulos y ejecución de pruebas de regresión.
2. Entrevistas, prototipos, reuniones facilitadas y observación de los usuarios en su entorno de trabajo.
3. Análisis de puntos de función, estimación COCOMO y planeación mediante póker de estimación.
4. Integración continua, control de versiones y revisión de código por pares durante la construcción.

SWEBOK ubica entrevistas, prototipos, reuniones facilitadas (JAD), observación e historias de usuario como técnicas de elicitación; las demás opciones corresponden a prácticas de construcción, estimación o gestión de configuración. (Guide to SWEBOK V3.0, IEEE Computer Society, KA 'Software Requirements', 3.3 'Elicitation Techniques')

26. Un equipo construye un prototipo únicamente para que los usuarios validen el flujo de una pantalla compleja; una vez aclarado el requerimiento, el prototipo se descarta y el sistema se construye desde cero con la arquitectura definitiva. ¿Qué tipo de prototipo describe mejor esta situación?

1. Prototipo evolutivo, que se construye y refina de manera incremental hasta convertirse en el producto final entregado al cliente.
2. Prototipo operacional, integrado directamente al ambiente productivo para sustituir la fase de pruebas de aceptación.
3. Prototipo desechable (exploratorio), construido para resolver dudas puntuales sobre el flujo, sin integrarse al sistema final.
4. Prototipo horizontal de alta fidelidad, que simula todas las capas del sistema con datos reales de producción.

Al descartarse tras cumplir su propósito de aclaración, corresponde a un prototipo desechable o exploratorio; el evolutivo, en cambio, se conserva y refina hasta ser el producto final. (Guide to SWEBOK V3.0, KA 'Software Requirements', 3.3; doctrina clásica de ingeniería de requerimientos sobre tipos de prototipo)

27. Los usuarios de un sistema nuevo no logran describir con precisión cómo debe organizarse la pantalla principal ni qué controles necesitan, aunque reconocen fácilmente una interfaz adecuada cuando la ven. ¿Qué técnica de obtención de requerimientos es más adecuada para este caso?

1. Redactar de inmediato la especificación formal de requerimientos, basándose únicamente en supuestos del analista.
2. Aplicar el modelo de Kano para clasificar los requerimientos en básicos, de desempeño y atractivos.
3. Construir directamente la matriz de trazabilidad de requerimientos, vinculando la interfaz con los casos de prueba.
4. Elaborar un prototipo de la interfaz para que los usuarios lo evalúen y retroalimenten sobre algo tangible.

El prototipado es la técnica indicada cuando el usuario 'sabe lo que quiere cuando lo ve'; redactar sin validar, priorizar con Kano o trazar no resuelven la ambigüedad inicial sobre la interfaz. (Guide to SWEBOK V3.0, KA 'Software Requirements', 3.3 'Elicitation Techniques')

28. Un analista presenta a la dirección un prototipo de alta fidelidad, con apariencia casi idéntica al producto final, para validar un módulo crítico. Días después, la dirección exige la entrega inmediata del sistema, pues asume que 'ya está terminado'. ¿Cuál es el riesgo del prototipado que se manifestó en este caso?

1. Que los interesados confundan el prototipo con el producto terminado y generen expectativas de entrega poco realistas.
2. Que el prototipo, al ser desechable, impida por completo cualquier retroalimentación útil de los usuarios finales.
3. Que la especificación de requerimientos deje de ser necesaria una vez que existe cualquier tipo de prototipo.
4. Que el prototipo sustituya de forma permanente a la matriz de trazabilidad exigida por la norma ISO/IEC/IEEE 29148.

Un riesgo documentado del prototipado de alta fidelidad es que los interesados lo perciban como el producto casi terminado, generando expectativas irreales de plazos; el prototipo no elimina la especificación ni la trazabilidad. (Guide to SWEBOK V3.0, KA 'Software Requirements', 3.3; doctrina de ingeniería de requerimientos sobre riesgos del prototipado)

29. Durante una sesión temprana de obtención de requerimientos, el equipo dibuja a mano bocetos en papel de las pantallas propuestas para discutirlas rápidamente con los usuarios, sin invertir tiempo en detalles visuales ni de navegación real. ¿Qué tipo de prototipo se está utilizando?

1. Un prototipo de alta fidelidad, capaz de simular con exactitud el comportamiento final del sistema en producción.
2. Un prototipo de baja fidelidad, orientado a explorar ideas de manera rápida y económica antes de detallar el diseño visual.
3. Un prototipo evolutivo que ya forma parte del código fuente definitivo incorporado al producto.
4. Un prototipo operacional que reemplaza por completo las pruebas de aceptación del usuario final.

Los bocetos en papel sin detalle visual ni funcional corresponden a un prototipo de baja fidelidad, útil para explorar ideas rápido y a bajo costo; la alta fidelidad requiere mayor semejanza con el producto final. (Guide to SWEBOK V3.0, KA 'Software Requirements', 3.3; práctica general de prototipado (baja vs. alta fidelidad))

30. Un equipo construye un prototipo que muestra la navegación completa entre todas las pantallas del sistema, pero ninguna de ellas procesa datos reales ni ejecuta lógica de negocio. ¿Qué tipo de prototipo corresponde a esta descripción?

1. Prototipo vertical, que implementa la lógica de negocio completa de un solo módulo, incluido el acceso a datos.
2. Prototipo evolutivo, que se construye y refina de manera incremental hasta convertirse en el producto final entregado al cliente.
3. Prototipo horizontal, que cubre de forma superficial toda la amplitud de la interfaz sin profundizar en la funcionalidad interna.
4. Prototipo desechable de un único caso de uso, sin relación con el resto de las pantallas del sistema.

Cubrir toda la navegación sin profundidad funcional es característico del prototipo horizontal; el vertical, en cambio, profundiza en un solo módulo con su lógica y datos reales. (Guide to SWEBOK V3.0, KA 'Software Requirements', 3.3; práctica de ingeniería de requerimientos sobre alcance de prototipos)

31. ¿Cuál de las siguientes definiciones corresponde a un caso de uso dentro del análisis de requerimientos?

1. La descripción de una secuencia de interacciones entre un actor y el sistema para lograr un objetivo específico del actor.
2. Un documento que enumera exclusivamente los atributos de calidad no funcionales que debe cumplir el sistema.
3. Una tabla de comparación por pares utilizada para asignar prioridades numéricas a los requerimientos del proyecto.
4. Un diagrama que muestra únicamente la arquitectura física de los servidores donde se desplegará el sistema.

Un caso de uso describe la interacción actor-sistema orientada a lograr una meta del actor; no es un listado de atributos de calidad, una técnica de priorización numérica ni un diagrama de arquitectura física. (Guide to SWEBOK V3.0, KA 'Software Requirements' (casos de uso como técnica de análisis); Ivar Jacobson, Object-Oriented Software Engineering)

32. ¿Cuál es el formato estándar que se utiliza para redactar una historia de usuario en el desarrollo ágil de software?

1. Dado un contexto inicial, cuando ocurre un evento, entonces se produce un resultado verificable en el sistema.
2. Como un tipo de usuario, quiero contar con una función, para obtener un beneficio o valor concreto.
3. El sistema deberá ejecutar una acción obligatoria, conforme al artículo correspondiente de la especificación de requerimientos.
4. Si se cumple una condición numérica, entonces se ejecuta un cálculo, de lo contrario se genera un error.

El formato 'Como/quiero/para' es el estándar de las historias de usuario; el formato 'Dado/cuando/entonces' corresponde a criterios de aceptación (Gherkin), no a la historia misma. (Mike Cohn, 'User Stories Applied' (2004); Guide to SWEBOK V3.0, KA 'Software Requirements', 3.3 (historias de usuario))

33. El acrónimo INVEST se utiliza para evaluar la calidad de una historia de usuario bien redactada. ¿Qué característica corresponde a la letra 'T' de este criterio?

1. Trazable: debe estar vinculada de forma bidireccional con el requerimiento de negocio que le dio origen.
2. Temporal: debe especificar una fecha límite fija para su implementación dentro del backlog del producto.
3. Testable (comprobable): debe ser posible verificar mediante pruebas si la historia fue implementada correctamente.
4. Técnica: debe describir el diseño interno y la arquitectura de la solución que implementará el equipo.

La 'T' de INVEST corresponde a Testable (comprobable); la trazabilidad, un plazo fijo o el detalle técnico no forman parte de este criterio. (Bill Wake, criterio INVEST para historias de usuario (Independent, Negotiable, Valuable, Estimable, Small, Testable))

34. Un equipo de análisis debe elegir entre documentar un requerimiento como caso de uso detallado (formato 'fully dressed') o como historia de usuario breve. ¿Cuál es la diferencia principal entre ambos insumos de análisis?

1. La historia de usuario siempre incluye diagramas UML de secuencia, mientras que el caso de uso se limita a una sola oración.
2. El caso de uso solo puede aplicarse en proyectos con metodología ágil, mientras que la historia de usuario es exclusiva del ciclo de vida en cascada.
3. Ambos insumos son completamente equivalentes en nivel de detalle y formalidad, por lo que su elección no afecta el análisis de requerimientos.
4. El caso de uso describe formalmente los flujos básico, alternos y de excepción, mientras que la historia de usuario es un enunciado breve para iniciar una conversación.

El caso de uso detallado documenta formalmente los flujos alternos y de excepción; la historia de usuario es intencionalmente breve y funciona como recordatorio para conversar con el equipo. (Alistair Cockburn, 'Writing Effective Use Cases'; Mike Cohn, 'User Stories Applied'; Guide to SWEBOK V3.0, KA 'Software Requirements')

35. Un equipo que trabaja con Scrum necesita documentar un requerimiento pequeño, negociable con el cliente y que pueda estimarse e implementarse en un solo sprint. ¿Qué insumo de análisis es más adecuado para este requerimiento?

1. Una historia de usuario, ya que su tamaño reducido y su naturaleza negociable encajan con el criterio INVEST del marco ágil.
2. Un caso de uso completamente detallado ('fully dressed'), con todos sus flujos alternos documentados antes de iniciar el sprint.
3. Una matriz de trazabilidad de requerimientos, ya que permite estimar directamente el esfuerzo de desarrollo del sprint.
4. Un modelo de calidad ISO/IEC 25010, ya que clasifica el requerimiento según sus atributos de mantenibilidad y portabilidad.

Un requerimiento pequeño, negociable y estimable en un sprint corresponde por definición a las características INVEST de una historia de usuario; el caso de uso fully dressed es más pesado de lo necesario aquí. (Bill Wake, criterio INVEST; Mike Cohn, 'User Stories Applied' (2004))