SDLC — Spec-driven (S)

2. SDLC com Spec-Driven

Spec-driven não adiciona fases ao SDLC — muda a natureza dos artefatos que cada fase produz e consome. A especificação formal precede e governa toda a execução.

Fase	Artefato de spec produzido	O que muda com spec-driven
01 · Descoberta	Glossário de domínio; definição do contrato de aceite final	Fase preparatória. Compromisso com spec-driven é firmado aqui — sem ele a abordagem não decola. Define quais specs serão exigidas nas fases seguintes e quem as valida.
02 · Requisitos	Feature files (.feature / Gherkin); tabelas de decisão; invariantes de negócio com ID rastreável	Núcleo da spec. Critérios de aceite deixam de ser texto em prosa e tornam-se cenários Given / When / Then (BDD) verificáveis. Cada requisito recebe ID rastreável. Ambiguidades bloqueiam o baseline — não passam adiante.
03 · Arquitetura	OpenAPI / AsyncAPI spec; JSON Schema; ADRs com restrições formais versionadas	Spec técnica. Contratos de interface formalizados antes da implementação. ADRs registram restrições que a implementação não pode violar. A spec técnica complementa a spec comportamental da fase 2.
04 · Implementação	Suite de testes unitários e de contrato; relatório de cobertura vinculado a IDs de requisito	Spec dirige o código. TDD: testes escritos antes do código, derivados dos critérios da fase 2. O desenvolvedor (ou agente de IA) implementa até satisfazer a spec — não até o código “parecer certo”. CI verifica spec técnica (contract tests) e spec comportamental (BDD scenarios) a cada push.
05 · Qualidade	Relatório de cobertura de spec; matriz de rastreabilidade requisito → teste → resultado	Spec como oráculo. QA não interpreta intenção — verifica spec. Cada defeito referencia o ID do requisito ou contrato violado. Cobertura de spec (quantos cenários estão cobertos) é a métrica principal, não apenas cobertura de linha.
06 · Homologação	Execução dos feature files como evidência de aceite; ata referenciando IDs de requisito	O usuário valida cenários BDD escritos na fase 2 — em linguagem de negócio que ele já conhece. O aceite é objetivo: os cenários passam ou não. Elimina “achei que seria diferente”.
07 · Deploy	Spec técnica versionada no artefato de release; resultado dos contract tests no pipeline	Contract tests no pipeline pré-deploy garantem que nenhuma interface foi quebrada. Spec versionada no artefato permite auditoria de “qual contrato estava em produção em qual data”.
08 · Operação	Post-mortem com referência a spec violada ou ausente; spec atualizada como ação corretiva	Incidentes rastreados até a spec violada ou ausente — não apenas ao componente que falhou. Post-mortems alimentam atualização de spec, fechando o ciclo: operação corrige a especificação, não apenas o código.

Princípio central: a spec não é documentação produzida após o fato — é o artefato que autoriza e limita cada fase. Sem spec aprovada, a fase seguinte não começa. Com ela, cada fase tem um alvo verificável e auditável.

Anterior: ← Base (8 fases) · Próximo: IA assistida →