INGENIERIA DE REQUISITOS

INGENIERÍA DE REQUERIMIENTOS.


2. INGENIERÍA DE REQUISITOS

 La ingeniería de requisitos, según Pressman [Pressman 05], es un conjunto de procesos, tareas y técnicas que permiten la definición y gestión de los requisitos de un producto de un modo sistemático. En definitiva, facilita los mecanismos adecuados para comprender las necesidades del cliente, analizando sus necesidades, confirmando su viabilidad, negociando una solución razonable, especificando la solución sin ambigüedad, validando la especificación y gestionando los requisitos para que se transformen en un sistema operacional. La ingeniería de requisitos permite la gestión adecuada de los requisitos de un proyecto de desarrollo software. Además, mejora la capacidad para realizar planificaciones de los procesos de proyectos de desarrollo software puesto que el conocer qué se tiene que desarrollar permite una efectiva proyección de las actividades, recursos, costos, tiempos, etc. del proyecto. Según Sommerville [Sommerville 05], se puede considerar como el proceso de comunicación entre los clientes, los usuarios del software y los desarrolladores del mismo. Llevar a cabo de manera adecuada el proceso de ingeniería de requisitos disminuye la probabilidad de fracaso de un proyecto. Esto es porque los requisitos bien definidos permiten conocer de un modo conciso que debe ser capaz de realizar el software a desarrollar y hace orientar las actividades, recursos y esfuerzos de manera eficiente permitiendo la disminución de costos y retrasos. Todo ello provoca una mejora en la calidad del software puesto que los requisitos bien especificados podrán probarse de manera efectiva y, por tanto, cumplirse.


2.1. Fases en ingeniería de requisitos

 La definición de las necesidades del sistema juega un papel fundamental en el proceso de desarrollo del software (SPD). Esta definición es un proceso complejo puesto que en él hay que identificar los requisitos que el Patrón de clasificación de tipos de requisitos Página 4 de 107 sistema debe cumplir para satisfacer las necesidades. Para realizar este proceso, no existe una única técnica estandarizada y estructurada que ofrezca un marco de desarrollo que garantice la calidad del resultado. La delimitación de ingeniería de requisitos no es del todo clara puesto que incluso, hay autores que, dentro de la ingeniería de requisitos, generan modelos estáticos de clases que son entendidos por otros autores como tareas de una fase posterior. Dentro de las posibles estructuras que se pueden definir en la fase de ingeniería de requisitos, la propuesta con mayor seguimiento es la establecida por Lowe y Hall [Lowe y Hall 99]. En ella, el proceso de tratamiento de requisitos está compuesto por tres actividades: - Captura de requisitos. - Definición de requisitos. - Validación de requisitos. Se puede representar este proceso de ingeniería de requisitos como un diagrama de actividades en UML, tal como se muestra en la ilustración 1. Es posible plantear el estudio de viabilidad y la gestión de requisitos en el proceso de tratamiento de requisitos. Ilustración 1: Proceso Ingeniería Requisitos Patrón de clasificación de tipos de requisitos Página 5 de 107 El estudio de viabilidad permite definir de modo global la funcionalidad y ver si es factible su ejecución dentro del aspecto económico y del tiempo establecido, elaborando para ello un informe de viabilidad. La gestión de requisitos permite las posibles actualizaciones y cambios que pueden sufrir los requisitos, dando lugar a versiones del documento de requisitos. Esta actividad se desarrolla a lo largo de todo el proceso de desarrollo software.

 2.1.1. Captura de requisitos

