Breve historia de la ingeniería de requisitos

Antes de la aparición de la ingeniería de requisitos, éstos eran competencia exclusiva del análisis de sistemas. En esta área se elaboraron algunos métodos de desarrollo estructurado como SA/SD (análisis y diseño estructurados) (De Marco, 1978), SADT (análisis de sistemas y técnica de diseño) (Ross y Schoman, 1977) o SSADM (análisis estructurado de sistema y método de diseño) (Downs et al., 1992). La idea general de todos estos métodos consiste en comenzar analizando los requisitos mediante un enfoque “divide y vencerás” que permita ir fraccionando el sistema en piezas más pequeñas y después definir las funciones u objetivos que cada parte del sistema debería realizar.

¿El análisis de sistemas no era suficientemente bueno? ¿Era realmente necesaria una nueva sub-disciplina como la ingeniería de requisitos? Parte de la respuesta hay que encontrarla en la comunidad académica. El análisis de sistemas está profundamente enraizado con los sistemas de información, una comunidad centrada en las metodologías y el modelado conceptual, de modo que probablemente el concepto de análisis de los requisitos surgió ligado a los esquemas tradicionales de descomposición funcional top-down. Los requisitos eran capturados y listados como objetivos del usuario, y después elaborados como un conjunto de funciones representados en diagramas de flujo de datos, procesos SADT o cualquier otra técnica de modelado.

El enfoque de los métodos estructurados para el análisis de requisitos fue desafiado en los 80 por las técnicas JAD (Joint Applications Development, Desarrollo Conjunto de Aplicaciones en español) (DSDM Consortium, 1995), que trataron de superar el incómodo y lento proceso de modelado involucrando a los usuarios en el diseño a través de reuniones, tormentas de ideas y escenarios. El enfoque del análisis funcional top-down sería también desafiado por la comunidad partidaria de la orientación a objetos, más inclinada por modelar el dominio del problema antes que establecer objetivos y funciones. Esto allanó el camino a la generación actual de métodos orientados a objetos: ingeniería de sistemas orientados a objetos (Jacobson et al., 1992), la técnica de modelado de objetos (Rumbaugh, 1991) y el análisis y el diseño orientados a objetos (Coad y Yourdon, 1991), sólo por citar algunos. Más recientemente, la comunidad de la orientación a objetos definió un estándar de desarrollo con la creación de UML y del Proceso Unificado, aunque sin aportar nada en cuanto al análisis de requisitos más allá de los casos de uso y escenarios.

La otra influencia de la ingeniería de requisitos la encontramos en la ingeniería del software, una comunidad tradicionalmente interesada en la especificación formal y en la entrega de productos software fiables, a menudo para sistemas de telecomunicaciones en tiempo real y aplicaciones críticas. Los ingenieros de software se encontraron con que, a pesar de contar con detalladas especificaciones formales, algunos sistemas no eran aceptados o fallaban en circunstancias que no habían podido predecirse.

La ingeniería de requisitos ha crecido a partir de estas áreas, a las que además ha contribuido de manera muy significativa. Asimismo, se ha centrado en investigar técnicas y herramientas que complementen los métodos de ingeniería del software.

La fundación de la ingeniería de requisitos puede encontrarse en una colección de artículos (Thayer y Dorfman, 1990) y ediciones especiales de Transactions on Software Engineering (IEEE-TSE, 1991) (Davies y Hsai, 1994), seguidos por las conferencias del IEEE (Filkenstein y Fickas, 1993). Estos eventos revelaron una importante diversidad de temas de investigación y prácticas industriales que estaban más relacionados con el qué construir que con el cómo construirlo. En 1993 Lubas, Potts y Ritcher (Lubars et al., 1993), en el marco de una investigación sobre las prácticas de ingeniería de requisitos en las empresas, expusieron que los requisitos ambiguos y cambiantes constituían un problema constante y que los desarrolladores preferían soluciones organizacionales antes que tecnológicas para hacer frente a los problemas relacionados con la ingeniería de requisitos. Más recientemente, algunos estudios de campo (El Emam y Madhavji, 1995) han determinado que la falta de personal cualificado y los métodos inadecuados son responsables de posteriores defectos en los sistemas.

Referencias

Para terminar, algunas referencias bibliográficas interesantes que he citado durante el post:

Coad, P., y Yourdon, E. E. (1991). Object-oriented analysis. Englewood Cliffs, NJ: Yourdon Press.

Davies, A. M., y Hsai, P. (1994). Proceedings IEEE International Conference on Requirements Engineering .

De Marco, T. (1978). Structured analysis and systems specification. Englewood, NJ: Prentice Hall.

Downs, E., Clase, P., y Coe, I. (1992). Structured systems analysis and design method: Application and context (2ª edición ed.). Nueva York: Prentice Hall.

DSDM Consortium. (1995). Dynamic Systems Development Method.Farnham Surrey: Tesseract Publishers.

El Emam, K., y Madhavji, N. H. (1995). A field study of requirements engineering practices in information systems development. Proceedings on 1995 IEEE International Symposium on Requirements Engineering (RE95) .

Filkenstein, A. C., y Fickas, S. (1993). Proceedings on 1993 IEEE International Symposium on Requirements Engineering (RE93).

Lubars, M., Potts, C., y Ritcher, C. (1993). A review of the state of the proactive in requirement modeling. Proceedings 1st International Symposium on Requirements Engineering.

Ross, D. T., y Schoman, K. E. (1977). Structured analysis for requirements definition. IEEE Transactions on Software Engineering (3), 23-47.

Rumbaugh, J. (1991). Object oriented modelling and design. Englewood Cliffs, NJ: Prentice Hall.

Thayer, y Dorfman. (1990). Systems and Software Requirements Engineering. IEEE.

Leave a Reply

Your email address will not be published. Required fields are marked *