Supuestos y restricciones que condicionan el diseño

Un supuesto es algo que el diseño da por cierto sin haberlo comprobado todavía: «el núcleo acepta certificados», «no llegan más de 3.000 solicitudes por hora». Cada supuesto necesita un dueño y una forma de validarse, porque hasta que se valida es un riesgo. Una restricción es un límite que el proyecto no puede cambiar: una fecha comprometida con la asamblea, un presupuesto, un contrato, una decisión del consejo o una ley. La restricción no se valida; se respeta, y el diseño se ajusta a ella.

Confundirlos sale caro en los dos sentidos. Un supuesto tratado como hecho nunca se comprueba. Una restricción anotada como supuesto parece negociable y alguien acaba diseñando contra ella.

La forma de validar un supuesto dice mucho de su solidez: un cruce con la base de asociados o un pico medido valen más que «lo dijo el proveedor en una reunión». Revisa registro/supuestos-y-restricciones.txt y contrasta cada supuesto con los documentos de evidencia/.

Hay una entrada del registro que no es algo por comprobar: ya la decidió alguien con autoridad para hacerlo, y obliga al proyecto desde el diseño. Está entre los supuestos, sin forma de validarse, porque nadie sabía que era una decisión ya tomada.

El supuesto desmentido de la tarea 2 no se borra ni se ignora: cambia el diseño. Hay que mirar también las restricciones del registro, porque deciden qué salidas existen: el proyecto tiene fecha comprometida y no puede tocar el núcleo financiero. La respuesta buena acepta lo que el contrato permite, protege la debilidad con controles del lado de la cooperativa y deja el riesgo escrito con dueño.

Un supuesto sin dueño es el más peligroso del registro: nadie lo va a validar y nadie se va a enterar cuando deje de ser cierto. Suele ser el que se escribió al final de una reunión, cuando todos asentían.