Sei sulla pagina 1di 4

PROCESO DE LA INGENIERÍA DE REQUERIMIENTOS

Los requerimientos se deben descubrir antes de empezar a construir un producto, y que puede ser algo que el producto debe hacer o una cualidad que el producto debe tener. Un requerimiento existe ya sea porque el tipo de producto demanda ciertas funciones o cualidades, o porque el cliente quiere que ese requerimiento sea parte del producto final.

Frederick P. Brooks [Brooks, 1987], dice "La parte más difícil de construir un sistema es precisamente saber qué construir. Los requerimientos se pueden dividir en requerimientos funcionales y no- funcionales. Los funcionales definen qué hace el sistema (describen todas las entradas y salidas), es decir, las funciones del sistema. Por su parte, los no-funcionales definen los atributos que le indican al sistema cómo realizar su trabajo (eficiencia, hardware, software, interfase, usabilidad, etc.); es el cómo, cuándo y cuánto del qué. ¿Qué es la Ingeniería de Requerimientos (IR)?: [Ortas 1997], como un "conjunto de actividades en las cuales, utilizando técnicas y herramientas, se analiza un problema y se concluye con la especificación de una solución (a veces más de una)." Entonces, "Ingeniería de Requerimientos" se utiliza para definir todas las actividades involucradas en el descubrimiento, documentación y mantenimiento de los requerimientos para un producto determinado. ¿Para qué un Proceso de Ingeniería de Requerimientos?: El Proceso de ingeniería de requerimientos es un conjunto estructurado de actividades, mediante las cuales obtenemos, validamos y mantenemos el documento de especificación de requerimientos (ESRE).

Las actividades del proceso incluyen la extracción de requerimientos, el análisis, la negociación y la validación. Modelo de proceso de IR: Un modelo es una simplificación de la realidad que incluye aquellos elementos que tienen una gran influencia y omite aquellos elementos que no son relevantes para el nivel de abstracción dado. los modelos son abstracciones simplificadas y estandarizadas de actividades repetitivas, Sin embargo, en el caso del proceso de IR y desde una perspectiva "intelectual", podemos decir que todos esos diversos modelos parten de una misma base, un modelo "madre" que llamaremos "modelo-abstracto".

Modelo tradicional en cascada: no existen fases claramente delimitadas ya que hay una retroalimentación constante entre las distintas etapas; los requerimientos del sistema van cambiando por circunstancias ajenas al proceso (como una ley nueva o un cambio de mercado que a su vez cambia las necesidades de la empresa) descubren problemas durante la validación que llevan a un cambio de requerimientos, etc.; y todo esto hará que más de una vez tengamos que volver "hacia atrás" en el proceso de IR.

Modelo en espiral: Un modo alternativo de presentar modelos de actividad que toma en cuenta la retroalimentación entre etapas y la repetición de tareas, es el llamado Modelo en Espiral. [Kotonya G.; Sommerville I. 1998.

Actividades de la Ingeniería de Requerimientos.

Usualmente podemos dividir las prácticas de la IR en 4 actividades, a saber:

Extracción es el nombre comúnmente dado a las actividades involucradas en el descubrimiento de los requerimientos del sistema.

Análisis un análisis luego de haber producido un bosquejo inicial del documento de requerimientos; aquí se leen los requerimientos, se conceptúan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requerimientos.

Especificación En esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle.

Validación es la etapa final de la IR. Su objetivo es, valga la redundancia, validar los requerimientos, es decir, verificar todos los requerimientos que aparecen en el documento especificado para asegurarse que representan una descripción, por lo menos, aceptable del sistema que se debe implementar.

1.1 REQUERIMIENTOS DE PROCESO

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 dónde se describen las funciones que realizará el sistema Boehm 1979.

Es un proceso que comprende todas las actividades para crear y mantener los requerimientos de un sistema.

Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.

Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.

Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.

Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.

No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector.

Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación:

inspección, análisis, demostración o pruebas. “Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos” Leite 1987.

1.2 REQUERIMIENTOS DE LOS USUARIOS.

Algunos de los problemas que surgen durante el proceso de ingeniería de requerimientos son resultado de no hacer una clara separación entre los diferentes niveles de descripción. Esto se hace utilizando requerimientos del usuario para determinar los requisitos abstractos de alto nivel, y requisitos del sistema, para designar la descripción detallada de lo que el sistema debe hacer. De igual forma que en estos dos niveles de detalle, se puede producir una descripción más detallada para establecer un puente entre la ingeniería de requerimientos y las

actividades

diseño.

de

Los requerimientos del usuario, los del sistema y la especificación del diseño de software se definen de la siguiente manera:

Requerimientos del usuario:

Son declaraciones en lenguaje

natural

y

en

diagramas de los servicios que

se espera que el sistema provea

y

de

las

restricciones bajo las cuales debe operar. Describen los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema que no posean un conocimiento técnico detallado. Únicamente especifican el comportamiento externo del sistema y evitan, tanto como sea posible, las características de diseño del sistema. Por consiguiente, los requerimientos del usuario no se deben definir utilizando un modelo de implementación. Deben redactarse utilizando el lenguaje natural, representaciones y diagramas intuitivos sencillos. Sin embargo, pueden surgir diversos problemas cuando se redactan en lenguaje natural: falta de claridad, confusión de requerimientos y conjunción de requerimientos.

Los requerimientos del sistema: Establecen con detalle los servicios y restricciones del sistema. El documento de requerimientos del sistema, algunas veces denominado especificación funcional, debe ser preciso. Éste sirve como un contrato entre el comprador del sistema y el desarrollador del software. Son descripciones más detalladas de los requerimientos del usuario. Sirven como base para definir el contrato de la especificación del sistema y, por lo tanto, debe ser una especificación completa y consistente del sistema. Son utilizados por los ingenieros de software como el punto de partida para el diseño del sistema.

La especificación de requerimientos del sistema incluye diferentes modelos del sistema como el de objetos o el de flujo de datos. En principio, los requerimientos del sistema deberán establecer lo que éste hará y no la manera en que se implementará. Sin embargo, en el nivel de detalle requerido para especificar el sistema completamente, es casi imposible excluir toda la información de diseño.

Una especificación del diseño del software: Es una descripción abstracta del diseño del software, que es una base para un diseño e implementación detallados; agrega detalle a la especificación de requerimientos del sistema.