¿Qué es un requisito?	Es una característica, condición o capacidad exigida por un usuario para resolver un problema o conseguir un objetivo. Este deberá cumplirse o tener algún sistema o componente que satisfaga un contrato, norma, especificación o cualquier otro documento formal.
¿Qué describe un requisito?	Un requisito describe tanto las necesidades de los usuarios como los intereses que surgen de la organización para la que está destinado el sistema o de norma industriales o leyes aplicables a ese campo además de las restricciones que se imponen a las funciones que se han de ofrecer.
Diferencias entre requisitos y manual de usuario.	El manual de usuario está pensado para ser usado por el usuario, mientras que los requisitos describen más condiciones exigidas que puede que solo sean útiles para los encargados de la empresa. Además, los requisitos se describen antes de empezar el proyecto, mientras que el manual de usuario se hace al final del proyecto.
¿Qué es un requisito derivado?	Es aquel que surge a raíz de los requisitos primarios. Serían propuestos por el analista.
¿Quién dice cuáles son los requisitos, el cliente o el analista?	El cliente dice las necesidades que el producto debe cumplir y el analista debe captarlas, mejorarlas, agruparlas y relacionarlas entre sí, formando una lista de requisitos que el cliente debe validar posteriormente.
¿En qué se distinguen los requisitos funcionales de los no funcionales?	Los funcionales describen qué debe hacer el sistema, mientras que los no funcionales establecen las restricciones sobre las soluciones planteadas mediante los requisitos funcionales.
¿Qué relación hay entre los requisitos a nivel organizativo, a nivel de producto y a nivel de proyecto?	El nivel organizativo y de producto pueden estar relacionados de forma que a la hora de organizar el proyecto (hacer más seguro el producto por ejemplo o los costes que se puede permitir la organización) puede afectar al producto (siendo menos fácil de usar o de menos calidad). Los requisitos de proyecto se deben organizar teniendo en cuenta los requisitos organizativos y de producto.
¿Qué es la Ingeniería de Requisitos?	Son el conjunto de actividades y procesos relacionados con los requisitos para conseguir una descripción clara y precisa del producto para trabajar más fácilmente y evitar posibles errores en el futuro. Estos procesos son descubrir, analizar, documentar y verificar los requisitos y restricciones del proyecto.
¿Cuáles son las actividades fundamentales en la Ingeniería de Requisitos?	Captura de requisitos Descripción de requisitos Análisis de requisitos Validación y negociación de requisitos Gestión de requisitos.
¿Qué ocurre si durante la fase de captura de requisitos se identifican nuevos participantes en el sistema?	Debido a la aparición de nuevos participantes habrá que concluir si es necesario introducir nuevos requisitos o modificar alguno existente para satisfacer las necesidades de todas las partes interesadas.
¿Cuál es la audiencia del documento que describe los requisitos?	La audiencia del documento de requisitos, denominado Visión, son aquellos desarrolladores que necesitan los requisitos creados por los analistas y aceptados por los clientes.
¿Por qué es necesario que los requisitos esten descritos en un lenguaje comprensible por el usuario?	Para que dicho usuario, que no tiene por qué tener conocimientos ni preparación técnica, sea capaz de comprenderlos y validarlos.
¿Por qué se hace un análisis de los requisitos después de su captura y descripción?	Porque es posible que la primera versión sufra de defectos como falta de concreción, incompletitud, incoherencia entre requisitos, que haya requisitos que se superpongan u otras situaciones similares.
¿En qué consiste la validación de los requisitos?	La validación consiste en la realización de reuniones con los clientes una vez que los analistas han mejorado la descripción capturada inicialmente, para validar los requisitos y dar el visto bueno a aquellos que sean correctos.
¿Qué aspectos se pueden negociar en la negociación de los requisitos?	Debido a ciertas incompatibilidades por parte de los requisitos se debe realizar una negociación de los mismos, tales como, pedir un formato distinto para un informe generado por un sistema o variar la complejidad estimada por los desarrolladores para que un requisito sea mayor que lo que el cliente había pensado. Dejando claro cuales son las situaciones problemáticas y cuáles son las soluciones, incluyendo la justificación de la decisión.
¿Por qué es necesaria la gestión de los requisitos?	Para garantizar el correcto desarrollo con el equipo, este debe entender lo mismo que el cliente sobre los requisitos. Se deben de trabajar en la misma línea e informar de posibles cambios para que el desarrollo se lleve de forma óptima.
¿Cómo se tratan los requisitos en la metodología en cascada?	En la metodología en cascada, se debe finalizar una etapa antes de comenzar la siguiente, es decir, que la ingeniería de requisitos se completa antes de pasar a la siguiente fase. Este método es poco flexible si se producen cambios en los requisitos durante el resto del desarrollo.
¿Cuáles son las suposiciones que hace la metodología en cascada sobre los requisitos?	Que los requisitos no van a sufrir modificaciones desde la primera versión y, por tanto, la ingeniería de requisitos acaba después de la primera etapa.
¿En qué tipos de proyectos son válidas esas suposiciones y es aplicable la metodología en cascada? ¿Y en qué proyectos no?	Podría ser válida en proyectos sencillos, cortos, con experiencia con el cliente, en aquellos con baja incertidumbre o sin la necesidad de cambios en el ciclo de vida del producto. No es válida en proyectos complejos en los que los requisitos puedan estar cambiando frecuentemente.
En los métodos iterativos hay un estudio inicial de los requisitos. ¿En qué se diferencia entonces ese estudio inicial del análisis de requisitos del método en cascada?	En el método en cascada el estudio inicial debe recoger todos los requisitos necesarios contemplando todos los casos, ya que teóricamente no deben ser modificados durante el proyecto. Por otro lado en la metodología iterativa se intentan recoger la mayoría de los requisitos para organizarlos y priorizar en las iteraciones los requisitos que desarrollar primero
¿Cómo se tratan los requisitos en cada iteración?	Al inicio de cada iteración se hace una gestión de los requisitos que incluye una nueva captura de requisitos para ver si ha surgido algún requisito nuevo, si hay que eliminar algún requisito, cambiar la prioridad de algunos requisitos o modificar la descripción de alguno de los requisitos existentes.
¿Qué contiene el documento de “Visión” en el PU?	Contiene las características fundamentales del sistema, incluyendo el entorno, las partes interesadas y los requisitos del sistema.
¿En qué fases del PU se hace un mayor trabajo sobre los requisitos?	Durante las fases de inicio y elaboración.
¿Cuál es la relación entre requisitos y casos de uso?	Los casos de uso son descripciones del sistema e interacciones basadas en los requisitos.
¿Qué es un escenario de un caso de uso?	Una descripción de una posible secuencia de acciones (usuario/sistema) en un determinado caso de uso.
¿Cómo se describen los escenarios de los casos de uso?	Los escenarios se pueden describir textualmente o usando un diagrama, como el diagrama de secuencia, donde se detallan las acciones entre los actores involucrados y el sistema.
¿Qué es un actor en el PU (Proceso Unificado)?	Un actor es un usuario que puede interactuar con el sistema descrito por los casos de uso.
¿Por qué se dice que el PU está dirigido por los casos de uso?	Porque a partir de ellos se construyen todos los demás modelos de los siguientes flujos de trabajo, análisis, diseño e implementación. Incluso las pruebas deben estar dirigidas por los casos de uso, de tal manera que las pruebas deberían cubrir todas las situaciones que se dan en los diferentes escenarios descritos en los casos de uso.
¿Qué diferencia hay en el tratamiento de los requisitos en el PU y las metodologías ágiles?	En el “Proceso Unificado” inicialmente los requisitos se recopilan en el documento “visión” el cual contiene las características principales del sistema. A partir de estos requisitos se producen los “casos de uso”, que describen las interacciones de los usuarios con el sistema. En las “metodologías ágiles” los requisitos son negociados con el cliente durante cada entrega parcial del proyecto y se pueden modificar en cualquiera de estas.
¿Qué relación hay entre el Registro del Producto y el Registro de la Iteración en Scrum?	Aunque ambas son fases iniciales de la metodología scrum, en el registro del producto se recoge (al principio del proyecto) un análisis genérico del sistema, incluyendo características o funcionalidades. Sin embargo en el registro de la iteración Scrum (en cada iteración) se incluyen los requisitos que se van a cumplir y trabajar en esa iteración.
¿Qué es una historia de usuario en Extreme Programming?	Una historia de usuario es una descripción general y breve de una función del software contada desde la perspectiva del usuario o cliente.
¿Qué es la trazabilidad de requisitos?	La habilidad para describir y seguir la vida de un requisito en la línea del tiempo a lo largo del ciclo de vida.
¿Cuál es la utilidad de la trazabilidad de requisitos?	Para analizar el impacto de un cambio de los requisitos en el sistema; conocer la motivación de la creación y evolución de un objeto; y asegurar que los componentes del sistema cubren los requisitos.
¿Qué es una matriz de trazabilidad?	Herramienta para definir y seguir un requisito a lo largo de todo su ciclo de vida mediante una tabla en la que se relacionan los requisitos con otros elementos del desarrollo.

Descubre

Crear Tarjetas

Acerca de Nosotros

Explore Tarjetas

Comparta este Set de Tarjetas de Aprendizaje

Tarjetas de Aprendizaje relacionadas

Tema 1 Ingeniería De Requisitos

Cómo estudiar sus tarjetas

Rango de Cartas a estudiar

34 Cartas en este set