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 de diseño.

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.