Modelo de Documento de Requisitos de Software para Imprimir

O documento de requisitos de software é o registro organizado das necessidades que um sistema deve atender. Ele transforma uma ideia, uma demanda de negócio ou um problema operacional em informações claras para clientes, gestores, analistas, designers, desenvolvedores e equipes de testes. Ao imprimir e preencher esse documento, a organização cria uma referência formal para o planejamento, a construção, a validação e a entrega do projeto.

Na prática, o documento descreve o objetivo do software, quem o utilizará, quais funcionalidades serão disponibilizadas, quais regras precisam ser respeitadas e quais características de qualidade são esperadas. Também pode indicar integrações, restrições técnicas, critérios de aceite e responsáveis pela aprovação. Essa organização reduz interpretações divergentes, mudanças sem controle e retrabalho durante o desenvolvimento.

O modelo abaixo pode ser usado como uma especificação inicial de requisitos, inclusive em projetos de aplicativos, sites, sistemas internos, plataformas de atendimento, automações e produtos digitais. Ele deve ser adaptado ao porte e à complexidade da solução. Projetos maiores podem exigir documentos complementares, como protótipos, diagramas, plano de testes, matriz de riscos e termo de abertura do projeto.

Quando usar o documento de requisitos de software

Utilize este documento antes de iniciar o desenvolvimento ou sempre que houver uma alteração relevante no escopo de um sistema. O ideal é que os requisitos sejam levantados em reunião com as pessoas que conhecem a necessidade do negócio e, depois, revisados por quem será responsável pela execução técnica.

• Na contratação de uma empresa ou profissional para desenvolver um sistema, aplicativo ou site.
• Na organização de demandas para uma equipe interna de tecnologia.
• Na modernização, correção ou ampliação de um software já existente.
• Na definição de funcionalidades de um produto digital que ainda está em fase de ideia.
• Na preparação de uma proposta comercial, cronograma ou orçamento de desenvolvimento.
• Na validação de entregas, pois os requisitos podem se transformar em critérios de aceite.
• Na documentação de regras internas que precisam ser preservadas, mesmo quando houver troca de equipe ou fornecedor.

É recomendável atribuir um código a cada requisito, como RF-01 para requisito funcional e RNF-01 para requisito não funcional. Dessa forma, cada item poderá ser discutido, priorizado, desenvolvido e testado com mais facilidade. Requisitos bem escritos devem ser objetivos, verificáveis e compreensíveis para todas as partes envolvidas.

Modelo completo de documento de requisitos de software

DOCUMENTO DE REQUISITOS DE SOFTWARE

1. IDENTIFICAÇÃO DO PROJETO
Nome do projeto: [NOME DO PROJETO]
Nome do sistema: [NOME DO SISTEMA]
Versão do documento: [VERSÃO]
Data de elaboração: [DATA]
Solicitante/área demandante: [NOME DA EMPRESA OU SETOR]
Responsável pelo levantamento: [NOME COMPLETO E CARGO]
Responsável pela aprovação: [NOME COMPLETO E CARGO]

2. OBJETIVO DO DOCUMENTO
Este documento tem por objetivo registrar os requisitos para o desenvolvimento ou a evolução do sistema [NOME DO SISTEMA], destinado a [PÚBLICO OU ÁREA USUÁRIA]. A solução deverá atender à seguinte necessidade: [DESCREVER O PROBLEMA, A OPORTUNIDADE OU A FINALIDADE DO SOFTWARE].

3. ESCOPO DO PROJETO
O sistema deverá abranger: [DESCREVER PROCESSOS, MÓDULOS, FUNCIONALIDADES OU SERVIÇOS INCLUÍDOS].
Ficam fora do escopo desta etapa: [DESCREVER ITENS, MÓDULOS OU SERVIÇOS NÃO INCLUÍDOS].

4. PERFIS DE USUÁRIOS
Perfil 1: [NOME DO PERFIL] — Permissões e responsabilidades: [DESCREVER].
Perfil 2: [NOME DO PERFIL] — Permissões e responsabilidades: [DESCREVER].
Perfil 3: [NOME DO PERFIL] — Permissões e responsabilidades: [DESCREVER].

