📄 Documentación de requerimientos

1. Según el estándar IEEE 830-1998, ¿cuántas características debe cumplir una Especificación de Requerimientos de Software (SRS) para considerarse una 'buena' SRS?

1. Ocho características, entre ellas no ambigua y verificable
2. Seis características, entre ellas correcta y completa
3. Cinco características, entre ellas correcta y modificable
4. Nueve características, entre ellas necesaria y factible

IEEE 830-1998, cláusula 4.3, enumera ocho características de una buena SRS (correcta, no ambigua, completa, consistente, jerarquizada, verificable, modificable y rastreable); el número nueve corresponde a las características del requerimiento individual en ISO/IEC/IEEE 29148, no a IEEE 830. (IEEE Std 830-1998, cláusula 4.3 'Characteristics of a good SRS')

2. ¿Cuál de las siguientes NO es una de las ocho características de una buena SRS según IEEE 830-1998?

1. Consistente
2. Reutilizable
3. Rastreable
4. Modificable

IEEE 830-1998 enumera correcta, no ambigua, completa, consistente, jerarquizada, verificable, modificable y rastreable; 'reutilizable' no forma parte de esa lista. (IEEE Std 830-1998, cláusula 4.3)

3. El estándar ISO/IEC/IEEE 29148:2018 sobre ingeniería de requerimientos declaró obsoletos a varios estándares previos de la IEEE. ¿Cuáles son esos estándares reemplazados?

1. IEEE 830-1998, IEEE 1471-2000 e IEEE 12207-2008
2. IEEE 1233-1998, IEEE 1465-1998 e IEEE 830-1993
3. IEEE 830-1998, IEEE 1233-1998 e IEEE 1362-1998
4. IEEE 830-1998, IEEE 1016-2009 e IEEE 1028-2008

ISO/IEC/IEEE 29148:2018 sustituye explícitamente a IEEE 830-1998, IEEE 1233-1998 e IEEE 1362-1998; los demás números corresponden a estándares reales de arquitectura, ciclo de vida o diseño, pero no forman parte de este reemplazo. (ISO/IEC/IEEE 29148:2018 'Systems and software engineering — Requirements engineering')

4. De acuerdo con ISO/IEC/IEEE 29148:2018, ¿qué característica aplica al CONJUNTO completo de requerimientos y no está definida como atributo de un requerimiento individual?

1. Verificable
2. Singular
3. Apropiado
4. Acotado

La cláusula 5.2.6 asigna al conjunto de requerimientos las características completo, consistente, factible/asequible y acotado; verificable, singular y apropiado son atributos de cada requerimiento individual según la cláusula 5.2.5. (ISO/IEC/IEEE 29148:2018, cláusula 5.2.6 'Characteristics of a set of requirements')

5. Un analista redacta en la SRS: 'El sistema shall enviar una notificación por correo al cerrar cada venta.' El equipo de pruebas interpreta que esa notificación es de cumplimiento obligatorio y la incluye en las pruebas de aceptación. ¿Qué convención de ISO/IEC/IEEE 29148:2018 sustenta esa interpretación?

1. El verbo 'shall' se reserva para requerimientos de cumplimiento obligatorio (binding)
2. El verbo 'shall' indica una recomendación que puede omitirse si hay restricciones de tiempo
3. El verbo 'shall' se usa para declarar hechos ya implementados en el sistema
4. El verbo 'shall' equivale a 'may' y otorga libertad de implementación al equipo

Según la cláusula 5.2.4 de ISO/IEC/IEEE 29148:2018, 'shall' expresa un requerimiento obligatorio, mientras que 'should' indica recomendación, 'will' un hecho o intención y 'may' una opción permitida. (ISO/IEC/IEEE 29148:2018, cláusula 5.2.4)

6. En la SRS de un sistema de nómina se necesita documentar que el proveedor de hosting garantiza, por contrato, un tiempo de actividad histórico, sin que ello imponga una obligación de diseño al equipo de desarrollo. ¿Qué verbo modal, según la convención de ISO/IEC/IEEE 29148:2018, es el más adecuado para ese enunciado?

1. shall
2. will
3. should
4. may

