Un Acercamiento a la Ingeniería de Requerimientos

Transcripción

1 Un Acercamiento a la Ingeniería de Requerimientos José Manuel Bahamonde jbahamon@inf.utfsm.cl Richard Rossel rrossel@inf.utfsm.cl Universidad Técnica Federico Santa María 03 de Noviembre de 2003 Resumen La Ingeniería de Requerimientos es una disciplina que cumple un papel primordial en el proceso de desarrollo de software, ya que se especializa en la definición del comportamiento del sistema, es decir, de lo que se desea desarrollar o producir. En este documento se presenta un acercamiento a la teoría y la práctica de la Ingeniería de Requerimientos, estudiando de manera general algunas técnicas y herramientas que permiten entender los desafíos futuros de esta ciencia. 1. Introducción Por años, la ingeniería de software ha presentado distintas metodologías y herramientas para la obtención de software, cada vez de mejor calidad. Sin embargo, los problemas del desarrollo de sistemas mal definidos no están del todo ausentes. El caso del año 2000, demostró a la comunidad que no solo se debe estar preparado para situaciones esperadas, sino que también para aquellas que no lo son. La integración de tecnologías nos hacen cada vez más dependientes de la calidad de los sistemas que se desarrollan, pero aún así, cómo se explica que muchos de los proyectos de software presenten problemas que no le permiten llegar a destino de la forma que se había planeado. La ingeniería de requerimientos es una disciplina que cumple un papel primordial en el proceso de desarrollo de software, ya que se especializa en la definición del comportamiento del sistema, es decir, de lo que se desea

