Ing.Requisitos: Tema 2

¿Cuál es la principal dificultad que enfrenta un analista en la fase de adquisición de requisitos?. La falta de herramientas de software. La complejidad de entender un problema en un mundo real desconocido. La resistencia de los usuarios al cambio.

¿Qué se debe descubrir primero en el entorno del problema para construir la solución?. Los aspectos irrelevantes. Los aspectos que conforman el contexto del sistema. Las limitaciones tecnológicas.

¿Por qué es importante organizar o clasificar el entorno del problema?. Para simplificar la documentación. Para poder manejar la complejidad del problema. Para reducir el número de requisitos.

Según la definición, ¿qué es el contexto del sistema?. Todo el entorno externo al sistema. La parte del entorno relevante para definir, comprender e interpretar los requisitos. Los componentes de hardware y software necesarios.

¿Cuántos límites o fronteras se consideran al definir el contexto del sistema?. Uno. Dos. Tres.

¿Qué separa el límite del contexto?. El sistema de los aspectos relevantes. El contexto del entorno irrelevante. Los aspectos tecnológicos de los aspectos de dominio.

¿Qué define el límite del contexto en otras palabras?. El dominio de la solución. El dominio del problema. El alcance del proyecto.

Los aspectos que están DENTRO del sistema, ¿qué características tienen?. Son estables y no pueden ser cambiados. Pertenecen al dominio de la solución y pueden ser cambiados. Están fuera del control del analista.

Los aspectos que están FUERA de los límites del sistema, ¿cómo se consideran?. Controlables y modificables. Estables y no cambiables. Parte del dominio de la solución.

¿Cuándo se definen los límites del sistema y del contexto?. Al principio del proceso de desarrollo. Solo al final del proceso de desarrollo. A lo largo del proceso de desarrollo de requisitos.

¿Puede un aspecto que inicialmente está fuera del sistema entrar en él durante el desarrollo?. No, los límites son inamovibles. Sí, si se observa que se tiene control sobre él. Solo si el cliente lo solicita explícitamente.

¿Cómo se organiza el contexto para su análisis?. Por tamaño y complejidad. Por tipos y facetas. Por fuentes de información y usuarios.

¿Cuál es el propósito de organizar el contexto por tipos y facetas?. Clasificar todos los elementos del entorno. Evitar la omisión de aspectos relevantes y planificar tareas. Simplificar la arquitectura del sistema.

¿Cuántos tipos de aspectos del contexto se consideran?. Dos. Tres. Cuatro.

¿Qué se entiende por 'Fuentes de requisitos'?. Los objetos físicos que forman parte del sistema. Los documentos y personas que proporcionan información para los requisitos. Las restricciones tecnológicas del sistema.

¿Cuál de los siguientes NO es un ejemplo de 'Fuentes de requisitos'?. Clientes. Manuales de otros sistemas. Objetos materiales como materias primas.

¿Qué son los 'Objetos del contexto'?. Las personas que desarrollarán el sistema. Los conceptos abstractos relevantes para el problema. Personas, objetos materiales o inmateriales relevantes para el sistema.

Un pedido o una factura, ¿a qué tipo de aspecto del contexto pertenecen?. Fuentes de requisitos. Objetos del contexto (inmateriales). Propiedades y relaciones entre objetos.

¿Qué implica el tipo 'Propiedades y relaciones entre objetos'?. Las características físicas de los objetos. Cómo los objetos interactúan entre sí y cuáles son sus atributos. La documentación que describe los objetos.

¿Cuántas facetas del contexto se consideran?. Dos. Tres. Cuatro.

¿Qué aborda la 'Faceta de dominio'?. Cómo será utilizado el sistema. Los aspectos conceptuales del dominio del PROBLEMA. La infraestructura tecnológica necesaria.

¿Qué aspectos se consideran en la 'Faceta de utilización'?. Las restricciones del hardware. Los métodos de desarrollo a seguir. Cómo el sistema será utilizado por personas o interactuará con otros sistemas.

La 'Faceta de aspectos tecnológicos' considera: Las necesidades de los usuarios finales. Las restricciones impuestas por el hardware y software donde funcionará el sistema. La documentación existente sobre el problema.

¿Qué abarca la 'Faceta del proceso de desarrollo'?. Los objetivos generales del sistema. Las herramientas, métodos y estándares para garantizar la calidad del desarrollo. Los posibles usuarios del sistema.

En la 'Faceta de utilización', ¿pueden los usuarios ser una fuente de requisitos y a la vez un objeto del contexto?. No, un elemento solo puede pertenecer a una categoría. Sí, si sus propiedades o relaciones son relevantes para el sistema. Solo si son usuarios administradores.

Ejemplo: Un sistema que solo consulta información pública. El usuario es un actor que interactúa con el sistema. ¿Qué rol cumple principalmente el usuario en este caso?. Objeto del contexto. Fuente de requisitos. Componente tecnológico.

Ejemplo: Un sistema bancario donde el usuario tiene un saldo y extractos. El usuario es actor y también un objeto con propiedades. ¿Qué rol cumple el usuario en este caso?. Solo fuente de requisitos. Solo objeto del contexto. Fuente de requisitos y objeto del contexto.

¿Cuál es el propósito principal de considerar las 'parcelas' (tipo, faceta) del contexto?. Clasificar exhaustivamente todos los elementos. Descubrir aspectos relevantes del contexto para el sistema. Definir los límites exactos del sistema.

¿Qué tipo de aspecto del contexto serían 'Clientes'?. Objetos del contexto. Fuentes de requisitos. Faceta de utilización.

¿Qué tipo de aspecto del contexto serían 'Materias primas'?. Objetos del contexto (materiales). Fuentes de requisitos. Faceta de dominio.