Son muchos los informes que apuntan en la línea de que el requisito debería ser el activo al que dediquemos una mayor atención durante todo el ciclo de vida de desarrollo de software; sin embargo, muchas veces no se hace así. Se obtienen innumerables métricas de nuestro software, pero casi siempre relacionadas con el código fuente o la planificación, y nunca en relación a nuestros requisitos.

Por otro lado, contar con productos como IRQA permite la correcta gestión de nuestros requisitos, pero se necesitan herramientas que permitan indicar si el nivel de calidad de nuestras especificaciones es correcto, así como alertar de los posibles puntos de mejora y, en definitiva, aumentar la calidad de nuestro software.

A través de IRQA Quality Analyzer podrá acometer esta importante tarea. Para ello, se ha efectuado un mapeo entre aquellas cualidades deseables de cualquier documento de especificación de requisitos (completa, consistente, verificable, no ambigua…) y una serie de indicadores y métricas de fácil medida mediante técnicas de Procesamiento de Lenguaje Natural (NLP):

• Tamaño del requisito: con la intención de evitar tanto requisitos muy breves, como aquellos muy extensos y complejos. Este tamaño puede medirse en caracteres, en palabras, en párrafos, en número de conceptos propios del dominio tratado...
• Uso de verbos en tiempo imperativo: este tiempo verbal debería predominar sobre el resto
• Uso de verbos en tiempo condicional: toda SRS debe evitar especulaciones, de ahí el hecho de evitar sentencias condicionales
• Uso de términos ambiguos: términos como "bastante", "suficiente", "seguro", "usable"… son difíciles de medir
• Uso de frases no completas: "más adelante", "en un futuro"… hacen que cada requisito no sea completo
• Presencia o ausencia de términos del dominio: evitando en la medida de lo posible términos no concernientes con el problema a modelar; pero también intentando acotar el número de conceptos tratados en un único requisito para conseguir requisitos atómicos
• Presencia o ausencia de verbos del dominio: por la misma razón que el anterior
• Legibilidad del texto: requisitos no legibles (frases demasiado extensas y palabras demasiado complicadas, frases que carecen de signos de puntuación...) complicarán el resto de actividades del proyecto
• 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: lo que garantiza requisitos claros
• Inclusión de términos relativos al diseño: p.e. base de datos, objeto, campo… que no deberían aparecer en especificaciones de alto nivel
• Inclusión de términos propios de un pseudo-código: términos como SI, SINO, FIN-SI, MIENTRAS... pueden implicar que el cuerpo del requisito incluye un pseudo-código
• Uso de frases especulativas: p.e. usualmente, generalmente, típicamente…
• Localización de conceptos condicionales: p.e. quizá, probablemente…, lo que permite también la reducción de especulaciones
• Abuso de negaciones: Demasiadas negaciones en un requisito (como en cualquier otra frase) puede implicar dificultados a la hora de leer y entender el requisito
• Abuso de conectores: del mismo modo, demasiados conectores en un mismo requisito puede implicar bien la mezcla de dos o más necesidades en el mismo requisito, o bien un exceso de detalle en el mismo
• Empleo de estructuras de frase subjetivas: frases del estilo "en mi opinión", "pienso que" no deben ser aceptadas en ningún requisito
• Abuso de pronombres: está demostrado que el abuso de pronombres en un requisito puede implicar que, algún stakeholder pueda malinterpretar alguno de dichos pronombres, dándole un significado contrario al requisito
• Número de dependencias: entre cada requisito y otros activos del proyecto, lo que permitirá comprobar si cada requisito de usuario tiene asociado un requisito de sistema, pruebas…
• Volatilidad: Número de versiones generadas tras la aceptación de un requisito

Junto con todas estas métricas que permiten analizar la calidad de requisitos de forma individual (aunque existan vistas e informes de conjunto), aparecen en la última versión del producto otros Indicadores Semánticos que permiten analizar una especificación en su conjunto. 
Ejemplo de estas métricas pueden ser las siguientes:

• Análisis semántico de solapamiento: que permite medir cuándo dos o más requisitos de una proyecto puedan solaparse, teniendo en cuenta que este solapamiento es la principal fuente de inconsistencias
• Empleo de unidades de medida inconsistentes: lo que permite la rápida detección de requisitos que, por ejemplo, mezclen kilómetros y millas en una misma especificación, hecho que puede ser frecuente en equipos procedentes de múltiples localizaciones y costumbres

IRQA Quality Analyzer permite a cada organización configurar cuáles son las métricas que quiere aplicar, qué peso darle a cada una, y cuáles son los rangos aceptables. Asimismo, cada diferente tipo de requisito puede, opcionalmente, ser medido mediante una configuración diferente de indicadores y rangos. Esto permite dotar a la herramienta de la flexibilidad necesaria para encajar en cualquier organización y proceso.

A través de estas métricas puede identificarse, de forma clara, qué requisitos no tienen la calidad esperada y han de ser redefinidos.

Consiga mediante IRQA Quality Analyzer especificaciones de requisitos bajo la premisa Right the first Time, garantizando con eso la calidad a través de todo el proyecto y evitando en gran medida los costes de retrabajo que consumen tanto tiempo y recursos en nuestros proyectos actuales.

Tomar métricas de su software es la única forma de mejorarlo y, si puede recibir métricas de todos sus activos y de forma temprana, el éxito está asegurado.

IRQA Quality Analyzer ya está operativo en los lenguajes Castellano e Inglés.