Tema 1 IR UEx

¿Qué son los requisitos? (Hay varias definiciones validas). Los requisitos son la base de cualquier desarrollo o evolución de un sistema. Los requisitos son las características que un sistema debe tener para ser útil y cumplir con su propósito. Los requisitos son la base de cualquier desarrollo o evolución de un eneba. Los requisitos son la base de algún desarrollo o evolución de un sistema. Los requisitos son las características que un sistema puede tener para ser útil y a lo mejor cumplir con su propósito. Los requisitos son las características que un eneba debe tener para ser útil y cumplir con su propósito.

Que es la ingeniería de requisitos? (Varias respuestas válidas). La ingeniería de requisitos (RE) es la especificación y gestión sistemática y disciplinada de los requisitos. La ingeniería de requisitos es una disciplina en el desarrollo de sistemas. Se encarga de definir, documentar y gestionar los requisitos de un sistema. La ingeniería de requisitos (RE) es la especificación y gestión sistemática y disciplinada de los saladitos. La ingeniería de requisitos es una disciplina en el desarrollo de sistemas. Se encarga de definir, condimentar y gestionar los saladitos de un sistema. La ingeniería de requisitos (RE) no es la especificación y gestión sistemática y para nada disciplinada de los requisitos. La ingeniería de requisitos no es una disciplina en el desarrollo de sistemas. Se encarga de definir, documentar y arruinar los requisitos de un sistema.

¿Qué tipos de requisitos hay si los clasificamos por su origen/destino?. Requisitos funcionales. Requisitos de calidad. Restricciones. Requisitos del sistema. Requisitos de los interesados. Requisitos de los usuarios. Requisitos del dominio. Requisitos del negocio. Requisitos utilitarios. Requisitos de encargado.

Beneficios de la ingeniería de requisitos. Minimiza los riesgos de fallo y de incremento de costes a futuro. Reduce la complejidad del problema. Nos permite estimar los costos del proyecto. Nos permite probar el sistema correctamente. Garantiza el éxito comercial. Elimina la necesidad de realizar pruebas. Nos asegura que no habrá que realizar mantenimientos futuros. Elimina la dependencia del sistema con elementos externos. Asegura un sistema a prueba de fallas. Define el diseño completo.

Cuales de estos son indicios de que posiblemente haya problemas en la IR?. Equipos de desarrollo que van directos a la implementación por presión en los tiempos de entrega. Problemas de comunicación entre diferentes partes, los interesados y los desarrolladores. Asumir que los requisitos son evidentes (falso en la mayoría de los casos). RE a cargo de personas sin las habilidades necesarias. Todos los interesados tienen exactamente las mismas necesidades. Los requisitos nunca cambian durante el ciclo de vida del proyecto. La ingeniería de requisitos ralentiza en exceso el inicio de la codificación. No hay conflictos ni ambigüedades en los requisitos identificados (Debería haberlos para un buen proceso).

¿Qué procesos componen la ingeniería de requisitos? (Escríbelos en orden alfabético, en minúsculas sin tildes así (ejemplo1, ejemplo2) ).

Escribe los tipos de requisitos según su naturaleza (Escríbelos en orden alfabético, en minúsculas sin tildes así (ejemplo1, ejemplo2) ).

¿Qué soft-skills deberá tener un buen candidato a Ingeniero de Requisitos?. Capacidad de escuchar. Mediación. Negociación. Empatía. Salva distancias entre problema y soluciones. Experiencia previa en roles de programación. Habilidades de modelado de datos. Resistencia al cambio. Imaginativo.

Escribe la palabra que corresponde a esta definición: "Fragmento de trabajo coherente que debe hacerse".

Escribe la palabra que corresponde a esta definición: "Acción o conjunto de acciones que una persona o grupo realiza para cumplir una tarea".

Escribe la palabra que corresponde a esta definición: "Manera probada de llevar a cabo ciertos tipos de tareas o actividades".