'will' se reserva para declarar hechos o intenciones, como una garantía externa del proveedor, a diferencia de 'shall', que impone una obligación de diseño al producto que se está especificando. (ISO/IEC/IEEE 29148:2018, cláusula 5.2.4)

7. El modelo de calidad de producto de software ISO/IEC 25010:2011, usado como referencia para clasificar requerimientos no funcionales en la SRS, organiza los atributos de calidad en ocho características. ¿Cuál de las siguientes pertenece a esa lista?

1. Trazabilidad
2. Verificabilidad
3. Portabilidad
4. Priorización

ISO/IEC 25010:2011 define ocho características: adecuación funcional, eficiencia de desempeño, compatibilidad, usabilidad, fiabilidad, seguridad, mantenibilidad y portabilidad; trazabilidad, verificabilidad y priorización pertenecen a otros marcos de gestión de requerimientos, no a este modelo de calidad. (ISO/IEC 25010:2011 (SQuaRE))

8. Un requerimiento establece: 'El sistema debe recuperarse de una caída del servidor en menos de 30 segundos sin pérdida de datos.' Según ISO/IEC 25010:2011, ¿bajo qué característica de calidad se clasifica principalmente este requerimiento no funcional?

1. Usabilidad
2. Portabilidad
3. Compatibilidad
4. Fiabilidad

La recuperación ante fallos sin pérdida de datos corresponde a la subcaracterística de recuperabilidad dentro de fiabilidad; usabilidad, portabilidad y compatibilidad describen otros atributos de calidad del producto. (ISO/IEC 25010:2011 (SQuaRE))

9. Durante una auditoría de un proyecto se detecta que cada requerimiento de la SRS enlaza correctamente con el caso de uso que lo implementa, pero ningún requerimiento indica de qué solicitud del cliente se originó. Según ISO/IEC/IEEE 29148:2018, ¿qué principio de trazabilidad está incumpliendo el equipo?

1. La trazabilidad hacia atrás (origen del requerimiento)
2. La completitud del conjunto de requerimientos
3. La verificabilidad del requerimiento individual
4. La jerarquización por estabilidad de la SRS

ISO/IEC/IEEE 29148:2018 exige trazabilidad bidireccional: hacia atrás, al origen del requerimiento, y hacia adelante, a su implementación o verificación; tener solo el enlace hacia adelante deja incompleta esa trazabilidad, sin que ello afecte directamente la completitud, verificabilidad o jerarquización. (ISO/IEC/IEEE 29148:2018, cláusula sobre trazabilidad de requerimientos)

10. ¿Quién introdujo los casos de uso como técnica de especificación de requerimientos, dentro del método de Ingeniería de Software Orientada a Objetos (OOSE)?

1. Grady Booch
2. Ivar Jacobson
3. James Rumbaugh
4. Kent Beck

Ivar Jacobson introdujo los casos de uso en 1992 dentro de su método OOSE; Booch y Rumbaugh aportaron otras notaciones orientadas a objetos posteriormente unificadas en UML, y Kent Beck es conocido por la programación extrema. (Jacobson, I., 'Object-Oriented Software Engineering: A Use Case Driven Approach', 1992)

11. Además de la asociación entre actor y caso de uso, ¿qué otras tres relaciones estándar admite el diagrama de casos de uso de UML?

1. «include», «depend» y composición
2. «extend», agregación y realización
3. «include», «extend» y generalización
4. Generalización, dependencia y multiplicidad

El estándar UML 2.5.1 define para casos de uso las relaciones «include» (inclusión obligatoria), «extend» (extensión condicional) y generalización, además de la asociación con el actor. (OMG Unified Modeling Language (UML) v2.5.1, sección 18 'UseCases')

12. En un sistema de compras en línea, el caso de uso 'Pagar pedido' siempre ejecuta obligatoriamente el subflujo 'Validar tarjeta de crédito' como parte de su comportamiento base, sin excepción. ¿Qué relación de UML debe usarse para modelar esta dependencia?

1. Relación de extensión («extend»)
2. Relación de generalización
3. Relación de asociación
4. Relación de inclusión («include»)

