Patrones de especificación de requisitos

Otra entrevista más. Si tenemos suerte no se alargará más de la cuenta. Si tenemos aun más suerte no divagaremos demasiado y hasta seremos capaces de entender los requisitos o aquello que sea que nos pide el entrevistado. Y, si ya somos enormemente afortunados, encontraremos la forma de transmitir todo aquello a lo que llamamos requisitos de usuario en algo comprensible para el equipo de desarrollo.

Detrás de esa suerte, por supuesto, se encuentra el talento. Y, un poco más atrás (habitualmente al fondo a la derecha), los recursos metodológicos habituales. Hoy vamos a centrarnos precisamente en esta última parte. Por ejemplo, estamos acostumbrados a la clasificación tradicional de los requisitos (usuario, funcionales, no funcionales) que no aporta prácticamente ningún valor salvo para crear secciones en los documentos Word. Sin embargo, podríamos y deberíamos ser mucho más ambiciosos a la hora de etiquetar y clasificar requisitos.

Hay que tener en cuenta que recoger y especificar requisitos no es una actividad sencilla. Requiere dotes técnicas para poder manejar conceptos del negocio o tecnológicos, capacidades sociales y mucha psicología para llevar a cabo entrevistas y, por supuesto, un buen manejo del lenguaje y de las reglas de modelado para evitar ser ambiguo al escribir o representar los requisitos. Requiere, en definitiva, una gran cantidad de aptitudes tanto humanas como técnicas.

Aunque parece que todo está dicho acerca de la gestión de requisitos, creo que todavía hay mucha inmadurez en los procesos y las técnicas aplicadas, con lamentables consecuencias de las que habremos leído y oído en infinidad de ocasiones.

Nada más lejos de mi intención el hecho de inundaros con números, estadísticas o análisis sobre las problemáticas habituales. Por el contrario, os voy a proponer algunos patrones que pueden ayudar a mejorar los modelos clásicos de gestión de requisitos. Como todo patrón que se precie, estos también incorporan prácticas y experiencias que han funcionado bien en diferentes dominios.

Patrón #1. Necesidades y especificaciones. DIVISIÓNHay muchas definiciones sobre lo que es un requisito. De hecho, hay demasiadas para hacerse una idea clara de lo que realmente es.

Más que hablar de requisitos, que es un concepto tremendamente ambiguo, yo prefiero referirme a necesidades para expresar todas aquellas peticiones (los problemas que realmente se quieren solucionar) que nos llegan originalmente del interlocutor y especificación para todas aquellas definiciones formales que establecen lo que el producto final debe ser.

Patrón #2. Necesidades y especificaciones. CLASIFICACIÓNMás allá de la clasificación ortodoxa de requisitos, la cual tiende a difuminar demasiado la diferencia entre necesidades y especificaciones, debemos avanzar hacia un modelo más ambicioso y asignar diferentes categorías o etiquetas adaptadas, evidentemente, a las características de nuestros desarrollos.

Por ejemplo, podríamos clasificar las necesidades como:

• Limitaciones, políticas, restricciones u objetivos impuestos por el negocio cuando tratamos aspectos muy cercanos a los responsables.

• Escenarios, precondiciones, capacidades, atributos del sistema, aspectos técnicos, funcionales u otras necesidades cercanas a lo que se espera del producto cuando hablamos con usuarios.

• Descripciones muy concretas de datos, diseños de pantallas u otros aspectos de infraestructura más a bajo nivel cuando nuestros interlocutores tienen un nivel y conocimiento técnico y de la aplicación muy alto.

Algo similar podemos hacer con las especificaciones. Las habrá puramente textuales y las clasificaremos como reglas de negocio, restricciones tecnológicas o de diseño, lista de funcionalidades, etc. Pero también las habrá gráficas, normalmente basadas en modelos UML que recogen casos de uso, entidades del dominio o aspectos de navegación e interfaz gráfica de usuario.

Quiero insistir nuevamente en la diferencia tan sutil, pero tan importante entre necesidades (más o menos técnicas, más o menos de alto nivel pero necesidades al fin y al cabo) y especificaciones (más o menos gráficas más o menos formales, pero que describe claramente las características del producto).

Patrón #3. Necesidades y especificaciones. DERIVACIÓNSi hemos conseguido clasificar las distintas instancias de uno u otro tipo, ahora es sencillo establecer una correspondencia entre ellas.

Ilustración 1. Posible mapeo de necesidades

Por ejemplo, una regla impuesta por el usuario puede derivarse en una precondición de un caso de uso; o un cambio en la navegación puede derivarse directamente en una nueva versión de nuestro modelo de interfaz de usuario.

Es decir, partiendo de una determinada necesidad, podremos obtener una especificación para nuestro producto de manera muy directa, escribiendo o modelando de manera formal lo que dicha necesidad sugiere, ya sea un aspecto de negocio, de comportamiento de la aplicación o de infraestructura y no sólo identificaremos más rápido y mejor lo que nos dice el cliente, sino que lo transmitiremos mejor al equipo de desarrollo.

Patrón #4. Necesidades y especificaciones. GESTIÓNLas necesidades, como todos sabemos, nunca cesan de surgir. Cuando las recogemos al principio del proyecto, las solemos llamar requisitos. Cuando no tenemos más remedio que asumirlas durante la implementación del producto las llamamos cambios. En cualquier caso, siempre son las necesidades los elementos que disparan cualquier ciclo de desarrollo, bien sea un proyecto, una iteración, una release o un parche, y tienen vigencia exclusivamente dentro del ciclo en el que se tratan.

En cuanto a las especificaciones, al representar formalmente las características del producto, las tendremos que mantener a lo largo de toda la vida útil del mismo al igual que el código, la base de datos o las pruebas. Por tanto, permanecen vigentes para todos y cada uno de los ciclos de desarrollo que afrontemos.

Este paradigma abre nuevas y emocionantes perspectivas en la gestión de requisitos, por ejemplo:

o Los criterios de calidad exigidos a la hora de describir necesidades o especificaciones del producto (nivel de ambigüedad, completitud, consistencia, etc.) se orientarían a cada tipología en particular

o El análisis de impacto y de trazabilidad estaría basado en considerar a las necesidades como punto inicial o final de dicho análisis

o Podríamos estimar el tipo de necesidades que irían surgiendo a lo largo de la vida del producto y por tanto, preparar mejor a nuestros equipos y stakeholders para optimizar su tratamiento. En fases iniciales, el tipo de necesidades que recibimos tienen más que ver con el negocio o con funcionalidades de alto nivel, mientras que en fases de construcción o mantenimiento del producto, recibiremos necesidades de tipo más técnico, mucho más concretas y atómicas.

Ilustración 2. Evolución de necesidades en el ciclo de vida

Resumiendo, un modelo coherente de división, clasificación, derivación y gestión de necesidades del usuario y especificaciones del producto es la mejor ayuda para tratar con esos compañeros de viaje llamados vulgarmente requisitos y que esconden aún muchos secretos. Antes o después descubriremos todos ellos y, sin duda, el reto se presenta apasionante.