En el artículo anterior te prometí que iba a poner orden en tres cosas que veo mezclar todos los días: spec-driven development (SDD), BDD y la ingeniería de requisitos. Pues aquí estoy.
Hace un año escribí, medio en broma, que antes a la ingeniería de prompts la llamábamos análisis de requisitos. Desde entonces ha aparecido una etiqueta nueva, SDD, con sus herramientas, sus comandos y sus ficheros Markdown. Y cada vez que alguien me la explica, tengo la misma sensación: esto ya lo había visto.
Mi tesis es sencilla. El spec-driven development no inventa nada. Recupera la ingeniería de requisitos de toda la vida porque ahora la spec la lee alguien que no rellena los huecos con sentido común: un agente de IA. Y por el camino se deja una pieza importante, que es la que más me interesa a mí.
Vamos por partes.
Ingeniería de requisitos: lo de toda la vida
La ingeniería de requisitos es la disciplina de decidir y escribir qué tiene que hacer un sistema antes de construirlo. Tiene norma desde hace décadas: el IEEE 830 nació en 1984, se revisó en 1993 y 1998, y en 2011 dio paso a la ISO/IEC/IEEE 29148, revisada en 2018.
De ahí salen cosas que seguro que te suenan:
- Requisitos funcionales: lo que hace el sistema («el usuario puede recuperar su contraseña por email»).
- Requisitos no funcionales: cómo de bien lo hace («la página carga en menos de 2 segundos»).
- Características de un buen requisito: necesario, sin ambigüedad, completo, factible y, la que más me importa, verificable. Si no puedes comprobar que se cumple, no es un requisito, es un deseo.
En 2009, en Rolls-Royce, Alistair Mavin y su equipo publicaron EARS (Easy Approach to Requirements Syntax), unas pocas plantillas para escribir requisitos sin ambigüedad. La más conocida es «CUANDO ocurre algo, EL SISTEMA DEBERÁ hacer esto». Quédate con ella, que vuelve a salir.
El problema de la ingeniería de requisitos nunca fue la teoría. Fue que escribir requisitos bien es pesado, y como el que los leía era otro desarrollador, podías permitirte dejar huecos. Ya preguntaría en el café.
BDD y Specification by Example: ejemplos que se ejecutan
En 2006, Dan North publicó Introducing BDD. Venía de enseñar TDD y se dio cuenta de que los malentendidos casi siempre venían de la palabra «test». Propuso hablar de comportamiento y escribirlo con una plantilla muy simple: Given un contexto, When ocurre algo, Then espero este resultado.
De ahí sale Gherkin, el lenguaje de Cucumber, que describe esos escenarios como especificaciones ejecutables. Y en 2011 Gojko Adzic lo llevó más allá con Specification by Example: el equipo se pone de acuerdo con ejemplos concretos, y esos ejemplos se convierten en pruebas automáticas.
Aquí hay un salto importante. Con BDD la especificación deja de ser solo un documento: una parte se puede ejecutar y te dice si el sistema la cumple.
Spec-driven development: la misma spec, ahora la lee un agente
Y llegamos a 2025. El spec-driven development propone algo que, contado así, suena muy razonable: antes de pedirle código al agente, escribes una especificación, y el agente trabaja a partir de ella.
Ni siquiera el nombre es nuevo. En 2004, Ostroff, Makalsky y Paige ya hablaban de Agile Specification-Driven Development para mezclar TDD con diseño por contrato. Lo de ahora es otra cosa con un nombre muy parecido, pero dice mucho que se haya reciclado.
Las herramientas más conocidas son estas:
- Spec Kit, de GitHub. Un flujo por comandos: constitución del proyecto, especificar, planificar, dividir en tareas e implementar.
- Kiro. Cada spec tiene un
requirements.md, undesign.mdy untasks.md. Y los requisitos se escriben con EARS: «WHEN … THE SYSTEM SHALL …». Sí, la plantilla de Rolls-Royce de 2009. - OpenSpec, de Fission-AI. Cada cambio vive en su carpeta con una propuesta, las specs, el diseño y las tareas, y los requisitos se escriben con «SHALL» y escenarios WHEN/THEN.
Birgitta Böckeler, en un análisis muy recomendable en martinfowler.com, distingue tres niveles de SDD:
- Spec-first: escribes una spec pensada antes de la tarea y la usas para desarrollarla.
- Spec-anchored: la spec se conserva cuando terminas y sirve para seguir evolucionando esa funcionalidad.
- Spec-as-source: la spec es el fichero fuente. La persona solo edita la spec y nunca toca el código.
Según su análisis, todas las herramientas que miró se quedan en spec-first. Y deja caer una observación que me hizo gracia: mucha gente usa «spec» como sinónimo de «prompt detallado». Lo dicho, ingeniería de prompts.
Entonces, ¿qué ha cambiado? Las plantillas no, porque son las de siempre. Ha cambiado quién lee la spec. Antes la leía un compañero que preguntaba cuando algo no estaba claro. Ahora la lee un agente que se la toma al pie de la letra y, cuando hay un hueco, lo rellena con lo que le parece más probable. Por eso escribir bien los requisitos vuelve a importar, y por eso el SDD ha calado tan rápido.
Un mismo requisito escrito de tres formas
Te lo enseño mejor con un ejemplo. Imagina que quiero añadir a pañalesenoferta.es un aviso cuando baje el precio de un pack que sigues.
Como requisito al estilo EARS:
CUANDO el precio de un producto seguido baje del precio objetivo del usuario,
EL SISTEMA DEBERÁ enviar al usuario un aviso por email en menos de 1 hora.Como escenario de BDD en Gherkin:
# language: es
Característica: Aviso de bajada de precio
Escenario: El precio baja del objetivo
Dado que sigo el pack "Talla 4, 120 unidades" con precio objetivo 30 €
Cuando su precio baja a 28,50 €
Entonces recibo un email de aviso con el precio nuevo
Y como cambio de OpenSpec, que es lo que le pasarías al agente con spec-driven development:
## ADDED Requirements
### Requirement: Aviso de bajada de precio
El sistema SHALL avisar por email al usuario cuando el precio de un producto
que sigue baje de su precio objetivo, en menos de 1 hora.
#### Scenario: El precio baja del objetivo
- **WHEN** el precio del pack seguido baja de 30 € a 28,50 €
- **THEN** el usuario recibe un email de aviso con el precio nuevo
Mira el tercero con calma. Es un requisito de toda la vida con un escenario BDD debajo. La forma cambia un poco, pero el fondo es el mismo.
| Ingeniería de requisitos | BDD | SDD | |
|---|---|---|---|
| Qué produce | Requisitos verificables | Ejemplos ejecutables | Specs para un agente |
| Quién la lee | Personas | Personas y la máquina de pruebas | Un agente que implementa |
| ¿Comprueba el resultado? | Dice que debe poder comprobarse | Sí, si alguien escribe y mantiene los escenarios | No lo define |
Lo que le falta al spec-driven development
Esa última fila es lo que me llevó a escribir esta serie.
El spec-driven development mejora mucho el punto de partida: el agente ya no trabaja con un «hazme una web sencilla», sino con algo explícito. Pero, como escribí en el documento de DGC, no dice cómo verificar que el resultado la cumple.
Y no es un detalle teórico. La propia Böckeler cuenta que vio con frecuencia que el agente acababa sin seguir todas las instrucciones de la spec. También dice que prefería revisar código a revisar todos esos ficheros Markdown. O sea, que pasas de revisar código a revisar specs y, además, el código.
Así que, aunque tengas una spec preciosa, acabas en el mismo sitio de siempre. O te lees todo lo que ha hecho el agente, o te fías de los tests que ha escrito el mismo agente. En el artículo anterior te conté con datos por qué ninguna de las dos escala, así que no me repito.
Te pongo mi caso. En MaIA, mi software factory, hoy reviso a mano todo el código que sale. Con specs, sí. Y es justo lo que quiero dejar de hacer.
Cómo encajan las tres en DGC
DGC, el Desarrollo Guiado por Contrapruebas, no inventa sus piezas. Las toma de estas tres disciplinas y añade la que falta:
- De la ingeniería de requisitos toma que un requisito tiene que ser verificable y la separación entre lo que hace el sistema y con qué calidad lo hace. En DGC lo llamo criterios de aceptación y restricciones. La regla práctica: si algo se puede medir u observar sin mirar el código, es una restricción. Si dicta cómo se construye, es una decisión técnica y va aparte.
- De BDD y Specification by Example toma los ejemplos concretos como forma de ponerse de acuerdo. Las contrapruebas son ejemplos, pero con una diferencia importante: el agente que implementa no los ve.
- Del spec-driven development toma la spec como punto de partida del agente. Mi objetivo es spec-as-source y, en el código que ya existe, spec-anchored.
Lo que DGC añade es una autoridad que comprueba el resultado y que es independiente de quien escribe el código. Cómo se escriben esas contrapruebas, quién las escribe y cómo se esconden al agente te lo cuento en las próximas semanas, que tiene su miga.
En el próximo artículo de la serie toca algo previo: cómo organizar las specs de un sistema entero como capacidades y deltas, igual que una base de datos se describe con sus migraciones. Mientras tanto, tienes la metodología completa en la página de DGC.
¡Te espero!