2 desarrollar o producir. El objetivo principal de la ingeniería de requerimientos es la definición clara, consistente y compacta de las especificaciones correctas que definen el comportamiento del sistema con el fin de minimizar al máximo los problemas que se presentan en el desarrollo de software y que tanto afectan a la calidad del producto final. Desde 1990 hasta la fecha, esta disciplina ha sido reconocida como tal. En 1993, el primer Simposio Internacional de la IEEE sobre Ingeniería de Requerimientos se llevó a cabo [1]. A la fecha, variadas son las técnicas y herramientas que se han desarrollado, y que han permitido aplicar ésta disciplina no solo en el ámbito del desarrollo de software, sino incluso en la definición de requerimientos de componentes para automóviles [5], por ejemplo. Este documento presenta un acercamiento a lo que es la ingeniería de requerimientos, algunas de las metodologías desarrolladas a la fecha, así como los desafíos que se presentan para los próximos años. 2. RE y sus actividades La tarea principal del RE consiste en la generación de informes de especificaciones que describan el comportamiento completo del sistema de forma clara y consistente, de tal forma disminuir los conflictos dentro y fuera del desarrollo del proyecto que se generan muy a menudo. Pero antes de entrar más en detalle revisando las actividades y características de la RE, debemos definir el concepto de requerimiento, para ello citamos la definición que realizó la IEEE: (1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. (3) Una representación documentada de una condición o capacidad como en (1) o (2) Requerimientos Existe dos tipos de requerimientos, funcionales y no funcionales. Los requerimientos funcionales definen las funciones que el sistema será capaz de 2

3 realizar. Estos deben definir y describir los procesos y actividades que componen el sistema completo. Los requerimientos no funcionales son aquellos que no están relacionados directamente con los procesos que definen el sistema, si no más bien tienen que ver con características adicionales, como seguridad, mantenimiento, robustez, portabilidad, etc. Un conjunto de requerimientos en estado de madurez debe poseer ciertas características importantes de mencionar como: Necesario: Un requerimiento es necesario solo si su omisión provoca una deficiencia en el sistema por lo que su reemplazo es imposible. Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara sin llegar a la incompletitud. Completo: Un requerimiento es completo si existe toda la información relacionada a él. Consistente: Un requerimiento es consistente si no se contradice con otro requerimiento. No Ambiguo: Un requerimiento no es ambiguo cuando su especificación tiene solo una interpretación, evitando de esa manera confusiones a los lectores. Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de métodos de verificación como inspección, análisis, demostración o pruebas. Durante la etapa de identificación de requerimientos a menudo surgen problemas y dificultades, a continuación una lista de estas complejidades. Los requerimientos no son obvios y vienen de muchas fuentes. Son difíciles de expresar en palabras Existen una variada gama de requerimientos y diferentes niveles de detalles. Gran número de requerimientos puede volverse inmanejable. Definir las relaciones entre requerimientos y otras áreas de procesos. 3

4 Los requerimientos pueden variar a lo largo del desarrollo del proyecto. Dificultad en la cuantificación de los requerimientos Definición de RE Pareciera ser que con un buen conjunto de requerimientos bien definidos, nos ayudaría a entender mejor el problema que se quiere resolver, obteniendo una visión más completa del panorama. Entonces si se definen bien estos requerimientos, Por qué continuamente el desarrollo de proyectos duran más de lo estimado?, Cuál es el motivo de que los proyectos terminen aumentando los costos de desarrollo?, o Por qué los clientes nunca están conformes con las entregas desarrolladas?. El motivo está centrado en la definición de requerimientos. En la sección 2.1 vimos las dificultades en definir requerimientos, y claro está que son esos los errores cometidos para que cada vez más clientes estén disconformes con la calidad de los softwares obtenidos. Desde hace ya un par de décadas atrás que vieron la importancia de esta actividad del desarrollo de software, y definieron una disciplina especializada en recopilar, analizar y verificar las necesidades del cliente, a esta actividad la llamaron Ingeniería de Requerimientos (RE, Requirements Enginnering). Una definición algo antigua, pero todavía vigente es la de Boehm en Ingeniería de Requerimientos es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en donde se describen las funciones que realizará el sistema Desde que los ingenieros empezaron a incorporar la RE en sus proyectos, vieron las utilidades y beneficios que esta actividad les entregaba. A continuación listaremos algunos de estos beneficios: Permitir las necesidades del proyecto en forma estructurada: Cada actividad de RE consiste de una serie de pasos organizados y bien definidos. Mejora la capacidad de predecir resultados: RE proporciona un punto de partida para los controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios. 4

5 Disminuye costos y retrasos en proyectos: RE proporciona un buen estudio del problema al principio del proyecto, disminuyendo de esta manera los errores encontrados durante el desarrollo, y ahorro de costos de reparación de estos errores. Mejoramiento de la calidad del software: Al cumplir con los requerimientos que define la RE,,mejoramos aspectos de la calidad como funcionalidad, facilidad de uso, confiabilidad, desempeño, etc. Mejoramiento de la comunicación entre equipos: RE proporciona una especificación de requerimientos que representa una forma de consenso entre clientes y desarrolladores. Evita rechazos de usuarios finales: Ya que RE incorpora a sus equipos de trabajos a los usuarios del sistema a desarrollar, obligándolos a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema. Hemos mencionado que la RE incorpora a sus actividades varios equipos de trabajos, contando con muchas personas involucradas en el desarrollo de requerimientos del sistema. El papel desempeñado por cada persona depende de su conocimiento e intereses que posea, por esto es esencial elegir a las personas correctas en las actividades de la RE. Los roles más importantes de la RE se pueden definir como: Usuario final: Son las personas que usarán el sistema desarrollado. Usuario líder: Son las personas que comprenden totalmente el dominio del problema en donde será empleado el software desarrollado. Ellos proporcionan al equipo técnico los detalles y requerimientos de las interfaces del sistema. Personal de mantenimiento: Para proyectos que requieran un mantenimiento eventual. Estas son las personas responsables de la administración de cambios, implementación y resolución de anomalías. Su trabajo consiste en revisar y mejorar los procesos del producto ya finalizado. Analistas y programadores: Son las personas responsables del desarrollo del producto en sí, estos interactúan directamente con el cliente. 5

6 Personal de pruebas: Estas personas se encargan de elaborar y ejecutar el plan de pruebas para asegurar que las condiciones presentadas por el sistema sean las adecuadas. Ellos son quienes validarán si los requerimientos satisfacen completamente las necesidades del cliente. Otros equipos de trabajos no mencionados en la lista pero que a veces aparecen en las actividades de RE son administradores de proyecto, documentadores, diseñadores de bases de datos, entre otros. 3. Técnicas de RE A la fecha se han identificado variadas técnicas que han demostrado ser efectivas al momento de definir los requerimientos del sistema. La utilización de cada herramienta, dependerá de la naturaleza del sistema que se desea definir. A continuación, se presentan cuatro de las técnicas más usadas en esta disciplina Entrevistas y Cuestionarios En esta técnica, el encargado de definir los requerimientos realiza una serie de preguntas a personas o grupos, que pueden ser futuros o potenciales usuarios del sistema que se desea definir. El objetivo es reunir la mayor cantidad de información posible que permita al analista descubrir opiniones, sentimientos y experiencias generales, que no necesariamente tengan relación con el conocimiento de la potencial solución. Las preguntas pueden ser enfocadas a distintos elementos del sistema como por ejemplo usuario, proceso, producto, entre otros. Estas preguntas deben ser de alto nivel y realizadas al comienzo del proceso para así lograr la recaudación de aspectos globales del problema. El éxito del uso de esta técnica dependerá de la experiencia y sensibilidad del entrevistador, ya que además de preparar estratégicamente el curso de la entrevista, debe ser capaz de interpretar la significancia de las respuestas Brainstorm o Lluvia de Ideas Esta técnica busca el incentivo de la creatividad de los participantes del proyecto, creando una atmósfera de trabajo donde todos puedan aportar con 6

7 ideas de la solución final sin que estas sean enjuiciadas ni criticadas hasta que ya nadie tenga una nueva idea que aportar. La lluvia de ideas se suele dividir en tres fases que se caracterizan por su relativa secuencialidad y los resultados que se obtienen. En la fase de Descubrimiento de Hechos, que consta con una etapa de ambientación especialmente importante para aquellos que no tienen experiencia en el tema, se determina y delimita el problema a tratar, para luego investigar documentación de experiencias anteriores, en caso de que exista. La segunda fase, Producción de Ideas, es la más importante, pues es aquí donde se busca producir una gran cantidad de ideas de todos los participantes, para la solución del problema. La tercera etapa, corresponde al Descubrimiento de Soluciones, y es aquella donde se seleccionan las ideas que parecen ser factibles, ponderándolas en caso de que sea necesario para generar la lista que más tarde debe ser analizada en detalle. Los participantes deben ser guiados por un director que se caracterice por una gran capacidad creativa. Este debe ser un moderador del encuentro, además de ser el encargado de definir claramente el problema a tratar. Por último, se desea que no existan diferencias jerárquicas entre los participantes, para que todos se sientan a gusto y sus ideas no sean inhibidas Prototipos. Esta técnica comienza con la definición básica de los requerimientos generales por parte de los usuarios y clientes con el fin de identificar las características globales del sistema. Luego, se diseña y construye una maqueta del sistema que permita la representación de aquellos aspectos del software que serán visibles para el usuario. Esta maqueta es la que se conoce como prototipo y es el que debe ser evaluado por el cliente y el usuario con el fin de refinar los requerimientos del sistema. Se han identificado dos tipos de prototipos, los Prototipos Rápidos, que son aquellos que facilitan la evaluación de los requerimientos en la etapa previa al diseño general del sistema; y los Prototipos Evolutivos, a medida que se avanza en el ciclo de vida del proyecto, los prototipos sufren modificaciones y mejoras con el fin de llegar hasta el producto final. 7

8 3.4. Casos de Uso. Un caso de uso puede ser definido como un conjunto de funcionalidades que le permiten a alguien o algo interactuar con el sistema, es decir, son historias o casos de utilización que ejemplifican e incluyen tácitamente los requerimientos del cliente[4]. Al hablar de algo o alguien, se hace referencia a que los sistemas no solo son usados por personas sino que también por otros sistemas de software o hardware. Esta técnica se divide en siete grandes pasos a seguir para la correcta definición de los requerimientos. Una primera etapa es la correcta identificación de los usuarios o actores del caso de uso, que corresponden a entes externos al sistema y que interactúan con él, es decir, el analista debe preguntarse para quién es este sistema?. Una segunda etapa, es la identificación de los principales casos de uso para cada actor, sin necesidad de conocer el detalle de las actividades que componen el caso de uso. Luego, para evitar la omisión de requerimientos, la tercera etapa consta de la identificación de nuevos casos de usos a partir de los definidos en la etapa anterior. Una vez que se tienen todos los casos de uso identificados, estos deben ser documentados en una cuarta etapa, donde se deben detallar el comienzo, el fin, el flujo normal de eventos, los flujos alternativos y las excepciones al flujo de eventos. En la quinta etapa, se deben definir prioridades de los requerimientos relacionándolos con los casos de uso con el fin de determinar la funcionalidad central, y algunos puntos críticos de éstos. Probablemente, el sistema completo involucra una gran cantidad de casos de uso, por lo que en una sexta etapa se debe definir los gráficos que se usarán y que casos incluirán, con el fin de ordenar la información. Por último, la séptima etapa corresponde a la utilización de herramientas automatizadas cuyos objetivos son la captura, administración y producción de una especificación de requerimientos. Es el caso de la herramienta RequisitePro, de Rational Software 1, o DOORS creada por Quality System and Software 2, las dos herramientas más usadas. 4. Metodologías Desde sus comienzos, variados autores han expuesto sus puntos de vista en la definición y descomposición de las etapas de la Ingeniería de Requerim

9 ientos. A pesar de esto, la mayoría acepta la secuencialidad de tres etapas que cada uno detalla de manera distinta. Las tres etapas, que son el eje central del proceso de gestión de requerimientos, son las siguientes. Elicitación: Es la etapa de mayor interacción con el usuario. Es el momento en el que se recurre a la observación, lectura de documentos, entrevistas, entre otras técnicas. Es la instancia en que equipos multidisciplinarios trabajan conjuntamente con el cliente/usuario para obtener los requerimientos reales de la mejor manera. Análisis: Esta etapa permite al analista representar el dominio de la información de la aplicación a desarrollar a través de un lenguaje más técnico, procurando reducir ambigüedades. Esta etapa le entrega al analista, la representación de la información y las funciones que facilitarán la definición del futuro diseño. Especificación: Es sabido que la forma de especificar tiene mucho que ver con la calidad de la solución, por lo que esta es quizás la etapa de mayor cuidado. Las consecuencias de una mala especificación se padecen en la calidad, oportunidad e integridad del software resultante. En base e estas tres etapas, variadas metodologías han aparecido para la administración de requerimientos. A continuación, se estudia una metodología de documentación de requerimientos centrada en el usuario, como referencia a muchas otras propuestas por distintos autores Metodología DoRCU para RE[3] DoRCU, Documentación de Requerimientos Centrada en el Usuario, es una metodología para la RE caracterizada por su flexibilidad y orientación al usuario. Esta metodología considera los mejores resultados de otros enfoques estudiados y se apoya en diversos métodos, técnicas y herramientas desarrolladas por otros autores, pero sin comprometerse con los lineamientos de un paradigma particular. La metodología DoRCU consta de cuatro etapas para las cuales se definen distintos objetivos. Elicitación de Requerimientos: En esta etapa se adquiere el conocimiento del trabajo del cliente/usuario, se busca comprender sus necesidades 9

10 y se detallan las restricciones medioambientales. Como resultado, se obtiene el conjunto de requerimientos de todas las partes involucradas. Análisis de Requerimientos: Aquí se estudian los requerimientos extraídos de la etapa anterior, con el fin de detectar áreas no especificadas, requisitos contradictorios y peticiones vagas e irrelevantes. Los resultados de este análisis podrían determinar el regreso a la etapa anterior para eliminar falencias e inconsistencias. Aquí se realizan acercamientos al lenguaje técnico. Especificación de Requerimientos: A partir de lo elaborado en la etapa anterior (funciones, datos, requerimientos no funcionales, objetivos, restricciones de diseño/implementación, costos), e independiente de como se realice, esta es una etapa de descripción del requerimiento. Evidentemente, esta etapa podría determinar el regreso a la anterior en caso de que exista alguna dificultad en la descripción de algún requerimiento. Validación y Certificación de los Requerimientos: En esta etapa se produce la integración y validación final de lo obtenido en las etapas anteriores, entregando como resultado final, el Documento de Requerimientos. Se crean dos copias de este documento, uno destinado al cliente/usuario con los efectos de la certificación de los requisitos, y otra copia técnica orientada a nutrir las restantes etapas de la Ingeniería de Software. Para cada una de estas, se definen cuatro etapas, las que no serán estudiadas en detalle, pero se mencionarán como referencia. 1. Elicitación de Requerimientos. Formar Equipo Multidisciplinario. Buscar hechos. Recolectar y clasificar requerimientos. Evaluar y racionalizar. Dar Prioridad. Integrar y Validar. Documentar la Etapa. 10

11 2. Análisis de Requerimientos. Reducir ambigüedades en los requerimientos. Traducir a lenguaje técnico los requerimientos. Plantear un modelo lógico. Documentar la Etapa. 3. Especificación de Requerimientos. Determinar el tipo de requerimiento. Elegir la herramienta de especificación. Especificar de acuerdo a la herramienta seleccionada. Documentar la etapa. 4. Validación y certificación de requerimientos. Elegir o diseñar el modelo de documento acorde al grado de detalle requerido. Elegir herramienta de documentación. Documentar respetando estándares vigentes. Verificar que el documento de requerimientos de usuario sea isomórfico con el documento técnico. Certificar el documento de requerimientos del usuario a través del conforme del usuario. A pesar de ser esta una metodología específica, entrega las pautas para entender otras metodologías propuestas. Algunas de las ventajas de la metodología DoRCU son las siguientes. Contribuye al entendimiento de la Ingeniería de Requerimientos al detallar etapas bien definidas. Ofrece libertad de acción para la selección e integración de las herramientas a emplear. Contempla aspectos metodológicos para la obtención del Documento de Requerimientos. Puede ser aplicada a distintos paradigmas. 11

12 5. Metas y Desafíos[1] Desde 1993 se han realizado conferencias que tienen como objetivo intercambiar ideas, resultados de investigación, visiones e innovaciones en el campo del ER, como por ejemplo IEEE International Symposium on Requirements Engineering y International Conference on Requirements Enginnering, siendo la IEEE International Requierements Engineering Conference la más importante de todas. Esta última conferencia se llevó a cabo en Septiembre del 2002 en Essen, Alemania. Los participantes de esta conferencia identificaron nuevos temas importantes tales como mejoramientos significativos del establecimiento de técnicas y herramientas. Algunos de estos son: Gestión Continua de Requerimientos Tradicionalmente, RE fue vista como una fase temprana en el proceso de desarrollo. Como se propuso en la mitad de los 90, a causa de los menores tiempos de salida al mercado, cambios técnologicos y los ambientes dinámicos, se produjo un cambio en la vista tradicional. Por esto, entonces RE debería entenderse como una actividad continua que gestiona la evolución de requerimientos a través del ciclo de vida del sistema y entre sus fronteras. El artículo de Matthias Weber y Joachim Weisobrod describe las experiencias y desafíos al adoptar una intensa gestión de requerimientos en la industria del automóvil de la DaimlerChrysler[5]. Abismo entre requerimientos y software Una continuidad debería existir desde el dominio del problema al dominio de la solución, como una estructura del problema, dado que usualmente difiere de lo que se quiere como solución. Algunas personas discuten soluciones que garantizan esta continuidad basada en chequeos consistentes sistemáticos entre los dos niveles. Otros enfatizan la definición y uso de estructuras reusables de problemas, que pueden entonces ser asociados con arquitecturas bien definidas. Gestión de Procesos ER Hubo una evidencia clara que los procesos RE son definidos y distribuidos en organizaciones con muchas sucursales. Un artículo describe la importancia de la gestión de procesos de requerimientos en los Sistemas Médicos Philips[2], este nos muestra una introducción a un sistema coordinado y centralizado de gestión de documentos de requerimientos y los procesos de soporte que requiere. 12

13 6. Conclusiones La definición de requerimientos es uno de los principales pasos que determinan del éxito de un proyecto de desarrollo y la calidad de la solución final. En este contexto, la ingeniería de requerimientos es una disciplina, que al igual que otras, requiere de tiempo de experiencia y desarrollo para descubrir más y mejores metodologías o técnicas que demuestren la efectividad de su aplicación. Por ahora, las técnicas o metodologías que se utilicen para la definición correcta de los requerimientos, dependerá del proyecto en desarrollo, y los resultados para cada una de ellas serán distintos. Es necesario realizar un estudio más exhaustivo de los avances y desafíos de la ingeniería de requerimientos para concluir su estado. Los casos prácticos de la aplicación de esta disciplina tanto en ámbitos de la ingeniería de software como en otros que no tienen relación, podrían demostrar la efectividad de la administración de los requerimientos en la calidad del producto final. Referencias [1] Eric Dubois and Klaus Pohl. Re02, a major step toward a mature requirements engineering community. IEEE Software, pages 14 15, Enero/Febrero [2] Stewart A. Higgins, Maurice de Laata, Paul M.C. Gieles, and Emilienne M. Geurts. Managing requirement for medical it products. IEEE Software, pages 26 33, Enero/Febrero [3] Silvia I. Barba Brunner M. Griselda Báez. Metodología dorcu para la ingeniería de requerimientos. Instituto Superior Politécnico José Antonio Echevarría, [4] T. Quatrani. Introduction to the unified modeling language. Rational Software Coporation, [5] Matthias Weber and Joachim Weisbrod. Requirements engineering in automotive development: Experiences and challenges. IEEE Software, pages 16 24, Enero/Febrero