Gestión de requisitos: clave del éxito de los proyectos informáticos

Ya se ha cerrado el presupuesto, se ha definido el objetivo y los plazos están claros: llegados a este punto, las empresas suelen apresurarse a poner en marcha el proyecto en lugar de recabar información acerca de los requisitos concretos de todas las partes interesadas en el producto final. Como resultado, muchos proyectos de software fracasan. Se trata de una pérdida de tiempo y de presupuesto que puede evitarse con una gestión estructurada de los requisitos.

La gestión de requisitos o requirements management es un componente integral de la gestión de proyectostecnológicos cuyo objetivo consiste en garantizar que el producto final se ajusta a lo que desean tanto los clientes, como los stakeholders, sean estos internos o externos.

Este proceso incluye la definición (análisis, documentación y validación de requisitos) y la administración de los requisitos (administración de riesgos, de cambios y de implementación). No se trata, por lo tanto, de una tarea sencilla que se realice una única vez al comienzo del proyecto, sino de un ciclo de procesos recurrentes a lo largo de todo el desarrollo. Un ingeniero de requerimientos es la persona responsable de supervisar la implementación y la integración de estos requisitos, así como de los posibles cambios que puedan surgir a lo largo del proyecto.

En el sector de la tecnología y las TIC, la gestión de requisitos está más consolidada que en otros sectores. En los proyectos informáticos debe especificarse desde el principio qué debe poder hacer el software en cuestión y qué procesos debe llevar a cabo, de lo contrario, es cuestión de tiempo que surjan complicaciones. Sin dichas especificaciones, el tiempo y los recursos no pueden planificarse de manera realista y es muy probable que los clientes empiecen a solicitar cambios que requieran un alargamiento de los plazos y que quizás el presupuesto no cubra. Si dichos cambios, a su vez, no se gestionan como deberían, los costes seguirán aumentando, y así sucesivamente.

La gestión de requisitos, sin embargo, es un elemento clave en cualquier sector. Especialmente en proyectos extensos y productos complejos, la ingeniería de requisitos se encarga de asegurar una gran eficiencia a lo largo de todo el proyecto y de evitar fallos o incongruencias entre las partes implicadas. Un ingeniero o ingeniera de requisitos puede reconocer precozmente cambios en los deseos del cliente y definir medidas para atenuar sus posibles efectos negativos.

Si bien la descripción de los requisitos puede suponer un esfuerzo para el cliente al inicio del proyecto, los frutos de implementar una gestión de requisitos estructurada se reflejan luego en su satisfacción.

• Mayor eficiencia
• Menos solicitudes de cambios durante el desarrollo del proyecto
• Menos errores e incongruencias
• Detección temprana de problemas y de la necesidad de hacer cambios
• Costes más bajos al evitar los fallos
• Finalización del proyecto a tiempo y de acuerdo con el presupuesto inicial
• Clientes más satisfechos

Algunas de las tareas más importantes que abarca la gestión de requisitos son la recopilación, la documentación y el análisis de los requerimientos, así como la gestión de cambios a lo largo del proyecto.

El primer paso es recopilar las especificaciones de todas las partes interesadas. El ingeniero o ingeniera de requisitos dispone de diferentes métodos para identificar los deseos y necesidades de los stakeholders y clientes y crear a partir de ellos la documentación de los requisitos.

• Entrevistas: puede llevar a cabo entrevistas con los stakeholders, ya sea en persona o por teléfono.
• Cuestionarios: también se puede hacer una encuesta por escrito para recabar los requisitos de forma más estructurada. Este método permite recopilar las respuestas de un mayor número de personas.
• Workshops o talleres: las partes interesadas pueden ser invitadas, por ejemplo, a participar en talleres creativos en los que se favorezca la detección de ciertos aspectos del proyecto que quizá no surgirían con una mera lluvia de ideas.
• Observaciones del contexto de aplicación: puede observar cómo trabaja el stakeholder o el cliente y documentarlo por escrito o mediante una grabación.
• Acercamiento al contexto de aplicación: aprende acerca de la actividad del stakeholder para identificar las necesidades que debe satisfacer el producto.
• Arqueología de sistemas: en el caso de sistemas informáticos de los cuales se tiene poca documentación, el ingeniero o ingeniera puede iniciar una investigación acerca del sistema y documentarla. Este análisis puede ser luego complementado con encuestas a usuarios del sistema.
• Reutilización: si se trata de renovar un sistema, probablemente haya que dejar intactos ciertos flujos de trabajo con los que ya se hayan familiarizado los usuarios. Así, en lugar de definir de cero todos los requisitos, se puede recurrir a la documentación ya existente.

El documento de requisitos de proyecto (DRP) es la base del acuerdo contractual entre ambas partes para iniciar el proyecto y es, por lo tanto, el primer documento que debe redactarse en el marco de la gestión de requisitos. En él se describen todas las exigencias del cliente de cara a la empresa encargada del proyecto: es decir, se establece qué se espera del producto final. En algunos casos, el DRP va acompañado de un pliego de condiciones que define por separado cómo debe desarrollarse la implementación.

Además, en muchos casos, conviene documentar los requisitos no solo por escrito, sino también de manera gráfica, especialmente cuando se trata de representar sistemas, procesos y ejemplos de uso. Para hacerlo, suelen usarse los llamados diagramas UML.

Una vez recopilados y documentados los requisitos, el siguiente paso dentro del requirements management es analizarlos. Puede que haya, por ejemplo, indicaciones contradictorias que deban ser aclaradas con las partes interesadas. El ingeniero o ingeniera debe, además, identificar y evaluar riegos (haciendo estimaciones sobre la probabilidad de que ocurran y del posible alcance de los daños). También se deben ordenar los requisitos según su prioridad.

A continuación, la documentación de los requisitos debe presentarse a las partes interesadas para que comprueben si concuerda con su idea del proyecto. El proyecto no debería iniciarse hasta que no se haya llegado a un acuerdo respecto al contenido de estos documentos.

En prácticamente todos los proyectos acaba surgiendo la necesidad de hacer algún cambio una vez iniciado el trabajo. Para evitar grandes discusiones acerca del trabajo adicional que eso supone y para poder deshacer los cambios si el cliente no queda satisfecho, vale la pena hacer distintas versiones. Este método se originó en el ámbito del desarrollo de software, pero se usa también en la gestión de proyectos: se documentan los distintos estados del proyecto y se definen los estados actuales como nuevas baselines o puntos de referencia. Así, es más fácil comparar el alcance de los cambios pasados y de los actuales.

Muchas empresas suponen que la gestión de requisitos no es necesaria en proyectos ágiles, puesto que la dirección del proyecto va cambiando según se va desarrollando, pero se equivocan.

En proyectos ágiles, de gran parte de las tareas que abarca la gestión de requisitos se ocupa el product owner, es decir, la persona que controla y dirige el desarrollo del proyecto y, por lo tanto, la implementación de los requisitos. Esta personase encarga, además, de priorizar ciertos requisitos y coordinar las modificaciones, dos tareas típicas del responsable de la gestión de requisitos.

Si el product owner no puede encargarse de todas las tareas de ingeniería de requisitos, también puede designar a otros miembros del equipo para que controlen la aplicación de nuevas indicaciones y mantengan al día la documentación (acerca de las modificaciones, por ejemplo).

La gestión de requisitos en proyectos ágiles no es tan compleja, pero sigue siendo tan importante como en proyectos clásicos de desarrollo en cascada.