¿Qué es una auditoría de requisitos? Cobertura, desviación y un ejemplo práctico

Por qué "¿qué acordamos construir?" es una pregunta difícil

Cualquier equipo puede decir cuántas tareas hay abiertas. Muy pocos pueden decir, requisito por requisito, si las tareas abiertas suman lo prometido. Los dos datos viven en sitios distintos. Los requisitos están en un PRD, una propuesta, un contrato o una página de Notion escrita hace meses. El trabajo está en un gestor de tareas, troceado en issues que nombró quien los cogió. Nadie enlaza ambas cosas, y el hueco entre ellas es invisible hasta que un cliente, un lanzamiento o una nueva incorporación lo encuentra.

El hueco crece de tres formas:

• Omisión. Un requisito se acordó y nunca se convirtió en trabajo. No está en el backlog, así que ningún tablero lo muestra como retrasado.
• Reescritura silenciosa. Un requisito se editó después de la aprobación, normalmente para ajustarlo a lo que era más fácil construir. El documento vivo ahora dice que la entrega "cumple", y la redacción original desapareció.
• Eliminación silenciosa. Un requisito se borró. El documento es más corto y nadie decidió que debiera serlo.

Una auditoría de requisitos hace visibles las tres. La entrada del glosario da la definición formal; otros nombres que se usan son auditoría de trazabilidad de requisitos y cobertura de requisitos.

Las tres partes: línea base, cobertura y desviación

Línea base. Una línea base de requisitos es una copia congelada y numerada de los requisitos en el momento en que se aprobaron: identificador, redacción, prioridad y criterios de aceptación de cada uno. El documento vivo sigue cambiando; la línea base no. La entrada sobre línea base trata la práctica con más detalle. Sin línea base no hay nada contra lo que auditar, porque la única versión de los requisitos es la que ya se ha desviado.

Cobertura. Para cada requisito de la línea base, ¿cuál es el estado del trabajo que lo respalda? Una auditoría útil distingue al menos estos estados:

Un requisito cuyas únicas tareas se cancelaron todas no tiene trabajo, aunque se hicieran tres intentos, y una auditoría honesta dice ambas cosas.

Desviación. La desviación compara la redacción de la línea base con la de hoy. Si el texto de un requisito cambió después de la congelación, la auditoría lo marca y muestra ambas versiones. Informar la cobertura contra la nueva redacción mientras se afirma evaluar la línea base sería engañoso, así que una buena auditoría siempre mide contra el texto congelado y muestra el texto vivo al lado.

Un ejemplo práctico: el PRD decía una cosa y la entrega hizo otra

Un caso pequeño y realista. Un equipo de cuatro personas acuerda un PRD para un portal de clientes con catorce requisitos y lo congela como línea base 1 el 2 de septiembre. El lanzamiento es el 30 de octubre. Dos semanas antes, alguien ejecuta la auditoría.

Once requisitos están en curso o terminados. Tres no:

• REQ-006, "Los clientes pueden exportar sus facturas en CSV y PDF." Cobertura: trabajo terminado. Desviación: marcada. La redacción viva ahora dice "Los clientes pueden exportar sus facturas en CSV". La mitad del PDF se descartó cuando el desarrollador encontró incómoda la librería de PDF, y el requisito se editó para que coincidiera. Nadie avisó al cliente que pidió PDF.
• REQ-009, "Los administradores reciben un email cuando un cliente disputa una factura." Cobertura: sin trabajo. Se acordó, nadie creó un issue y el backlog no tiene ninguna fila para ello. Todos los tableros estaban en verde porque el tablero solo conoce los issues que existen.
• REQ-013, "El portal soporta dos idiomas en el lanzamiento." Cobertura: eliminado después. Se quitó del PRD vivo en la tercera semana durante una conversación de alcance que ocurrió en el chat. Puede que la decisión fuera correcta; su registro es un mensaje que nadie encuentra.

Nada de esto aparecería en una revisión de sprint. REQ-006 se demostró y parecía terminado. REQ-009 nunca existió como tarea. REQ-013 había dejado de ser un requisito sin que nadie lo notara. La auditoría convirtió tres huecos invisibles en tres decisiones: crear el trabajo de REQ-009, restaurar o renegociar formalmente REQ-006, y dejar por escrito la decisión sobre REQ-013 para que la línea base 2 la recoja.

Por esto la auditoría debe calcularse a partir de registros, no de la lectura que un modelo haga del proyecto. Un modelo de lenguaje al que se pregunta "¿está cubierto REQ-009?" buscará algo que se parezca a notificaciones por email y puede encontrar un issue relacionado con recibos. La cobertura calculada a partir de enlaces explícitos entre requisitos e issues da un simple "sin trabajo", que es la respuesta que el equipo necesitaba.

Auditoría de requisitos frente a escaneo de código y revisión de código

La gente oye "auditoría" y piensa en un escáner leyendo código fuente. Es una actividad distinta con una pregunta distinta.

Las tres no se sustituyen entre sí. Una base de código puede pasar todos los escaneos y aun así carecer de la función que un cliente pagó. Una auditoría de requisitos puede mostrar todos los requisitos cubiertos y aun así publicar un agujero de seguridad. Los equipos a los que les importan ambas cosas hacen ambas.

Dos cautelas mantienen honesta una auditoría de requisitos. Primero, "trabajo terminado" no es "requisito cumplido". Un issue completado demuestra que alguien terminó una tarea, no que el resultado satisface los criterios de aceptación; una persona tiene que comprobarlo. Segundo, la auditoría vale lo que valen los enlaces. Si los issues no están ligados a requisitos, todos los requisitos dicen "sin trabajo", lo que no sirve. Enlazar es el coste inicial, y es el mismo coste que hace posible la auditoría.

