El contrato persistente del comportamiento esperado
Una especificación de funcionalidad registra qué se espera que haga el producto, por qué existe ese comportamiento, a quién afecta y cómo puede evaluarse su corrección. Proporciona al Product Engineer, al agente de programación, a los revisores y al agente de verificación una referencia común más allá de un intercambio conversacional.
Una especificación no es simplemente una instrucción larga. Es un artefacto mantenido del producto. Un cambio del comportamiento acordado debe producir un cambio visible en la especificación pertinente, con un historial significativo de qué cambió y por qué.
Organizar las especificaciones por funcionalidades coherentes
El marco recomienda un directorio specs/ que contenga archivos Markdown orientados a funcionalidades y con identificadores estables. Una funcionalidad podría ser «Buscar clientes», «Aprobar solicitud de compra» o «Gestionar roles de la aplicación». La identidad estable importa más que un formato de numeración específico. Evite crear un archivo nuevo con versión para cada revisión cuando el control de versiones habitual pueda conservar el historial de la misma funcionalidad.
Una especificación coherente debe ser lo bastante acotada para comprenderla y verificarla, pero no estar fragmentada en decenas de archivos para controles individuales triviales. Una funcionalidad puede depender de otra especificación; haga una referencia cruzada explícita en lugar de duplicar reglas con formas contradictorias.
Qué debe recoger una especificación de funcionalidad
Como mínimo útil, registre el propósito y alcance de la funcionalidad, los actores o permisos, las acciones que la activan, el comportamiento esperado, las reglas empresariales, el comportamiento significativo de fallo o excepción, las dependencias o restricciones y las condiciones de aceptación. Cuando intervengan datos, describa la información visible o modificada y las expectativas importantes de validación o acceso.
Utilice lenguaje concreto. «El sistema debe ser intuitivo» es difícil de verificar. «Un revisor solo puede rechazar una solicitud si proporciona un motivo; después el solicitante puede ver el motivo registrado» expresa un comportamiento observable.
Aclarar la incertidumbre antes de inventar reglas
Un agente de programación puede cubrir un vacío con una suposición plausible que el negocio no ha aprobado. El Product Engineer debe resolver las ambigüedades importantes con las partes interesadas y actualizar la especificación. Los detalles no críticos pueden descubrirse mediante iteraciones sobre software en funcionamiento, pero las decisiones de comportamiento aceptadas deben pasar igualmente a formar parte del conjunto duradero de especificaciones.
Las especificaciones evolucionan con el producto
Las primeras especificaciones pueden centrarse en los flujos de trabajo acordados inicialmente. Los comentarios de las partes interesadas, los hallazgos de las UAT, los cambios de mantenimiento y las funcionalidades nuevas pueden revisarlas. La disciplina importante es que el conjunto represente el comportamiento previsto actual. Una especificación que describe el producto del año pasado mientras la implementación ha cambiado ya no es una referencia fiable.
Las especificaciones apoyan la verificación independiente
Un agente de verificación separado deriva comprobaciones del conjunto registrado en el repositorio, ejercita la implementación cuando es viable y comunica los resultados contra los requisitos. Los criterios de aceptación mejoran ese proceso, pero no implican que todos los requisitos puedan evaluarse perfectamente mediante automatización. La evaluación humana y las garantías especializadas siguen siendo importantes.
Estructura sugerida de una especificación
La plantilla de ejemplo del marco incluye un identificador estable, resumen, propósito, actores, precondiciones, comportamiento principal, reglas empresariales, excepciones, criterios de aceptación, dependencias y decisiones pendientes. Los proyectos pueden adaptar esa estructura siempre que las especificaciones sigan siendo comprensibles, mantenibles y verificables.