La relación «include» representa un comportamiento que el caso de uso base siempre incorpora de forma obligatoria; «extend» modela comportamiento opcional, y la generalización expresa variantes de un caso de uso más general. (OMG UML v2.5.1, sección 18 'UseCases')

13. En el mismo sistema, el subflujo 'Aplicar cupón de descuento' solo se ejecuta si el cliente decide ingresar un código promocional durante el pago; en la mayoría de los casos no ocurre. ¿Qué relación UML modela correctamente este comportamiento opcional dentro del caso de uso 'Pagar pedido'?

1. Relación de extensión («extend»)
2. Relación de inclusión («include»)
3. Relación de generalización
4. Relación de composición

«extend» modela un comportamiento opcional que se inserta condicionalmente en un punto de extensión definido, a diferencia de «include», que representa un subflujo obligatorio siempre ejecutado. (OMG UML v2.5.1, sección 18 'UseCases')

14. Según la plantilla de especificación de casos de uso propuesta por Alistair Cockburn, ¿qué elemento describe la condición que debe cumplirse ANTES de que el caso de uso pueda iniciar?

1. Garantía de éxito
2. Precondición
3. Escenario principal
4. Extensiones

La precondición es el estado que debe existir antes de iniciar el caso de uso; la garantía de éxito describe el estado al finalizar, el escenario principal el flujo básico y las extensiones los flujos alternativos. (Cockburn, A., 'Writing Effective Use Cases', 2001)

15. ¿Cuál es la estructura de la plantilla clásica de historia de usuario (formato Connextra) difundida por Mike Cohn?

1. Dado <contexto>, cuando <acción>, entonces <resultado>
2. El sistema shall <funcionalidad> cuando <condición>
3. Como <rol>, quiero <funcionalidad>, para <beneficio>
4. Como <rol>, necesito <restricción>, porque <riesgo>

El formato Connextra estructura la historia de usuario como 'Como <rol>, quiero <funcionalidad/objetivo>, para <beneficio>'; el patrón 'Dado/cuando/entonces' corresponde a los criterios de aceptación en Gherkin, no a la historia misma. (Cohn, M., 'User Stories Applied: For Agile Software Development', 2004)

16. Un equipo escribe la historia 'Como cliente frecuente, quiero acumular puntos de lealtad en cada compra, para canjearlos por descuentos' y luego agrega: 'Dado que el cliente tiene una cuenta activa, cuando realiza una compra mayor a $200, entonces el sistema le asigna 10 puntos.' ¿Qué papel cumple específicamente ese segundo enunciado dentro de la documentación de requerimientos?

1. Una historia de usuario adicional e independiente de la primera
2. Una regla de negocio que sustituye a la historia de usuario
3. La definición de terminado (Definition of Done) del proyecto
4. Un criterio de aceptación en formato Gherkin de la historia de usuario

El patrón Given/When/Then de Gherkin se usa para expresar criterios de aceptación que precisan las condiciones concretas de cumplimiento de una historia de usuario, no para reemplazarla ni para definir el 'Definition of Done' general del proyecto. (Lenguaje Gherkin (Cucumber); Dan North, 'Introducing BDD', 2006)

17. El acrónimo INVEST, propuesto por Bill Wake para evaluar la calidad de una historia de usuario, incluye el atributo 'Small' (Pequeña). ¿Qué otro atributo forma parte de INVEST?

1. Negociable
2. Medible
3. Alcanzable
4. Relevante

INVEST significa Independiente, Negociable, Valiosa, Estimable, Pequeña y Verificable/Testeable; 'medible', 'alcanzable' y 'relevante' pertenecen al acrónimo SMART, que el mismo autor propuso para las tareas, no para las historias de usuario. (Wake, B., 'INVEST in Good Stories, and SMART Tasks', 2003)

18. Un product owner redacta una historia de usuario tan amplia que abarca 'gestionar todo el módulo de facturación' y, además, no puede completarse sin que otras tres historias se implementen primero en un orden estricto. ¿Qué dos atributos del acrónimo INVEST está incumpliendo esta historia?

1. Estimable y Verificable
2. Pequeña e Independiente
3. Valiosa y Negociable
4. Independiente y Valiosa

