Qual livro ler sobre spec-driven development e requisitos de software?

Tem uma diferença gigante entre decorar receita de prompt e ter repertório de especificação

Receita de prompt envelhece a cada versão nova de modelo

Repertório de especificação não envelhece, ele só fica mais útil

E se liga nisso: com um agente de codificação no meio do caminho, uma spec ruim não gera código ruim mais devagar

Ela gera código errado MUITO mais rápido, com testes passando e tudo 😀

Por isso a pergunta "que livro ler sobre spec-driven development e requisitos" começou a aparecer

Aqui eu comparo os títulos disponíveis, incluindo o único livro publicado dedicado a spec-driven development com agentes de IA, e digo pra quem cada um serve

Formação Recomendada

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

• 474 aulas
• 20 projetos
• 39h 27min

Conhecer formação

Livros sobre especificação e requisitos lado a lado

São seis frentes diferentes, e elas não competem entre si: cada uma resolve um pedaço do problema de dizer o que o software precisa fazer antes de alguém (ou algum agente) sair escrevendo código

Se você for caçar a edição certa, alguns ISBNs ajudam a não comprar gato por lebre: Wiegers e Beatty é o 9780735679665, o Essentials é o 978-0-13-819028-6, o Adzic é o 9781617290084, o Patton é o 9781491904909, o Cockburn é o 9780201702255 e o brasileiro da Brasport é o 9788574527963

O Martinelli tem ISBN 979-8-8688-2850-8 no softcover e 979-8-8688-2851-5 no ebook

Vale comprar o livro de spec-driven development com agentes de IA?

Veredito curto: vale como porta de entrada, não como fundamento

O livro do Simon Martinelli é o único título publicado que eu encontrei dedicado especificamente a spec-driven development com agentes de IA, saiu pela Apress dentro da série Apress Pocket Guides

E aí mora a resposta: é um pocket guide

São 107 páginas, com 19 ilustrações em preto e branco e 4 coloridas

Faça a conta comigo: o clássico do Wiegers e da Beatty tem 672 páginas só de requisitos

Não dá pra caber o mesmo terreno em 107 páginas, e nem é essa a proposta de um guia de bolso

Então o que dá pra esperar dele é o vocabulário e o desenho do fluxo (o que é uma spec, como ela conversa com o agente, onde entra o plano e onde entra a implementação)

O que ele não vai te dar, por tamanho, é a profundidade de elicitação, priorização, validação e gestão de mudança que os livros de requisitos passaram décadas destrinchando

Por isso o combo rende mais que a escolha única: pocket guide pra pegar o formato do fluxo com agente, livro de requisitos pra você saber O QUE colocar dentro da spec

Porque o agente executa muito bem uma especificação errada, e essa é exatamente a armadilha

Que livro ler para cada situação

Você é dev solo, já usa agente de IA e quer o vocabulário do fluxo

Começa pelo Martinelli

É curto, é recente e é o único focado no assunto com agentes de codificação no centro

Em um fim de semana você sai falando a língua do fluxo, e isso já muda a qualidade do que você entrega pro agente

Você escreve requisitos pra um time e precisa de prática estruturada

‘Software Requirements Essentials’, do Wiegers com a Candase Hokanson, publicado em 2023 pela Addison-Wesley Professional

São 208 páginas organizadas em 20 práticas centrais que cobrem planejamento, elicitação, análise, especificação, validação e gestão de requisitos

É o Wiegers em versão enxuta, com prática nomeada pra você aplicar uma por vez

Se depois você quiser o tratado inteiro, aí sim vai pro ‘Software Requirements, 3rd Edition’ (2013, Microsoft Press, 672 páginas), que é o completão da área

Você quer transformar critério de aceite em exemplo testável

‘Specification by Example’, do Gojko Adzic, de 2011 pela Manning, 296 páginas

Esse aqui é o mais direto pra quem faz vibe coding hoje, e olha que ele é de 2011

A ideia central é usar exemplos realistas como fonte única de verdade, em vez de um documento cheio de "o sistema deve"

Exemplo concreto é justamente o que um agente consegue verificar sozinho

Você sofre com escopo e priorização de produto

‘User Story Mapping’, do Jeff Patton, pela O’Reilly Media em 2014

