Spec Driven Development

Una spec puede respetar todas las reglas de forma y seguir diciendo dos cosas a la vez. La clarificación busca esas frases a propósito, con señales concretas, y le da a cada una un destino escrito antes de que alguien la implemente.

Un requisito dice qué debe cumplir el sistema en general. Un criterio de aceptación lo baja a un caso concreto, con datos reales y un resultado que se puede observar. Escribirlos deja a la vista qué requisitos todavía no se pueden comprobar.

EARS fija de antemano el orden de una frase de requisito: primero la situación o el disparador, después la respuesta. Cinco patrones alcanzan para casi todo, y cada uno se corresponde con un caso de prueba.

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.