Una historia demasiado amplia viola el atributo 'Small' (Pequeña), y una historia que depende estrictamente de otras para poder implementarse viola 'Independent'; el problema descrito no se relaciona directamente con la estimabilidad, el valor o la negociabilidad. (Wake, B., 'INVEST in Good Stories, and SMART Tasks', 2003)

19. La técnica de priorización MoSCoW, formalizada dentro del marco DSDM, clasifica los requerimientos en cuatro categorías. ¿Cuál de las siguientes es una de ellas?

1. Can have (posible)
2. Would have (deseado)
3. Could have (opcional)
4. Shall have (obligatorio)

MoSCoW define Must have, Should have, Could have y Won't have; 'Can have', 'Would have' y 'Shall have' no son categorías reales de la técnica formal de DSDM. (DSDM Consortium, 'MoSCoW Prioritisation', DSDM Agile Project Framework)

20. En la planeación de un sprint, el equipo determina que una funcionalidad sería conveniente tenerla si sobra tiempo, pero su ausencia no compromete la entrega ni el valor del incremento. Según MoSCoW, ¿en qué categoría debe clasificarse ese requerimiento?

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

'Could have' agrupa los requerimientos deseables pero no críticos, que se implementan solo si el tiempo y los recursos lo permiten, a diferencia de 'Must have' (obligatorio) y 'Should have' (importante aunque no crítico). (DSDM Consortium, 'MoSCoW Prioritisation', DSDM Agile Project Framework)

21. Según IEEE 830-1998, un requerimiento se considera 'verificable' cuando existe un proceso finito y costo-efectivo mediante el cual una persona o una máquina puede comprobar que el software lo cumple. ¿Cuál de los siguientes enunciados cumple mejor con esa característica?

1. El sistema debe generar el reporte de ventas en máximo 3 segundos
2. El sistema debe generar el reporte de ventas de forma rápida
3. El sistema debe tener una interfaz agradable para el usuario
4. El sistema debe procesar las ventas de manera eficiente

El enunciado con un umbral numérico concreto (3 segundos) permite comprobación objetiva; términos como 'rápida', 'agradable' o 'eficiente' son subjetivos y no verificables según la cláusula 4.3.6 de IEEE 830-1998. (IEEE Std 830-1998, cláusula 4.3.6 'Verifiable')

22. De acuerdo con IEEE 830-1998, ¿cuándo se considera que una SRS es 'no ambigua'?

1. Cuando cada requerimiento admite más de una interpretación según el lector
2. Cuando cada requerimiento enunciado tiene una sola interpretación posible
3. Cuando el documento evita el uso de diagramas y solo contiene texto narrativo
4. Cuando todos los requerimientos están escritos por la misma persona

La cláusula 4.3.2 de IEEE 830-1998 define 'no ambiguo' como que cada requerimiento tenga una única interpretación; permitir varias interpretaciones es justamente lo que la ambigüedad busca evitar. (IEEE Std 830-1998, cláusula 4.3.2 'Unambiguous')

23. Un requerimiento dice: 'El sistema debe soportar varios usuarios simultáneos.' Dos desarrolladores lo interpretan de forma distinta: uno diseña para 50 usuarios concurrentes y otro para 500. ¿Qué atributo de un buen requerimiento, según IEEE 830-1998, se está incumpliendo?

1. Modificabilidad, porque el requerimiento no puede actualizarse después
2. Rastreabilidad, porque no se sabe de dónde proviene el requerimiento
3. No ambigüedad, porque el enunciado admite más de una interpretación
4. Jerarquización, porque no se indica la prioridad del requerimiento

Un requerimiento que permite dos interpretaciones distintas viola la característica de no ambigüedad de la cláusula 4.3.2 de IEEE 830-1998; el problema descrito no tiene relación con la modificabilidad, la rastreabilidad ni la jerarquización. (IEEE Std 830-1998, cláusula 4.3.2 'Unambiguous')

24. ISO/IEC/IEEE 29148:2018 define nueve características que debe cumplir cada requerimiento individual bien formado. ¿Cuál de las siguientes pertenece a esa lista?

