Ayuda a los ingenieros de software a entender mejor el problema en cuya solución trabajarán. ¿Por qué es importante? Se debe entender lo que el cliente quiere antes de comenzar a diseñar y construir un sistema. Toma en cuenta errores, coste y tiempo. La IR trata de los principios, métodos, técnicas y herramientas que permiten descubrir, documentar y mantener los requisitos,  de forma sistemática y repetible. Ingeniería de requisitos
El objetivo del proceso de la ingeniería de requisitos es darle a todas las partes una explicación escrita del problema. Es esencial que se haga un esfuerzo real por entender los requisitos de un problema antes de intentar resolverlo. Ingeniería de requisitos
Funcionales Describen  los servicios que se esperan del sistema. No funcionales Restricciones sobre los requisitos funcionales Existen dos tipos: Ingeniería de requisitos ORIENTADOS AL USUARIO ORIENTADOS AL DESARROLLADOR Fiabilidad Disponibilidad Seguridad Portabilidad Usabilidad Adaptabilidad Robustez Testabilidad Rendimiento, etc Comprensibilidad
Proporciona el mecanismo adecuado para entender lo que el cliente quiere. Fases de la IR: Ingeniería de requisitos
Se inicia muchas veces por: Identifica nueva necesidad de negocios. Se descubre un nuevo mercado. Se descubre un nuevo servicio. Ingeniería de requisitos
La obtención de información no es tan fácil como parece. Los ingenieros deben realizar en forma organizada la actividad de recopilación de requisitos. Ingeniería de requisitos DE ÁMBITO DE COMPRENSIÓN DE VOLATILIDAD Limite del sistema mal definido El cliente no está seguro 100% de que es lo que necesita  Los problemas cambian con el tiempo. Detalles técnicos innecesarios, etc. Tienen dificultades para comunicar sus necesidades, etc.
Objetivo: Desarrollar modelo técnico refinado de las funciones, características y restricciones del software. Se conduce mediante la creación y refinamiento de escenarios. El resultado final es un modelo de análisis que define: El dominio de la información. Funciones. Comportamiento del problema. Ingeniería de requisitos
Clientes, usuarios y otros interesados deben ordenar sus requisitos y luego discutir los conflictos relacionados con la prioridad. Hacer estimaciones preliminares del esfuerzo requerido para su desarrollo. Mediante un enfoque iterativo los requisitos se elimina, combinan o modifican. Ingeniería de requisitos
Puede ser: Se recomienda que: La especificación es el trabajo final que genera la IR. Ingeniería de requisitos SISTEMAS GRANDES SISTEMAS PEQUEÑOS Documentos escritos Escenarios de uso Documento escrito Conjunto de modelos gráficos Modelo matemático formal Escenarios de uso Prototipo Una combinación de estos.
Examina la especificación para asegurar que los requisitos de software se han establecido de manera precisa. Ingeniería de requisitos ALGUNAS PREGUNTAS RECOMENDADAS PARA VALIDAR ¿La fuente del requisito está identificado? ¿Cuáles otros requisitos están relacionados con éste? ¿El requisito viola alguna restricción del dominio del sistema? ¿El requisito se puede probar? ¿Se pueden especificar las pruebas?, etc.
Es el conjunto de actividades que ayuda al equipo del proyecto a identificar, controlar, rastrear los requisitos como también los cambios a éstos en el desarrollo del proyecto. Para esto se desarrollan las siguientes tablas: La gestión formal se inicia solo para proyectos grandes Ingeniería de requisitos TABLAS De rastreabilidad de las características. De rastreabilidad de la fuente. De rastreabilidad del subsistema. De rastreabilidad de la interfaz.
Identificación de los interesados. Todos aquellos que se benefician en una forma directa o indirecta del sistema. Reconocimiento de múltiples puntos de vista. Categorizar la información de los interesados de manera que permita elegir un conjunto de requisitos para el sistema que sean consistentes de manera interna. Trabajo con respecto a la colaboración. Identificar áreas en común y áreas inconsistentes. Formulación de las primeras preguntas Las preguntas deben ser ‘libres de contexto’. ¿Quién usará la solución? ¿Cuál será el beneficio económico de una solución exitosa? Ingeniería de requisitos
Recopilación conjunta de requisitos La meta es identificar el problema, proponer elementos de solución, negociar diferentes enfoques y especificar un conjunto de requisitos preliminares. Ingeniería de requisitos
Es una técnica que traduce las necesidades del cliente en requisitos técnicos para el software. QFD define los requisitos para maximizar la satisfacción del cliente. QFD identifica 3 tipos de requisitos. Ingeniería de requisitos NORMALES ESPERADOS ESTIMULANTES Objetivos y metas establecidos para un  sistema durante las reuniones con el cliente. Están implícitos en el producto o sistema. Características que van más allá de las expectativas del cliente.
Se aplica para determinar el valor de cada función que se requiere para el sistema. El despliegue de la información identifica los datos de los objetos y eventos que debe consumir y producir el sistema. El despliegue de tareas examina el comportamiento del sistema o producto dentro del contexto de su entorno. Ingeniería de requisitos
Escenarios del usuario. Proporcionan una descripción de cómo se usará el sistema. Productos de trabajo de obtención. Los productos producidos como consecuencia de la obtención de requisitos variará de acuerdo con el tamaño del sistema a construir. Ingeniería de requisitos
Un caso de uso muestra el software o sistema desde el punto de vista del usuario final. Los actores son las diferentes personas que utilizan el sistema dentro del contexto de la función y el comportamiento que se describirá. Un actor es algún elemento que se comunica con el sistema y que es externo al sistema. Ingeniería de requisitos PRIMARIOS SECUNDARIOS Interactúan para lograr la función requerida del sistema Dan soporte al sistema.
Ingeniería de requisitos
El objetivo del modelo de análisis radica en describir requeridos de información, funcionamiento y comportamiento para un sistema basado en computadoras. Es una representación de los requisitos en un momento determinado. Los elementos del modelo los determina el método de modelado que se utilice. Ingeniería de requisitos
Elementos basados en escenarios Sirven como una entrada para la creación de otros elementos de modelado. Elementos basados en clases. Conjuntos de objetos que se manipula mientras un actor interactúa con el sistema. Ingeniería de requisitos
Elementos de comportamiento. El comportamiento de un sistema puede tener efecto sobre el diseño que se elija. Un estado es cualquier forma de comportamiento observable. Las variables de estado indican la manera en que el estado se manifiesta. Ingeniería de requisitos
Elementos orientados al flujo. La información se transforma mientras fluye a través de un sistema. Es posible crear un modelo de flujo para un sistema sin que importe su complejidad. Ingeniería de requisitos
Representan algo dentro del dominio de aplicación que puede reutilizarse al modelar muchas aplicaciones. Se pueden encontrar en casi cualquier actividad de la vida diaria. Ingeniería de requisitos PLANTILLA Nombre del patrón Intención Motivación Fuerzas y contexto Solución Consecuencias Diseño Usos conocidos Patrones relacionados
El objetivo es desarrollar un plan proyecto que satisfaga las necesidades del cliente. Ingeniería de requisitos DIRECTRICES A CONSIDERAR Reconocer que no es una competencia Decidir que es lo que se desearía lograr No se debe pensar en formular una respuesta mientras la otra parte está hablando Enfocarse en los intereses de la otra parte No dejar que se vuelva personal Ser creativo Estar listo para pactar. ACTIVIDADES A CONSIDERAR Identificación de los interesados clave en el sistema o subsistema. Determinación de las condiciones 'ganadoras' de los interresados. Negociación de las condiciones ganadoras para unirlas en un conjunto de condiciones del tipo ganar - ganar para todos los involucrados.
Los modelos de análisis se examinan para conocer que consistencia, omisiones o ambigüedades portan. Cada requisito y modelo de análisis se validan como un todo contrastándolos con las necesidades del cliente para asegurar que se construirá el sistema correcto. Ingeniería de requisitos ASPÉCTOS DE LA VALIDACIÓN Válidez Consistencia Completitud Realismo
“ Ingeniería de software: un enfoque práctico” Roger Pressman, VI edición, McGrawHill. www.gris.det.uvigo.es/~jose/doctorado/re/ www.lsi.us.es/docs/informes/LSI-2002-4.pdf Ingeniería de requisitos
Ingeniería de requisitos
Ingeniería de requisitos