Escribe cuales son los principios fundamentales (Escríbelos en orden de las diapositivas, en minúsculas sin tildes y separados por . y espacio (ejemplo1. ejemplo2) ).

Selecciona el principio fundamental definido abajo: "Este principio fundamental establece que los requisitos deben ser un medio para alcanzar un objetivo final, no un fin en sí mismos". Orientación al valor. Interesados. Entendimiento compartido. Contexto. Problema, requisito, solución. Validación. Evolución. Innovación. Trabajo sistemático y disciplinado.

Selecciona el principio fundamental definido abajo: "Son todas las personas u organizaciones que, de alguna manera, se ven afectadas o podrían verse afectadas por el sistema que se está desarrollando.". Orientación al valor. Interesados. Entendimiento compartido. Contexto. Problema, requisito, solución. Validación. Evolución. Innovación. Trabajo sistemático y disciplinado.

Selecciona el principio fundamental definido abajo: "Se refiere a la comprensión común que deben tener todas las partes involucradas en el desarrollo de un sistema sobre el problema a abordar.". Orientación al valor. Interesados. Entendimiento compartido. Contexto. Problema, requisito, solución. Validación. Evolución. Innovación. Trabajo sistemático y disciplinado.

Selecciona el principio fundamental definido abajo: "Nos referimos al entorno en el que se encuentra un sistema y que influye en su funcionamiento y en los requisitos que debe cumplir.". Orientación al valor. Interesados. Entendimiento compartido. Contexto. Problema, requisito, solución. Validación. Evolución. Innovación. Trabajo sistemático y disciplinado.

Selecciona el principio fundamental definido abajo: "Este principio fundamental resalta la naturaleza interconectada de una serie de elementos en el desarrollo de sistemas.". Orientación al valor. Interesados. Entendimiento compartido. Contexto. Problema, requisito, solución. Validación. Evolución. Innovación. Trabajo sistemático y disciplinado.

Selecciona el principio fundamental definido abajo: "Este principio fundamental es un proceso obligatorio para todo requisito, proceso en el que confirmamos que un elemento satisface las necesidades de sus interesados.". Orientación al valor. Interesados. Entendimiento compartido. Contexto. Problema, requisito, solución. Validación. Evolución. Innovación. Trabajo sistemático y disciplinado.

Selecciona el principio fundamental definido abajo: "En el ciclo de vida natural de un sistema, los requisitos cambian constantemente debido a diversos factores.". Orientación al valor. Interesados. Entendimiento compartido. Contexto. Problema, requisito, solución. Validación. Evolución. Innovación. Trabajo sistemático y disciplinado.

Selecciona el principio fundamental definido abajo: "Este principio fundamental se basa en descubrir necesidades no expresadas y explorar soluciones creativas.". Orientación al valor. Interesados. Entendimiento compartido. Contexto. Problema, requisito, solución. Validación. Evolución. Innovación. Trabajo sistemático y disciplinado.

Selecciona el principio fundamental definido abajo: "Este principio fundamental establece que debemos seguir un proceso definido y utilizar prácticas y herramientas adecuadas para el proyecto en cuestión, pero sin una rigidez absoluta, la metodología deberá adaptarsze al proyecto.". Orientación al valor. Interesados. Entendimiento compartido. Contexto. Problema, requisito, solución. Validación. Evolución. Innovación. Trabajo sistemático y disciplinado.

Selecciona las afirmaciones verdaderas sobre los costes y beneficios de la IR gracias a la orientación al valor. Los beneficios de RE son a largo plazo. Los costes son inmediatos y cuantificables. El valor económico de RE es fundamentalmente indirecto. Los costes de RE son a largo plazo. Los beneficios son inmediatos y cuantificables. El valor económico de RE es totalmente directo.

