DOCUMENTACION DE REQUERIMIENTO

La parte más dura en la construcción de un sistema software es decidir cómo construirlo…Ninguna parte del trabajo mutila el resultado del sistema si está hecho mal. Ninguna parte es más dificultosa para rectificarlo después”.

La ingeniería de requisitos facilita el mecanismo apropiado para comprender lo que quiere el cliente, analizando 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.

Los requerimientos para un sistema de software determinan lo que hará el sistema y definen las restricciones de su operación e implementación.

El proceso de ingeniería de requisitos puede ser descrito en 5 pasos distintos: identificación de requisitos, Análisis de requisitos y negociación, Especificación de requisitos, Modelizado del sistema, Validación y gestión de requisitos.

IDENTIFICACION DE REQUISITOS

Christel y Kang identifican una serie de problemas que nos ayudan a comprender por qué la obtención de requisitos es costosa.

• Problemas de alcance. El límite del sistema está mal definido o los detalles técnicos innecesarios, que han sido aportados por los clientes/usuarios, pueden confundir más que clarificar los objetivos del sistema.

• Problemas de comprensión. Los clientes no están completamente seguros de lo que necesitan, tienen una pobre comprensión de las capacidades y limitaciones de su entorno de computación, no existe un total entendimiento del problema, etc.

• Problemas de volatilidad. Los requisitos cambian con el tiempo.

Para ayudar a solucionar estos problemas, los ingenieros de sistemas deben aproximarse de una manera organizada a través de reuniones para definir requisitos. El resultado alcanzado como consecuencia de la identificación de requisitos variará dependiendo del tamaño del sistema o producto a construir.

ANÁLISIS Y NEGOCIACIÓN DE REQUISITOS

Una vez recopilados los requisitos, el producto obtenido configura la base del análisis de requisitos. Los requisitos se agrupan por categorías y se organizan en subconjuntos, se estudia cada requisito en relación con el resto, se examinan los requisitos en su consistencia, completitud y ambigüedad, y se clasifican en base a las necesidades de los clientes/usuarios.

Es corriente en clientes y usuarios solicitar más de lo que puede realizarse, consumiendo recursos de negocios limitados. También es relativamente común en clientes y usuarios el proponer requisitos contradictorios, argumentando que se versión es “esencial por necesidades especiales”.

El ingeniero del sistema debe resolver estos conflictos a través de un proceso de negociación. Los clientes, usuarios y el resto de intervinientes deberán clasificar sus requisitos y discutir los posibles conflictos según su prioridad. Los riesgos asociados con cada requisito serán identificados y analizados. Se efectúan estimaciones del esfuerzo de desarrollo que se utilizan para valorar el impacto de cada requisito en el costo del proyecto y en el plazo de entrega. Utilizando un procedimiento iterativo, se irán eliminando requisitos, se irán combinando y/o modificando para conseguir satisfacer los objetivos planteados.

ESPECIFICACION DE REQUERIMIENTOS

El termino requerimiento no se utiliza de forma consistente en la industria del software. En algunos casos, un requerimiento se visualiza como una declaración abstracta de alto nivel de un servicio que debe proveer el sistema o como una restricción de éste. Por otro lado, es una definición matemática detallada y formal de una función del sistema.

REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES

A menudo los requerimientos de sistemas de software se clasifican en funcionales y no funcionales, o como requerimientos del dominio.

REQUERIMIENTOS FUNCIONALES

Son declaraciones de los servicios que proveerá el sistema, de la manera en que éste reaccionará a entradas particulares. En algunos casos, los requerimientos funcionales de los sistemas también declaran explícitamente lo que el sistema no debe hacer.

Los requerimientos funcionales de un sistema describen la funcionalidad o los servicios que se espera que éste provea. Estos dependen del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software. Cuando se expresan como requerimientos del usuario, habitualmente se describen de forma general mientras que los requerimientos funcionales del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etc.

Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la especificación de requerimientos. Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación. Sin embargo, a menudo no es lo que el cliente desea. Se tienen que estipular nuevos requerimientos y se deben hacer cambios al sistema, retrasando la entrega de éste e incrementando el costo.

En principio, la especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente. La compleción significa que todos los servicios solicitados por el usuario están definidos. La consistencia significa que los requerimientos no tienen definiciones contradictorias.

 En la práctica, para sistemas grandes y complejos, es imposible cumplir los requerimientos de consistencia y compleción. La razón de esto se debe parcialmente a la complejidad inherente del sistema y parcialmente a que los diferentes puntos de vista tienen necesidades inconsistentes. Estas inconsistencias son obvias cuando los requerimientos se especifican por primera vez. Los problemas emergen después de un análisis profundo. Una vez que éstos se hayan descubierto en las diferentes revisiones o en las fases posteriores del ciclo de vida, se deben corregir en el documento de requerimientos.