Ingeniería de Requisitos Parcial 2

¿Cómo se define formalmente una Especificación de Requisitos?. Como un plan de fabricación que delimita los costes del diseño arquitectónico y las garantías del sistema. Como una descripción informal orientada en exclusiva a los programadores para codificar lógica formal. Como un documento formal que describe las funciones, restricciones, y atributos de un sistema software, así como sus interfaces externas. Como un glosario técnico que traduce las métricas de rendimiento en diagramas de estados lógicos.

Desde la perspectiva de los roles del proyecto, ¿cuál es el objetivo principal de la especificación de requisitos para el usuario o cliente?. Iniciar el diseño arquitectónico y apoyar el proceso de pruebas automáticas. Controlar la evolución continua del sistema y cuantificar los ingresos con puntos de función. Definir claramente qué se quiere y qué no se quiere del sistema. Limitar la intervención de analistas externos para agilizar el plan de entregas.

¿Qué objetivos persigue el desarrollador al utilizar el documento de especificación de requisitos?. Identificar errores de compilación, modelar amenazas por diseño y validar el hardware. Estimar el presupuesto, redactar las garantías del software y diseñar la interfaz gráfica final. Facilitar la comunicación con usuarios/clientes, iniciar el diseño, apoyar el proceso de pruebas, y controlar la evolución del sistema. Sustituir la documentación informal, evitar pre-revisiones y estructurar axiomas algebraicos.

¿Qué elementos deben formar parte del contenido de un buen Documento de Requisitos?. Aspectos de planificación, diseño detallado y garantías comerciales del fabricante. Descripción del problema, interfaz externa, propiedades, comportamiento, restricciones de diseño/fabricación, ayuda a usuarios y restricciones tecnológicas/no funcionales. El árbol completo de decisiones del cliente, los esquemas de bases de datos externas y las firmas de la reunión diaria. Las precondiciones algebraicas de los tipos abstractos de datos y las variables de estado de las redes de Petri.

¿Qué aspectos quedan explícitamente excluidos y NO deben incluirse en un documento de requisitos?. Las restricciones tecnológicas y las propiedades de rendimiento o fiabilidad. La descripción de cómo el sistema ayudará a los usuarios en su entorno. Las interfaces externas del sistema y el modo en que interactúa con su entorno. Aspectos de planificación, diseño detallado o garantías.

¿Qué diferencia fundamental existe entre un Documento de Requisitos de Usuario (DRU) y una Especificación de Requisitos de Software (ERS/SRS)?. El DRU recoge necesidades desde la perspectiva del usuario sin mucho detalle técnico; la ERS adopta la perspectiva del desarrollador y es más detallada y técnica. El DRU es un documento estrictamente matemático; la ERS utiliza siempre lenguaje natural informal. El DRU detalla las restricciones de fabricación y código; la ERS se limita a esbozar el propósito y la audiencia. El DRU es gestionado por el Scrum Master; la ERS es un artefacto exclusivo del Product Owner.

Según la norma IEEE 830, ¿cuándo se considera que una especificación de requisitos es "No ambigua"?. Cuando incluye todas las funciones esperadas y las respuestas a entradas válidas y erróneas. Cuando cada término tiene un solo significado, incluyendo un glosario si es necesario. Cuando se puede probar objetivamente mediante un caso de prueba concreto. Cuando no condiciona soluciones específicas ni decisiones de diseño detallado.

¿Qué significa que una especificación sea "Completa" de acuerdo con las características de la norma IEEE 830?. Que se puede implementar con los recursos técnicos y económicos disponibles. Que no es más extensa de lo estrictamente necesario. Que incluye todas las funciones esperadas, respuestas a entradas válidas/erróneas, y todos los casos posibles. Que cada requisito se encuentra anotado según su obligatoriedad y probabilidad de cambio.

Dentro de las características de la norma IEEE 830, ¿cómo se define un requisito "Verificable"?. Aquel que satisface necesidades reales de los clientes de forma económica. Aquel que se puede probar objetivamente. Aquel que resulta fácil de actualizar sin introducir inconsistencias en el sistema. Aquel que utiliza únicamente lenguaje natural sin notaciones formales.

