¿Cuál es el objetivo principal de la fase de obtención de requisitos?	Identificar las necesidades de las partes interesadas y resolver los conflictos entre ellas si los hubiera, así como convertir dichas listas de necesidades y restricciones en los requisitos del proyecto para que los desarrolladores puedan implementarlo.
¿Cuáles son las principales consecuencias de no conseguir un buen resultado en la fase de obtención de requisitos?	La mayor consecuencia sería que el resultado final no refleje lo que el cliente quería. Y realizar cambios en los requisitos en una fase avanzada de desarrollo sería muy costoso.
¿Cuáles son las actividades fundamentales de la obtención de requisitos?	Estudiar y entender el dominio de la aplicación, identificando la información relevante, listando, refinando y documentando la lista de necesidades, integrar la lista de varias partes interesadas y determinar los requisitos no funcionales.
¿Por qué las actividades de la fase de obtención de requisitos se ejecutan varias veces de forma iterativa?	En el posterior desarrollo se pueden elaborar modelos o prototipos que aporten nuevas ideas al cliente, o que muestren la necesidad de requisitos adicionales o contradictorios, requiriendo por tanto nuevas rondas de consulta y obtención de requisitos para garantizar un cumplimiento satisfactorio de las necesidades del cliente.
¿Qué ventajas aporta que el analista tenga conocimientos del dominio del problema?	Cuando el analista tiene conocimientos del dominio del problema facilita obtener los detalles del problema planteado de forma fiable y con más facilidad para encontrar los errores o problemas que podría traer la solución planteada
¿Qué problemas pueden aparecer al integrar la lista de necesidades y requisitos de las distintas partes interesadas?	Incoherencias o conflictos de intereses entre las partes interesadas.
¿Cuáles son los criterios de calidad que debe cumplir una buena descripción de requisitos?	Que sea unívoca, completa, verificable, consistente, modificable, trazable y usable durante la operación y el mantenimiento del sistema.
¿Qué problemas pueden surgir si la descripción de requisitos no cumple cada uno de esos criterios de calidad?	De ámbito, donde el requisito puede reunir demasiada o demasiada poca información De comprensión, tanto entre usuarios como analistas De volatilidad, donde los requisitos cambian de forma, aparecen y desaparecen.
¿Qué acciones podría tomar el analista para solventar algunos de los problemas que se consideran más habituales en la obtención de requisitos?	Definir correctamente los límites del sistema, no aportar información innecesaria, informarse para conocer el dominio del problema, evitar requisitos vagos y difíciles de probar y comunicarse con el usuario para asegurarse correctamente de qué es lo que necesita el cliente.
¿Con qué problemas nos podemos encontrar si no se delimita correctamente cuál es el ámbito del sistema?	Se corre el riesgo de obtener una especificación incompleta de los requisitos porque los requisitos que se definan para el sistema no se ajusten a los objetivos de la organización.
¿Qué se determina cuando se establece cuál es el ámbito del sistema?	Se determina de que se responsabiliza el sistema que se va a construir y de que se responsabiliza el entorno del mismo.
¿Por qué los requisitos no deben incluir cuestiones de diseño?	Los requisitos solo deberían tratar cuáles son los objetivos del sistema, no como llegar a ellos. El objetivo principal no es el diseño del programa, sino los beneficios que proporcionará.
¿Qué acciones puede tomar el analista para resolver algunos de los posibles problemas de comunicación?	Haciendo preguntas aclaratorias con entrevistas y cuestionarios, intentando hacer un correcto análisis de tareas y dominio para comprobar que lo que se pide no es contradictorio; y creando prototipos, escenarios y storyboards para que el cliente confirme que es lo que desea
Enumere algunas de las posibles fuentes de cambios en los requisitos a lo largo del proyecto.	La evolución de las necesidades de los usuarios a lo largo del tiempo, los cambios en la organización de la empresa o cambios en los usuarios.
Explique por qué los métodos iterativos son capaces de integrar los cambios en los requisitos mejor que la metodología en cascada.	Mediante los métodos iterativos, los desarrolladores pueden implementar cualquier cambio y adaptarlo más fácilmente al proyecto. En caso de que ocurra un error, no se perdería tanto tiempo como en una metodología en cascada, donde se realiza una tarea tras otra sin volver atrás, y en caso de algún cambio o problema, habría que rehacer gran parte del trabajo de nuevo. En resumidas cuentas, mejora eficazmente la flexibilidad del proyecto.
¿Cuáles son las responsabilidades fundamentales de los clientes y del analista durante la obtención de requisitos?	La responsabilidad del cliente recae en involucrarse y comprometerse lo suficiente aportando la información necesaria al analista, este último tiene la responsabilidad de identificar correctamente sus necesidades y explicarle la situación (lo que se espera de él) para que no se produzca ningún tipo de malentendido y sin imponer su punto de vista, de manera que la descripción del sistema sea formal para que el equipo de desarrollo pueda construir el sistema pero de manera que el cliente lo comprenda y valide.
¿Cuál es la diferencia entre una entrevista estructurada y una no estructurada?	La diferencia es que en las entrevistas estructuradas el entrevistador viene con una serie de preguntas para el cliente preparadas de antemano, mientras que en las entrevistas sin estructura el proceso y la dirección de las preguntas es más improvisado y orientado a una conversación.
¿Cuándo es más conveniente usar cada tipo de entrevista?	Las entrevistas no estructuradas son más útiles al inicio del proceso, donde se tienen que aclarar grandes cuestiones sobre el sistema o su entorno. Y las entrevistas estructuradas convienen más posteriormente, cuando se necesite especificar más profundamente el proyecto, ya con un conocimiento previo del entorno del sistema y las características de este.
¿Cuál es la diferencia principal entre las entrevistas y el uso de cuestionarios?	Un cuestionario es una lista de preguntas que se envían a las partes interesadas, para así para capturar requisitos, útil cuando se debe obtener información de muchos usuarios o es difícil organizar una reunión, pero tienen la desventaja de no poder modificar las preguntas. Por eso, el método más usado para la captura de requisitos es la entrevista, donde el entrevistador puede obtener gran cantidad de información del entrevistado en poco tiempo, y además ir modificando las preguntas según el flujo de la conversación (si es no estructurada), o bien preparando una lista de preguntas de antemano (si es estructurada).
¿Tiene sentido el uso de cuestionarios no estructurados? ¿Por qué?	Las preguntas de un cuestionario se deben decidir antes de obtener las respuestas, así que no tiene sentido el concepto de cuestionario no estructurado. No poder modificar las preguntas es una de las mayores desventajas de los cuestionarios respecto a las entrevistas.
¿Cuáles son los puntos débiles y los fuertes y las ventajas e inconvenientes de cada uno de los tres métodos de obtención de requisitos basados en preguntas?	-Entrevistas no estructuradas ·Puntos fuertes: Muy útiles al inicio del proceso, naturales e informales ·Puntos débiles: Desequilibrio en la profundidad con la que se trata diferentes áreas del sistema -Entrevistas estructuradas ·Puntos fuertes: Preguntas predefinidas y efectivas ·Puntos débiles: Trabajo previo necesario sobre el sistema y características, falta de flexibilidad -Cuestionarios ·Puntos fuertes: Útiles para obtener requisitos de un número elevado de usuarios y mayor facilidad para contestarlos ·Puntos débiles: Sin posibilidad de improvisar las preguntas e involucran menos a los clientes
¿En qué consiste la técnica de análisis de tareas?	El análisis de tareas consiste en descomponer las tareas desde el más alto nivel a tareas más sencillas hasta un nivel básico.
¿Cuáles son los principales riesgos que se achacan a la técnica de análisis de tareas?	Que se intente describir el funcionamiento interno del sistema en lugar de describir sólo la interacción de dicho sistema con el usuario.
¿En qué se diferencia la técnica de Análisis del dominio de la técnica de Etnografía?	La etnografía consistiría en convivir con los usuarios y otros empleados de la organización para familiarizarse con el dominio del problema; mientras que el análisis del dominio consistiría en examinar documentación y aplicaciones relacionadas con semejante propósito.
¿Qué problemas se pueden dar a la hora de usar una técnica de trabajo en grupo?	Es complicado coordinar la disponibilidad de todos los participantes, además de conseguir un lugar, infraestructura para teleconferencia o material necesario.
¿Para qué situaciones se dice que las tormentas de ideas son más adecuadas?	Para aquellas en las que se quieran desarrollar nuevos productos parecidos a los ya existentes o para encontrar soluciones novedosas a problemas.
¿Cuál es la diferencia fundamental entre una tormenta de ideas y una reunión tipo JAD?	Las reuniones JAD son más estructuradas, ya se han establecido los principales objetivos del sistema y los participantes ya conocen cómo se va a desarrollar el proyecto y su función en él. Las tormentas de ideas se realizan sin preparación previa y tratan de realizar las bases del proyecto.
¿Qué se entiende por prototipo en la fase de obtención de requisitos?	Un prototipo es un modelo que muestra parte de la funcionalidad del sistema a desarrollar y su principal objetivo es dar una idea parcial del producto finalizado.
¿Cuáles son algunas de las utilidades del uso de prototipos?	Sirven para proporcionar al cliente una vista previa del funcionamiento y apariencia del sistema, ayudando a la comprensión y facilitando la demostración de la satisfacibilidad de los requisitos. También puede proporcionar ideas sobre nuevos requisitos o actualizaciones de los mismos.
¿Cuáles son algunos de los riesgos del uso de prototipos?	Su diseño no tiene por qué ser bueno ni eficiente, incluso los datos que usa pueden no ser reales. También supone un coste tanto económico como temporal a tener en cuenta antes de su construcción. El cliente puede hacerse una idea errónea pensando que el proyecto está más avanzado de lo que está, y posteriormente frustrarse porque el proyecto no avanza según sus expectativas, o puede que le guste el prototipo y desee que este sea usado como solución definitiva.
¿En qué consiste la técnica de descripción de escenarios?	Es una descripción de procesos actuales y futuros incluyendo las acciones y la interacción entre el usuario y el sistema. Debe mostrar interacciones simples y evitar el uso de condiciones que lleven a cabo distintos caminos en la interacción.
¿Por qué no se muestra la estructura interna del sistema en la descripción de los escenarios?	No se muestra ya que los escenarios buscan describir procesos actuales y futuros, además de acciones e interacciones entre usuario y sistema, donde se considera al sistema una caja negra.
¿Cuál es la utilidad de los escenarios en los que se describen situaciones incorrectas, inesperadas o de error?	La utilidad en estas situaciones es el poder conocer estos escenarios para así solventarlos, detallando el funcionamiento que debe tener el sistema en esos casos.
¿Cuáles son las similitudes y las diferencias entre los escenarios y los storyboards?	Similitudes: Ambos son técnicas usadas para describir y entender mejor la funcionalidad que necesita el cliente. Diferencias: Los storyboards hacen una descripción gráfica con el uso de imágenes, videos, texto, audio, animaciones, etc., a diferencia de los escenarios que son descripciones que no incluyen estos elementos, son textuales. Además, los storyboards incluyen elementos mucho más concretos que en los escenarios, haciendo referencias al hardware e interfaces subyacentes.

Descubre

Crear Tarjetas

Acerca de Nosotros

Explore Tarjetas

Comparta este Set de Tarjetas de Aprendizaje

Tarjetas de Aprendizaje relacionadas

Tema 2 Ingeniería De Requisitos

Cómo estudiar sus tarjetas

Rango de Cartas a estudiar

34 Cartas en este set