El responsable directo de la elaboración del documento de “especificación de requerimientos de software” es el: Cliente Usuario Analista.
Se considera como la base para el diseño, la implementación y las pruebas del sistema, al: Plan de especificación de requerimientos Alcance del sistema Especificación de requerimientos de software.
La primera actividad en la fase de especificación de requerimientos consiste en: Documentar los requerimientos de usuario Verificar las necesidades del usuario Documentar los requerimientos de software.
Cuando se requiere que los interesados comprueben que los requisitos están completos, consistentes y que sean de alta calidad, se necesita: Verificar las necesidades del usuario. Documentar los requerimientos de usuario. Documentar los requerimientos de software.
Cuando en la especificación se describen los requisitos funcionales, los atributos de calidad, las interfaces de sistema y las limitaciones de diseño e implementación, se requiere: Verificar las necesidades del usuario. Documentar los requerimientos de usuario. Documentar los requerimientos de software.
Comprobar que los requisitos de software se derivan de las necesidades de usuario, de los requisitos de sistema y otras fuentes, se conoce como: Verificación de requerimientos de software. Documenta los requerimientos de usuario. Documenta los requerimientos de software.
Cuando se requiere documentar y verificar requerimientos de usuario se debe crear: El documento de requerimientos de usuario. El documento de especificación de requerimientos de software. El documento de visión.
Al documento que contiene de forma conjunta y completa los requerimientos funcionales y no funcionales que el producto debe cumplir, se denomina: El documento de requerimientos de usuario. El documento de especificación de requerimientos de software. El documento de visión.
Cuando la especificación de requerimientos de software exige a los grupos de interesados a considerar rigurosamente todos los requerimientos antes que inicie el diseño, se conoce como: Reducir el esfuerzo en el desarrollo. Facilitar la transferencia. Proveer bases para la estimación de costos y cronogramas.
Cuando la ERS refleja una necesidad real y el sistema implementado es el deseado, se refiere al atributo: Correcto. Completo. Consistente.
El documento donde se especifican los requerimientos de software está destinado al: Sponsor Analista (miembro del equipo de desarrollo) Cliente.
Cuando se conoce el origen de cada requisito y se facilita la referencia de cada requisito a los componentes de diseño e implementación, se refiere al atributo de: Trazable. Consistente. Completo.
Las referencias a normas GUI o lineamientos de estilo que se deben seguir, se incluyen en las descripciones de: Interfaz de usuario Interfaz de software Interfaz de hardware.
Las tecnologías específicas, herramientas, lenguajes de programación y bases de datos que podrían ser usadas, se describen en la ERS en la sección de: Restricciones de diseño e implementación. Suposiciones y dependencias. Características del sistema.
Establecer ciertas funciones que el sistema pueda utilizar en cuanto a correo electrónico, explorador web, protocolos de red de comunicación y formularios web; se necesitan definir: Requerimientos de interfaz externa - La interfaz de hardware. Requerimientos de interfaz externa - La interfaz de usuario. Requerimientos de interfaz externa - La interfaz de comunicaciones.
Es una descripción que incluye los tipos de dispositivos compatibles, las interacciones de datos y controles entre el software y hardware; para esto se necesita definir: Requerimientos de interfaz externa - La interfaz de hardware. Requerimientos de interfaz externa - La interfaz de usuario. Requerimientos de interfaz externa - La interfaz de comunicaciones.
“Cada usuario debe cambiar su contraseña de inicio de sesión asignado inicialmente inmediatamente después de su ingreso por primera vez”. Es un ejemplo de: Requerimiento de desempeño Requerimiento de protección Requerimiento de seguridad.
“El sistema pondrá fin a cualquier operación dentro de 1 segundo si la presión media del tanque supera el 95% de la presión máxima especificada”. Es un ejemplo de: Requerimiento de desempeño Requerimiento de protección Requerimiento de seguridad.
Cuando la demanda del uso de la base de datos con respecto a los tiempos de respuesta puede llevar a los diseñadores a establecer a la base de datos en múltiples localizaciones geográficas, es un caso de: Requerimiento de desempeño. Requerimiento de protección. Requerimiento de seguridad.
Al proceso de comprobar que los requisitos fueron especificados de acuerdo a las necesidades de los clientes, se conoce como: Especificación. Desarrollo. Validación.
El proceso de validación de requisitos consiste en: Pruebas funcionales. Pruebas unitarias. Seleccionar e integrar técnicas, participación del usuario, validar los requisitos y revisar la documentación.
El costo de corregir un error en las etapas finales es de: 1 a 5 veces. 10 a 100 veces. 95 a 100 veces.
Cuando se requiere revisar y documentar los requerimientos se debe realizar: Crear pruebas de validación Revisión de pares Mostrar partes del sistema.
Cuando se requiere validar los modelos, se debe: Realizar pruebas sobre modelos de requerimientos. Revisión de pares. Mostrar partes del sistema.
Cuando se requiere realizar pruebas de aceptación por parte del usuario, se debe: Realizar pruebas sobre modelos de requerimientos. Crear pruebas de validación. Mostrar partes del sistema.
Cuando existen errores en cuanto a colores, fuentes y las demostraciones de interfaz que son menos que deseables pueden ser corregidos en algún tiempo futuro, se refiere a un nivel de severidad: Visual. Análisis. Herramienta.
Cuando se determina que es imposible continuar con las pruebas, se refiere a un nivel de severidad: Alto. Mediano. Critico.
Cuando las pruebas pueden continuar, pero el sistema no se puede implementar con este problema, se refiere a un nivel de severidad: Alto Mediano Critico.
Cuando las pruebas pueden continuar y el sistema es probable que se siga desarrollando con algunas salidas de funcionalidad del negocio acordado, se refiere a un nivel de severidad: Alto Mediano Critico.
Se utilizan simulaciones de pruebas en lugar de casos de prueba real para pasar por múltiples modelos de análisis. Esto se denomina: Modelos de validación. Prototipos operacionales. Prototipos visuales.
Permite demostrar si los modelos son compatibles entre ellos: Prototipos operacionales. Modelos de validación. Pruebas de aceptación.
Para realizar la validación de debe realizar los siguientes pasos: Corregir los modelos. Rastrear los modelos a través de los casos de prueba paso a paso. Identificar y crear casos de prueba; seleccionar modelos, rastrear los modelos y corregir los modelos.
Puede ser desarrollado en: papel, un ejecutable del sistema o utilizar algún sistema. Esto es una validación basada en: Prototipo de rendimiento. Prototipo de interfaz de usuario. Prototipo funcional.
Va orientado a los desarrolladores con el fin de comprobar la funcionalidad de los componentes de la solución que se está desarrollando. Es una validación basada en: Prototipo de rendimiento. Prototipo de interfaz de usuario. Prototipo funcional.
Es una versión limitada de la solución desarrollada. No se aplica a la ingeniería de requisitos: Prototipo de rendimiento. Prototipo de interfaz de usuario. Prototipo funcional.
El proceso de prototipado consiste en: Desarrollar el prototipo. Validar el prototipo. Determinar los requisitos, desarrollar y evaluar el prototipo.
Consiste en tener una comprensión y control de los cambios de cada uno de los requisitos. A esto se conoce como: Trazabilidad. Gestión de requisitos. Redundancia.
Consisten en determinar el ciclo de vida de los requisitos, además de que cada uno de estos posee su propia identificación, diferenciándolo de los demás. A esto se conoce como: Trazabilidad. Gestión de requisitos. Redundancia.
Asegurar que los clientes entienden y aceptan los cambios en los requisitos, se logra al aplicar: Realizar matrices de trazabilidad. Definir atributos de los requerimientos. Control de cambios.
Cuando se desea entender la procedencia de los requerimientos y sus relaciones, se debe crear: Atributos de requerimientos. Políticas y procedimientos de control de cambios. Matrices de trazabilidad de requerimientos.
|
