A gente decide no papel, enquanto ainda é barato

Todo projeto que o meu time desenha passa por três documentos: o que o negócio precisa, o que o sistema precisa fazer e como o design vai entregar isso. Escrever cedo é a decisão mais barata de todo o projeto.

  • BRSBusiness Requirements Specification
  • SRSSystem Requirements Specification
  • SDDSoftware Design Description
Ver os três documentos Fale comigo

Por que a gente escreve

O preço de uma decisão é definido por quanto já foi construído em cima da resposta que falta.

De The Price of Not Deciding, meu ensaio sobre requisitos, 2026
Quanto custa corrigir um defeito de requisito
  1. 1×enquanto ainda está no papel
  2. 10×durante o desenvolvimento
  3. 100×com o sistema no ar

Dados de Barry Boehm dos anos 1980, confirmados muitas vezes desde então. Os multiplicadores mudam de estudo para estudo; o formato da curva nunca muda.

Um arquiteto sabe que o lugar de uma janela decide a luz e o calor de cada cômodo atrás dela. O lugar de uma tela num funil faz o mesmo com toda a vida do software. Por isso o nosso design começa pelos requisitos, não pelas telas.

Três documentos, um mesmo fio

O discovery termina em entregas compartilhadas, escritas para quem constrói em seguida. Cada documento responde a uma pergunta e passa a resposta para o próximo.

Business Requirements Specification

Do que o negócio precisa?

A Business Requirements Specification, a especificação de requisitos de negócio, descreve o negócio antes do produto: seus objetivos, o jeito como ele funciona hoje, as pessoas envolvidas e os limites dentro dos quais ele opera. Ela separa os processos internos do cliente daquilo que a plataforma precisa fazer, para que um não seja confundido com o outro.

O que entra

  • Objetivos do negócio e como o sucesso será medido
  • Como o negócio funciona hoje, passo a passo
  • Stakeholders, seus papéis e as decisões de cada um
  • Restrições: orçamento, prazos, plataformas e regulação
  • O que está no escopo e o que não está
  • Requisitos de negócio, em ordem de prioridade
Quem lê
A liderança do cliente, o gerente de projeto e o design
Pronto quando
O cliente aprova os objetivos, o escopo e as prioridades.

Construída a partir de workshops de discovery, benchmarking e um registro de lacunas com cada pergunta em aberto.

System Requirements Specification

O que o sistema precisa fazer?

A System Requirements Specification, a especificação de requisitos de sistema, transforma as necessidades do negócio em comportamento que o time consegue construir e testar. Cada requisito tem um tipo, um responsável e uma forma de provar que funciona, para que desenvolvimento e QA leiam a mesma promessa.

O que entra

  • Propósito, escopo e definições
  • Usuários, seus papéis e suas permissões
  • Requisitos funcionais, cada um em uma frase testável
  • Requisitos de qualidade: performance, segurança e acessibilidade
  • Interfaces com outros sistemas e seus dados
  • Tipos de requisito e o responsável por cada um
  • Critérios de aceite
Quem lê
Desenvolvimento, QA, design e o gerente de projeto
Pronto quando
Todo requisito de negócio aponta para pelo menos um requisito de sistema, e todo requisito de sistema pode ser testado.

Baseada na IEEE 830 e na IEEE 1233.

Software Design Description

Como o design vai entregar isso?

A Software Design Description, a descrição do design de software, é onde o design encontra a especificação. Ela mostra como o produto é montado para quem não vive dentro do desenvolvimento de software: os fluxos, as telas e seus estados, os casos de borda e as decisões por trás deles, em palavras que produto, QA e desenvolvimento compartilham.

O que entra

  • Objetivos e entregas de cada área do design
  • Fluxos de usuário e arquitetura de informação
  • Telas, componentes e todos os estados possíveis
  • Casos de borda e caminhos de falha
  • Decisões de design, cada uma com o seu porquê
  • Um glossário, para que todos os times usem as mesmas palavras
Quem lê
Designers, desenvolvedores, QA e gerentes de produto
Pronto quando
Um desenvolvedor consegue construir uma tela e um testador consegue conferir o resultado sem perguntar ao designer o que ele quis dizer.

Segue a IEEE 1016. O nosso template vem com um guia interativo que conduz quem chega, seção por seção.

Como funciona na prática

Os documentos são vivos. Eles começam no sprint de discovery de duas semanas e ficam mais precisos a cada sprint, conforme o trabalho ensina. Quatro regras mantêm tudo honesto.

  • Escreva na semana em que surgiu

    Toda decisão em aberto vai para o papel na semana em que aparece, com um responsável e uma data.

  • Rascunho agora vale mais que perfeição depois

    Uma frase pode ser refinada. Uma página em branco, não.

  • Priorize antes de detalhar

    O tempo de análise vai para os requisitos que sustentam o negócio, não para os que chegaram primeiro.

  • Toda decisão tem um prazo

    Uma decisão reversível tomada neste sprint vale mais que uma perfeita tomada depois que o banco de dados já está no ar.

O que isso muda

63 perguntas em aberto
Registradas no registro de lacunas de um discovery de duas semanas para uma plataforma de eventos e assinaturas, antes da primeira tela ser desenhada.
2 entregas
Dividir o discovery em requisitos de negócio e requisitos de sistema deu ao design uma passagem clara para os outros times. O time adotou isso em setembro de 2026.
13 para 1 ferramentas
Um conceito de operações uniu três portais administrativos em um único CRM para a Container Alliance. Pelo meu inventário, ele substituiu 13 ferramentas separadas.

  • Quem chega aprende com o trabalho de verdade

    Designers novos estudam os tipos de requisito e os papéis na nossa SRS, com três camadas de apoio ao redor, até conseguirem conduzir o discovery sozinhos.

  • Um só vocabulário

    O glossário da SDD dá a produto, QA, desenvolvimento e design as mesmas palavras para as mesmas coisas.

  • O design deixa de ser opcional

    Quando cada tela aponta para um requisito escrito, os outros times conseguem ver por que ela está ali.

Começando um projeto? Comece pelos requisitos.

Todo projeto começa com um sprint de discovery de duas semanas. Ele termina com os requisitos de negócio no papel, para que o sistema seja especificado antes que alguém desenhe uma tela.

Fale comigoVer os trabalhos