TAREAS DE INGENIERIA EN REQUISITOS Erik Ivan Mancilla Romero | Fundamentos de ingeniería de software | Catedrático Rita Hernandez Flores Introducción La ingeniería de requisitos proporciona el mecanismo apropiado para entender lo que el cliente quiere, analizar las necesidades, evaluar la factibilidad, negociar unasolución razonable, especificar la solución sin ambigüedades, validar laespecificación, y administrar los requisitos conforme estos se transforman en unsistema operacional. Existen muchos procesos de desarrollo de software con unagran serie de estándares para medir.En el proceso de la ingeniería de requisitosse ejecutan las tareas de inicio, obtención, elaboración, negociación, especificación, validación y gestión. Dichas funciones deben adaptarse a lasnecesidades y particularidades de cada proyecto. En este caso se hablara de las tareas, actividades o funciones que debe efectuar para llegar a esta meta. Definición Se define como un conjunto de actividades en los cuales, utilizando tecnicas y herramientas, se analiza un problema y se concluye con la especificación de una solución. La ingeniería de requisitos es el proceso de desarrollar una especificación de software. Tareas Inicio Tiene por objetivo identificar el ámbito del proyecto general. Comienza con una serie de conversaciones informales entre los participantes del mismo. Esta fase suele ser acompañada de los documentos de definición de la visión global y la visión del dominio del sistema. Se inicia muchas veces por: se descubre un nuevo mercado y se descubre un nuevo servicio. Obtención Se sugiere a los ingenieros recopilar requisitos de manera organizada, preguntando a los usuarios y otros interesados cuales son os objetivos para el sistema o producto, que es lo que se debe lograr, de que forma el producto satisface las necesidades del negocio y como se utilizara el producto día d día. Se identifican una serie de problemas que ayudan a entender porque es difícil la obtención de requisitos: Problema de ámbito Problema de comprensión Problemas de volatilidad Elaboración Los ingenieros de software crean un modelo de análisis con la informaciónobtenida del cliente en las fases de inicio y obtención. El modelo de análisisdefine el dominio de la información, las funciones y el compartimiento del problema.La información conseguida con el cliente durante el inicio y obtención seexpande y se refina durante la elaboración. Esta actividad de la ingeniería derequisitos se enfoca en el desarrollo de un modelo técnico refinado de lasfunciones, características y restricciones del software.La elaboración del modelado del análisis y su componente de una serie de tareasde modelado y refinamiento. La elaboración se conduce mediante la creación yrefinamiento de escenarios del usuario que describen la forma en que el usuariofinal (y otros actores) interactuaran con el sistema. Cada escenario del usuario seanaliza para obtener clases del análisis: entidades del dominio de negociosvisibles para el usuario final. Se definen los atributos de cada clase de análisis yse identifican los servicios que requiere cada clase. Se identifican las relaciones yla colaboración entre las clases y se produce una variedad de diagramas de UMLcomplementarios.El resultado final de la elaboración es un modelo de análisis que definen eldominio de la información, las funciones y el comportamiento del problema. Negociación En esta etapa el ingeniero de requisitos debe negociar con el cliente los alcances y límites del sistema. De forma iterativa los requisitos se prioriza, modifican, combinan o eliminan buscando acuerdos que beneficien a todas las partes. Se identifican y analizan los riesgos asociados con cada requisito. Especificaciones Es el producto final de la ingeniería de requisitos, y se convierte en la materia prima para las actividades posteriores en el proceso de desarrollo del sistema. Una especificación puede ser un documento escrito, un conjunto de modelos gráficos, un modelo matemático formal, una colección de escenarios de uso, un prototipo o cualquier combinación de estos. Validación Un equipo de validación toma el producto de la fase de especialización, lo revisa para detectar errores, conflictos u omisiones y los corrige con el fin de garantizar la consistencia de los requisitos.La calidad de los productos de trabajo procedentes de la ingeniería de requisitos se evalúa durante un paso de validación. La validación de requisitos examina la especificación para asegurar que todos los requisitos de software se han establecidos de manera precisa; que se han detectado las inconsistencias omisiones y errores y queestos han sido corregidos, y que los producto de trabajo cumplen con los estándares establecidos para el proceso, proyecto y producto.El mecanismo primario para la validación de requisitos es la revisión técnica formal. El equipo de revisión que valida los requisitos incluye ingenieros de software, clientes, usuarios y otros interesados que examinan la especificación y buscan errores en el contenido o la interpretación, áreas que tal vez requieran una clasificación, información faltante, inconsistencia (que es problema importante) cuando se desarrollan productos o sistemas grandes), conflictos entre los requisitos, o requisitos irreales (inalcanzables). Gestión de requisitos Ayuda a rastrear los requisitos según las características de los mismos, el código fuente relacionado, dependencia entre requisitos, subsistemas e interfaces internas y externas de forma que pueda identificarse con rapidez para entender como afectara una modificación diferentes aspectos del sistema a construir. Es un conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en cualquier momento mientras se desarrolla el proyecto. La gestión de requisitos es un conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en Cualquier momento mientras se desarrolla el proyecto. Muchas de estas actividades son idénticas a las actividades de la gestión de la configuración del software (GGS).La gestión de requisitos comienza con la identificación. Cada requerimiento se asigna a un solo identificador. Una vez identificados los requisitos se desarrollan las tablas de rastreabilidad que son las siguientes: Tabla de rastreabilidad de las características: Muestra la manera en que los requisitos se relacionan con las características del sistema/producto observables para el cliente. Tabla de rastreabilidad de la fuente: Identifica la fuente de cada requisito. Tabla de rastreabilidad de dependencia: Indica la forma en que los requisitos están relacionados entre sí. Tablas de rastreabilidad del subsistema: Establece categorías entre los requisitos de acuerdo con el (los) subsistema(s) que gobierna(n). Tablas de rastreabilidad de la interfaz: Muestra la forma en que los requisitos se relacionan con las interfaces internas y externas del sistema. En muchos casos, esas tablas de rastreabilidad se mantienen como parte de la base de datos de los requisitos de forma que pueda buscársele con rapidez para entender como el cambio en un requisito afectara diferentes aspectos del sistema que se construirá. Los requerimientos en un proyecto no solo comprenden las tareas de captura y manejo de los cambios a lo largo de todo el proyecto, también comprenden de estas otras tareas: Identificar los stakeholders (se refiere a «quienes pueden afectar o son afectados por las actividades de una empresa»): Se describe una lista de toda la persona interesada en el desarrollo del sistema. Entender las necesidades de los usuarios y clientes necesarias para planear el sistema y sus expectativas. Identificar los requerimientos: Inicialmente los requerimientos provienen de los objetivos que plantea el negocio. En esta actividad los requerimientos se indican por medio de sentencias. En un escenario de negocio se usa para entender los requerimientos del negocio. Aclarecer y refinar los requerimientos: Esta actividad se ejecuta cuando se tiene plena seguridad plena certeza de que los requerimientos indican las necesidades reales del cliente y que estos pueden ser usados por el resto de equipos en el proyecto. Analizar los requerimientos: Se realiza cuando los requerimientos se encuentran bien definidos y cumplen con el criterio de un buen requerimiento. Definir los requerimientos de forma estándar para los stakeholders: Debido a que cada stakeholders tiene una perspectiva diferente del sistema y sus requerimientos, es importante esforzar un poco de tiempo en la descripción de los requerimientos usando un vocabulario adecuado. Especificar los requerimientos: Cada requerimiento debe expresarse en forma detallada de tal manera que pueda ser incluido en otros documentos de especificación o en otros proyectos. Priorizar los requerimientos: Todos los requerimientos tienen niveles diferentes de importancia para los clientes y usuarios. Unos tienen prioridad críticas, otros no tanta y otros de bajo nivel de prioridad. La priorización de los requerimientos es una actividad que nos va a permitir desarrollar nuevas versiones de nuestro proyecto de forma continua sin verse retrasadas por tiempo en sus salidas. Derivar los requerimientos: Esta actividad nos permite detallar requerimientos no visibles para nuestros clientes o usuarios que no se han logrado identificar, pero que son importantes para el funcionamiento adecuado del requerimiento en detalle. Particionar los requerimientos: donde se clasifican los requerimientos en diferentes criterios: Hardware, software y entrenamiento. Asignar los requerimientos: Esta actividad asigna los requerimientos a diferentes subsistemas y componentes internos. Hacer seguimiento a los requerimientos: Se desarrolla la capacidad de permitir que un requerimiento satisfecho pueda ser referenciado dentro del sistema. Manejar los requerimientos: Se desarrolla un sistema de control de los requerimientos, necesario para adicionar, modificar y borrar requerimientos, al igual que la implantación de un repositorio para estos. Probar y verificar los requerimientos: En esta actividad se validan los requerimientos, diseños, código, etc... Para asegurarse que los requerimientos están bien. Validar los requerimientos: Finalmente se confirman los requerimientos reales que han sido implementados. Ejemplos MODELO Actividades Oliver and Steiner 1996 EIA / IS-632 IEEE Std 1220- CMM nivel 1994 Repetitivo (2) Evaluar la información disponible Análisis de Análisis de Identificación de requerimientos Requerimientos requerimientos RUP Análisis del Problema Definir métricas Análisis efectivas funcional Estudio de los Identificación de Comprender las requerimientos restricciones del necesidades de los sistema a desarrollar involucrados Crear un Síntesis modelo del comportamiento del sistema Validación de Análisis de los requerimientos requerimientos Definir el sistema Crear un modelo de los objetos Análisis funcional Representación de los requerimientos Analizar el alcance del proyecto Ejecutar el análisis Evaluación y estudio de funciones Comunicación de los requerimientos Modificar la definición del sistema Crear un plan secuencial de construcción y pruebas Verificación de Validación de funciones requerimientos Análisis y control del sistema Administrar los cambios de requerimientos Síntesis Estudio y evaluación del diseño Verificación física Control Conclusión Es de mucha importancia tomarse el tiempo necesario para conocer a los clientes y usuarios, así como su ambiente de trabajo. Esto ayuda a establecer una buena relación de trabajo y comunicación entre el equipo de desarrollo y los clientes. Es realmente necesario que los clientes y usuarios participen en la definición de sus requerimientos, y con estos tareas, funciones o actividades que acabamos de ver, son necesario porque ponen una serie de estándares para medir y certificar localidad tanto del sistema que está a desarrollar, como también del proceso de desarrollo que con lleva ya que esto son los que deciden el destino del proyecto y se decide del gusto o inconformidad y además del financiamiento que dará de fruto el proyecto. Referencias http://yaqui.mxl.uabc.mx/~molguin/as/IngReq.htmhttp://es.scribd.com/doc/270431/Ingenieriarequerimientos http://www.monografias.com/trabajos6/resof/resof.shtmlhttp://redalyc.uaemex.mx/pdf/666/666 61111.pdf http://ldc.usb.ve/~abianc/materias/ci4712/apuntes3.pdfhttp://es.scribd.com/doc/19083744/ING ENIERIA-DE-REQUERIMIENTOS http://www.monografias.com/trabajos5/inso/inso2.shtml http://www.arcos.inf.uc3m.es/~ii_si/IngReqCIII.pdf http://www.rodolfoquispe.org/blog/que-es-la-ingenieria-de-requisitos.php