Ingeniería De Requisitos

  • 1.
  • 2.
    Ayuda a losingenieros de software a entender mejor el problema en cuya solución trabajarán. ¿Por qué es importante? Se debe entender lo que el cliente quiere antes de comenzar a diseñar y construir un sistema. Toma en cuenta errores, coste y tiempo. La IR trata de los principios, métodos, técnicas y herramientas que permiten descubrir, documentar y mantener los requisitos, de forma sistemática y repetible. Ingeniería de requisitos
  • 3.
    El objetivo delproceso de la ingeniería de requisitos es darle a todas las partes una explicación escrita del problema. Es esencial que se haga un esfuerzo real por entender los requisitos de un problema antes de intentar resolverlo. Ingeniería de requisitos
  • 4.
    Funcionales Describen los servicios que se esperan del sistema. No funcionales Restricciones sobre los requisitos funcionales Existen dos tipos: Ingeniería de requisitos ORIENTADOS AL USUARIO ORIENTADOS AL DESARROLLADOR Fiabilidad Disponibilidad Seguridad Portabilidad Usabilidad Adaptabilidad Robustez Testabilidad Rendimiento, etc Comprensibilidad
  • 5.
    Proporciona el mecanismoadecuado para entender lo que el cliente quiere. Fases de la IR: Ingeniería de requisitos
  • 6.
    Se inicia muchasveces por: Identifica nueva necesidad de negocios. Se descubre un nuevo mercado. Se descubre un nuevo servicio. Ingeniería de requisitos
  • 7.
    La obtención deinformación no es tan fácil como parece. Los ingenieros deben realizar en forma organizada la actividad de recopilación de requisitos. Ingeniería de requisitos DE ÁMBITO DE COMPRENSIÓN DE VOLATILIDAD Limite del sistema mal definido El cliente no está seguro 100% de que es lo que necesita Los problemas cambian con el tiempo. Detalles técnicos innecesarios, etc. Tienen dificultades para comunicar sus necesidades, etc.
  • 8.
    Objetivo: Desarrollar modelotécnico refinado de las funciones, características y restricciones del software. Se conduce mediante la creación y refinamiento de escenarios. El resultado final es un modelo de análisis que define: El dominio de la información. Funciones. Comportamiento del problema. Ingeniería de requisitos
  • 9.
    Clientes, usuarios yotros interesados deben ordenar sus requisitos y luego discutir los conflictos relacionados con la prioridad. Hacer estimaciones preliminares del esfuerzo requerido para su desarrollo. Mediante un enfoque iterativo los requisitos se elimina, combinan o modifican. Ingeniería de requisitos
  • 10.
    Puede ser: Serecomienda que: La especificación es el trabajo final que genera la IR. Ingeniería de requisitos SISTEMAS GRANDES SISTEMAS PEQUEÑOS Documentos escritos Escenarios de uso Documento escrito Conjunto de modelos gráficos Modelo matemático formal Escenarios de uso Prototipo Una combinación de estos.
  • 11.
    Examina la especificaciónpara asegurar que los requisitos de software se han establecido de manera precisa. Ingeniería de requisitos ALGUNAS PREGUNTAS RECOMENDADAS PARA VALIDAR ¿La fuente del requisito está identificado? ¿Cuáles otros requisitos están relacionados con éste? ¿El requisito viola alguna restricción del dominio del sistema? ¿El requisito se puede probar? ¿Se pueden especificar las pruebas?, etc.
  • 12.
    Es el conjuntode actividades que ayuda al equipo del proyecto a identificar, controlar, rastrear los requisitos como también los cambios a éstos en el desarrollo del proyecto. Para esto se desarrollan las siguientes tablas: La gestión formal se inicia solo para proyectos grandes Ingeniería de requisitos TABLAS De rastreabilidad de las características. De rastreabilidad de la fuente. De rastreabilidad del subsistema. De rastreabilidad de la interfaz.
  • 13.
    Identificación de losinteresados. Todos aquellos que se benefician en una forma directa o indirecta del sistema. Reconocimiento de múltiples puntos de vista. Categorizar la información de los interesados de manera que permita elegir un conjunto de requisitos para el sistema que sean consistentes de manera interna. Trabajo con respecto a la colaboración. Identificar áreas en común y áreas inconsistentes. Formulación de las primeras preguntas Las preguntas deben ser ‘libres de contexto’. ¿Quién usará la solución? ¿Cuál será el beneficio económico de una solución exitosa? Ingeniería de requisitos
  • 14.
    Recopilación conjunta derequisitos La meta es identificar el problema, proponer elementos de solución, negociar diferentes enfoques y especificar un conjunto de requisitos preliminares. Ingeniería de requisitos
  • 15.
    Es una técnicaque traduce las necesidades del cliente en requisitos técnicos para el software. QFD define los requisitos para maximizar la satisfacción del cliente. QFD identifica 3 tipos de requisitos. Ingeniería de requisitos NORMALES ESPERADOS ESTIMULANTES Objetivos y metas establecidos para un sistema durante las reuniones con el cliente. Están implícitos en el producto o sistema. Características que van más allá de las expectativas del cliente.
  • 16.
    Se aplica paradeterminar el valor de cada función que se requiere para el sistema. El despliegue de la información identifica los datos de los objetos y eventos que debe consumir y producir el sistema. El despliegue de tareas examina el comportamiento del sistema o producto dentro del contexto de su entorno. Ingeniería de requisitos
  • 17.
    Escenarios del usuario.Proporcionan una descripción de cómo se usará el sistema. Productos de trabajo de obtención. Los productos producidos como consecuencia de la obtención de requisitos variará de acuerdo con el tamaño del sistema a construir. Ingeniería de requisitos
  • 18.
    Un caso deuso muestra el software o sistema desde el punto de vista del usuario final. Los actores son las diferentes personas que utilizan el sistema dentro del contexto de la función y el comportamiento que se describirá. Un actor es algún elemento que se comunica con el sistema y que es externo al sistema. Ingeniería de requisitos PRIMARIOS SECUNDARIOS Interactúan para lograr la función requerida del sistema Dan soporte al sistema.
  • 19.
  • 20.
    El objetivo delmodelo de análisis radica en describir requeridos de información, funcionamiento y comportamiento para un sistema basado en computadoras. Es una representación de los requisitos en un momento determinado. Los elementos del modelo los determina el método de modelado que se utilice. Ingeniería de requisitos
  • 21.
    Elementos basados enescenarios Sirven como una entrada para la creación de otros elementos de modelado. Elementos basados en clases. Conjuntos de objetos que se manipula mientras un actor interactúa con el sistema. Ingeniería de requisitos
  • 22.
    Elementos de comportamiento.El comportamiento de un sistema puede tener efecto sobre el diseño que se elija. Un estado es cualquier forma de comportamiento observable. Las variables de estado indican la manera en que el estado se manifiesta. Ingeniería de requisitos
  • 23.
    Elementos orientados alflujo. La información se transforma mientras fluye a través de un sistema. Es posible crear un modelo de flujo para un sistema sin que importe su complejidad. Ingeniería de requisitos
  • 24.
    Representan algo dentrodel dominio de aplicación que puede reutilizarse al modelar muchas aplicaciones. Se pueden encontrar en casi cualquier actividad de la vida diaria. Ingeniería de requisitos PLANTILLA Nombre del patrón Intención Motivación Fuerzas y contexto Solución Consecuencias Diseño Usos conocidos Patrones relacionados
  • 25.
    El objetivo esdesarrollar un plan proyecto que satisfaga las necesidades del cliente. Ingeniería de requisitos DIRECTRICES A CONSIDERAR Reconocer que no es una competencia Decidir que es lo que se desearía lograr No se debe pensar en formular una respuesta mientras la otra parte está hablando Enfocarse en los intereses de la otra parte No dejar que se vuelva personal Ser creativo Estar listo para pactar. ACTIVIDADES A CONSIDERAR Identificación de los interesados clave en el sistema o subsistema. Determinación de las condiciones 'ganadoras' de los interresados. Negociación de las condiciones ganadoras para unirlas en un conjunto de condiciones del tipo ganar - ganar para todos los involucrados.
  • 26.
    Los modelos deanálisis se examinan para conocer que consistencia, omisiones o ambigüedades portan. Cada requisito y modelo de análisis se validan como un todo contrastándolos con las necesidades del cliente para asegurar que se construirá el sistema correcto. Ingeniería de requisitos ASPÉCTOS DE LA VALIDACIÓN Válidez Consistencia Completitud Realismo
  • 27.
    “ Ingeniería desoftware: un enfoque práctico” Roger Pressman, VI edición, McGrawHill. www.gris.det.uvigo.es/~jose/doctorado/re/ www.lsi.us.es/docs/informes/LSI-2002-4.pdf Ingeniería de requisitos
  • 28.
  • 29.