Selecciona factores a considerar para buscar el equilibrio. Cada situación es única y requiere una evaluación particular. Es crucial establecer la importancia de cada requisito para los interesados y el impacto de no cumplirlo. Qué tan único o especial es el requisito en comparación con otros. La cantidad de trabajo requerida para definir claramente un requisito. Siempre hay que tener en cuenta por encima de todo los requisitos del desarrollador. En todo momentos deberemos mantenernos en sistemas ya usados para evitar los costes de los nuevos. Normalmente deberemos sacrificar la calidad en base al tiempo de desarrollo.

Selecciona las afirmaciones verdaderas sobre los roles de los interesados. Todo interesado en el sistema debe ser clasificado con un rol en el contexto del mismo, Usuarios, clientes, operadores, desarrolladores…. En ocasiones el desarrollador puede ser un interesado, para agilizar el desarrollo del proyecto. Todo rol relevante debe de tener un grupo de personas que sean sus representantes. Para roles con muchas personas o donde no conozcamos a nadie definiremos personajes ficticios que los representan. Para sistemas ya en uso necesitaremos usuarios que proporcionen feedback. Bajo ningún concepto deberemos usar personajes ficticios como representantes de algún rol. Para sistemas en desuso deberemos integrar como un rol a los antiguos desarrolladores. Es suficiente con un único representante para cada rol de interesado. La clasificación de los interesados no es importante para la gestión de requisitos.

Escribe los tipos de interesados que hay (Escrito en minusculas, separado por comas, y en orden alfabetico).

Relaciona los tipos de entendimiento compartido con sus características. Explicito. Implícito.

Selecciona los desafíos del entendimento compartido. Las personas pueden interpretar la misma información de manera diferente, incluso si creen que se han entendido. Es posible que no se tenga toda la información necesaria para comprender completamente el problema o los requisitos. El contexto del proyecto puede cambiar con el tiempo, lo que puede afectar la comprensión de los requisitos. Las personas pueden interpretar la misma información de la misma manera siempre, incluso si creen que no se han entendido. Es posible que no se tenga toda la información necesaria para comerse el problema o los requisitos. El contexto del proyecto puede cambiar con el tiempo, lo que no afectará a la comprensión de los requisitos.

Prácticas para fomentar el entendimiento compartido explícito. Utilizar glosarios para definir términos clave. Construir prototipos para ilustrar el funcionamiento del sistema. Buscar referencias en sistemas existentes. Realizar revisiones y validaciones meticulosas de los requisitos. Buscar ejemplos de resultados esperados. Construir prototipos. Estimar costes de implementar un requisito.

Prácticas para fomentar el entendimiento compartido implícito. Utilizar glosarios para definir términos clave. Construir prototipos para ilustrar el funcionamiento del sistema. Buscar referencias en sistemas existentes. Realizar revisiones y validaciones meticulosas de los requisitos. Buscar ejemplos de resultados esperados. Construir prototipos. Estimar costes de implementar un requisito.

Factores que potencian el entendimiento compartido. Conocimiento del dominio: Compartir un conocimiento profundo del área de aplicación del sistema. Estándares específicos del dominio: Utilizar un lenguaje y prácticas comunes dentro del dominio. Colaboraciones previas: Haber trabajado juntos en proyectos anteriores con éxito. Sistemas de referencia: Tener un sistema similar que sirva como ejemplo. Cultura y valores compartidos: Compartir una visión y valores comunes sobre el desarrollo de software. Confianza mutua: Tener una relación de confianza y respeto entre las partes involucradas. Distancia geográfica: La comunicación a distancia puede facilitar la comprensión y la colaboración. Altas tasas de rotación: Los cambios frecuentes de personal pueden potenciar la continuidad del conocimiento y la comprensión. Restricciones legales: Las regulaciones y leyes obligan a aclarar la información que se debe compartir. Subcontratación: La externalización de partes del proyecto obliga al detallamiento de los intereses para una mejor comunicación.