1. Jerarquizado
2. Modificable
3. Rastreable
4. Singular

Las nueve características del requerimiento individual, según la cláusula 5.2.5, son necesario, apropiado, no ambiguo, completo, singular, factible, verificable, correcto y conforme; jerarquizado, modificable y rastreable son atributos de la SRS completa en el modelo de IEEE 830-1998. (ISO/IEC/IEEE 29148:2018, cláusula 5.2.5 'Characteristics of individual requirements')

25. Un requerimiento redactado dice: 'El sistema debe permitir a los administradores crear cuentas de usuario y, además, generar automáticamente reportes de auditoría mensuales.' ¿Qué característica de un requerimiento individual, según ISO/IEC/IEEE 29148:2018, se está violando al combinar ambas capacidades en un solo enunciado?

1. Singular, porque el enunciado debe abordar una sola capacidad o condición
2. Verificable, porque no existe forma de comprobar el requerimiento
3. Apropiado, porque el nivel de abstracción no corresponde a la etapa del proyecto
4. Necesario, porque el requerimiento no está justificado por una necesidad real

La característica 'singular' exige que cada requerimiento exprese una única capacidad o condición; combinar dos funcionalidades distintas en un mismo enunciado infringe esa característica, no la verificabilidad, la pertinencia ni la necesidad. (ISO/IEC/IEEE 29148:2018, cláusula 5.2.5 'Characteristics of individual requirements')

26. Un equipo confunde dos listas de atributos de calidad de requerimientos: por un lado, las ocho características que IEEE 830-1998 exige a la SRS completa y, por otro, las nueve características que ISO/IEC/IEEE 29148:2018 exige a cada requerimiento individual. ¿Cuál de las siguientes características aparece en AMBAS listas?

1. Jerarquizada
2. Verificable
3. Acotada
4. Apropiada

'Verificable' figura tanto entre las ocho características de la SRS en IEEE 830-1998 (cláusula 4.3.6) como entre las nueve características del requerimiento individual en ISO/IEC/IEEE 29148:2018 (cláusula 5.2.5); 'jerarquizada' es exclusiva de IEEE 830-1998, mientras que 'acotada' y 'apropiada' son exclusivas de 29148. (IEEE Std 830-1998, cláusula 4.3; ISO/IEC/IEEE 29148:2018, cláusula 5.2.5)

27. Según la práctica recomendada IEEE Std 830-1998, ¿cuál de las siguientes es una de las ocho características que debe cumplir una Especificación de Requerimientos de Software (SRS) bien elaborada?

1. Portable
2. Reusable
3. Verificable
4. Escalable

IEEE 830-1998 (cláusula 4.3) enumera ocho características de una buena SRS, entre ellas 'verificable'; portabilidad, reusabilidad y escalabilidad son atributos de calidad de otros modelos, como ISO/IEC 25010, no de esta lista. (IEEE Std 830-1998, cláusula 4.3 'Characteristics of a good SRS')

28. Un analista redacta el requerimiento: 'El sistema debe ser fácil de usar para el usuario final.' Según IEEE Std 830-1998, ¿qué característica de una buena SRS se está violando con esta redacción?

1. Verificabilidad, porque 'fácil de usar' no es medible con un proceso costo-efectivo
2. Completitud, porque omite describir la interfaz gráfica del sistema
3. Consistencia, porque contradice otro requerimiento del mismo documento
4. Rastreabilidad, porque no se indica el origen de ese requerimiento

IEEE 830-1998 exige evitar términos subjetivos como 'fácil' porque impiden comprobar el cumplimiento mediante un proceso finito y costo-efectivo (cláusula 4.3.6); no hay evidencia de contradicción, omisión de interfaz ni falta de origen. (IEEE Std 830-1998, cláusula 4.3.6 'Verifiable')

29. De acuerdo con IEEE Std 830-1998, se considera que una SRS es 'no ambigua' cuando...

1. cada requerimiento puede interpretarse de más de una manera según el lector
2. cada requerimiento enunciado admite una sola interpretación posible
3. el documento evita el uso de cualquier notación gráfica o diagrama
4. el documento se redacta exclusivamente con lenguaje natural, sin plantillas