La captura de requisitos es la actividad en la que un grupo especializado extrae, de cualquier fuente de información disponible (documentos, aplicaciones existentes, entrevistas, etc.), las necesidades de cubrir dicho sistema. El proceso de captura de requisitos puede resultar complejo, debido a esto existen un conjunto de técnicas que permiten hacer este proceso de una forma más eficiente y precisa, obteniéndose necesidades y modelos del sistema. A continuación se enumeran un grupo de técnicas que son utilizadas para esta actividad: - Entrevistas. Permiten tomar conocimiento del problema y comprender los objetivos de la solución buscada. - Desarrollo de conjunto de aplicaciones. Es una práctica de grupo donde participan usuarios, analistas, administradores del sistema, y clientes y en la que se concretan las necesidades del sistema. - Tormenta de ideas. Consiste en la mera acumulación de ideas sin evaluar las mismas. Ofrece una visión general de las necesidades del sistema pero sin ofrecer detalles concretos. - Mapa conceptual. Grafos en los que los vértices representan conceptos y las aristas representan posibles relaciones entre dichos conceptos. Estos grafos sirven para aclarar los conceptos relacionados con el sistema a desarrollar, ofreciendo una visión general de las necesidades del sistema. Patrón de clasificación de tipos de requisitos Página 6 de 107 - Casos de uso. Muestran el contorno (actores) y el alcance del sistema (requisitos expresados como casos de uso). Un caso de uso describe la secuencia de interacciones que se producen entre el sistema y los actores del mismo para realizar una determinada función. La ventaja principal de los casos de uso es que resultan muy fáciles de entender para el cliente, sin embargo pueden carecer de a precisión necesaria, es por ello que pueden acompañarse de una información textual. - Cuestionarios. Recoge información del sistema de forma independiente de la entrevista.

 2.1.2. Definición de requisitos

 Para la definición de los requisitos son usados lenguajes naturales que, a pesar de poder ser ambiguos y/o extensos, su coste reducido hace que sean la alternativa común a los lenguajes formales. Es necesario elaborar el documento de requisitos, en el cual, se definen los objetivos y necesidades del sistema. Existe un conjunto de técnicas propuestas para esta actividad: - Lenguajes naturales y formales. Los lenguajes naturales es una técnica muy ambigua en contraposición a los lenguajes formales. - Ontologías. Donde se definen los conceptos que intervienen en la definición del sistema así como las relaciones que existen entre ellos. - Patrones. Define los requisitos mediante el lenguaje natural pero de una manera estructurada. Una plantilla es una tabla con una serie de campos y una estructura predefinida. Es necesario clasificar el conjunto de requisitos, pudiendo generarse un catálogo distinto dependiendo del estándar utilizado. Patrón de clasificación de tipos de requisitos Página 7 de 107 2.1.3. Validación de requisitos Por último, se procede a la validación de requisitos, llevándose a cabo la valoración de los mismos, comprobando la veracidad, consistencia y completitud de requisitos. Las técnicas existentes para desarrollar esta actividad son: - Revisiones de verificabilidad. Consiste en la lectura y corrección de la documentación o modelado de la definición de requisitos. - Auditorías. Consiste en un chequeo de los resultados. - Matrices de trazabilidad. Consiste en marcar los objetivos del sistema y chequearlos contra los requisitos del mismo. Es necesario ir viendo que objetivos cubre cada requisito para detectar inconsistencias u objetivos no cubiertos. - Prototipos. Permite que el usuario se haga una idea del sistema. Los requisitos han de ser gestionados mediante el llamado plan de gestión de requisitos que establece las medidas, el método, soporte y técnicas para almacenar los requisitos, gestionar el cambio de éstos (debido a que pueden ser volátiles) y gestionar su trazabilidad.

 2.2. Evolución y negociación de los requisitos

 Desde el principio, se pretende especificar los requisitos de forma detallada pero es casi imposible conocer al principio del proyecto todos los detalles del futuro software. En la práctica, los requisitos son cambiantes dentro del proceso iterativo y evolutivo del software. Pueden existir muchos problemas en los proyectos software por la volatibilidad de los requisitos, muchos clientes desean que se añadan o modifiquen nuevos requisitos por el mismo precio y es tarea del ingeniero negociar esas nuevas funcionalidades no presentadas en el pliego inicial. Es por esto que para llevar con éxito un proyecto, es necesario el contacto continuado entre el cliente y el ingeniero software para conocer las Patrón de clasificación de tipos de requisitos Página 8 de 107 dificultades y necesidades de ambas partes y así buscar una solución de manera conjunta.

2.3. Necesidad del establecimiento y gestión de requisitos

La necesidad de modelar los requisitos dado un sistema tiene una importancia vital puesto que sin éstos el equipo no sabes cuales son las metas a lograr, ni puede inspeccionar y probar su trabajo de modo adecuado, ni puede controlar su productividad, ni puede obtener datos que se adecuen a las pruebas, ni pueden predecir el tamaño y esfuerzo del proyecto. En definitiva, no hay ingeniería completa sin requisitos escritos. Muchos proyectos iniciados no llegan a finalizarse o aquellos que son terminados, incurren en mayores costes y tiempos o no incluyen la totalidad de los requisitos iniciales. Una de las causas de este problema es la deficiente captura y gestión de los requisitos. Otro punto importante de la ingeniería de requisitos es la adecuada gestión de los requisitos que se puede considerar como el factor más relevante para el éxito o el fracaso de un proyecto. Esto es motivado por lo cambiante que son los requisitos. El plan de gestión de requisitos define las medidas, métodos, soportes y técnicas para almacenar los requisitos, gestionar el posible cambio de éstos así como su trazabilidad. La gestión de requisitos no es una tarea sencilla, Chiristel y Kang [Christel y Kang 92], plantean una serie de inconvenientes:  Problemas de alcance. Esto es debido a que es complejo especificar los límites que abarcan los requisitos.  Problemas de comprensión. Esto es debido a que los clientes y usuarios no suelen estar completamente seguros de lo que quieren.  Problemas de volatibilidad. Esto es debido a que los requisitos pueden cambiar con el tiempo puesto que durante el proceso mismo del desarrollo los requisitos evolucionan.