¿Qué implica que un requisito esté anotado por su "Importancia y estabilidad" en una ERS?. Que relaciona de manera exacta los requisitos vinculados mediante referencias cruzadas. Que define un tipo abstracto de datos independiente de la representación interna. Que debe indicar su obligatoriedad y la probabilidad de cambio. Que resulta comprensible por todos los usuarios potenciales del software.

¿Qué significa textualmente que un documento de requisitos sea "Independiente del diseño"?. Que se encuentra almacenado electrónicamente para su fácil distribución. Que no es más extenso de lo estrictamente necesario para el desarrollador. Que no condiciona soluciones específicas. Que utiliza valores numéricos precisos en lugar de descripciones cualitativas.

¿Cuál es el orden de las tres grandes secciones que componen la Estructura Estándar de la norma IEEE 830?. 1. Descripción del problema, 2. Prototipado, 3. Casos de prueba. 1. Introducción, 2. Gestión de cambios, 3. Triage de requisitos. 1. Introducción, 2. Descripción General, 3. Requisitos Específicos. 1. Perspectiva del usuario, 2. Interfaces externas, 3. Especificación algebraica.

¿Cuáles son los cuatro subapartados que integran la sección de "Introducción" en el estándar IEEE 830?. Perspectiva del producto, Funciones principales, Características de los usuarios y Restricciones generales. Interfaces externas, Requisitos funcionales, Requisitos de rendimiento y Atributos de calidad. Propósito y audiencia, Ámbito, Definiciones y referencias, y Visión global. Identificación, Análisis, Decisión e Implementación.

Si necesitas consultar las "Características de los usuarios" o las "Suposiciones y dependencias", ¿en qué sección de la estructura estándar IEEE 830 se encuentran?. Introducción. Descripción General. Requisitos Específicos. Glosario y Referencias Cruzadas.

¿En qué sección de la norma IEEE 830 se deben ubicar los "Atributos de calidad (fiabilidad, mantenibilidad, seguridad, etc.)"?. Introducción. Descripción General. Requisitos Específicos. Anexo de Ingeniería Progresiva.

En sistemas sensibles, ¿qué directriz de especificación se considera especialmente crítica?. No especificar requisitos obvios usando el sentido común. Especificar tanto lo que el sistema debe hacer como lo que no debe hacer. Utilizar herramientas CASE sofisticadas para almacenar electrónicamente la información. Definir únicamente interfaces basadas en el enfoque algebraico.

¿Qué es una "Especificación formal"?. Un documento redactado en lenguaje claro y accesible estructurado por estimulaciones externas. Una maqueta funcional que los usuarios evalúan mediante escenarios reales de trabajo. Una descripción escrita y aprobada de acuerdo con estándares, expresada en lenguajes matemáticos (teoría de conjuntos, lógica y álgebra). Una lista priorizada de tareas e historias de usuario acordadas en la planificación del sprint.

¿Qué componentes integran conceptualmente un "Método formal"?. Lenguaje natural + Prototipado + Historias de usuario. Especificación formal + análisis/verificación + prueba de programas. Análisis de inventario + Ingeniería inversa + Ingeniería progresiva. Matrices de trazabilidad + Puntos de función + Triage.

¿Cuáles son los principales inconvenientes o limitaciones de las especificaciones formales?. Aumentan la ambigüedad y empeoran la calidad de la documentación del ciclo de vida. Incrementan el coste de corrección de errores en las etapas iniciales de la especificación. Limitan la intervención del cliente, requieren formación avanzada, no son escalables para sistemas muy grandes ni están adaptados para interfaces de usuario. Impiden la comprobación automática de la consistencia y la completitud de los requisitos.

¿En qué tipo de aplicaciones se utilizan principalmente los métodos formales debido a su necesidad de rigor?. En aplicaciones web comerciales de corta vida útil y entornos de comercio electrónico. En maquetas rápidas de interfaces de usuario y guías de estilo visuales. En sistemas críticos (aeronáutica, medicina, espacio). En proyectos ágiles gestionados puramente bajo marcos de trabajo Scrum.

