IA

Un requisito es verificable si dos personas que lo leen por separado coinciden, sin discutir, en si el sistema lo cumple. Escribirlo así obliga a elegir una medida, y ahí está el valor.

Una spec de funcionalidad tiene seis partes fijas. La que más se omite, lo que queda fuera de alcance, y la que más incomoda, las preguntas abiertas, son las que evitan que un agente decida en silencio.

Escribir una especificación antes de tocar código suena a la fase de requisitos de cascada. La diferencia real no es si hay documento, es cuánto tarda esa decisión en confrontarse con código que corre de verdad.

El término es nuevo desde 2025, pero la idea no: contratos de Hoare en 1969, diseño por contrato de Meyer en 1986, y una tesis académica de 2004 que ya proponía tests y contratos como especificaciones de distinta granularidad.

Toda funcionalidad tiene tres capas, para qué, qué y cómo, y confundirlas es el error más común al empezar a escribir especificaciones.

El cuello de botella ya no es escribir código: es decidir qué significa que esté correcto y poder comprobarlo. Así arranca la serie de Spec Driven Development.