Cómo hacer una auditoría de requisitos a mano

No necesitas una herramienta. Necesitas disciplina y una hoja de cálculo.

1. Congela la línea base. Copia los requisitos aprobados en una hoja con un ID estable por fila (REQ-001, REQ-002), la redacción exacta, la prioridad y los criterios de aceptación. Ponle fecha y anota quién la aprobó. No vuelvas a editar esta hoja.
2. Enlaza el trabajo a los requisitos. En tu gestor, da a cada issue un campo o etiqueta con el requisito al que sirve. El trabajo nuevo sin ID de requisito es un bug, una tarea de mantenimiento o alcance añadido; decide cuál.
3. Calcula la cobertura. Para cada fila REQ, lista sus issues y sus estados. Asigna un estado de la tabla anterior. Cuenta primero las filas sin trabajo; esa lista es el hallazgo principal de la auditoría.
4. Comprueba la desviación. Pon el documento vivo de requisitos junto a la hoja congelada. Marca cada fila cuya redacción difiera y cada fila que falte en la versión viva.
5. Escribe las decisiones. Para cada hueco: crear trabajo, renegociar o descartar formalmente. Registra los descartados con un motivo y congela la línea base 2.
6. Repite en los hitos. Antes de una revisión con cliente, un lanzamiento, una factura o un traspaso. Mensual basta para la mayoría de equipos pequeños.

La versión manual funciona. Su debilidad es el paso 2: los enlaces se degradan en cuanto la gente está ocupada, y una hoja que nadie actualiza produce una auditoría en la que nadie confía.

Cómo lo hacen las herramientas, y qué hace Atrix

Varias herramientas de gestión de requisitos orientadas a industrias reguladas llevan décadas haciendo trazabilidad, normalmente como una matriz de requisitos contra pruebas y tareas. Están hechas para equipos aeroespaciales, médicos y de automoción, y tienen precios acordes.

Para equipos de producto pequeños, la versión práctica es un gestor que guarda requisitos e issues en el mismo sitio y mantiene los enlaces por ti. Eso es lo que construimos en Atrix para nuestros propios proyectos, y conviene ser exactos sobre lo que hace. La ejecución Develop del agente escribe los requisitos a partir de un brief; tú los editas y apruebas, y el modo Audit congela una línea base. Desde entonces, la auditoría informa los cinco estados anteriores para cada requisito de la línea base, con una marca de desviación y la redacción viva cuando cambió. Cada estado se calcula a partir de filas, no del juicio de un modelo, así que la auditoría no gasta ejecuciones de IA y da la misma respuesta dos veces. Los proyectos de GitHub y Vercel enlazados añaden señales de repositorio y despliegue al lado.

Lo que no hace importa igual. Atrix no escanea código, no ejecuta análisis estático ni encuentra vulnerabilidades, y la página de la función lo dice. Si necesitas una auditoría de código, eso es otro servicio, y por nuestra parte lo hacen los auditores humanos de la agencia, no el producto. Si necesitas saber si la entrega coincide con el acuerdo, eso es el trabajo del producto.

Preguntas frecuentes

¿Qué diferencia hay entre una auditoría de requisitos y una auditoría de código?

Una auditoría de requisitos compara los requisitos acordados con el trabajo que existe e informa cobertura y desviación. Una auditoría de código examina el código fuente contra un estándar buscando errores, seguridad y calidad. La primera responde "¿construimos lo acordado?"; la segunda, "¿el código es sólido?". Ninguna sustituye a la otra.

¿Qué es la trazabilidad de requisitos?

La trazabilidad es el conjunto de enlaces desde cada requisito hasta el trabajo, las pruebas o el código que lo implementan, y de vuelta. Una auditoría de requisitos depende de ella: sin enlaces de los issues a los requisitos, la cobertura no se puede calcular.

¿Qué es la desviación de alcance?

La desviación de alcance, o de requisitos, es el cambio gradual de lo que un proyecto debe entregar sin una decisión explícita: requisitos reescritos para ajustarse a la entrega, descartados en silencio o añadidos sin aprobación. Una auditoría la detecta comparando una línea base congelada con los requisitos vivos.

¿Cada cuánto hay que auditar los requisitos?

En los hitos, más que en un calendario fijo: antes de una revisión con cliente, un lanzamiento, un traspaso o una factura importante. Los equipos que mantienen los enlaces al día pueden auditar bajo demanda en minutos; los que lo hacen a mano suelen llegar a una vez al mes.

¿Una tarea terminada significa que el requisito está cumplido?

No. Una tarea completada muestra que alguien terminó un trabajo, no que el resultado satisface los criterios de aceptación. Una buena auditoría etiqueta ese estado como "trabajo terminado" y deja la verificación contra los criterios a una persona.

¿Puede la IA hacer una auditoría de requisitos?

La IA puede escribir y refinar requisitos, y puede ayudar a enlazar el trabajo con ellos. La auditoría en sí debe calcularse a partir de registros, porque la opinión de un modelo sobre si algo está "cubierto" varía entre ejecuciones y no se puede defender ante un cliente. Atrix usa el agente para escribir los requisitos y datos planos para calcular la auditoría.

Siguiente paso

Empieza por la definición y los estados en la entrada del glosario sobre auditoría de requisitos, y luego congela tu primera línea base. Si quieres que los enlaces y la auditoría se mantengan por ti, la auditoría de requisitos de Atrix lo hace a partir de tus propios issues.