Un puente hacia el diseño y la Construcción

Las actividades de diseño y construcción de software de computadora son desafiantes, creativas y hasta divertidas. De hecho, la construcción es tan irresistible que muchos desarrolladores de software quieren entrar en ella antes de comprender con claridad de que es lo que se necesita. Ellos argumentan que las cosas se aclaran mientras construyen; que los interesados en software serán capaces de entender mejor las necesidades solo después de examinar las primeras iteraciones del software; que las cosas cambian tan rápido que la ingeniería de requisitos es una pérdida de tiempo; que la línea base produce un programa que funciona y todo lo demás es secundario. Lo que hace seductores a estos argumentos es que contienen elementos de verdad. Pero cada uno de ellos es imperfecto y puede conducir a un proyecto de software fallido.

“La parte más difícil de construir un sistema de software es decidir que construir.  Ninguna parte del trabajo estropea tanto el sistema resultante si se hace mal. Ninguna parte es más difícil de rectificar después”.

La ingeniería de requisitos, como todas las demás actividades de la ingeniería del software, debe adaptarse a las necesidades del proceso, el proyecto, el producto y las personas que realizan el trabajo. Desde la perspectiva del proceso del software, la ingeniería de requisitos (IR) es una acción de la ingeniería de software que comienza durante a actividad de comunicación y continua en la actividad de modelado.

En algunos casos se elige un enfoque abreviado. En otros, cada una de las tareas definidas para comprender los requisitos de debe llevar a cabo de manera rigurosa. Sobre todo, el equipo de software debe adaptar su enfoque a la IR, lo que no significa abandono. Es esencial que el equipo de software haga un esfuerzo real por entender los requisitos de un problema antes de intentar resolverlo.

La ingeniería de requisitos tiende un puente hacia el diseño y la construcción. Pero ¿Dónde se origina el puente? Se puede argumentar que comienza al pie de los participantes del proyecto (es decir, gerentes, clientes, usuarios finales), donde se definen las necesidades del negocio, de describen los escenarios de los usuarios, se delinean las características y funciones, y se identifican las restricciones del proyecto. Otros quizás sugieren que comienza con la definición más amplia del sistema, en el que el software es solo un componente del dominio del sistema que se inicia en la parte alta del proyecto, lo que permite que el equipo de software examine el contexto del trabajo de software que será realizado; las necesidades específicas que el diseño y la construcción deben abordar; las prioridades que indican el orden en que se deben completar el trabajo; y la información, las funciones y los comportamientos que tendrán un impacto profundo en el diseño resultante.