La cláusula 4.3.2 define 'no ambigua' como que cada requerimiento tenga una única interpretación; lo contrario describiría precisamente la ambigüedad que el estándar busca evitar. (IEEE Std 830-1998, cláusula 4.3.2 'Unambiguous')

30. ¿Qué estándar internacional sustituyó y dejó obsoletos a los estándares IEEE 830-1998, IEEE 1233-1998 e IEEE 1362-1998 en materia de ingeniería de requerimientos?

1. ISO/IEC 25010:2011
2. ISO/IEC/IEEE 12207:2017
3. IEEE 1471-2000
4. ISO/IEC/IEEE 29148:2018

ISO/IEC/IEEE 29148:2018 'Requirements engineering' reemplaza a esos tres estándares previos de la IEEE; 25010 es un modelo de calidad, 12207 cubre procesos de ciclo de vida y 1471 trata la descripción de arquitectura. (ISO/IEC/IEEE 29148:2018, introducción)

31. Según ISO/IEC/IEEE 29148:2018, ¿cuántas características debe cumplir un requerimiento individual bien formado (por ejemplo, necesario, apropiado, singular y factible, entre otras)?

1. 6
2. 8
3. 9
4. 10

La cláusula 5.2.5 enumera nueve características para requerimientos individuales, una más que las ocho que IEEE 830-1998 exige para la SRS considerada como conjunto; confundir ambos números es un error frecuente. (ISO/IEC/IEEE 29148:2018, cláusula 5.2.5 'Characteristics of individual requirements')

32. ¿Cuál de las siguientes características fue definida por ISO/IEC/IEEE 29148:2018 para requerimientos individuales, pero no aparece entre las ocho características de una SRS según IEEE Std 830-1998?

1. Singular
2. Verificable
3. No ambiguo
4. Correcto

'Singular' (aborda una sola capacidad) es propia de la cláusula 5.2.5 de ISO/IEC/IEEE 29148:2018; verificable, no ambiguo y correcto aparecen, con nombres equivalentes, también en la lista de IEEE Std 830-1998. (ISO/IEC/IEEE 29148:2018, cláusula 5.2.5, comparada con IEEE Std 830-1998, cláusula 4.3)

33. En la redacción de requerimientos según ISO/IEC/IEEE 29148:2018, ¿qué verbo modal se reserva para expresar un requerimiento de cumplimiento obligatorio?

1. Should
2. Shall
3. Will
4. May

La cláusula 5.2.4 reserva 'shall' para requerimientos obligatorios (binding); 'should' indica recomendación, 'will' expresa un hecho o intención y 'may' señala una opción permitida. (ISO/IEC/IEEE 29148:2018, cláusula 5.2.4)

34. Un documento de requerimientos incluye el enunciado: 'El sistema enviará una notificación por correo electrónico cuando se complete el pago.' Si el equipo siguió la convención de verbos modales de ISO/IEC/IEEE 29148:2018 al usar 'enviará' (will), ¿cómo debe interpretarse ese enunciado?

1. Como un requerimiento obligatorio, equivalente en fuerza a 'shall'
2. Como una recomendación opcional, equivalente en fuerza a 'should'
3. Como un permiso o alternativa, equivalente en fuerza a 'may'
4. Como una declaración de hecho o intención, no como un requerimiento obligatorio

Según la cláusula 5.2.4, 'will' describe un hecho o una intención futura, no un compromiso obligatorio como 'shall'; confundir ambos verbos modales es un error común al redactar requerimientos. (ISO/IEC/IEEE 29148:2018, cláusula 5.2.4)

35. Un requerimiento aporta un valor de negocio importante, pero el sistema puede entregarse sin él en el corto plazo porque su ausencia solo genera incomodidad, no una falla crítica. Según la técnica de priorización MoSCoW del marco DSDM, ¿en qué categoría debe clasificarse?

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

'Should have' agrupa requerimientos importantes pero no críticos para la versión actual; 'Must have' sería obligatorio, 'Could have' es deseable de menor impacto y 'Won't have' queda fuera del alcance vigente. (DSDM Consortium, 'MoSCoW Prioritisation')