¿Cuáles son las métricas para un buen SRS (Especificación de requisitos de software)?

Algunas de las métricas para un buen SRS no son diferentes de las métricas que definen cualquier buena especificación. Por ejemplo:

• vencimiento : medido por el número de TBX, abreviatura de por determinar (TBD), por revisar (TBD), por suministrar (TBS), etc.
• información de verificación : en una buena especificación, cada requisito tendrá un método de verificación asociado (es decir, prueba, inspección, demostración o análisis) y una metodología (es decir, qué acción se tomará para verificar el requisito). La metodología de verificación no tiene que ser larga, pero es importante. Por ejemplo, si el requisito es un sistema con algún porcentaje de tiempo de actividad, ¿cómo se medirá eso? ¿Por cuanto tiempo? ¿Qué cuenta como abajo?
• línea base : una especificación que no está bajo control de revisión no es muy útil

Weinberg y Gause propusieron una " Métrica de ambigüedad " en su libro "Explorando los requisitos. Calidad antes que el diseño" (Dorset House 1989). La idea es que le pida a "individuos calificados" que calculen el costo o el esfuerzo para diseñar y construir una solución que cumpla con los requisitos. Cuando el rango de estimaciones es grande, sabe que todavía tiene trabajo por hacer.

No sé si alguien usó esto alguna vez, pero no creo que sea muy práctico.

Lo que puede hacer es cuantificar su proceso de prueba o revisión de requisitos, lo que debe hacer de todos modos. Por ejemplo, 17 de 20 requisitos pasaron las pruebas. Puede calcular un número general o más detallado según las pruebas individuales (por ejemplo, 15/20 están incompletos; 3 aún no hemos descubierto cómo probar ...).

Las pruebas de requisitos individuales pueden ser cualquiera o todos los criterios para 'buenos requisitos' que la mayoría de los libros de texto sobre ingeniería de requisitos ofrecerán, p.

• Integridad de la plantilla de requisitos
• Trazabilidad
• Terminología consistente
• ¿Es relevante para los objetivos de negocio?
• ¿Es comprobable?
• El número de madurez propuesto por Adam también es bueno.
• Etc.

IEEE 830 requiere que un SRS sea correcto, sin ambigüedades, completo, consistente, clasificado por importancia, verificable, modificable y rastreable.

Cada una de estas cualidades podría (y debería) verificarse en sus propias formas específicas. Cómo exactamente: depende del formato del documento SRS que esté utilizando.