5. REQUISITOS FUNCIONAIS
RF-01 — [NOME DO REQUISITO]
Descrição: O sistema deverá [DESCREVER A FUNÇÃO QUE O SISTEMA DEVE EXECUTAR].
Usuário responsável: [PERFIL DE USUÁRIO].
Prioridade: [ALTA/MÉDIA/BAIXA].
Critério de aceite: [DESCREVER COMO SERÁ CONFIRMADO QUE O REQUISITO FOI ATENDIDO].

RF-02 — [NOME DO REQUISITO]
Descrição: O sistema deverá [DESCREVER A FUNÇÃO].
Usuário responsável: [PERFIL DE USUÁRIO].
Prioridade: [ALTA/MÉDIA/BAIXA].
Critério de aceite: [DESCREVER A VALIDAÇÃO].

RF-03 — [NOME DO REQUISITO]
Descrição: O sistema deverá [DESCREVER A FUNÇÃO].
Usuário responsável: [PERFIL DE USUÁRIO].
Prioridade: [ALTA/MÉDIA/BAIXA].
Critério de aceite: [DESCREVER A VALIDAÇÃO].

6. REGRAS DE NEGÓCIO
RN-01 — [NOME DA REGRA]
Regra: [DESCREVER A CONDIÇÃO, O CÁLCULO, A VALIDAÇÃO OU O PROCEDIMENTO QUE DEVE SER OBRIGATORIAMENTE RESPEITADO].
RN-02 — [NOME DA REGRA]
Regra: [DESCREVER].

7. REQUISITOS NÃO FUNCIONAIS
Desempenho: [INFORMAR TEMPO DE RESPOSTA, QUANTIDADE ESTIMADA DE ACESSOS OU OUTRO PARÂMETRO].
Segurança: [INFORMAR AUTENTICAÇÃO, NÍVEIS DE ACESSO, REGISTRO DE LOGS, CRIPTOGRAFIA OU OUTRAS MEDIDAS].
Disponibilidade: [INFORMAR HORÁRIOS, ÍNDICE ESPERADO OU NECESSIDADE DE ACESSO CONTÍNUO].
Compatibilidade: [INFORMAR NAVEGADORES, SISTEMAS OPERACIONAIS, DISPOSITIVOS OU VERSÕES SUPORTADAS].
Acessibilidade: [INFORMAR REQUISITOS DE ACESSIBILIDADE APLICÁVEIS].
Backup e recuperação: [INFORMAR FREQUÊNCIA, PRAZO DE GUARDA E PROCEDIMENTO ESPERADO].

8. DADOS PESSOAIS E PRIVACIDADE
Dados pessoais tratados pelo sistema: [LISTAR DADOS].
Finalidade do tratamento: [DESCREVER].
Base legal e responsáveis internos: [DESCREVER, QUANDO APLICÁVEL].
Medidas de segurança e retenção: [DESCREVER].
O tratamento de dados pessoais deverá observar a Lei nº 13.709/2018 (Lei Geral de Proteção de Dados Pessoais — LGPD), quando aplicável.

9. INTEGRAÇÕES E DEPENDÊNCIAS
Integração 1: [NOME DO SISTEMA, API, SERVIÇO OU FORNECEDOR]. Finalidade: [DESCREVER].
Integração 2: [NOME DO SISTEMA, API, SERVIÇO OU FORNECEDOR]. Finalidade: [DESCREVER].
Dependências, premissas e recursos necessários: [DESCREVER].

10. RESTRIÇÕES DO PROJETO
Prazo previsto: [DATA OU PERÍODO].
Orçamento ou limite de recursos: [INFORMAR, SE HOUVER].
Tecnologias obrigatórias ou vedadas: [DESCREVER].
Outras restrições: [DESCREVER].

11. CRITÉRIOS GERAIS DE ACEITE
O sistema será considerado apto para entrega quando: [LISTAR CONDIÇÕES DE HOMOLOGAÇÃO, TESTES, APROVAÇÕES, TREINAMENTO, DOCUMENTAÇÃO E CORREÇÕES NECESSÁRIAS].

12. APROVAÇÃO
Declaro que li, compreendi e aprovo os requisitos descritos neste documento, ciente de que alterações posteriores deverão ser registradas e avaliadas quanto a prazo, custo e impacto técnico.

