Los requisitos son definidos durante las fases más tempranas del desarrollo de sistemas informáticos, y pueden verse como la especificación de lo que debería ser implementado (1). Por lo tanto, y de forma más concreta, la IEEE (Institute of Electrical and Electronics Engineers) (2) los define como:
– Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo
– Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal
– Una representación documentada de una condición o capacidad como en (1) o (2)
Estos requisitos han de ser vistos desde un punto de vista muy relacionado con la ingeniería, lo que implica el uso de técnicas sistemáticas y repetibles para asegurar que los requisitos del sistema son completos, consistentes y relevantes (1). Sin estas técnicas, el equipo de desarrollo (3):
– No sabe cuales son las metas a lograr
– No pueden inspeccionar y probar su trabajo de manera adecuada
– No se puede controlar su productividad
– No obtiene datos adecuados de sus prácticas
– No puede predecir el tamaño y esfuerzo del siguiente proyecto
– No puede satisfacer a sus clientes
En resumen: no hay ingeniería profesional sin requisitos bien gestionados. Todas estas actividades relacionadas con la ingeniería de requisitos, hasta hace no mucho tiempo, eran acometidas de manera absolutamente manual, incluyendo el uso de procesadores de texto para acometer su gestión.
Sin embargo, la aparición de modernas herramientas para la definición y gestión de requisitos ha supuesto un avance extraordinario. Entre otras, puede verse la gestión de diferentes versiones de cada requisito, y la trazabilidad entre estos y otros activos del ciclo de vida como las actividades más beneficiadas del uso de herramientas propias para la gestión de requisitos.
Dónde radica la importancia
La importancia de estos requisitos dentro del conjunto de actividades de desarrollo es patente. El Chaos Report (4) alerta de que sólo un tercio de los proyectos que se comienzan son finalizados en los plazos y costes, y con la calidad esperada. ¿Cuál es la principal razón de esta cifra tan baja? Según este mismo informe, las causas se detallan en la siguiente tabla:
||Factores de fracaso de los proyectos |% de respuestas||
|1. Requisitos incompletos |13.1%|
|2. Escasa involucración del usuario |12.4%|
|3. Escasez de recursos |10.6%|
|4. Expectativas irrealistas |9.9%|
|5. Falta de soporte de la dirección |9.3%|
|6. Especificaciones cambiantes |8.7%|
|7. Falta de planificación |8.1%|
|8. El sistema ya no se necesita |7.5%|
|9. Falta de gestión IT |6.2%|
|10. Analfabetismo tecnológico |4.3%|
|Otros |9.9%|
De estas 10 razones para el éxito, podemos ver que prácticamente la mitad de los apartados se relacionan directamente con la gestión de requisitos. Asimismo, según otros informes del SEI (Software Engineering Institute), alrededor de un 50% de los problemas que sufren nuestros desarrollos están originados en una deficiente etapa de gestión y definición de requisitos; sobre el 45% del esfuerzo total de un proyecto se debe a costes de retrabado debido también a requisitos defectuosos; por último, este informe destaca que un problema en la fase de requisitos, si no es encontrado a tiempo, puede costar entre 5 y 200 veces más esfuerzo solucionarlo que si se hubiese detectado a tiempo.
Por lo tanto, tras ver estos datos, y si sólo el 15% del esfuerzo de un proyecto se dedica a la programación, ¿por qué nos centramos en políticas de calidad y reutilización de código cuando la calidad y reutilización deberían apuntar mucho más a los requisitos más que al código? Veamos a continuación cómo pueden aplicarse técnicas de medición de calidad y de reutilización a nuestros requisitos.
Reutilización de Requisitos
Existen diferentes iniciativas que persiguen la optimización del desarrollo basado en la reutilización de código fuente y componentes ejecutables. Sin embargo, tal y como se acaba de ver, el mayor énfasis debería hacerse principalmente en requisitos y, fundamentalmente, en todos aquellos elementos de alto nivel que garantizan una independencia de la plataforma y, así, evitan el riesgo de obsolescencia. Es decir, la reutilización de un código fuente de gran calidad, pero escrito en un lenguaje en desuso, no tiene valor, mientras que las especificaciones de requisitos no tienen fecha de caducidad tecnológica.
Supongamos que un gran banco invirtió en la construcción de activos reutilizables en Cobol, qué le puede ocurrir ahora que la mayor parte de tecnologías no apuntan en este sentido. Incluso, de forma más reciente, existió un gran auge de reutilización de componentes COM y CORBA; ahora parece que las tecnologías relacionadas con servicios (SOA – Service Oriented Architectures) son las que presentan mayor auge; ¿qué pasará dentro de 5 años?
La apuesta por la reutilización
Necesitamos, visto lo visto, apostar por reutilización de elementos independientes de la plataforma (para evitar el problema de la obsolescencia tecnológica ya referido) y que nos aporten gran valor. ¿Cómo podemos reutilizar requisitos?:
_ Búsqueda semántica de requisitos: permite indexar con técnicas semánticas todos y cada uno de los requisitos de nuestros proyectos. Gracias a estas técnicas, la precisión en la recuperación se puede multiplicar por varios órdenes de magnitud y permitirá recuperar requisitos de proyectos previos hasta ahora inalcanzables. Además, haciendo uso de la trazabilidad, otros activos de estos proyectos previos pueden aportar aún más valor a nuestros nuevos proyectos
_ Patrones de requisitos: las experiencias indican que cada nuevo proyecto relativo a un dominio ya abordado anteriormente comparte un mínimo de un 10% de requisitos con proyectos previos. ¿Cuál es el valor de este 10% en nuestros proyectos? Si almacenamos estos requisitos en un repositorio junto con la definición de sus riesgos, pruebas, código… podremos reutilizarlo en proyectos futuros con un coste mínimo. Podemos clasificar estos patrones en dos grupos: patrones verticales (propios de un dominio dado, p.e. banca, eléctricas…); y patrones horizontales (aplicables a cualquier dominio como por ejemplo, p.e. seguridad, usabilidad…)
_ Requisitos parametrizables: representan un tipo especial de requisitos dentro de un patrón. Contienen una parte común, aunque requieren que se indique algún dato como parte de la instanciación de este requisito en un nuevo proyecto. Por ejemplo “El tiempo de respuesta ha de ser menor que
La reutilización puede proporcionar múltiples ventajas, pero ojo, con este tipo de técnicas hay que garantizar que los activos que se publican para su posterior reutilización hayan pasado unos controles de calidad adecuados. Veamos a continuación una posible forma de medir objetivamente la calidad de una especificación de requisitos.
Métricas de calidad
Completa: describe toda la situación del cliente
Consistente: sin conflictos internos entre requisitos
Correcta: describe de forma precisa y exacta la situación y necesidades del cliente
Modificable: documentados de forma estructurada y accesible
Ordenable: los requisitos pueden ordenarse de acuerdo a su importancia o estabilidad
Verificable: debe ser sencillo determinar la cualidad éxito/fallo de cada requisito
Trazable: con el resto de elementos del ciclo de vida
No ambigua: cada requisito sólo se puede interpretar de una única forma
Tamaño del requisito
Uso de verbos en tiempo imperativo
Uso de verbos en tiempo condicional
Uso de términos ambiguos: ‘bastante’, ‘suficiente’, ‘seguro’, ‘usable’…
Uso de frases no completas: ‘más adelante’, ‘en un futuro’…
Presencia o ausencia de términos del dominio: basado en mapas de conceptos
Presencia o ausencia de verbos del dominio: basado en mapas de conceptos
Legibilidad del texto
Número de dependencias: entre cada requisito y otros activos del proyecto
Volatilidad: Número de versiones generadas tras la aceptación de un requisito
A este conjunto, pueden añadírsele otros indicadores a medir como:
Uso de un único verbo por requisito: lo que permite comprobar la existencia de una única necesidad en cada requisito
Reducción del número de acrónimos y tecnicismos
Limitación del uso de términos relativos al diseño: p.e. base de datos, objeto, campo…
Uso de frases especulativas: p.e. usualmente, generalmente, típicamente…
Localización de conceptos condicionales: p.e. quizá, probablemente…
Conocer estas métricas en el preciso momento en el que se están generando las especificaciones de requisitos permitirán crear documentos bajo la premisa ”Right the first time”, lo que reduce de forma extraordinaria el coste del retrabajo evitando especificaciones de baja calidad y aumentando el valor de la reutilización. Asimismo, nos posibilita entrar en iteraciones de mejora continua, permitiendo monitorizar la mejora de la calidad de los requisitos de nuestros proyectos, e incluso la calidad de cada uno de los ingenieros involucrados.
Conclusiones
Acabamos de ver cómo técnicas de gestión de repositorios (patrones), de búsqueda semántica y de Procesamiento de Lenguaje Natural pueden ser de gran utilidad en los procesos de desarrollo del software y, en particular, en los relacionados con la gestión de requisitos. Su intención es por un lado la reducción de tiempos y costes; y, por otro lado, el aumento de la calidad de nuestros proyectos.
The Reuse Company lanza al mercado un conjunto de herramientas para acometer esta funcionalidad y conseguir alcanzar la calidad deseada para las especificaciones de requisitos.
Requirements REUSER: que nos permite localizar semánticamente requisitos dentro de un repositorio
Requirements Quality Analyzer: que nos permite medir la calidad de los requisitos, tanto de un proyecto dado, como los generados por uno u otro ingeniero involucrado
En esta línea, y para facilitar el acceso a esta interesante funcionalidad por parte de usuarios de otras herramientas de amplia implantación en el mercado, The Reuse Company está alcanzando acuerdos con los principales proveedores de herramientas de gestión de requisitos de cara a incluir esta funcionalidad dentro de sus respectivas herramientas.
