Los objetivos de impacto de un proyecto nos dan un estado objetivo. ¿Dónde queremos estar al final? ¿Qué se debe conseguir con el proyecto? Los objetivos de aplicación proporcionan las condiciones marco. ¿De qué recursos disponemos en el proyecto? ¿Qué camino tomamos para llegar a la meta? Los objetivos del proyecto, es decir, los objetivos de impacto y ejecución, se definen al principio del proyecto, normalmente. Pero, ¿qué significan los requisitos? ¿Y cuándo entran en juego?

Los requisitos son objetivos concretos...

En un proyecto sólo hay unos pocos objetivos, al menos en comparación con los requisitos. Los requisitos suelen existir en forma de listas. Sin embargo, a menudo no se establece realmente la relación entre los requisitos y los objetivos. Al fin y al cabo, ¿qué son los requisitos sino objetivos desglosados? Objetivos detallados del proyecto. Concreción de los objetivos del proyecto. En las primeras fases del proyecto, por ejemplo en la fase de diseño o concepto, se elaboran los requisitos. Esto forma parte de la disciplina del proyecto "Ingeniería de Requisitos". Y los objetivos del proyecto son el punto de partida. Al menos esta es la teoría.

...y los objetivos son requisitos abstraídos

Analicemos esto un poco más de cerca. Demos la vuelta a la línea de tiempo y volvamos de la lista de requisitos a los objetivos. Los objetivos son básicamente el resumen de los requisitos y constituyen un nivel superior de abstracción. En realidad, los objetivos y los requisitos son la misma cosa. Sólo que a diferentes alturas o niveles de consideración. Un ejemplo lo ilustra. Digamos que queremos construir un sistema de software que nos permita planificar mejor nuestros recursos humanos (un objetivo de impacto del proyecto). Además, no debe costar más de 200.000 CHF y debe realizarse en un año (dos objetivos de ejecución del proyecto). Probablemente se trata más de objetivos de proyecto desde la perspectiva de la gestión (de altura).

Es probable que el director del proyecto y su equipo no estén del todo satisfechos con estos objetivos de gestión: ¿Qué significa concretamente "ser capaz de planificar mejor los recursos humanos"? ¿Y qué significa "presentado dentro de un año"? El equipo del proyecto debe conocerlo con mayor precisión y desglosar estos objetivos a su nivel de vuelo. Esta concreción se produce en las primeras fases del proyecto. Mejor podría significar, por ejemplo, que se obtiene más rápidamente una visión general de la utilización de los recursos existentes. O que se puedan registrar las necesidades de recursos en el sistema. Más concreto aún: El sistema debe mostrar gráficamente a un director de departamento las curvas de carga de trabajo de sus empleados durante los próximos 3 meses con sólo pulsar un botón. En el mundo del desarrollo de software, esto se corresponde en cierto modo con una historia de usuario o un caso de uso. (Esta analogía debería ser suficiente para esta aproximación).

Los objetivos son el QUÉ, los requisitos el CÓMO

Al desglosar los objetivos del proyecto en requisitos en el contexto de la ingeniería de requisitos, rápidamente se hace evidente que puede haber varias concreciones para muchos objetivos. El objetivo "mejor" puede entenderse como "más rápido", "más claro" o también "más rentable". Se trata de diferentes enfoques (diseños) para lograr un objetivo. Por lo tanto, hay que tomar muchas decisiones en esta fase del proyecto: Cada objetivo (QUÉ) puede alcanzarse con diferentes soluciones (CÓMO). Y alguien tiene que decidir en esta fase cuál de estas soluciones se llevará a cabo. Se trata de decisiones de diseño que a menudo se toman de forma insidiosa y no realmente consciente en el proyecto.

Del objetivo a la decisión de diseño, pasando por el requisito, ad infinitum

Una vez que los objetivos del proyecto (WHAT) se han transformado en forma de requisitos (HOW) mediante decisiones de diseño, todo el proceso puede repetirse, por supuesto. Estos requisitos pueden considerarse ahora, a su vez, como objetivos detallados. Al fin y al cabo, ¿qué son los requisitos sino objetivos concretados? Así que se pueden concretar aún más. Volviendo a nuestro ejemplo, esto significa que la historia de usuario anterior puede concretarse más. En el desarrollo de software, probablemente se dibujaría aquí un diseño de pantalla que muestre dónde puede pulsar el usuario qué botón, para luego obtener un gráfico de barras, etc. Así es como se puede concretar más la historia de usuario.

Sin embargo, no queremos continuar aquí con este ejemplo de forma tan detallada. La cuestión es que aquí vemos que el desglose de los objetivos en requisitos puede, en principio, repetirse varias veces. Cada requisito (CÓMO) puede verse como un objetivo (QUÉ) en un nivel más profundo, que a su vez puede desglosarse en detalles. Esto podría repetirse a voluntad. En el desarrollo de software, los objetivos pueden desglosarse con decisiones de diseño hasta tal punto que al final surge un pseudocódigo o incluso un código ejecutable y, por tanto, los requisitos son tan concretos que la solución acabada está casi ya delante de ti. A este nivel de detalle, se suele hablar de especificaciones técnicas. Pero, básicamente, se trata de objetivos muy, muy detallados.