O problema aqui não é escrever a spec, é decidir qual pedaço entra agora e qual pode esperar

Se o teu projeto vive crescendo de escopo no meio do caminho, o buraco é esse

Você precisa descrever comportamento passo a passo

‘Writing Effective Use Cases’, do Alistair Cockburn, publicado em 2000 pela Addison-Wesley Professional dentro da Agile Software Development Series

É o livro de referência pra caso de uso, aquele detalhamento de fluxo principal, alternativo e de exceção

Parece antigo? é

Mas descrever comportamento com precisão não mudou porque apareceu LLM 🙂

Você prefere ler em português

‘Engenharia de Requisitos: software orientado ao negócio’, 1ª edição de 2016 pela Brasport

É a opção nacional pra quem quer o fundamento sem a barreira do inglês técnico

Ordem de leitura sugerida

Se eu tivesse que montar uma trilha, seria assim:

1. Martinelli, pra pegar o formato do fluxo com agente
2. Wiegers e Hokanson, pras 20 práticas de requisitos
3. Adzic, pra virar a chave de "descrever" pra "exemplificar"
4. Patton ou Cockburn, dependendo se a tua dor é escopo ou comportamento

E um aviso de escopo: nenhum desses fala de estrutura de código depois que a spec está pronta

Se é aí que você trava, o caminho passa mais por livros de design de software, e se o gargalo for modelagem, por livros de banco de dados

De onde vem a ideia de especificar por exemplos

Aqui vale um parênteses histórico, porque muita gente acha que isso nasceu com IA

Não nasceu

O termo ‘Specification by Example’ foi cunhado por Martin Fowler em 2004

E o uso documentado mais antigo de exemplos realistas como fonte única de verdade aparece antes disso, no projeto WyCash+, descrito por Ward Cunningham em 1996 em ‘A Pattern Language of Competitive Development’

1996

Ou seja: a prática de especificar por exemplo tem quase três décadas de estrada e sobreviveu a várias ondas de metodologia

É por isso que ler os clássicos ainda paga: a ferramenta muda, a disciplina de dizer com clareza o que o sistema faz não muda

Como esse repertório se aplica ao desenvolvimento com IA hoje

Beleza, livro é teoria

E na prática, onde isso encosta no teu terminal?

O nome mais visível hoje é o Spec Kit, projeto open source oficial do GitHub, descrito no próprio repositório como "Toolkit to help you get started with Spec-Driven Development"

Ele passa de 120,2 mil estrelas no GitHub, integra com mais de 30 agentes de codificação com IA e roda em Linux, macOS e Windows

A porta de entrada é o comando de init, que instala os arquivos de comando e a estrutura de diretórios pro agente que você escolheu:

specify init my-project --integration copilot

Depois do init, o agente passa a ter comandos de barra pro fluxo estruturado

E é exatamente nesse ponto que o repertório dos livros aparece: a ferramenta te dá o esqueleto do processo, mas quem escreve o conteúdo da spec é você

Um template vazio preenchido com requisito vago entrega… requisito vago, só que com diretório bonitinho 😛

Se você prefere aprender em vídeo antes de encarar livro, tem também o curso curto ‘Spec-Driven Development with Coding Agents’, da DeepLearning.AI em parceria com a JetBrains, ministrado pelo Paul Everitt, developer advocate da JetBrains

Funciona bem como complemento: vídeo pra ver o fluxo rodando, livro pra entender por que cada parte existe

Por onde começar

Recapitulando sem enrolação

Se você já usa agente de codificação e quer só o vocabulário do fluxo, o livro de spec-driven development do Martinelli resolve, com a ressalva honesta de ser um pocket guide de 107 páginas

Se você quer fundamento que não expira na próxima versão de modelo, o ‘Software Requirements Essentials’ (2023, 208 páginas, 20 práticas) é a melhor relação entre densidade e tamanho

E se a tua dor é escrever critério de aceite que a IA consiga verificar, o Adzic é o caminho

O próximo passo concreto eu deixo assim: escolhe UM dos dois primeiros, lê, e roda o fluxo em um projeto pequeno seu com o Spec Kit

Projeto pequeno mesmo, coisa de uma feature só

Porque conceito de especificação só vira habilidade quando você vê a própria spec voltar torta e precisa consertar ela 🙂

até o próximo post!