SPEC-DRIVEN DEVELOPMENT
Respuestas claras. Un mejor comienzo.
Lo esencial sobre el enfoque SDD y el paquete que prepara esta herramienta.
El enfoque
¿Qué significa Spec-Driven Development?
Es un enfoque en el que una especificación del comportamiento esperado orienta la planificación, las tareas y la verificación del desarrollo. En esta herramienta, ese acuerdo se recoge en spec.md.
¿Necesito inteligencia artificial para usar este generador?
No. El generador utiliza tus respuestas y plantillas locales. No llama a modelos de IA ni a servicios de traducción. Puedes usar los documentos con tu equipo y, si lo decides, como contexto para herramientas de desarrollo.
¿La spec reemplaza las pruebas o la revisión del código?
La spec describe qué debe comprobarse. Las pruebas y la revisión aportan evidencia de que la implementación lo cumple. El ZIP inicial no contiene pruebas ejecutadas ni acredita que un sistema ya funcione.
¿Cómo se usa con un sistema heredado?
Selecciona Heredado para documentar lo observado hoy, o Migración si vas a cambiar la plataforma. Se agregan inventario, spec inversa, caracterización y plan de migración. Valida el comportamiento con usuarios y evidencia antes de modificarlo.
El paquete inicial
¿Qué documentos se generan?
Spec, plan, tareas, análisis de riesgo, ADR, checklists, solicitud de cambio, descripción de PR, constitución, controles y retención de evidencias, README, PENDIENTES y respuestas.json. Nuevo, Evolutivo y Correctivo producen 16 archivos; Heredado y Migración producen 20.
¿Tengo que responder todas las preguntas?
Son obligatorios los datos comunes y al menos un requisito con comportamiento, caso correcto y caso de error. Las preguntas de documentos son opcionales: cada vacío se identifica en PENDIENTES.md para resolverlo después.
¿Qué diferencia hay entre spec, plan y tareas?
La spec recoge la necesidad y los resultados esperados. El plan propone la solución técnica. Las tareas descomponen el trabajo y lo vinculan con requisitos y pruebas. Mantén los tres coherentes cuando cambie el alcance.
¿Qué significan RF, RNF, RS y CA?
RF identifica un requisito funcional; RNF, uno no funcional; RS, uno de seguridad; y CA, un criterio de aceptación. Sus IDs ayudan a relacionar requisitos, tareas y evidencia sin depender del título de cada documento.
¿El paquete autoriza un pase a producción o una certificación?
Se entrega como borrador. Las aprobaciones humanas, pruebas, evidencias y checklists siguen pendientes. Las referencias a controles SGSI sirven para organizar el trabajo y deben ajustarse a tu organización.
Tus respuestas
¿Puedo continuar más tarde?
Usa Guardar respuestas JSON antes de salir. Después elige el mismo tipo de desarrollo e importa ese archivo. El ZIP también incluye respuestas.json. La herramienta no guarda automáticamente tu formulario cuando cierras la página.
¿Dónde se guardan mis respuestas?
Para la vista previa y el ZIP, el servidor procesa las respuestas durante la solicitud y no las guarda en archivos, base de datos ni sesión. La sesión mantiene el token de protección del formulario. El ZIP y JSON descargados quedan bajo tu custodia; evita incluir credenciales.
¿Cambiar de idioma traduce mis respuestas?
Español / English cambia la interfaz, ayudas, ejemplos y plantillas del paquete. Con JavaScript conserva lo escrito. Tus respuestas libres permanecen en el idioma original; para un paquete completamente inglés, escribe también las respuestas en inglés.
¿Puedo editar los documentos y usar Windows o Linux?
Los documentos son Markdown y se pueden editar e incorporar al repositorio del desarrollo. Bash, PowerShell y web comparten el mismo motor y el JSON de respuestas. La consola requiere PHP 8.2+; PowerShell también puede utilizar el PHP de Rocky en WSL.
¿Cómo añado más filas, requisitos o adapto el stack?
El formulario admite hasta 100 RF. La plantilla inicial conserva tres RNF, cuatro RS y filas base de actores, datos e interfaces. Añade las filas necesarias en Markdown y adapta constitución, tecnologías, controles y estimaciones al proyecto antes de aprobarlos.