Requisitos que se contradicen y cómo se resuelve el choque

Dos requisitos se contradicen cuando cumplir uno impide cumplir el otro. El primer trabajo del arquitecto es buscar un diseño que cumpla los dos: muchas contradicciones son aparentes y desaparecen con otra forma de construir la solución (registrar con un identificador seudónimo, separar quién ve qué, pedir el segundo factor solo en el momento crítico).

Cuando el choque es real, no lo resuelve quien diseña ni quien grita más fuerte. Se aplica un orden de precedencia aprobado de antemano, decide alguien que no es parte interesada, y el requisito que pierde queda registrado como riesgo aceptado, con firma. Así la decisión se puede revisar después y no depende de la memoria de nadie.

Lee conflictos/requisitos-por-area.txt buscando pares que no pueden cumplirse a la vez, y después mira cuáles ya están en conflictos/registro-de-conflictos.txt. Uno de los requisitos de protección de datos choca con otro de un área de control, y el choque no aparece en el registro.

La política de conflictos/politica-de-resolucion.txt dice quién decide y quién no puede firmar. La regla existe por la misma razón que la separación de funciones: si una de las áreas en conflicto firma la decisión, el conflicto se resuelve siempre a su favor.

Compara la columna de firma del registro con el punto 3 de la política y con el área de cada requisito en choque.

En ese conflicto no hay un diseño que cumpla los dos requisitos: o el desembolso espera la evaluación de fraude o no la espera. Por eso se aplica el orden de precedencia de la política. Ubica cada requisito en uno de los cuatro niveles y decide cuál prevalece.

El choque de la tarea 2 sí tiene salida de diseño. Control interno necesita poder reconstruir cada solicitud durante cinco años; protección de datos necesita que los registros técnicos, que leen muchos equipos, no lleven documento ni ingresos en claro. La clave es que no hace falta que los dos datos vivan en el mismo sitio.