Modelo de Documento de Requisitos de Software: Guia Completo

O documento de requisitos de software é o registro que descreve, de forma organizada e verificável, o que um sistema, aplicativo, site ou plataforma deverá fazer. Ele transforma necessidades do cliente, dos usuários e do negócio em orientações claras para as pessoas responsáveis por análise, desenvolvimento, testes, implantação e manutenção da solução.

Também conhecido como especificação de requisitos de software, documento de requisitos ou SRS, do inglês Software Requirements Specification, esse material reduz interpretações divergentes sobre o projeto. Em vez de trabalhar com pedidos genéricos, como “o sistema deve ser fácil de usar” ou “precisa ter cadastro de clientes”, a equipe passa a contar com definições objetivas sobre telas, permissões, regras de negócio, integrações, prazos, dados tratados e critérios para considerar cada entrega concluída.

Um bom documento não precisa ser excessivamente técnico. Sua principal qualidade é ser compreensível pelas partes interessadas e suficientemente detalhado para orientar a construção e a validação do software. O modelo abaixo pode ser utilizado em projetos internos de empresas, contratação de fornecedores, desenvolvimento sob demanda, evolução de sistemas existentes e criação de produtos digitais.

Quando usar um documento de requisitos de software

O ideal é elaborar o documento antes do início da programação, após as conversas iniciais de levantamento de necessidades. Entretanto, ele também pode ser preparado durante a revisão de um sistema legado, antes da contratação de uma fábrica de software ou quando uma mudança relevante precisar ser formalizada.

• Criação de um novo sistema: para delimitar objetivos, público, escopo e funcionalidades desde a fase de planejamento.
• Desenvolvimento de aplicativos e sites: para documentar jornadas do usuário, telas, integrações e comportamentos esperados.
• Contratação de empresa ou profissional: para tornar a proposta comercial, o contrato e a execução mais alinhados ao resultado desejado.
• Melhorias em plataforma existente: para detalhar novas funções, correções, migração de dados ou alterações de processo.
• Projetos com dados pessoais: para definir medidas de segurança, perfis de acesso, finalidade de uso e responsabilidades relacionadas à Lei Geral de Proteção de Dados Pessoais, Lei nº 13.709/2018.
• Testes e homologação: para estabelecer critérios objetivos que permitam verificar se cada requisito foi atendido.

O documento de requisitos não substitui, por si só, um contrato de desenvolvimento de software. Em uma relação comercial, ele pode funcionar como anexo contratual ou como referência técnica do escopo, desde que as partes indiquem expressamente essa vinculação. Questões como preço, propriedade intelectual, confidencialidade, responsabilidades, prazos e penalidades devem ser tratadas em instrumento contratual próprio ou em cláusulas adequadas.

Modelo completo de documento de requisitos de software

DOCUMENTO DE REQUISITOS DE SOFTWARE

1. IDENTIFICAÇÃO DO DOCUMENTO
Projeto: [NOME DO PROJETO OU SISTEMA]
Versão do documento: [NÚMERO DA VERSÃO]
Data de emissão: [DATA]
Elaborado por: [NOME COMPLETO / CARGO / EMPRESA]
Solicitante: [NOME COMPLETO OU RAZÃO SOCIAL]
Responsável pela aprovação: [NOME COMPLETO / CARGO]

2. OBJETIVO
Este documento tem por objetivo especificar os requisitos do software [NOME DO SISTEMA], destinado a [DESCREVER O PÚBLICO E A FINALIDADE PRINCIPAL]. A solução deverá apoiar o processo de [DESCREVER O PROCESSO OU NECESSIDADE], permitindo [RESULTADOS ESPERADOS].

3. ESCOPO DO PROJETO
Estão incluídos neste projeto: [LISTAR MÓDULOS, FUNCIONALIDADES, SERVIÇOS E ENTREGAS INCLUÍDOS].
Não estão incluídos neste projeto: [LISTAR FUNÇÕES, SERVIÇOS, EQUIPAMENTOS OU ATIVIDADES FORA DO ESCOPO].

4. PERFIS DE USUÁRIO E PERMISSÕES
[PERFIL 1]: poderá [AÇÕES E ACESSOS PERMITIDOS].
[PERFIL 2]: poderá [AÇÕES E ACESSOS PERMITIDOS].
[PERFIL 3]: poderá [AÇÕES E ACESSOS PERMITIDOS].
O acesso ao sistema deverá ocorrer por meio de [LOGIN, SENHA, AUTENTICAÇÃO EM DOIS FATORES OU OUTRA FORMA], conforme as permissões atribuídas a cada perfil.

