Lcdo. Eddy Cortez Sistemas II. Ingeniería de Requisitos.

Presentación del tema: "Lcdo. Eddy Cortez Sistemas II. Ingeniería de Requisitos."— Transcripción de la presentación:

1 Lcdo. Eddy Cortez Sistemas II

2 Ingeniería de Requisitos

3

4  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?

5  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. Objetivo

6  Funcionales ◦ Describen los servicios que se esperan del sistema.  No funcionales ◦ Restricciones sobre los requisitos funcionales ◦ Existen dos tipos: Ingeniería de requisitos6 ORIENTADOS AL USUARIOORIENTADOS AL DESARROLLADOR FiabilidadDisponibilidad SeguridadPortabilidad UsabilidadAdaptabilidad RobustezTestabilidad Rendimiento, etcComprensibilidad Tipos de Requisitos

7  Proporciona el mecanismo adecuado para entender lo que el cliente quiere.  Fases: Fases de la IR

8  Típicas razones para iniciar la IR: ◦ Oportunidades:  Identificación de nueva(s) necesidad(es) de negocios.  Descubrimiento de nuevo(s) mercado(s).  Descubrimiento de nuevo(s) servicio(s).  Investigación y desarrollo (mantenimiento perfectivo). ◦ Necesidades:  Solicitud de nuevo servicio.  Crecimiento de la organización.  Incorporación de procesos en la organización. Inicio

9  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. DE ÁMBITODE COMPRENSIÓNDE 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. Obtención

10  El objetivo es desarrollar un modelo técnico refinado de las funciones, características y restricciones del sistema.  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 del sistema. ◦ El problema. Elaboración

11  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. Negociación

12  Puede ser:  Recomendaciones: Es el producto final que genera la IR. Documento escrito Conjunto de modelos gráficos Modelo matemático formal Escenarios de uso Prototipo Una combinación de estos. Especificación SISTEMAS GRANDESSISTEMAS PEQUEÑOSPOCA CLARIDAD EN SOLICITUD Documentos escritosEscenarios de UsoPrototipo

13  Examinar la especificación para asegurar que los requisitos de software se han establecido de manera correcta y precisa. 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? Validación

14  Es el conjunto de actividades que ayuda al equipo del proyecto a identificar, controlar y hacer seguimiento a los requisitos; así como también, los cambios a éstos durante el desarrollo del proyecto.  La gestión formal se recomienda para proyectos grandes, pero en todos los casos es importante la rastreabilidad de los requisitos identificados. Gestión