Modelo de Documento de Requisitos de Software Word Completo

Um documento de requisitos de software é o registro organizado das necessidades que um sistema deve atender. Ele transforma uma ideia, um problema de negócio ou uma solicitação de cliente em orientações claras para quem vai analisar, desenvolver, testar, contratar ou aprovar uma solução digital. Este modelo de documento de requisitos de software Word foi estruturado para ser copiado, preenchido e ajustado no Microsoft Word ou em outro editor compatível.

Também conhecido como especificação de requisitos de software (SRS, da expressão Software Requirements Specification), esse documento reduz dúvidas sobre o escopo do projeto. Em vez de depender apenas de conversas, mensagens e interpretações individuais, a equipe passa a contar com uma referência versionada, contendo objetivos, funcionalidades, regras de negócio, requisitos de qualidade, restrições e critérios de aceite.

Um requisito bem escrito descreve o que o sistema deve fazer e em quais condições, sem antecipar desnecessariamente como a solução será programada. Por exemplo, “o sistema deve permitir que o usuário recupere a senha por e-mail” é uma necessidade funcional. Já “a página de recuperação deve carregar em até três segundos em condições normais de uso” trata de desempenho, portanto é um requisito não funcional.

O modelo abaixo é útil para projetos internos, desenvolvimento sob encomenda, contratação de fornecedores, criação de aplicativos, plataformas web, sistemas administrativos e melhorias em softwares existentes. Antes de aprová-lo, revise o texto com as partes interessadas e mantenha um histórico das alterações realizadas.

Quando usar um documento de requisitos de software

Prepare esse documento no início do projeto, preferencialmente após o levantamento inicial das necessidades e antes do desenvolvimento. Ele pode ser simples em uma demanda pequena ou mais detalhado em sistemas com vários usuários, integrações, dados sensíveis ou impacto financeiro relevante.

• Ao solicitar a criação de um site, aplicativo, sistema web ou sistema interno;
• Ao documentar uma nova funcionalidade em um software já existente;
• Ao contratar uma software house, profissional autônomo ou equipe de tecnologia;
• Ao alinhar expectativas entre cliente, usuários, gestores, analistas, desenvolvedores e testadores;
• Ao definir prioridades, entregas, prazos estimados e critérios para homologação;
• Ao registrar regras de negócio, perfis de acesso e integrações com outros sistemas;
• Ao criar uma base para propostas comerciais, contratos, planos de teste e manuais de usuário.

Quando o software tratar dados pessoais, o levantamento deve considerar a Lei Geral de Proteção de Dados Pessoais — LGPD (Lei nº 13.709/2018). Nesse caso, é recomendável registrar quais dados serão coletados, para qual finalidade, quem terá acesso, por quanto tempo serão retidos e quais medidas de segurança serão adotadas. O documento de requisitos não substitui orientação jurídica, avaliação de segurança ou contrato, mas ajuda a tornar essas necessidades visíveis desde o planejamento.

Modelo completo de documento de requisitos de software

DOCUMENTO DE REQUISITOS DE SOFTWARE

1. IDENTIFICAÇÃO DO DOCUMENTO
Projeto: [NOME DO PROJETO OU SISTEMA]
Cliente/área solicitante: [NOME DA EMPRESA, SETOR OU CLIENTE]
Responsável pelo documento: [NOME COMPLETO E CARGO]
Versão: [NÚMERO DA VERSÃO]
Data: [DD/MM/AAAA]
Status: [RASCUNHO / EM REVISÃO / APROVADO]

2. HISTÓRICO DE REVISÕES
Versão [NÚMERO] — [DD/MM/AAAA] — [NOME DO RESPONSÁVEL] — [DESCRIÇÃO DA ALTERAÇÃO]

3. OBJETIVO
Este documento descreve os requisitos do sistema [NOME DO SISTEMA], cuja finalidade é [DESCREVER O PROBLEMA QUE SERÁ RESOLVIDO E O RESULTADO ESPERADO].

4. CONTEXTO E JUSTIFICATIVA
Atualmente, [DESCREVER COMO O PROCESSO É REALIZADO HOJE, AS DIFICULDADES EXISTENTES E OS MOTIVOS PARA A CRIAÇÃO OU ALTERAÇÃO DO SOFTWARE].