5. REQUISITOS FUNCIONAIS
RF-01 – [NOME DO REQUISITO]
O sistema deverá [DESCREVER A FUNÇÃO DE FORMA OBJETIVA].
Dados de entrada: [INFORMAR DADOS NECESSÁRIOS].
Processamento: [INFORMAR REGRAS E AÇÕES DO SISTEMA].
Resultado esperado: [INFORMAR SAÍDA, TELA, ALERTA, RELATÓRIO OU REGISTRO].
Critério de aceitação: [CONDIÇÃO OBJETIVA PARA VALIDAR O REQUISITO].

RF-02 – [NOME DO REQUISITO]
O sistema deverá [DESCREVER A FUNÇÃO].
Dados de entrada: [DADOS NECESSÁRIOS].
Processamento: [REGRAS APLICÁVEIS].
Resultado esperado: [SAÍDA ESPERADA].
Critério de aceitação: [CONDIÇÃO DE VALIDAÇÃO].

RF-03 – [NOME DO REQUISITO]
O sistema deverá [DESCREVER A FUNÇÃO].
Dados de entrada: [DADOS NECESSÁRIOS].
Processamento: [REGRAS APLICÁVEIS].
Resultado esperado: [SAÍDA ESPERADA].
Critério de aceitação: [CONDIÇÃO DE VALIDAÇÃO].

6. REGRAS DE NEGÓCIO
RN-01 – [NOME DA REGRA]: [DESCREVER A REGRA, EXCEÇÕES, CÁLCULOS, PRAZOS OU LIMITAÇÕES].
RN-02 – [NOME DA REGRA]: [DESCREVER A REGRA].
RN-03 – [NOME DA REGRA]: [DESCREVER A REGRA].

7. REQUISITOS NÃO FUNCIONAIS
RNF-01 – Desempenho: o sistema deverá [INFORMAR TEMPO DE RESPOSTA, VOLUME DE ACESSOS OU META DE DESEMPENHO].
RNF-02 – Disponibilidade: o sistema deverá estar disponível [INFORMAR JANELA DE OPERAÇÃO OU NÍVEL ESPERADO].
RNF-03 – Segurança: o sistema deverá [INFORMAR CONTROLES DE ACESSO, REGISTROS, CRIPTOGRAFIA, BACKUP OU OUTRAS MEDIDAS].
RNF-04 – Compatibilidade: o sistema deverá funcionar em [NAVEGADORES, SISTEMAS OPERACIONAIS, DISPOSITIVOS OU VERSÕES].
RNF-05 – Usabilidade e acessibilidade: a interface deverá [INFORMAR PADRÕES, IDIOMA, REQUISITOS DE ACESSIBILIDADE OU DIRETRIZES].

8. DADOS PESSOAIS E PRIVACIDADE
O sistema tratará os seguintes dados pessoais: [LISTAR DADOS].
Finalidade do tratamento: [DESCREVER A FINALIDADE].
Base legal e responsabilidades: [INDICAR CONFORME AVALIAÇÃO JURÍDICA E A LGPD].
Medidas de segurança previstas: [DESCREVER MEDIDAS].
Prazo e forma de retenção ou eliminação dos dados: [INFORMAR].

9. INTEGRAÇÕES E DEPENDÊNCIAS
O software deverá integrar-se a [SISTEMA, API, GATEWAY, BANCO DE DADOS OU SERVIÇO].
Responsável pela disponibilização dos acessos: [NOME / EMPRESA].
Dependências conhecidas: [LISTAR LICENÇAS, EQUIPAMENTOS, DADOS, APROVAÇÕES OU TERCEIROS].

10. CRITÉRIOS DE HOMOLOGAÇÃO E ACEITE
A homologação será realizada por [NOME OU ÁREA RESPONSÁVEL], no período de [DATA OU PRAZO]. Cada requisito será considerado aceito quando [DESCREVER TESTES, EVIDÊNCIAS E RESULTADOS EXIGIDOS]. Eventuais não conformidades deverão ser registradas em [FERRAMENTA, E-MAIL OU DOCUMENTO] e tratadas conforme [PROCESSO OU PRAZO].

