ALGUNAS PREGUNTAS SOBRE LA GESTIÓN DE REQUERIMIENTOS

Se suele decir que un buen código tiene en el fondo un buen diseño, sin embargo, un buen diseño solamente se puede verificar teniendo claros los objetivos del producto cuyo desarrollo ha sido emprendido. ¿Quiere decir esto que las únicas características susceptibles de ser medidas están asociadas directamente al dominio de los problemas que dicho desarrollo soluciona?  De no ser así, ¿existe un mínimo de características de naturaleza subyacente que emerge de manera implícita en cada uno de los requerimientos del desarrollo?

Para ponerlo en términos mas simples, cuando decidimos construir software por ejemplo un editor de texto un requisito puede estas asociado a la capacidad del sistema para escribir contenidos por parte de un usuario.  Sin embargo, un requerimiento funcional de este tipo no puede estar completo de ninguna manera sin  tener en cuenta el numero de palabras que deben ser escritas en un tiempo de referencia.  Es decir. No nos sirve que se puedan escribir palabras si cada letra se demora un minuto en procesarse, seria en la practica un sistema completamente inútil.

Si acordamos entonces que existen requerimientos subyacentes a este primero nuestra especificación crecería notablemente y nada sería capaz de garantizarnos que nuevos requerimientos no presenten la misma situación recurrentemente y hasta el infinito.  ¿Cuál seria entonces la granularidad de los requerimientos de manera tal que sea viable establecer con exactitud las caracteristicas funcionales del producto y todos los requerimientos hijos relevantes?  Pareciera que la respuesta se encuentra en las bases mismas del lenguaje. Nada que sea lo suficientemente claro de manera general debe ser reformulado con el fin de esclarecer detalles redundantes.  Los requerimientos técnicos comunes deben plantearse de manera no redundante para poder alcanzar la completitud y la sencillez de manera sensata en nestras definiciones.

Si vieramos una especificacion de un sistema como un arbol donde los nodos de dicho arbol son requerimientos . ¿podriamos construir un algoritmo para construir dicho arbol minimizando el numero de niveles y maximizando la descripcion del problema?  ¿Podríamos realizar una clasificación automática sobre los conjuntos de tipos de requisitos técnicos generales que son comunes a un subconjunto de requerimientos?  Probablemente basados en la experiencia previa algunos algoritmos existentes de clasificación y optimización podrían afinar con precisión cada vez mayor en el tiempo las predicciones de asociaciones o relaciones entre requisitos funcionales y técnicos, logrando una mayor robustez en las definiciones y los objetivos de nuestros desarrollos.

Otra pregunta que podríamos hacernos sería, ¿Existe alguna forma de poder detectar en un esquema evolutivo de los requerimientos aquellas tareas que al final del ciclo de vida del desarrollo no habrán generado valor alguno en el producto final?  Resolver este tipo de interrogantes pueden representar mejoras significativas en la productividad de los equipos, sin embargo, algunas parecen estar asociadas con la visión estratégica de la gestión de los proyectos y otras parecen estar relacionadas con la forma en la que crecen las expectativas a medida que avanzamos en la construcción de los conceptos fundamentales del sistema en cuestión.

Seria interesante poder armar un modelo sencillo con las premisas esperadas con el fin de poder determinar si este tipo de interrogantes sobre la gestión de los requisitos puede abordarse de manera general o si estamos destinados a lidiar sin ninguna generalización clara con las dependencias aparentemente aleatorias entre los criterios que determinarán la calidad del software entregado.  Espero que esto se analice en una entrada posterior.