Requisitos de seguridad que se pueden verificar

El arquitecto traduce las amenazas en requisitos, y un requisito sirve cuando tres cosas son ciertas: describe un comportamiento observable, una prueba puede comprobarlo con un resultado de sí o no, y está ligado a la amenaza que cierra. «La API debe ser segura» no pasa ninguna de las tres: nadie sabría decir cuándo se cumple.

Catálogos como el ASVS de OWASP o las prácticas del Marco de Desarrollo de Software Seguro del NIST (SP 800-218, versión 1.1 de febrero de 2022) ofrecen requisitos ya redactados para no partir de cero. El trabajo del arquitecto es elegir los que corresponden al riesgo del producto, redactarlos con valores concretos y asegurarse de que llegan al backlog.

En requisitos/requisitos.txt están los ocho requisitos del producto, cada uno con la amenaza que cierra. Léelos como lo haría quien tiene que escribir la prueba: unos dicen qué debe devolver o qué valor máximo no se supera y otros solo expresan una intención.

Un requisito que no está en el backlog no se construye. La forma de comprobarlo es cruzar dos tablas: cada requisito debería aparecer en la columna «cubre» de alguna historia del sprint. Las historias están en requisitos/backlog-sprint.txt.

Tener una historia tampoco basta: lo que demuestra que el requisito se cumple es una verificación que corra cada vez que cambia el código, o una revisión con fecha y responsable. La matriz de requisitos/verificacion.txt dice cómo se comprueba cada uno y cuándo. Una fila con «ninguna» es una promesa sin evidencia.

Cuando un requisito es vago, el arquitecto no lo borra: lo reescribe con el valor concreto que el equipo y el negocio aceptan. Un límite de uso por cliente, con una cifra y un código de respuesta, se puede comprobar con una prueba automática. Una frase como «razonable» o «se vigila» no.

Compara las tres reescrituras del requisito que identificaste en la tarea 2.