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.