11. PREMISSAS, RISCOS E ALTERAÇÕES
Premissas: [LISTAR CONDIÇÕES ASSUMIDAS PARA O PROJETO].
Riscos identificados: [LISTAR RISCOS E POSSÍVEIS IMPACTOS].
Alterações posteriores a este documento deverão ser solicitadas por [CANAL], avaliadas quanto a impacto em prazo, custo e escopo e aprovadas por [RESPONSÁVEL].

12. APROVAÇÃO
Por meio da aprovação deste documento, as partes declaram ciência sobre os requisitos aqui descritos.

[CIDADE], [DATA].

________________________________________
[NOME DO SOLICITANTE / CARGO]

________________________________________
[NOME DO RESPONSÁVEL TÉCNICO / CARGO]

Como preencher o documento passo a passo

1. Identifique o projeto e os responsáveis. Informe um nome inequívoco para o sistema, a versão do documento, a data e quem elaborou, solicitou e aprovará o conteúdo. O controle de versão é essencial quando houver revisões.
2. Descreva o objetivo em termos de resultado. Explique qual problema será resolvido, quem utilizará a solução e qual ganho é esperado. Evite começar pelo recurso técnico; priorize a necessidade de negócio.
3. Delimite o escopo e as exclusões. Liste o que será entregue e, principalmente, o que não faz parte desta etapa. Essa definição ajuda a evitar pedidos adicionais apresentados como se já estivessem incluídos.
4. Organize os requisitos funcionais. Numere cada item com um código, como RF-01. Use verbos claros, por exemplo: “o sistema deverá permitir”, “deverá calcular”, “deverá bloquear” ou “deverá emitir”. Um requisito deve expressar uma necessidade que possa ser testada.
5. Registre as regras de negócio. Inclua condições que orientam o funcionamento, como limites de desconto, cálculos de comissão, prazo de cancelamento, obrigatoriedade de campos e exceções autorizadas.
6. Não esqueça os requisitos não funcionais. Segurança, desempenho, disponibilidade, compatibilidade e acessibilidade interferem diretamente na qualidade da entrega. Termos vagos devem ser convertidos em parâmetros mensuráveis sempre que possível.
7. Mapeie dados e integrações. Caso o sistema trate dados pessoais, descreva a finalidade e as proteções necessárias, observando a LGPD. Informe também sistemas externos, APIs e responsáveis por credenciais ou documentação técnica.
8. Defina testes e aceite. Determine quem testa, como serão registradas falhas, qual é o prazo de correção e quais evidências demonstram que a entrega atende aos requisitos.
9. Formalize as aprovações. Após a revisão pelas partes interessadas, registre a aprovação. Quando o documento estiver ligado a uma contratação, guarde a versão aprovada junto do contrato e dos demais anexos.

Perguntas comuns

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

O requisito funcional descreve uma ação ou serviço que o sistema deve oferecer, como cadastrar usuários, gerar boletos ou emitir relatórios. O requisito não funcional estabelece atributos e restrições de qualidade, como tempo de resposta, segurança, navegador compatível, disponibilidade e controle de acesso.

Todo projeto precisa de um documento extenso?

Não. O nível de detalhamento deve acompanhar a complexidade e os riscos do projeto. Uma pequena automação pode exigir poucas páginas, enquanto um sistema que integra vários setores, movimenta valores ou trata dados pessoais necessita de especificação mais completa. Ainda assim, todo projeto se beneficia de um escopo e de critérios de aceite registrados.

Quem deve escrever os requisitos de software?

O levantamento pode ser conduzido por analista de negócios, gerente de projeto, product owner, desenvolvedor, consultor ou fornecedor técnico. A validação, porém, deve envolver quem conhece o processo de negócio e os usuários que executarão as atividades na prática.

Como lidar com mudanças após a aprovação?

Registre a solicitação, descreva a alteração pretendida e avalie seus impactos em escopo, custo, prazo, segurança e integrações. Depois, atualize a versão do documento somente após a aprovação das pessoas responsáveis. Esse procedimento preserva a rastreabilidade das decisões.

Este documento garante que o software será entregue sem problemas?

Não há garantia absoluta, mas uma especificação consistente diminui riscos de retrabalho, atrasos e conflitos de entendimento. O resultado também depende da gestão do projeto, da comunicação entre as partes, dos testes, da qualidade técnica e das condições previstas no contrato aplicável.

Este modelo tem caráter informativo e deve ser adaptado às particularidades do projeto. Para contratos, tratamento de dados pessoais, propriedade intelectual ou situações que envolvam riscos jurídicos relevantes, recomenda-se a orientação de profissional qualificado.