¿Cómo define las interfaces el "Enfoque Algebraico" dentro de la especificación formal?. Como un modelo de estados con precondiciones y postcondiciones explícitas. Como tipos abstractos de datos (TAD), indicando sólo las operaciones disponibles, no la representación interna. Mediante redes de Petri orientadas a flujos continuos de control asíncrono. Utilizando las notaciones lógicas comerciales Z, VDM y B.

¿Cuál es la estructura típica que se emplea en el Enfoque Algebraico?. Precondición, Postcondición, Restricción de diseño y Atributo de calidad. Identificación, Análisis, Decisión e Implementación. Nombre de clase, operaciones, sintaxis (signatura) y axiomas (comportamiento de operaciones). Estado inicial, variables de entorno, entradas erróneas y salidas válidas.

¿Cómo expresa el sistema el "Enfoque Basado en Modelos" y qué notaciones utiliza?. Como un modelo de estados (variables de estado y operaciones que modifican este estado) usando notaciones como Z, VDM, B, CSP o Redes de Petri. Como un árbol de decisiones jerárquico usando puntos de función y matrices CASE. Mediante un conjunto de historias de usuario con la plantilla de rol, meta y beneficio. Mediante signaturas lógicas orientadas a la definición del glosario de la norma IEEE 830.

En el Enfoque Basado en Modelos de la especificación formal, ¿qué elementos definen exactamente los llamados "esquemas"?. Nombre de clase, operaciones disponibles, sintaxis y axiomas de comportamiento. El Product Backlog, las historias de usuario y el Sprint Backlog. Variables de estado, restricciones, operaciones, precondiciones y postcondiciones. El coste, el esfuerzo, las dependencias físicas del hardware y las garantías del sistema.

¿Cuál es el uso idóneo y diferenciado de los métodos algebraicos frente a los basados en modelos?. Los métodos algebraicos describen el manual de usuario; los basados en modelos definen la interfaz gráfica de usuario (GUI). Los métodos algebraicos son ideales para especificar interfaces; los modelos, para describir estados y comportamiento del sistema. Los métodos algebraicos se aplican a metodologías ágiles; los basados en modelos son exclusivos de la ingeniería de requisitos tradicional. Los métodos algebraicos miden los puntos de función; los basados en modelos generan los árboles de decisión del cliente.

¿Cuál es la relación idónea entre la especificación formal y la especificación informal?. La especificación formal sustituye por completo a la especificación informal en cualquier tipo de software. La especificación formal se complementa (no sustituye) con la especificación informal: ayuda a clarificar ambigüedades y evitar malas interpretaciones. La especificación informal se utiliza para las interfaces de sistemas críticos y la formal para las interfaces de usuario. No existe ninguna relación, ya que pertenecen a fases del ciclo de vida de desarrollo de software totalmente opuestas.

En una especificación formal de un sistema bancario donde el cierre de cuenta exige que el saldo sea cero, ¿bajo qué condición estricta se permite dicha operación?. Solo si el cliente se identifica con un DNI válido y vigente. Solo si el cliente realiza una extracción de efectivo previa en la caja. Solo si el saldo es exactamente cero. Solo si la cuenta está anotada como estable y de alta importancia.

¿En qué consiste el proceso de "Validación de requisitos" y qué atributos comprueba?. En reescribir la especificación técnica en historias de usuario ágiles evaluando su coste y esfuerzo. En comprobar que el documento de requisitos describe el sistema que realmente necesita el usuario, cumpliendo atributos como validez, consistencia, completitud, realismo y verificabilidad. En negociar e implementar cambios en los requisitos del software durante el mantenimiento. En almacenar electrónicamente las matrices de trazabilidad interna y hacia adelante.

Dentro de los atributos de validación, ¿qué diferencia existe entre "Consistencia" y "Realismo"?. Consistencia significa que incluye todas las funciones; Realismo significa que satisface las necesidades del cliente. Consistencia evalúa los costes del software; Realismo mide el tiempo de pruebas automáticas. Consistencia implica que no hay contradicciones entre requisitos; Realismo implica que se puede implementar con los recursos disponibles. Consistencia obliga a usar lenguajes matemáticos; Realismo permite emplear historias de usuario informales.

