Gestión de requerimientos I

Comenzamos la serie de artículos sobre gestión de requerimientos en software de seguro con la explicación de la orientación general sobre la manipulación de los mismos que daremos en adelante.

La primera de las premisas es que

los requerimientos cambian durante el proyecto

según la cual debemos estar dispuestos a aceptar modificaciones en los requerimientos según avanza el desarrollo.
Porque aunque estemos seguros de la idea que se tiene sobre el proyecto, aunque haya un acuerdo completo en lo esperado, los requisitos son una de las formas de verbalizar esta idea. ¿Qué ocurre? Que la verbalización puede no ser absolutamente precisa al principio y ha de ser refinada a medida que pasa el tiempo o bien puede que no exista ninguna manera de formalizarla. Así que es muy importante que tengamos en cuenta que

los requerimientos son una posible aproximación a lo esperado del sistema.

La manera de ir refinando los requerimientos en conjunto es comunicar de manera fluida con los involucrados en el proyecto, y ello implica identificarlos, temporizar y personalizar los mensajes y tramitar las respuestas.

Consecuentemente, hemos de

enmarcar los requerimientos en un Plan de Requerimientos

que contendrá los siguientes elementos:

1. Un sumario del proyecto


2. Personas y roles involucrados
   
   
   
   • Proveedores de requerimientos
   
   
   • Interesados en el éxito
   
   
   • Responsables de aprobación
    
   
   • Interesados colaterales
   
   
   • Reticencias posibles y apoyos residuales
   
   


3. Modelo de gestión de los requerimientos


• Planificación temporal de tratamiento


• Esbozo del Plan de Gestión de Cambios


4. Esbozo del Plan de Comunicación

Simultáneamente, deberíamos conformar dos planes adicionales, perfectamente reutilizables entre proyectos (y que acabarán constituyendo parte del estilo de desarrollo del equipo):

1. Plan de Gestion de Cambios


2. Plan de Comunicación

En sucesivos artículos entraremos en la descripción detallada de los elementos de estos dos planes junto con el Plan de Requerimientos global.

Los problemas que suelen encontrarse como manifestaciones de una deficiente gestión de los requerimientos, son de sobra conocidos y atribuidos habitualmente a la hipotética crisis del software:
    ➡ Requerimientos incompletos o poco claros
    ➡ Requerimientos cambian muy a menudo
    ➡ Todo tiene la misma prioridad
    ➡ Retraso en la implantación que se aprovecha para añadir más requerimientos
    ➡ Cliente y otros interesados empiezan a ignorar el desarrollo del proyecto
    ➡ Preocupación desorbitada por el presupuesto excedido

Ante estos indicios, podemos extraer una serie de conclusiones parciales sobre la importancia que tiene la manipulación correcta de los requerimientos:

• Escuchar a los usuarios, promotore e interesados NO es suficiente
  
• No se ha de comenzar demasiado pronto
  
• No se ha de comenzar demasiado tarde
  
• Aprovechemos todas las herramientas para nuestro beneficio
  
• Flexibilidad y aceptación del cambio

Evidentemente, si pensamos que los requerimientos no son más que una de las expresiones posibles de las expectativas que un individuo o un conjunto de ellos tienen del sistema, queda claro que no basta con tomar nota de lo que se nos está pidiendo explícitamente. Hay que entender, proponer, sintetizar, eliminar redundancias, buscar relaciones y prioridades, siempre involucrando a los personajes relacionados con el proyecto. Los requerimientos irán surgiendo, refinándose o desapareciendo a lo largo del tiempo de vida del desarrollo del proyecto. Así que nuestra vida será más fácil si los contemplamos como un fruto del proceso de desarrollo mismo: además de la ya vista evolución fluida de los requisitos

son un fruto también del equipo de desarrollo.

El riesgo derivado del inicio temprano o tardío de la codificación, pruebas u otras actividades tradicionalmente consideradas como productivas, lo veremos en la lista de patrones y antipatrones adaptados a la gestión de los requerimientos. Obtendremos un listado de herramientas útiles para la extracción, análisis y manipulación de los requerimientos, así como la repercusión en los distintos modelos de desarrollo de software ágil. Para poder hacer realidad la flexibilidad ante el cambio, tendremos la aplicación de los planes, herramientas y patrones anteriores explicada en detalle adaptándola a este fin.