5. ESCOPO
O sistema deverá contemplar: [LISTAR AS PRINCIPAIS ENTREGAS, MÓDULOS OU PROCESSOS INCLUÍDOS].
Não fazem parte deste escopo: [LISTAR FUNÇÕES, INTEGRAÇÕES, ETAPAS OU SERVIÇOS EXPRESSAMENTE EXCLUÍDOS].

6. PARTES INTERESSADAS E PERFIS DE USUÁRIO
Patrocinador/solicitante: [NOME E FUNÇÃO].
Usuários principais: [DESCREVER QUEM UTILIZARÁ O SISTEMA].
Administrador: [DESCREVER PERMISSÕES DO PERFIL].
Demais perfis: [NOME DO PERFIL E RESPECTIVAS PERMISSÕES].

7. REQUISITOS FUNCIONAIS
RF-01 — [NOME DO REQUISITO]: O sistema deve [DESCREVER A FUNÇÃO DE FORMA OBJETIVA]. Prioridade: [ALTA / MÉDIA / BAIXA]. Critério de aceite: [CONDIÇÃO VERIFICÁVEL PARA CONSIDERAR O ITEM ENTREGUE].
RF-02 — [NOME DO REQUISITO]: O sistema deve [DESCREVER A FUNÇÃO]. Prioridade: [ALTA / MÉDIA / BAIXA]. Critério de aceite: [CONDIÇÃO VERIFICÁVEL].
RF-03 — [NOME DO REQUISITO]: O sistema deve [DESCREVER A FUNÇÃO]. Prioridade: [ALTA / MÉDIA / BAIXA]. Critério de aceite: [CONDIÇÃO VERIFICÁVEL].
RF-[NÚMERO] — [REPETIR A ESTRUTURA PARA OS DEMAIS REQUISITOS].

8. REGRAS DE NEGÓCIO
RN-01 — [DESCREVER UMA REGRA, CÁLCULO, VALIDAÇÃO, LIMITE, FLUXO DE APROVAÇÃO OU CONDIÇÃO OBRIGATÓRIA].
RN-02 — [DESCREVER OUTRA REGRA DE NEGÓCIO].
RN-[NÚMERO] — [REPETIR CONFORME NECESSÁRIO].

9. REQUISITOS NÃO FUNCIONAIS
RNF-01 — Segurança: [DESCREVER AUTENTICAÇÃO, CONTROLE DE ACESSO, REGISTRO DE LOGS, CRIPTOGRAFIA OU OUTRA MEDIDA NECESSÁRIA].
RNF-02 — Desempenho: [INFORMAR TEMPO MÁXIMO DE RESPOSTA, VOLUME DE USUÁRIOS OU CAPACIDADE ESPERADA].
RNF-03 — Disponibilidade: [INFORMAR JANELA DE FUNCIONAMENTO, META DE DISPONIBILIDADE OU ROTINA DE MANUTENÇÃO].
RNF-04 — Compatibilidade: [INFORMAR NAVEGADORES, DISPOSITIVOS, SISTEMAS OPERACIONAIS OU VERSÕES SUPORTADAS].
RNF-05 — Acessibilidade: [INFORMAR REQUISITOS DE ACESSIBILIDADE APLICÁVEIS].
RNF-06 — Proteção de dados: [DESCREVER DADOS PESSOAIS TRATADOS, FINALIDADE, PERFIS DE ACESSO E MEDIDAS RELACIONADAS À LGPD].

10. INTEGRAÇÕES E DADOS
Integrações necessárias: [SISTEMAS, APIs, SERVIÇOS DE E-MAIL, PAGAMENTO, ERP OU OUTROS].
Dados de entrada: [DADOS QUE SERÃO INFORMADOS, IMPORTADOS OU RECEBIDOS].
Dados de saída: [RELATÓRIOS, NOTIFICAÇÕES, EXPORTAÇÕES OU OUTROS RESULTADOS].
Responsável pelos dados e acessos: [NOME, ÁREA OU FORNECEDOR].

