Mantén la trazabilidad de los requisitos mientras cambia el software

Describe un comportamiento que se pueda verificar

«Crea una exportación moderna de clientes» deja abiertas decisiones importantes. No define usuarios, registros, campos ni comportamiento ante fallos. El agente debe preguntar o asumir. Los supuestos no registrados son difíciles de revisar después.

Usa un requisito ficticio con un límite claro: un responsable autenticado puede exportar clientes activos de su propia organización. La exportación contiene el identificador del cliente y su nombre visible. Excluye los datos de contacto y los registros archivados. Un usuario sin el rol de responsable no recibe ninguna exportación.

Todavía hay que decidir formato, volumen, tiempo de respuesta y gestión de fallos. Marca explícitamente lo que se desconoce. Una especificación útil expone la incertidumbre en vez de ocultarla en una redacción segura de sí misma.

Separa los requisitos de las decisiones de implementación

El usuario necesita un conjunto permitido de registros en un formato útil. La consulta a la base de datos, la biblioteca y la estructura del endpoint son decisiones de implementación. Relaciónalas con el requisito sin tratar cada decisión actual como una necesidad permanente del negocio.

Registra las decisiones importantes con su contexto, alternativas y motivo. Por ejemplo, una exportación síncrona puede servir para volúmenes pequeños. Un volumen mayor puede exigir un proceso en segundo plano y una comprobación independiente de autorización de descarga.

Mantén estable el requisito cuando sea posible y versiona la decisión modificada. Así, quien revise podrá distinguir una implementación diferente de una promesa diferente al usuario.

Crea una cadena breve de pruebas

Usa identificadores que se entiendan durante las revisiones. En este ejemplo, EXPORT-01 puede identificar el límite de organización. El nombre es ilustrativo, no un sistema obligatorio de numeración.

La cadena debe apuntar a pruebas reales. Que el nombre de una prueba contenga el identificador del requisito no demuestra que su aserción lo compruebe. Inspecciona la prueba y el recorrido de producción que ejercita.

El SSDF de NIST aporta contexto para los requisitos y la verificación dentro del desarrollo seguro. Usa la trazabilidad para hacer inspeccionables esas actividades, en vez de producir documentación por producirla. Lee el marco.

Revisa el impacto de un supuesto modificado

Supongamos que el negocio ahora necesita clientes archivados. El cambio afecta a más que una opción de consulta. Comprueba las reglas de conservación, la autorización, el volumen esperado, las explicaciones al usuario y el significado de los informes existentes.

Marca para revisión los documentos y las comprobaciones afectados. Conserva la decisión anterior para que un operador pueda explicar una publicación antigua. No reescribas la historia en silencio para presentar el diseño actual como inevitable.

Un agente puede ayudar a encontrar referencias y proponer actualizaciones. Las personas responsables deben resolver los requisitos contradictorios y aceptar el comportamiento modificado. Una lista de archivos coincidentes es un punto de partida, no una evaluación completa del impacto.

Mantén un registro lo bastante pequeño para usarlo

Registra las decisiones que afecten a la implementación, la verificación y la operación. Evita repetir el mismo requisito en muchos documentos desconectados. Prefiere enlaces a una única fuente mantenida.

Antes de aceptar un cambio, pregunta si quien lo revisa puede seguir su propósito hasta las pruebas reales. Antes de operarlo, pregunta si el responsable del servicio puede localizar el límite pertinente y la decisión de recuperación. Estas son comprobaciones prácticas de una trazabilidad útil.