Factores que perjudican el entendimiento compartido. Distancia geográfica: La comunicación a distancia puede dificultar la comprensión y la colaboración. Desconfianza: Una relación basada en la desconfianza puede impedir la comunicación abierta y honesta. Subcontratación: La externalización de partes del proyecto puede crear barreras de comunicación y culturales. Restricciones legales: Las regulaciones y leyes pueden limitar la información que se puede compartir. Equipos grandes y diversos: La diversidad de backgrounds y experiencias puede dificultar la comunicación efectiva. Altas tasas de rotación: Los cambios frecuentes de personal pueden afectar la continuidad del conocimiento y la comprensión. Conocimiento del dominio: Creer compartir un conocimiento profundo del área de aplicación del sistema, complica abrirse a una verdadera comprensión. Sistemas de referencia: Tener un sistema similar que sirva como ejemplo es un falso caso de entendimiento compartido. Estándares específicos del dominio: Utilizar un lenguaje y prácticas comunes dentro del dominio es un falso caso de entendimiento compartido. Colaboraciones previas: Haber trabajado juntos en proyectos anteriores puede ser la ruina para hacer llegar el entendimiento compartido al nuevo proyecto.

El contexto de un sistema está delimitado por el perímetro del sistema y el perímetro del contexto. Perímetro del sistema. Perímetro del contexto.

Slecciona donde está el perímetro del contexto.

Selecciona el perímetro del sistema.

Selecciona que parte es el alcance.

El alcance y perímetro pueden no coincidir en algunos casos. Selecciona el caso en el que se reutilizan componentes existentes.

El alcance y perímetro pueden no coincidir en algunos casos. Selecciona el caso en el que se requiere modificar elementos del contexto externo.

Selecciona con que parte de los apuntes va cada apartado. La ingeniería de requisitos debe ir más allá del propio perímetro del sistema e interfaces externas, teniendo en cuenta el contexto:. Al analizar el contexto, se debe considerar:.

Importancia de la Validación. Requisitos no validados son inútiles, ya que un sistema busca satisfacer las necesidades de los interesados. Comprobar si lo logra al final del desarrollo es muy arriesgado y costoso. Es mejor validar los requisitos desde la propia fase de Ingeniería de Requisitos. Comprobar si el software cumple con los requisitos al final del desarrollo es un proceso seguro y económico. La validación solo es necesaria para software complejo o crítico.

Aspectos a Validar. Acuerdo entre los diferentes interesados respecto a los requisitos (manejo de conflictos, prioridades, etc). Que las necesidades de los interesados quedan cubiertas por los requisitos especificados. Que las suposiciones sobre el dominio de aplicación son razonables. Que el código fuente del software sea comprensible y fácil de modificar por cualquier programador. Que el software tenga un diseño estético atractivo y moderno.

Factores que impulsan la evolución de los requisitos: Cambios en los procesos de negocio: Reestructuraciones, nuevas estrategias o adopción de nuevos modelos de negocio. Competencia: Nuevos productos o servicios de la competencia. Necesidades cambiantes de los clientes: Prioridades, opiniones y expectativas de los usuarios. Avances tecnológicos: Nuevas tecnologías o mejoras en las existentes. Retroalimentación de los usuarios: Errores, fallos o áreas de mejora detectados. Detección de errores en los requisitos o suposiciones: Errores en la definición inicial o suposiciones erróneas. Obsesión por incorporar la última tecnología disponible, sin importar su utilidad real. Desinformación o rumores. Cambios en las tendencias sociales o culturales.

Un trabajo sistemático y disciplinado en RE implica: Definir un proceso de RE adaptado al problema y al proceso de desarrollo. Utilizar las prácticas y herramientas de RE mejor adaptadas al problema, contexto y entorno de trabajo. Evitar el uso rutinario de las mismas prácticas y herramientas. No reutilizar procesos y prácticas sin reflexionar. Aplicar un proceso de RE genérico a todos los proyectos. Exceso de documentación. Dependencia excesiva de herramientas. Falta de seguimiento de los requisitos.