Modelo de Documento de Requisitos: Estrutura Completa p/ Baixar
Modelo de documento de requisitos pronto, com exemplo preenchido, checklist e base na ISO/IEC/IEEE 29148. Baixe e adapte ao seu projeto em minutos.
Se você chegou até aqui, provavelmente precisa entregar um documento de requisitos ainda hoje e não quer reinventar a roda. Este modelo de documento de requisitos traz a estrutura completa, seção por seção, com texto de exemplo já preenchido — não apenas campos entre colchetes como nos templates genéricos em inglês. A base é a norma ISO/IEC/IEEE 29148:2018, que substituiu o antigo IEEE 830 e é a referência técnica mais atual sobre o assunto.
O que é um documento de requisitos e quando usar cada tipo (SRS, PRD, BRD)?
Um modelo de documento de requisitos é o artefato que descreve, de forma estruturada, o que um sistema deve fazer, para quem e sob quais condições — a base que times técnicos usam para construir, testar e validar um produto sem depender de reuniões repetidas para "lembrar" o que foi combinado. O problema é que, na prática, três siglas costumam ser usadas como sinônimos quando não são: SRS, PRD e BRD respondem perguntas diferentes, servem públicos diferentes e, se confundidos, geram documentos genéricos demais para orientar desenvolvimento ou específicos demais para orientar decisão de negócio.
O BRD (Business Requirements Document, ou documento de requisitos de negócio) existe para responder "por que fazer isso e que valor isso traz para a empresa?". É o documento que um patrocinador de projeto ou diretor financeiro lê antes de aprovar orçamento: fala de objetivos estratégicos, indicadores de sucesso e restrições orçamentárias, sem entrar em telas ou regras de validação. O PRD (Product Requirements Document, documento de requisitos de produto) fica uma camada abaixo: traduz o BRD em funcionalidades e experiência de usuário, geralmente escrito por um product manager para alinhar design, negócio e engenharia sobre o que o produto vai fazer do ponto de vista do usuário final. Já o SRS (Software Requirements Specification, ou documento de especificação de requisitos de software) é o mais técnico dos três — detalha requisitos funcionais, não funcionais, interfaces e regras de negócio com precisão suficiente para orientar arquitetura, codificação e testes. É esse o tipo de documento que este modelo de documento de requisitos cobre em detalhe, porque é o que mais falta pronto e completo em português.
A estrutura que este modelo segue não é aleatória: baseia-se na ISO/IEC/IEEE 29148:2018, a norma internacional que descreve os processos de engenharia de requisitos para sistemas e software e que formalmente obsoleta o antigo IEEE 830-1998 (ReqView; IEEE Standards Association). É comum encontrar por aí materiais que ainda tratam o IEEE 830 como referência vigente, mas a segunda edição da 29148 já substitui a de 2011 e harmoniza a estrutura de requisitos com as normas de ciclo de vida ISO/IEC/IEEE 15288 e 12207 (ISO/IEC/IEEE 29148:2018). Para quem quer entender o processo completo por trás desse artefato — não só o documento final, mas como levantar, validar e priorizar requisitos antes de escrevê-los — vale complementar com o Guia Completo do Processo de Engenharia de Requisitos.
Modelo de documento de requisitos: a estrutura seção por seção (com exemplo preenchido)
Um modelo de documento de requisitos útil não é uma lista de campos entre colchetes — é um esqueleto com texto real dentro, que mostra como cada seção deveria ficar depois de preenchida. É essa lacuna que a maioria dos modelos disponíveis deixa aberta: os PDFs acadêmicos da UFPE trazem exemplos censurados ou incompletos, e os templates comerciais como o SRS gratuito da Asana explicam o que cada seção deve conter, mas entregam apenas placeholders genéricos. Para fechar essa lacuna, vamos usar um caso nomeado e fictício — o AgendaFácil, um app de agendamento de horários para salões e clínicas de pequeno porte — e preencher cada seção como ela apareceria num documento real.
A estrutura abaixo segue o esqueleto clássico consolidado pelo IEEE 830 e reorganizado pela ISO/IEC/IEEE 29148, norma que substituiu o 830 em 2011 e ganhou uma segunda edição em 2018 — detalhe que quase nenhum material em português menciona, mas que importa porque a 29148 harmoniza o documento de requisitos com os processos de ciclo de vida descritos nas normas ISO/IEC/IEEE 15288 e 12207, segundo o texto oficial da norma. Na prática, isso significa que o documento não é um artefato isolado: ele se conecta ao planejamento e ao desenvolvimento do sistema como um todo, um ponto que aprofundamos no Guia Completo do Processo de Engenharia de Requisitos.
A tabela a seguir resume as seis seções essenciais, o que cada uma deve conter e como ficaria preenchida no caso do AgendaFácil:
| Seção | O que vai | Exemplo preenchido (AgendaFácil) |
|---|---|---|
| Introdução (Objetivo e Escopo) | Por que o documento existe e o que o sistema vai e não vai fazer | "O AgendaFácil permite que salões de beleza e clínicas de estética gerenciem agendamentos online. Está fora do escopo: pagamento integrado e emissão de nota fiscal." |
| Descrição Geral | Visão do produto, usuários-tipo e restrições | "Usuários: donos de salão (administradores) e clientes finais (agendam via link público). Restrição: operar em navegadores mobile sem app nativo na primeira versão." |
| Requisitos Funcionais | O que o sistema faz, com código de rastreio | "RF01 — O sistema deve permitir que o cliente escolha um horário disponível e receba confirmação por WhatsApp em até 1 minuto." |
| Requisitos Não Funcionais | Como o sistema deve se comportar (desempenho, segurança, usabilidade) | "RNF01 — A tela de agendamento deve carregar em até 2 segundos com conexão 4G." |
| Glossário | Termos e siglas usados no documento | "Slot: intervalo de horário disponível para agendamento, definido pelo administrador do salão." |
| Referências | Documentos, normas e materiais consultados | "ISO/IEC/IEEE 29148:2018; pesquisa de UX com 12 salões parceiros, jan/2025." |
O valor de preencher com um caso nomeado é justamente esse: ao ler "RF01" com uma frase real ao lado, o gestor entende como cobrar clareza do time — quem escreve "o sistema deve ser rápido" sem número não passaria pelo mesmo teste. Sobre como escrever cada requisito funcional e não funcional sem essa ambiguidade, vale o comparativo detalhado do Guia de Requisitos Funcionais e Não Funcionais.
Como escrever requisitos funcionais e não funcionais sem ambiguidade?
O erro mais comum em qualquer modelo de documento de requisitos não é a falta de conteúdo — é a ambiguidade. Frases como "o sistema deve ser rápido" ou "a tela deve ser amigável" parecem completas, mas não dizem a nenhum desenvolvedor o que construir nem a nenhum testador o que verificar. Os exemplos acadêmicos da CIn-UFPE resolvem esse problema com uma convenção simples: cada requisito funcional recebe um código sequencial (RF01, RF02...) e cada requisito não funcional, outro (RNF01, RNF02...), categorizado por atributo — usabilidade, confiabilidade, desempenho. Essa numeração não é burocracia; é o que permite rastrear, testar e priorizar cada item individualmente, em vez de discutir o sistema como um bloco só.
A ISO/IEC/IEEE 29148:2011 formaliza o que os exemplos acadêmicos fazem na prática: define o construto de um "bom requisito" a partir de atributos e características objetivas, não de boa intenção de escrita. Na prática, isso significa que um requisito precisa ser verificável (dá para provar que foi atendido ou não), não ambíguo (só uma interpretação possível) e atômico (uma exigência por item, não várias amarradas). É esse padrão — detalhado com mais profundidade no Guia de Requisitos Funcionais e Não Funcionais — que separa um documento que orienta decisões de um que só ocupa espaço no repositório.
O exercício de antes e depois deixa o problema visível. Pegue um sistema de agendamento de consultas, chamado aqui de AgendaFácil:
| Versão | Requisito | Problema |
|---|---|---|
| Antes (ambíguo) | "O sistema deve confirmar agendamentos rapidamente." | Não define o que é "rapidamente" nem como confirmar — não é testável. |
| Depois (RF03) | "O sistema deve enviar confirmação de agendamento por e-mail em até 30 segundos após o clique em 'Confirmar'." | Mensurável, verificável e atribuível a um teste automatizado. |
| Antes (ambíguo) | "A interface deve ser amigável." | Subjetivo — depende de quem avalia. |
| Depois (RNF02 — Usabilidade) | "Um usuário sem treinamento deve concluir um agendamento em, no máximo, 3 cliques." | Critério objetivo, replicável em teste de usabilidade. |
Esse padrão de reescrita — trocar adjetivo por número, verbo vago por ação testável — é o que transforma um processo de engenharia de requisitos em artefato confiável, e é exatamente o que preenchemos, seção por seção, no modelo completo mais adiante.
Checklist: como saber se sua especificação de requisitos está boa?
A pergunta mais comum de quem termina de preencher um modelo de documento de requisitos é: "está bom o suficiente ou falta alguma coisa?". A resposta não é subjetiva. A ISO/IEC/IEEE 29148 — norma que substituiu o antigo IEEE 830 e define hoje o padrão internacional de engenharia de requisitos — estabelece um construto objetivo para avaliar cada requisito individualmente e o conjunto como um todo (ISO/IEC/IEEE 29148:2011). Ou seja: existe um checklist real, testável, que você pode aplicar linha por linha no seu documento antes de considerá-lo pronto para aprovação.
Os critérios abaixo resumem essas características. Rode cada requisito do seu modelo de documento de requisitos por eles:
- Testável/verificável — é possível escrever um caso de teste que prove, sim ou não, que o requisito foi atendido? "O sistema deve ser rápido" reprova; "a busca deve retornar resultados em até 2 segundos com 500 usuários simultâneos" passa.
- Não ambíguo — só admite uma interpretação. Se dois desenvolvedores lerem o mesmo requisito e entenderem coisas diferentes, ele falhou.
- Único — cada requisito descreve uma única necessidade. Textos que misturam duas regras numa mesma frase dificultam rastreamento e teste.
- Rastreável — tem um identificador (RF01, RNF03) que permite ligá-lo a uma origem (regra de negócio, stakeholder) e a um destino (caso de teste, história de usuário).
- Completo — não depende de informação que só existe na cabeça de quem escreveu. Um novo membro do time consegue implementar sem perguntar nada.
- Consistente — não contradiz outro requisito do mesmo documento.
Um ponto que os modelos genéricos costumam pular: quando o texto corrido deixa de ser suficiente. Fluxos com muitos atores, exceções encadeadas ou decisões condicionais — como o caminho de uma compra de passagem com regras de preço por faixa etária, caso citado no exemplo acadêmico da UFPE — ficam mais claros num diagrama de atividades ou caso de uso em UML do que em parágrafos. A regra prática: se você precisar de mais de três
O documento de requisitos ainda é útil na era ágil? Como conectá-lo à rastreabilidade
Sim, mas com uma ressalva que muita empresa brasileira ignora: um modelo de documento de requisitos bem preenchido não garante, por si só, gestão eficiente do projeto. É o que aponta a análise de requisitos.com.br: o artefato de documentação precisa ser combinado com uma aplicação que gerencie a matriz de rastreabilidade — caso contrário, o gestor tem um PDF bonito parado numa pasta enquanto o time discute prioridades no Jira ou no Trello sem olhar para ele. O documento define o quê; a matriz de rastreabilidade garante que cada requisito continue vivo, vinculado a uma tarefa, um teste e um responsável até a entrega.
Na prática, isso significa que RF01 ("o sistema deve permitir agendamento de horários") não pode existir só no Word. Ele precisa apontar para uma user story no backlog, para um caso de teste e, idealmente, para o commit ou a tela que o implementou. Sem esse fio condutor, mudanças de escopo — que em squads ágeis acontecem a cada sprint — deixam o documento desatualizado em semanas, e ele passa a ser ignorado. É o motivo pelo qual tanta empresa cria um SRS caprichado na fase de kickoff e nunca mais abre o arquivo.
Para squads ágeis, a saída não é abandonar o documento, e sim reduzir sua granularidade e aumentar sua frequência de revisão. Times que trabalham com Scrum costumam manter uma versão "viva" do documento de requisitos como referência de arquitetura e regras de negócio estáveis (o que raramente muda a cada sprint), enquanto o backlog e as user stories tratam do detalhamento tático de cada entrega. A combinação funciona assim:
- Documento de requisitos: regras de negócio, requisitos não funcionais, integrações — atualizado a cada release maior;
- Matriz de rastreabilidade: liga cada requisito a stories, testes e status de implementação;
- Backlog/user stories: fatia o requisito em entregas incrementais, sprint a sprint.
Esse encadeamento é justamente o tipo de trabalho manual que consome dias de analista e ainda assim fica desatualizado — e é onde a IA generativa muda a equação, gerando e mantendo a rastreabilidade automaticamente à medida que o requisito evolui. Vale entender por que a maioria das empresas brasileiras ainda não colhe esse retorno: veja por que só 5% das empresas têm ROI real com IA e como isso se repete em escala no Brasil. Para entender o processo completo por trás da elicitação e validação desses requisitos, o guia de engenharia de requisitos é o próximo passo natural.
Radar da semana
- Asana lança modelo gratuito de SRS com seções de introdução, requisitos funcionais e não funcionais, mas ainda em formato genérico traduzido.
- ReqView detalha os templates da ISO/IEC/IEEE 29148, a norma que tornou obsoleto o IEEE 830-1998.
- CIn-UFPE disponibiliza exemplo acadêmico de documento de requisitos com regras de negócio de um sistema de venda de passagens.
- Blog Análise de Requisitos reforça que o documento sozinho não basta sem uma matriz de rastreabilidade.
Perguntas frequentes
Qual o erro mais comum ao escrever um documento de requisitos?
O erro mais comum é a ambiguidade: escrever requisitos que podem ser interpretados de mais de uma forma, como 'o sistema deve ser rápido' em vez de 'a tela deve carregar em até 2 segundos'. Isso torna o requisito impossível de testar e gera retrabalho quando o time de desenvolvimento interpreta de um jeito e o negócio esperava outro.
Quando devo usar UML em vez de texto corrido no documento de requisitos?
Use diagramas UML (casos de uso, diagrama de sequência) quando o fluxo envolve múltiplos atores, decisões condicionais ou integrações entre sistemas — situações em que o texto corrido fica confuso de acompanhar. Para regras de negócio simples e requisitos isolados, o texto corrido numerado (RF01, RF02) costuma ser suficiente e mais rápido de manter.
O documento de requisitos tradicional ainda é útil em times ágeis?
Sim, mas em formato reduzido: em vez de um documento fechado de centenas de páginas, ele funciona melhor como um artefato de referência vivo, atualizado e ligado a uma matriz de rastreabilidade que conecta cada requisito às user stories do backlog. O ganho real vem de revisá-lo a cada sprint, e não de tratá-lo como algo estático assinado uma única vez.
Com a estrutura e o exemplo preenchido deste modelo de documento de requisitos, o próximo passo é adaptá-lo ao seu projeto real — trocando o caso fictício do AgendaFácil pelas regras de negócio do seu sistema — e, se quiser pular a parte manual de redigir cada seção do zero, vale ver como o espacoia.com.br usa agentes de IA para transformar a descrição da sua necessidade de negócio direto nesse tipo de documentação técnica completa.