34. Revisión, inspección y aprobación de requerimientos
La revisión, la inspección y la aprobación de requerimientos son actividades que ayudan a detectar problemas antes de que el equipo avance hacia diseño, desarrollo o pruebas. Su objetivo es asegurar que los requerimientos sean comprensibles, correctos, completos y aceptados.
Estas actividades no deben verse como trámites burocráticos. Bien aplicadas, reducen errores costosos, mejoran la comunicación y dejan evidencia de los acuerdos alcanzados.
34.1 Introducción
En el tema anterior estudiamos la validación con usuarios e interesados. Ahora profundizaremos en mecanismos más estructurados para revisar, inspeccionar y aprobar requerimientos.
La diferencia principal está en el grado de formalidad. Una revisión puede ser liviana y colaborativa, mientras que una inspección suele seguir un proceso más definido con roles, criterios y registro de defectos.
34.2 Qué es una revisión de requerimientos
Una revisión es una evaluación del contenido de los requerimientos realizada por una o más personas. Puede enfocarse en claridad, consistencia, completitud, factibilidad, trazabilidad, prioridad o alineación con los objetivos del negocio.
Las revisiones pueden ser informales, semiformales o formales, según el riesgo del proyecto y la necesidad de evidencia.
34.3 Qué es una inspección de requerimientos
Una inspección es una revisión formal y sistemática. Normalmente sigue pasos definidos, asigna roles, utiliza listas de verificación y registra defectos encontrados.
Su propósito principal es encontrar problemas en el documento o en el contenido de los requerimientos, no resolverlos durante la misma reunión.
34.4 Qué es la aprobación de requerimientos
La aprobación es la aceptación explícita de una versión de los requerimientos por parte de las personas con autoridad para hacerlo. Indica que esa versión puede usarse como base para el trabajo posterior.
Aprobar no significa que nunca habrá cambios. Significa que los cambios posteriores deberán gestionarse de manera controlada.
34.5 Objetivos de la revisión
Una revisión busca detectar requerimientos ambiguos, incompletos, contradictorios, duplicados, no verificables, innecesarios o poco factibles. También permite confirmar que cada requerimiento tenga prioridad, origen y criterios de aceptación.
Además, ayuda a que distintos participantes compartan la misma interpretación antes de invertir esfuerzo en construir la solución.
34.6 Participantes principales
Los participantes pueden incluir analistas, usuarios clave, responsables del negocio, desarrolladores, testers, arquitectos, seguridad, soporte y líderes de proyecto.
La selección depende del contenido revisado. Un requerimiento de seguridad debe involucrar perfiles distintos de un requerimiento sobre una pantalla administrativa o un reporte comercial.
34.7 Roles en una inspección
En una inspección formal pueden existir roles como moderador, autor, lector, revisor y registrador. El moderador conduce el proceso, el autor aclara el contenido, los revisores detectan defectos y el registrador documenta hallazgos.
No siempre es necesario usar todos estos roles, pero conocerlos ayuda a organizar revisiones más rigurosas cuando el proyecto lo requiere.
34.8 Preparación del material
Antes de revisar, el material debe estar en una versión identificable, con requerimientos numerados, secciones completas, cambios visibles y dudas marcadas.
También conviene definir qué se revisará y qué queda fuera de la sesión. Revisar un alcance demasiado amplio reduce la profundidad del análisis.
34.9 Listas de verificación
Las listas de verificación ayudan a revisar de manera consistente. Pueden incluir preguntas sobre claridad, ambigüedad, completitud, consistencia, verificabilidad, factibilidad, necesidad, prioridad y trazabilidad.
Una buena lista no reemplaza el criterio profesional, pero evita olvidar aspectos importantes.
34.10 Revisión de claridad
Revisar claridad significa comprobar que el requerimiento se entiende sin explicaciones adicionales. Debe identificarse el actor, la acción, el objeto, las condiciones y el resultado esperado.
Si el equipo necesita interpretar demasiado o hacer suposiciones, el requerimiento debe corregirse antes de aprobarse.
34.11 Revisión de consistencia
La consistencia se revisa comparando requerimientos entre sí y con reglas de negocio, restricciones, decisiones previas y documentos relacionados.
Las contradicciones deben resolverse con los interesados correspondientes y quedar registradas como decisiones explícitas.
34.12 Revisión de completitud
Un requerimiento completo contiene la información necesaria para avanzar. La revisión debe detectar datos faltantes, excepciones no contempladas, reglas incompletas, condiciones omitidas o resultados no definidos.
La completitud no significa escribir todo en exceso, sino incluir lo necesario para reducir incertidumbre.
34.13 Revisión de verificabilidad
Cada requerimiento debe poder comprobarse. Durante la revisión se debe preguntar qué prueba, medición, inspección o demostración permitiría confirmar su cumplimiento.
Si no se puede definir un criterio objetivo, el requerimiento necesita una redacción más precisa.
34.14 Revisión de factibilidad
La factibilidad evalúa si el requerimiento puede implementarse con las restricciones actuales de tecnología, presupuesto, tiempo, conocimientos, infraestructura y normas aplicables.
Un requerimiento puede ser valioso, pero si no es factible en el contexto del proyecto debe renegociarse, dividirse o planificarse de otra manera.
34.15 Clasificación de defectos
Los problemas encontrados pueden clasificarse como ambigüedad, omisión, contradicción, duplicación, error de negocio, falta de prioridad, falta de criterio de aceptación, falta de trazabilidad o requerimiento no factible.
Clasificar defectos ayuda a analizarlos, priorizarlos y mejorar el proceso de especificación.
34.16 Registro de hallazgos
Todo hallazgo relevante debe registrarse con un identificador, descripción, requerimiento afectado, responsable, severidad, estado y fecha de resolución esperada.
El registro permite dar seguimiento y evita que observaciones importantes se pierdan después de la reunión.
34.17 Corrección y seguimiento
Después de la revisión, el autor o responsable debe corregir los requerimientos afectados. Luego se verifica si las correcciones resuelven los hallazgos sin introducir nuevos problemas.
En proyectos críticos, puede ser necesaria una nueva revisión antes de aprobar la versión corregida.
34.18 Criterios de aprobación
Antes de aprobar, conviene definir criterios mínimos. Por ejemplo: no debe haber defectos críticos abiertos, los requerimientos deben tener prioridad, los criterios de aceptación principales deben estar definidos y los interesados clave deben haber validado el contenido.
Los criterios de aprobación evitan que cada persona tenga una expectativa diferente sobre cuándo un documento está listo.
34.19 Aprobación formal
La aprobación formal puede quedar documentada mediante acta, firma, correo, herramienta de gestión, versión aprobada o flujo de autorización. Lo importante es que exista evidencia de quién aprobó, qué aprobó y cuándo lo hizo.
También debe quedar claro qué alcance tiene la aprobación y qué elementos quedan pendientes.
34.20 Línea base de requerimientos
Una línea base es una versión aprobada de los requerimientos que se usa como referencia para diseño, desarrollo, pruebas y control de cambios.
A partir de una línea base, cualquier modificación relevante debe evaluarse por su impacto en alcance, costo, tiempo, calidad y riesgos.
34.21 Relación con el control de cambios
La aprobación de requerimientos se conecta directamente con el control de cambios. Cuando un requerimiento aprobado cambia, debe registrarse el motivo, la decisión, el impacto y la nueva versión afectada.
Esto protege al proyecto de cambios informales que alteran el alcance sin análisis suficiente.
34.22 Errores frecuentes
Algunos errores comunes son aprobar requerimientos incompletos, revisar documentos demasiado extensos sin preparación, no convocar a los interesados adecuados, no registrar hallazgos y confundir comentarios informales con aprobación.
También es un error centrar la revisión solo en estilo y formato, dejando de lado reglas de negocio, excepciones, criterios de aceptación y factibilidad.
34.23 Buenas prácticas
Conviene revisar en bloques pequeños, usar listas de verificación, separar detección de defectos y solución, registrar acuerdos, asignar responsables y confirmar que las correcciones fueron aplicadas.
También es recomendable involucrar a testers y desarrolladores, ya que pueden detectar problemas de verificabilidad, factibilidad y casos límite.
34.24 Qué debes recordar
Revisar requerimientos permite detectar problemas; inspeccionarlos aporta un proceso más formal; aprobarlos establece una versión acordada para avanzar.
La aprobación debe basarse en criterios claros y evidencia registrada, no solo en una conversación informal.
34.25 Conclusión
La revisión, inspección y aprobación de requerimientos aumentan la calidad del trabajo antes de que los errores se propaguen al diseño, al código o a las pruebas. Son prácticas esenciales para proyectos donde el entendimiento compartido y el control del alcance son importantes.
En el siguiente tema veremos cómo los requerimientos se relacionan con el diseño, el desarrollo y las pruebas dentro del ciclo de construcción del software.