Ingeniería de requisitos

Ingeniería de requisitos (RE) es el proceso de definir, documentar y mantener requisitos en el proceso de diseño de ingeniería. Es un rol común en la ingeniería de sistemas y la ingeniería de software.

El término ingeniería de requisitos se utilizó por primera vez probablemente en 1964 en el artículo de la conferencia "Mantenimiento, mantenibilidad e ingeniería de requisitos del sistema", pero no llegó a ser de uso general. hasta finales de la década de 1990 con la publicación de un tutorial de la IEEE Computer Society en marzo de 1997 y el establecimiento de una serie de conferencias sobre ingeniería de requisitos que se ha convertido en la Conferencia Internacional de Ingeniería de Requisitos.

En el modelo en cascada, la ingeniería de requisitos se presenta como la primera fase del proceso de desarrollo. Los métodos de desarrollo posteriores, incluido el Proceso Unificado Racional (RUP) para software, suponen que la ingeniería de requisitos continúa durante toda la vida útil de un sistema.

La gestión de requisitos, que es una subfunción de las prácticas de Ingeniería de Sistemas, también está indexada en los manuales del Consejo Internacional de Ingeniería de Sistemas (INCOSE).

Actividades

Las actividades involucradas en la ingeniería de requisitos varían ampliamente, según el tipo de sistema que se está desarrollando y las prácticas específicas de la organización involucradas. Estos pueden incluir:

1. Necesidades de creación o requisitos de obtención – Los desarrolladores y los interesados se reúnen; estos últimos se preguntan sobre sus necesidades y deseos respecto al producto del software.
2. Análisis de requisitos y negociación – Se identifican requisitos (incluidos los nuevos si el desarrollo es iterativo), y se resuelven conflictos con los interesados. Tanto las herramientas escritas como gráficas (las últimas utilizadas comúnmente en la fase de diseño, pero algunas las encuentran útiles en esta etapa, también) se utilizan con éxito como ayudas. Ejemplos de herramientas de análisis escrito: utilizar casos e historias de usuarios. Ejemplos de herramientas gráficas: UML y LML.
3. Modelo de sistema – Algunos campos de ingeniería (o situaciones específicas) requieren que el producto esté completamente diseñado y modelado antes de que comience su construcción o fabricación. Por lo tanto, la fase de diseño debe realizarse con antelación. Por ejemplo, los planos de un edificio deben elaborarse antes de que cualquier contrato pueda ser aprobado y firmado. Muchos campos podrían derivar modelos del sistema con el lenguaje de modelado de ciclos de vida, mientras que otros, podrían usar UML. Nota: En muchos campos, como la ingeniería de software, la mayoría de las actividades de modelado se clasifican como actividades de diseño y no como actividades de ingeniería de requisitos.
4. Especificación de requisitos – Los requisitos se documentan en un artefacto formal llamado Requisitos Especificación (RS), que se convertirá en oficial sólo después de la validación. Una RS puede contener información escrita y gráfica (modelos) si es necesario. Ejemplo: especificación de requisitos de software (SRS).
5. Requisitos de validación – Comprobando que los requisitos y modelos documentados son consistentes y satisfacen las necesidades de los interesados. Sólo si el borrador final pasa el proceso de validación, la RS se vuelve oficial.
6. Gestión de requisitos – Gestionar todas las actividades relacionadas con los requisitos desde el inicio, supervisando a medida que se desarrolla el sistema, e incluso hasta después de que se ponga en uso (por ejemplo, cambios, extensiones, etc.)

A veces se presentan como etapas cronológicas aunque, en la práctica, hay un considerable entrelazamiento de estas actividades.

Se ha demostrado que la ingeniería de requisitos contribuye claramente al éxito de los proyectos de software.

Problemas

Un estudio limitado realizado en Alemania presentó posibles problemas en la implementación de la ingeniería de requisitos y preguntó a los encuestados si estaban de acuerdo en que se trataba de problemas reales. Los resultados no se presentaron como generalizables, pero sugirieron que los principales problemas percibidos eran requisitos incompletos, objetivos móviles y limitaciones de tiempo, siendo los problemas menores fallas de comunicación, falta de trazabilidad, problemas terminológicos y responsabilidades poco claras.

Crítica

Se ha especulado que la estructuración de problemas, un aspecto clave de la ingeniería de requisitos, reduce el rendimiento del diseño. Algunas investigaciones sugieren que es posible que si hay deficiencias en el proceso de ingeniería de requisitos que resultan en una situación en la que los requisitos no existen, los requisitos de software pueden crearse independientemente como una ilusión que tergiversa las decisiones de diseño como requisitos.