35. Verificación de requerimientos mediante criterios y pruebas

Verificar requerimientos significa comprobar que están escritos de forma suficientemente clara, completa, consistente y comprobable. Una manera práctica de hacerlo es relacionarlos con criterios de aceptación, casos de prueba y evidencias que permitan confirmar su cumplimiento.

La verificación ayuda a descubrir requerimientos ambiguos antes de que lleguen al diseño o al desarrollo. Si no puede imaginarse una prueba razonable para un requerimiento, probablemente todavía no está listo.

35.1 Introducción

En el tema anterior vimos la revisión, inspección y aprobación de requerimientos. En este tema estudiaremos cómo comprobar la verificabilidad de cada requerimiento mediante criterios, pruebas y ejemplos concretos.

El objetivo no es reemplazar las pruebas del sistema, sino preparar requerimientos que puedan probarse sin depender de interpretaciones personales.

35.2 Qué es verificar requerimientos

Verificar requerimientos es evaluar si cumplen condiciones de calidad interna: claridad, precisión, consistencia, completitud, trazabilidad y posibilidad de comprobación.

La pregunta central es: ¿este requerimiento está formulado de manera que el equipo pueda demostrar objetivamente si fue satisfecho?

35.3 Diferencia entre verificación y validación

La validación pregunta si el requerimiento representa una necesidad real del negocio o del usuario. La verificación pregunta si el requerimiento está bien especificado y puede ser evaluado.

Un requerimiento puede ser válido para el negocio, pero estar mal escrito. También puede estar perfectamente redactado, pero no resolver una necesidad importante.

35.4 Relación con las pruebas

Las pruebas permiten confirmar si una implementación cumple los requerimientos. Por eso, durante la especificación conviene pensar tempranamente cómo se probará cada comportamiento, regla o restricción.

Cuando el equipo de pruebas participa desde el análisis, suele detectar ambigüedades, excepciones faltantes y condiciones de borde que no aparecieron en la primera redacción.

35.5 Criterios de aceptación

Los criterios de aceptación describen condiciones concretas que deben cumplirse para considerar satisfecho un requerimiento. Deben ser observables, verificables y entendibles por el equipo y los interesados.

Un criterio de aceptación convierte una expectativa general en una regla evaluable. Esto reduce discusiones posteriores sobre qué significa que una funcionalidad esté terminada.

35.6 Criterios claros y medibles

Un criterio claro evita palabras vagas como rápido, simple, seguro, flexible o amigable, salvo que se acompañen con una definición concreta.

Por ejemplo, en lugar de indicar que una búsqueda debe ser rápida, puede establecerse que el sistema debe mostrar resultados en menos de dos segundos para el volumen esperado de datos.

35.7 Casos de prueba derivados de requerimientos

Un caso de prueba describe condiciones iniciales, datos de entrada, pasos, resultado esperado y criterio de aprobación. Debe poder relacionarse con uno o varios requerimientos.

Si al intentar escribir un caso de prueba aparecen dudas importantes, esa es una señal de que el requerimiento necesita más análisis o una redacción más precisa.

35.8 Pruebas positivas y negativas

Las pruebas positivas verifican que el sistema funciona cuando se cumplen las condiciones esperadas. Las pruebas negativas verifican qué ocurre ante datos inválidos, permisos insuficientes, errores externos o estados no permitidos.

Un requerimiento completo debe permitir razonar sobre ambos tipos de situaciones, especialmente cuando hay validaciones, reglas de negocio o flujos críticos.

35.9 Pruebas de reglas de negocio

Las reglas de negocio suelen requerir pruebas con ejemplos concretos. Conviene incluir valores normales, valores límite, excepciones y combinaciones relevantes.

Si una regla no puede probarse con datos específicos, probablemente falta definir condiciones, prioridades entre reglas o resultados esperados.

35.10 Pruebas de requerimientos no funcionales

Los requerimientos no funcionales también deben verificarse. Rendimiento, disponibilidad, seguridad, usabilidad, compatibilidad y mantenibilidad necesitan criterios observables o mediciones acordadas.

Un requerimiento no funcional como "el sistema debe ser seguro" no es suficiente. Debe traducirse en controles, restricciones, pruebas o métricas verificables.

35.11 Pruebas de datos

Muchos requerimientos dependen de datos obligatorios, formatos, rangos, catálogos, relaciones, estados o reglas de integridad. La verificación debe comprobar que esos datos estén definidos.

También es importante revisar qué sucede cuando faltan datos, cuando hay duplicados, cuando una referencia no existe o cuando un dato cambia de estado.