¿En qué momento se debe realizar el proceso de validación de requisitos?. Únicamente durante la retrospectiva del último sprint del proyecto. Antes de redactar la primera versión del Documento de Requisitos de Usuario (DRU). Cuando se tiene una primera versión de los requisitos. Al finalizar el desarrollo del código para redactar el manual de usuario.

En las técnicas de revisión de requisitos, ¿qué son las "Pre-revisiones"?. Evaluaciones matemáticas rigurosas realizadas por el Product Owner de manera diaria. Revisiones rápidas e informales para detectar errores fáciles antes de la revisión formal. Pruebas detalladas con datos de entrada y resultados esperados automáticos. Simulaciones de la interfaz gráfica original aprovechando componentes gráficos del servidor.

Al utilizar la técnica de "Prototipado" para validar requisitos, ¿cómo se evalúa la maqueta o prototipo construido?. Aplicando álgebra formal sobre las operaciones internas del sistema. Mediante checklists distribuidos en reuniones formales de analistas externos. Mediante escenarios o tareas reales por parte de usuarios y clientes para obtener feedback. Verificando que cumpla el modelo de 3 capas en un entorno cliente/servidor.

¿Qué condición se debe cumplir para asegurar que un requisito es verdaderamente "Verificable" según la técnica de casos de prueba?. Que esté libre de valores numéricos o restricciones tecnológicas complejas. Que haya sido aprobado de forma unánime en una reunión informal de pre-revisión. Que se pueda diseñar un caso de prueba concreto con datos de entrada, acciones y resultados esperados. Que esté redactado en un lenguaje formal matemático basado en modelos (como Z o VDM).

Además de las revisiones, el prototipado y los casos de prueba, ¿qué otras tres técnicas de validación existen?. Manual de usuario, Animación/modelos y Demostraciones formales. Puntos de función, Glosario de términos e Historias de usuario. Identificación de riesgos, Matrices de trazabilidad y Triage de releases. Daily meetings, Retrospectivas y Evaluaciones de Impacto en Protección de Datos.

¿Qué impacto cuantitativo aproximado tiene la localización y corrección temprana de defectos en los requisitos?. Reduce el coste un 50% y el tiempo de codificación un 90%. Reduce el coste un 25-30% y el tiempo de pruebas un 50-90%. Incrementa el beneficio neto un 10-15% sin alterar el tiempo de pruebas unitarias. Ahorra un 5% en la gestión de cambios y duplica las referencias cruzadas de la IEEE 830.

Ante un requisito ambiguo como “El sistema debe ser seguro”, ¿cuál es una reformulación correcta y verificable?. “El sistema tiene que asegurar la total y completa invulnerabilidad de los datos lógicos”. “El sistema se desarrollará de acuerdo con las guías oficiales de aeronáutica espacial”. “El sistema deberá bloquear la cuenta tras 3 intentos fallidos de acceso”. “El sistema obligará a usar el ratón y el teclado de forma cifrada”.

¿Qué es la "Gestión de requisitos" y qué actividades abarca?. Es la disciplina matemática que formaliza las interfaces lógicas utilizando el enfoque algebraico. Es la fase inicial encargada de construir prototipos rápidos para evitar la resistencia al cambio del cliente. Es la disciplina que controla y supervisa los requisitos durante todo el ciclo de vida del software, incluyendo su desarrollo, especificación, verificación, gestión de cambios y selección para versiones. Es el evento de Scrum donde el equipo de desarrollo estima las tareas de programación mediante puntos de función.

¿Por qué factores cambian los requisitos de forma habitual durante el ciclo de vida de un sistema?. Por la falta de información, la resistencia al cambio y las quejas de los usuarios finales. Por errores en el código fuente, interfaces de usuario obsoletas o bases de datos no relacionales. Por nuevas prioridades de negocio, avances tecnológicos o cambios legales. Por fallos detectados en las pre-revisiones informales o checklists incompletos.

¿Cuáles son las cuatro etapas secuenciales que componen el proceso de "Gestión de cambios"?. Concepto, Contenido, Contexto y Clasificación. Identificación, Análisis, Decisión e Implementación/Rechazo. Introducción, Descripción General, Requisitos Específicos y Validación. Trazabilidad hacia atrás, Trazabilidad hacia adelante, Trazabilidad interna y Triage.