[CIDADE], [DATA].

________________________________________
[NOME DO SOLICITANTE OU RESPONSÁVEL PELA APROVAÇÃO]
[CARGO]
[EMPRESA OU ÓRGÃO]

________________________________________
[NOME DO RESPONSÁVEL TÉCNICO OU FORNECEDOR]
[CARGO OU EMPRESA]

Como preencher o documento passo a passo

1. Identifique o projeto. Informe um nome que permita localizar o documento depois, registre a versão e indique quem solicitou, elaborou e aprovou o conteúdo. Sempre atualize a versão quando houver mudança relevante.
2. Descreva o objetivo sem entrar em solução técnica cedo demais. Explique qual problema o sistema resolverá e para quem. Em vez de escrever apenas “criar um aplicativo”, prefira indicar o resultado esperado, como “permitir o agendamento de atendimentos pelos clientes”.
3. Delimite o escopo. Liste o que será entregue nesta fase e o que não será entregue. Essa separação é essencial para evitar a inclusão informal de novas funções ao longo do trabalho.
4. Defina os usuários. Indique cada perfil de acesso, como administrador, atendente, cliente ou gestor, e descreva suas permissões. Não basta dizer que haverá login: é necessário esclarecer quem pode visualizar, cadastrar, alterar, excluir ou aprovar informações.
5. Registre os requisitos funcionais. Cada requisito deve representar uma ação ou capacidade do sistema. Use frases como “O sistema deverá permitir...” e acrescente um critério de aceite que possa ser testado de maneira objetiva.
6. Inclua regras e requisitos não funcionais. As regras de negócio tratam das condições do processo, enquanto os requisitos não funcionais tratam de qualidade, desempenho, segurança, disponibilidade e compatibilidade. Ambos são importantes para que a solução funcione adequadamente no uso real.
7. Revise privacidade e integrações. Se o sistema tratar dados pessoais, avalie a aplicação da LGPD e registre medidas necessárias. Também descreva sistemas externos, APIs, gateways de pagamento, serviços de e-mail ou outras dependências.
8. Formalize a aprovação. Revise o texto com as partes interessadas antes da assinatura. Guarde o documento assinado, físico ou eletronicamente, junto com eventuais anexos e registros de alteração.

Perguntas comuns

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

O requisito funcional descreve o que o sistema faz, como cadastrar usuários, emitir relatórios ou enviar notificações. O requisito não funcional define como a solução deve se comportar, por exemplo, tempo de resposta, segurança, disponibilidade, compatibilidade com dispositivos e acessibilidade.

O documento de requisitos substitui um contrato de desenvolvimento?

Não necessariamente. O documento de requisitos detalha o objeto técnico e pode ser um anexo importante do contrato, mas não substitui cláusulas contratuais sobre preço, prazo, propriedade intelectual, confidencialidade, responsabilidades, suporte, rescisão e penalidades. Em uma contratação, o ideal é que ambos sejam coerentes entre si.

É obrigatório assinar o documento?

A assinatura não é uma exigência universal para que a documentação seja útil, mas é altamente recomendável quando há relação entre cliente e fornecedor ou necessidade de governança interna. A aprovação registrada demonstra que as partes tiveram acesso ao escopo e concordaram com a referência utilizada para o projeto.

Como registrar uma mudança de requisito?

Evite alterar o texto sem controle. Crie uma nova versão, informe a data, descreva o requisito modificado, o motivo da mudança e os impactos em prazo, custo, segurança e demais funcionalidades. Depois, obtenha a aprovação das pessoas responsáveis antes de implementar a alteração.

Esse modelo serve para projetos pequenos?

Sim. Em projetos simples, é possível preencher apenas os campos essenciais, como objetivo, escopo, usuários, funcionalidades, critérios de aceite e aprovação. Mesmo uma documentação breve é preferível a decisões baseadas apenas em mensagens dispersas ou conversas informais.

Este modelo tem caráter exclusivamente informativo e deve ser adaptado às particularidades técnicas, comerciais e legais de cada projeto. Para contratos, tratamento de dados pessoais, propriedade intelectual ou situações que envolvam riscos específicos, recomenda-se a orientação de profissionais qualificados.