---
title: "Spec-Driven Development"
type: "architectural-pattern"
slug: "spec-driven-development"
url: "http://localhost:3000/pt-br/architectural-patterns/spec-driven-development.md"
also_known_as: "SDD"
description: "Escreva primeiro uma especificação explícita e autoritativa e, então, derive dela a implementação, os testes e o código gerado — mantendo a especificação como a única fonte da verdade."
languages: ["typescript"]
---
# Spec-Driven Development

_Also known as: SDD_

> Escreva primeiro uma especificação explícita e autoritativa e, então, derive dela a implementação, os testes e o código gerado — mantendo a especificação como a única fonte da verdade.

## Intent

Faça de uma especificação precisa o artefato primário do desenvolvimento. A implementação, os testes e até o código gerado por IA são derivados da especificação e verificados em relação a ela, em vez de a especificação ser um documento descartável escrito antes do trabalho "de verdade".

## Problem

Os requisitos geralmente vivem na cabeça das pessoas, em conversas de chat ou em documentos desatualizados. A implementação se distancia da intenção e, quando isso acontece, não há referência autoritativa para definir o que o sistema _deveria_ fazer.

Isso é mais doloroso na programação assistida por IA: um prompt vago produz um código de aparência plausível que pode não corresponder ao que realmente se queria, e não há nada concreto para verificá-lo.

## Solution

Capture o comportamento pretendido em uma **especificação** clara e versionada — cenários, critérios de aceitação e contratos — e trate-a como a fonte da verdade. Gere ou guie a implementação (muitas vezes com a assistência de IA) _a partir_ da especificação, derive **testes de conformidade** da mesma especificação e verifique a implementação em relação a eles.

Quando o comportamento precisar mudar, você muda a especificação primeiro e deixa a implementação e os testes seguirem. A especificação, não o código, é o que a equipe revisa e discute.

## Structure

* **Especificação** — intenção, cenários, critérios de aceitação e contratos/schemas, mantidos sob controle de versão.
* **Geração / implementação** — código produzido ou guiado para satisfazer a especificação.
* **Testes de conformidade** — verificações derivadas da especificação que a implementação deve passar.
* **Ciclo de feedback** — discrepâncias atualizam a especificação, que reorienta o código e os testes.

## Applicability

* Use em **desenvolvimento assistido por IA**, onde uma especificação precisa transforma um prompt vago em uma intenção verificável.
* Use em **APIs contract-first**, coordenação entre múltiplas equipes e sistemas regulados ou auditáveis.
* **Evite especificações pesadas** para scripts minúsculos ou spikes exploratórios, onde elas custam mais do que retornam.

## How to Implement

1. Escreva a **especificação**: intenção, cenários concretos, critérios de aceitação e quaisquer contratos ou schemas.
2. Revise-a com as partes interessadas — é aqui que as divergências são resolvidas.
3. Derive **testes de aceitação / conformidade** a partir dos cenários.
4. Implemente para satisfazer a especificação, frequentemente com a assistência de IA guiada pela especificação.
5. Rode os testes de conformidade; trate as falhas como bugs ou como sinais para refinar a especificação.
6. Mantenha a especificação como autoridade — atualize-a primeiro sempre que o comportamento mudar.

## Pros

* Uma única fonte da verdade, revisável, mantém a intenção explícita.
* Combina naturalmente com a geração de código por IA, transformando prompts em contratos verificáveis.
* A conformidade pode ser verificada automaticamente, reduzindo o desvio.
* As decisões são debatidas sobre a especificação, antes de o código ser escrito.

## Cons

* Exige esforço inicial real para escrever e manter a especificação.
* Especificações apodrecem e enganam se não forem mantidas em sincronia com a realidade.
* O ferramental e as convenções ainda estão amadurecendo.
* Especificar demais pode ser tão prejudicial quanto especificar de menos.
## Relations

**Related patterns**

- [Test-Driven Development](/pt-br/architectural-patterns/test-driven-development.md)

## Code Examples

### typescript

```typescript
// A especificação é a fonte da verdade: cenários como dados.
export const slugifySpec = {
  name: 'slugify',
  cases: [
    { input: 'Hello World', expected: 'hello-world' },
    { input: 'A  B', expected: 'a-b' },
  ],
}

// Teste de conformidade derivado da especificação — a implementação deve satisfazê-lo.
for (const c of slugifySpec.cases) {
  test(`${slugifySpec.name}(${c.input})`, () => {
    expect(slugify(c.input)).toBe(c.expected)
  })
}
```