Durante la gestión de cambios, ¿qué se evalúa concretamente en la fase de "Análisis"?. La veracidad de la firma del usuario que solicita la modificación. El impacto del cambio (coste, esfuerzo, dependencias en todo el sistema). Las precondiciones algebraicas de las variables de estado afectadas. La reestructuración del código veterano según el modelo de 3 capas.

¿Cómo puede modelarse el proceso final de "Implementación/Rechazo" de un cambio?. Como una especificación algebraica de tipos abstractos de datos. Como un árbol de decisiones. Como un diagrama de estados o actividades basado en el teclado y ratón. Como una lista priorizada dentro del Sprint Backlog.

¿Cómo se define la trazabilidad de requisitos "Hacia atrás"?. Es la que vincula cada requisito con el diseño, código, pruebas y demás productos generados. Es la que relaciona los requisitos entre sí, permitiendo identificar dependencias y agrupaciones. Es la que relaciona cada requisito con su fuente (cliente, documento, entrevista). Es la que conecta las variables de estado con las postcondiciones del modelo formal Z.

¿Cuál es la definición de la trazabilidad de requisitos "Hacia adelante"?. Es el atributo mediante el cual cada requisito puede vincularse con el diseño, código, pruebas y demás productos generados. Relaciona los requisitos con sus orígenes históricos mediante herramientas CASE. Permite identificar dependencias internas y agrupaciones lógicas dentro del catálogo. Determina la probabilidad de cambio de una funcionalidad en lanzamientos futuros.

¿Cómo se define formalmente la trazabilidad "Interna"?. Es la que relaciona cada requisito con su fuente original, como clientes o entrevistas. Es la que vincula cada requisito con los productos derivados como el diseño, código y pruebas. Es la que relaciona requisitos entre sí, permitiendo identificar dependencias y agrupaciones. Es la que extrae abstracciones lógicas utilizando herramientas CASE para sistemas grandes.

¿Qué es el "Triage" en el contexto de la gestión de requisitos?. Una técnica de revisión formal basada en checklists y analistas externos al proyecto. El modelado de amenazas informáticas para implementar la seguridad por diseño. El proceso de decidir qué requisitos se implementan en cada versión del producto, buscando el máximo beneficio. La corrección automática de contradicciones internas en la especificación IEEE 830.

¿Qué criterios clave se deben considerar al realizar el triage de requisitos?. El uso de lenguaje natural, las pre-revisiones informales y los diagramas de actividades de la GUI. La audiencia de la introducción, el glosario de términos y el número de analistas externos. Estabilidad, importancia, referencias cruzadas y dependencias con otros requisitos, además de cuantificar gastos e ingresos. Los principios del Manifiesto Ágil, las reuniones diarias y los artefactos de Scrum.

Durante el proceso de triage, ¿qué métrica se utiliza habitualmente para cuantificar los gastos e ingresos asociados a cada requisito?. Las matrices de trazabilidad hacia adelante. Las horas de esfuerzo estimadas por el Scrum Master. Los puntos de función. Los axiomas de comportamiento de las operaciones formales.

¿Qué priorizan las metodologías ágiles según los principios del Manifiesto Ágil?. Los procesos sobre las interacciones, la documentación exhaustiva sobre el software y los contratos sobre la colaboración. La entrega temprana y frecuente de funcionalidades útiles, la adaptación al cambio, el trabajo en equipo, los individuos y colaboración sobre procesos, y software funcionando sobre documentación. La trazabilidad matemática completa, las especificaciones formales algebraicas y la validación formal antes del desarrollo. El diseño detallado del sistema, la planificación rígida a largo plazo y las garantías del fabricante.

En contraste con la ingeniería de requisitos tradicional, ¿cómo se gestiona la recolección de requisitos y la documentación en el enfoque ágil?. Se redacta una especificación exhaustiva bajo la norma IEEE 830 y se busca una trazabilidad inmutable y fija. Se prohíbe la participación del cliente para evitar cambios en las prioridades técnicas del equipo de desarrollo. Es más flexible y continua (reuniones frecuentes, entrevistas, priorización constante), usando documentación ligera e historias de usuario. Se emplean exclusivamente lenguajes matemáticos (Z, VDM) para modelar las variables de estado en cada iteración.