11. PREMISSAS, RESTRIÇÕES E RISCOS
Premissas: [CONDIÇÕES CONSIDERADAS VERDADEIRAS PARA O PROJETO].
Restrições: [LIMITE DE PRAZO, ORÇAMENTO, TECNOLOGIA, EQUIPE OU INFRAESTRUTURA].
Riscos identificados: [EVENTO QUE PODE AFETAR O PROJETO E FORMA DE TRATAMENTO].

12. CRITÉRIOS DE HOMOLOGAÇÃO E ACEITE
O sistema será submetido a testes pela área [NOME DA ÁREA OU RESPONSÁVEL]. A entrega será considerada aceita quando os requisitos classificados como [PRIORIDADE] forem demonstrados, os critérios de aceite forem atendidos, os defeitos críticos forem corrigidos e houver aprovação formal de [NOME OU CARGO].

13. APROVAÇÕES
Solicitante: [NOME COMPLETO] — [CARGO] — Assinatura: [ASSINATURA] — Data: [DD/MM/AAAA].
Responsável técnico: [NOME COMPLETO] — [CARGO] — Assinatura: [ASSINATURA] — Data: [DD/MM/AAAA].
Gestor aprovador: [NOME COMPLETO] — [CARGO] — Assinatura: [ASSINATURA] — Data: [DD/MM/AAAA].

Como preencher o documento passo a passo

1. Identifique o projeto e controle a versão. Dê um nome inequívoco ao sistema, informe a data e mantenha o número da versão atualizado. Isso evita que a equipe trabalhe com um arquivo antigo.
2. Explique o problema antes de listar funções. No objetivo e no contexto, descreva a situação atual, quem é afetado e o ganho esperado. Evite frases genéricas como “modernizar o processo”; informe o que precisa melhorar.
3. Delimite o escopo. Registre o que será entregue e, principalmente, o que não será entregue nesta fase. Itens fora do escopo podem ser registrados como futuras melhorias.
4. Numere os requisitos. Use códigos como RF-01 e RNF-01. Essa identificação facilita conversas, testes, relatórios de falhas e solicitações de mudança.
5. Escreva requisitos testáveis. Prefira verbos como “deve permitir”, “deve registrar”, “deve bloquear” e “deve enviar”. Cada item precisa ter critério de aceite observável, para que seja possível verificar se foi cumprido.
6. Separe funcionalidade de qualidade. Funções pertencem aos requisitos funcionais. Segurança, velocidade, disponibilidade, compatibilidade e acessibilidade devem aparecer como requisitos não funcionais, com medidas objetivas sempre que possível.
7. Valide com usuários e responsáveis. Faça uma revisão conjunta, registre dúvidas resolvidas e colha aprovações. Se houver alteração posterior, atualize o histórico de revisões e avalie o impacto em prazo, custo e testes.

Perguntas comuns

Qual é a diferença entre requisito funcional e não funcional?

O requisito funcional informa uma ação ou serviço que o sistema deve oferecer, como cadastrar produtos ou emitir um relatório. O requisito não funcional define condições de qualidade ou operação, como tempo de resposta, segurança, disponibilidade e compatibilidade com navegadores.

O documento de requisitos substitui um contrato de desenvolvimento?

Não necessariamente. Ele pode integrar um contrato, uma proposta ou um anexo técnico e detalhar o objeto contratado. Porém, cláusulas sobre preço, propriedade intelectual, responsabilidade, confidencialidade, suporte, prazos e penalidades devem ser tratadas em instrumento contratual adequado.

É obrigatório seguir um padrão específico, como IEEE?

Não há uma obrigatoriedade geral para todos os projetos privados. Referências de engenharia de requisitos podem ajudar na organização, mas o mais importante é que o documento seja claro, completo na medida necessária, rastreável e aprovado pelos envolvidos.

Como lidar com mudanças depois da aprovação?

Registre a solicitação de mudança, descreva o requisito afetado, indique a justificativa e avalie impactos técnicos, financeiros e de prazo. Após a aprovação dos responsáveis, atualize a versão do documento. Essa prática evita alterações informais e conflitos sobre o que foi combinado.

Este modelo tem caráter informativo e deve ser adaptado às necessidades do projeto. Para contratos, tratamento de dados pessoais, requisitos regulatórios ou situações com risco jurídico relevante, recomenda-se a revisão por profissionais técnicos e jurídicos qualificados.