35.12 Pruebas de interfaces

Cuando el sistema se comunica con otros sistemas, la verificación debe considerar mensajes, formatos, protocolos, códigos de error, tiempos de espera y responsabilidades ante fallas.

Un requerimiento de integración incompleto puede generar problemas difíciles de resolver durante la construcción o las pruebas finales.

35.13 Condiciones de borde

Las condiciones de borde son situaciones cercanas a límites mínimos, máximos o cambios de estado. Ayudan a descubrir requerimientos incompletos o reglas mal definidas.

Por ejemplo, si un descuento aplica desde diez unidades, conviene probar nueve, diez y once unidades para confirmar la interpretación exacta de la regla.

35.14 Matriz entre requerimientos y pruebas

Una matriz simple puede relacionar cada requerimiento con sus criterios de aceptación y casos de prueba. Esta relación ayuda a identificar requerimientos sin cobertura o pruebas sin justificación.

La matriz no debe convertirse en un documento pesado. Su utilidad está en mostrar de forma clara qué evidencia verificará cada parte del alcance.

35.15 Cobertura de pruebas

La cobertura indica qué parte de los requerimientos está contemplada por criterios, casos de prueba o evidencias de verificación. Una baja cobertura revela zonas de incertidumbre.

No todos los requerimientos requieren la misma cantidad de pruebas. Los más críticos, riesgosos o complejos necesitan mayor profundidad.

35.16 Verificación temprana

La verificación debe comenzar antes de programar. Revisar criterios y pruebas durante el análisis permite corregir ambigüedades con menor costo.

Si el equipo espera hasta el final para descubrir que un requerimiento no se puede probar, el retrabajo puede afectar diseño, desarrollo, datos, documentación y planificación.

35.17 Participación del equipo de pruebas

Los testers aportan una mirada orientada a evidencias, excepciones y escenarios concretos. Su participación temprana mejora la calidad de los requerimientos.

También ayudan a convertir necesidades generales en criterios evaluables y a detectar supuestos que los usuarios o analistas pueden pasar por alto.

35.18 Evidencia de verificación

La evidencia puede incluir resultados de pruebas, capturas, reportes, registros, mediciones, revisiones firmadas, demostraciones o comprobaciones automáticas.

Para requerimientos importantes, conviene acordar de antemano qué evidencia será suficiente para aceptar que el requerimiento fue cumplido.

35.19 Automatización de pruebas

Algunos requerimientos pueden verificarse mediante pruebas automatizadas. Esto es especialmente útil para reglas repetitivas, validaciones, cálculos, servicios, integraciones y regresiones.

La automatización no elimina la necesidad de buenos requerimientos. Al contrario, requiere criterios precisos para poder codificar comprobaciones confiables.

35.20 Defectos detectados durante la verificación

Durante la verificación pueden encontrarse ambigüedades, omisiones, contradicciones, criterios imposibles de medir, reglas incompletas, prioridades dudosas o dependencias no identificadas.

Estos defectos deben registrarse, corregirse y volver a revisarse antes de aprobar el requerimiento o usarlo como base de trabajo.

35.21 Errores frecuentes

Algunos errores comunes son escribir criterios demasiado generales, probar solo el flujo exitoso, ignorar requerimientos no funcionales, no relacionar pruebas con requerimientos y dejar casos límite para el final.

También es frecuente confundir una demostración superficial con una verificación suficiente de reglas, permisos, datos y escenarios alternativos.

35.22 Buenas prácticas

Conviene definir criterios de aceptación desde el análisis, usar ejemplos concretos, revisar condiciones de borde, involucrar a testers, mantener trazabilidad y registrar evidencia.

También es recomendable revisar periódicamente si los cambios en requerimientos obligan a modificar pruebas existentes o agregar nuevas verificaciones.

35.23 Qué debes recordar

Un requerimiento verificable permite demostrar objetivamente si fue cumplido. Para lograrlo necesita criterios claros, datos definidos, resultados esperados y relación con pruebas o evidencias.

Pensar en pruebas desde el inicio mejora la calidad de la especificación y reduce discusiones durante la aceptación del producto.

35.24 Conclusión

La verificación mediante criterios y pruebas conecta los requerimientos con evidencias concretas. Ayuda a transformar necesidades y reglas en condiciones comprobables, lo que mejora la comunicación entre negocio, análisis, desarrollo y pruebas.

En el siguiente tema veremos la trazabilidad de requerimientos, una práctica clave para relacionar necesidades, decisiones, especificaciones, diseño, código y pruebas.