Dentro del marco Scrum, ¿cuál es la función exacta del rol del "Product Owner"?. Facilitar la metodología de trabajo y solucionar todos los obstáculos del equipo. Gestionar y priorizar las necesidades del cliente y definir criterios de aceptación. Analizar y crear el producto software de forma multidisciplinar. Auditar de forma externa la calidad del documento de requisitos mediante checklists.

¿Cómo se definen textualmente las funciones del "Equipo de desarrollo" y del "Scrum Master"?. Equipo de desarrollo: multidisciplinar, encargado de analizar y crear el producto; Scrum Master: facilita la metodología y soluciona obstáculos. Equipo de desarrollo: gestiona las necesidades del cliente; Scrum Master: define los criterios de aceptación. Equipo de desarrollo: audita externamente los requisitos; Scrum Master: se encarga de programar el código en su totalidad. Equipo de desarrollo: redacta el documento formal ERS; Scrum Master: realiza la demostración matemática formal.

¿Qué es una "Historia de usuario" y cuál es su estructura formal estándar?. Un diagrama de estados que modela el comportamiento interactivo del teclado y el ratón. Una especificación detallada de restricciones no funcionales medida en puntos de función. Una descripción corta de una función vista desde el usuario final que sigue la plantilla: “Como [rol], quiero [meta], para [beneficio]”. Un documento de requisitos técnicos que define las precondiciones del modelo relacional.

¿Qué diferencias de definición existen en Scrum entre los artefactos "Product Backlog" y "Sprint Backlog"?. El Product Backlog recoge las restricciones de hardware; el Sprint Backlog almacena las variables de estado formales. El Product Backlog es la lista priorizada de requisitos y funcionalidades; el Sprint Backlog es la lista de tareas del Sprint actual. El Product Backlog pertenece en exclusiva al cliente; el Sprint Backlog lo redactan los analistas externos. El Product Backlog contiene los datos sensibles; el Sprint Backlog contiene los componentes gráficos de la GUI.

Vinculando los eventos de Scrum, ¿qué actividad se realiza específicamente durante la "Planificación de Sprint"?. Se presenta al cliente el avance logrado y el software funcional construido. Se reúne diariamente el equipo para coordinar las tareas técnicas de las últimas 24 horas. Se acuerda qué funcionalidades se van a desarrollar. Se analiza cómo mejorar el funcionamiento del equipo y el proceso metodológico.

¿En qué evento de Scrum se realiza la presentación del avance logrado en el producto?. Daily Meeting. Retrospectiva. Revisión de Sprint. Triage de Versiones.

¿Cuál es la finalidad exacta del evento de Scrum denominado "Retrospectiva"?. Presentar al cliente el avance logrado y el incremento de software funcional. Reunirse diariamente durante 15 minutos para coordinar las tareas del equipo. Acordar de forma colaborativa qué funcionalidades se van a desarrollar en el ciclo corto. Analizar cómo mejorar el equipo y el proceso.

Con respecto a la seguridad y la privacidad en el desarrollo de software, ¿qué principios se deben integrar desde la fase de requisitos?. Seguridad por animación y verificación algebraica formal. Seguridad “por defecto y por diseño”. Trazabilidad retrospectiva y validación mediante maquetas físicas. Seguridad por aislamiento físico del Product Backlog.

¿En qué situación se especifica que se debe realizar una Evaluación de Impacto en Protección de Datos (EIPD)?. Siempre que se utilice documentación ligera o historias de usuario en un Sprint Backlog. Al redactar la introducción y el ámbito del producto según el estándar IEEE 830. Cuando existe un alto riesgo sobre los derechos de las personas (tratamiento de grandes volúmenes, datos sensibles, perfiles, etc.). Cuando no se pueden generar casos de prueba concretos para los requisitos funcionales.

¿Qué técnica se recomienda emplear en la fase de requisitos para identificar y documentar los requisitos de seguridad y privacidad?. Especificación algebraica de tipos abstractos de datos (TAD). Revisiones informales rápidas o pre-revisiones con checklists de usuario. Técnicas de modelado de amenazas. Planificación de lanzamientos basada en puntos de función.