Requisitos funcionais

Quando uma organização decide desenvolver ou contratar um sistema, uma das primeiras perguntas é: o que esse software precisa fazer? A resposta passa diretamente pela definição dos requisitos funcionais, tema recorrente em provas de Engenharia de Software.

Os requisitos funcionais descrevem os serviços, as operações e os comportamentos esperados de um sistema. Eles mostram como o software deverá reagir às entradas recebidas, quais resultados deverá produzir e quais atividades estarão disponíveis para usuários ou outros sistemas.

Em um sistema acadêmico, por exemplo, matricular alunos, lançar notas, calcular médias e emitir históricos são requisitos funcionais. Cada item representa algo que o sistema deverá efetivamente realizar.

Embora o conceito pareça simples, as bancas costumam explorar situações em que requisitos funcionais são confundidos com requisitos não funcionais, regras de negócio, casos de uso, histórias de usuário e critérios de aceitação.

O que são requisitos funcionais?

Requisitos funcionais são declarações dos serviços que o sistema deve oferecer. Eles também podem definir como o sistema deverá reagir a determinadas entradas ou se comportar diante de situações específicas.

Na prática, esses requisitos traduzem necessidades do negócio em comportamentos que poderão ser implementados e testados. É comum que sejam escritos com verbos como cadastrar, consultar, calcular, emitir, validar, bloquear, distribuir, autenticar, alterar e excluir.

Considere um sistema de processo eletrônico. Permitir a assinatura de documentos, distribuir processos entre unidades, controlar prazos e encaminhar expedientes são funcionalidades que deverão ser disponibilizadas pelo sistema.

Nem todo requisito funcional depende de uma ação direta do usuário. O sistema pode executar atividades automáticas, como calcular juros, enviar notificações, atualizar uma situação cadastral ou consultar outro sistema.

Também é possível que um requisito funcional estabeleça aquilo que o software não deverá permitir. Impedir que um usuário sem autorização exclua determinado registro, por exemplo, descreve um comportamento esperado do sistema.

Exemplos de requisitos funcionais

Em um sistema de comércio eletrônico, podemos identificar os seguintes requisitos funcionais:

• O sistema deve permitir que o cliente pesquise produtos por nome ou categoria.
• O sistema deve calcular o valor do frete com base no endereço de entrega.
• O sistema deve permitir a inclusão e a remoção de produtos no carrinho.
• O sistema deve registrar o pagamento após a confirmação da instituição financeira.
• O sistema deve enviar uma mensagem ao cliente quando o pedido for despachado.

Em um sistema de gestão de pessoas, seriam exemplos o cadastro de servidores, a solicitação de férias, a consulta de contracheques, a atualização de dados pessoais e a emissão de relatórios de afastamentos.

Na Administração Pública, um sistema pode receber documentos, autuar processos, controlar prazos, distribuir demandas, registrar manifestações e encaminhar processos entre unidades administrativas.

Em um sistema bancário, consultar saldo, pagar boleto, realizar transferência e bloquear cartão também são requisitos funcionais. Já o tempo máximo permitido para concluir uma transferência está relacionado ao desempenho do sistema e, em regra, é classificado como requisito não funcional.

Requisitos funcionais e não funcionais

A distinção mais conhecida afirma que os requisitos funcionais descrevem o que o sistema deve fazer, enquanto os requisitos não funcionais estabelecem restrições ou características relacionadas à forma como o sistema deverá funcionar.

Essa explicação é útil para concursos, mas deve ser aplicada com atenção. O candidato precisa identificar qual aspecto do sistema está sendo enfatizado pelo enunciado.

Desempenho, disponibilidade, segurança, confiabilidade, portabilidade, acessibilidade e usabilidade são exemplos tradicionais de requisitos não funcionais.

Observe a diferença entre duas especificações. “O sistema deve permitir a autenticação do usuário” descreve uma função. “O sistema deve bloquear o acesso após cinco tentativas consecutivas com senha incorreta” detalha uma reação do sistema e também pode ser tratado como requisito funcional associado à autenticação.

Por outro lado, a exigência de que as senhas sejam armazenadas por meio de algoritmo criptográfico adequado estabelece uma condição de segurança. Nesse caso, estamos diante de um requisito não funcional.

A classificação depende do aspecto destacado. Segurança, por exemplo, pode dar origem a funções específicas e a restrições de qualidade. Por isso, a análise do enunciado deve prevalecer sobre a simples procura de palavras-chave.

Requisitos funcionais e regras de negócio

Uma regra de negócio expressa uma política, condição ou restrição pertencente ao domínio da organização. Em muitos casos, ela continuaria existindo mesmo que o sistema informatizado fosse substituído.

Considere a seguinte regra: servidores somente podem marcar férias depois de completar o período aquisitivo. Essa determinação pertence ao negócio e não ao software.

Para aplicar essa regra, pode ser criado o seguinte requisito funcional: antes de confirmar a solicitação de férias, o sistema deve verificar se o servidor completou o período aquisitivo.

Outro exemplo seria a regra segundo a qual compras acima de determinado valor precisam da aprovação de um gerente. O requisito funcional poderá determinar que o sistema encaminhe automaticamente essas compras para aprovação.

A regra de negócio apresenta a lógica que deve ser respeitada. O requisito funcional descreve o comportamento que o sistema deverá executar para apoiar ou aplicar essa lógica.

Como escrever um requisito funcional?

Um requisito bem escrito precisa ser claro, necessário, consistente, viável, rastreável e verificável. Desenvolvedores, usuários e testadores devem chegar a uma interpretação semelhante sobre aquilo que será entregue.

Uma estrutura bastante utilizada começa com a expressão “O sistema deve”, seguida de um verbo e da descrição da funcionalidade:

O sistema deve permitir que o candidato consulte a situação de sua inscrição utilizando o CPF e a senha cadastrada.

Quando houver condições relevantes, elas também deverão ser informadas:

Quando o pagamento for confirmado pela instituição financeira, o sistema deve alterar a situação da inscrição para “Confirmada” e enviar uma mensagem ao candidato.

Expressões como “rapidamente”, “quando possível”, “de maneira adequada” ou “com uma interface amigável” devem ser evitadas. Elas permitem interpretações diferentes e dificultam a verificação do requisito.

Outro problema frequente é colocar diversas funcionalidades independentes em uma única frase. Separar os comportamentos facilita a estimativa, a implementação, a priorização, a rastreabilidade e a elaboração dos testes.

Como transformar um requisito vago em um requisito testável?

Considere a seguinte especificação:

O sistema deve emitir relatórios rapidamente.

Não está claro qual relatório deverá ser gerado, quem poderá solicitá-lo, quais informações serão apresentadas ou qual tempo será considerado rápido.

Uma redação mais precisa seria:

O sistema deve permitir que usuários com perfil de gestor emitam o relatório mensal de despesas em formato PDF, contendo unidade administrativa, categoria da despesa, valor e período de referência.

O desempenho pode ser especificado separadamente:

O relatório mensal de despesas deve ser gerado em até cinco segundos para consultas que envolvam até 100 mil registros.

Com essa separação, a equipe consegue verificar a existência da funcionalidade e medir o atendimento ao requisito de desempenho.

Elicitação de requisitos funcionais

A elicitação é o processo de identificar necessidades, expectativas, limitações e problemas apresentados pelas partes interessadas. Não consiste apenas em perguntar ao usuário quais telas ele deseja.

Entrevistas, questionários, oficinas, observação, análise documental, brainstorming, prototipação, grupos focais e análise de sistemas existentes estão entre as técnicas que podem ser utilizadas.

A observação é especialmente útil quando parte do trabalho realizado pelos usuários não está formalmente documentada. Ao acompanhar a rotina, o analista pode descobrir exceções, atalhos e regras que dificilmente apareceriam em uma entrevista.

A prototipação também contribui para a descoberta e a validação de requisitos. Ao visualizar uma representação da solução, o usuário consegue perceber campos ausentes, etapas desnecessárias ou comportamentos incompatíveis com seu trabalho.

Durante a elicitação, o analista deve compreender o problema antes de propor uma solução. Perguntar apenas qual tela o usuário deseja pode levar à informatização de um processo ineficiente.

Uma boa investigação identifica atores, eventos, entradas, saídas, permissões, regras de negócio, integrações, exceções e resultados esperados.

Documentação dos requisitos

Os requisitos funcionais podem ser registrados em documentos de especificação, casos de uso, histórias de usuário, modelos de processos, protótipos ou ferramentas de gestão do produto.

Em abordagens tradicionais, é comum que a especificação seja produzida com maior detalhamento antes da implementação. Nos métodos ágeis, o refinamento pode ocorrer progressivamente, de acordo com a prioridade das funcionalidades.

Isso não significa que os métodos ágeis dispensem documentação. A equipe continua precisando registrar regras, critérios de aceitação, decisões, integrações e outras informações necessárias ao desenvolvimento.

O nível de detalhamento deve considerar a complexidade e o risco do projeto. Um sistema sujeito a exigências legais ou integrado a diversos órgãos costuma exigir uma documentação mais rigorosa.

Requisitos funcionais e casos de uso

O requisito funcional declara uma capacidade que deverá ser oferecida pelo sistema. O caso de uso descreve a interação entre um ator e o sistema para alcançar determinado objetivo.

Um requisito pode estabelecer que o sistema permita a recuperação da senha. O caso de uso correspondente poderá detalhar o ator, as condições iniciais, o fluxo principal, as exceções e o resultado da operação.

Portanto, requisito funcional e caso de uso não são sinônimos. O caso de uso é uma técnica utilizada para representar e detalhar determinados requisitos.

Um caso de uso pode estar relacionado a vários requisitos funcionais. Da mesma forma, algumas funções automáticas do sistema podem não ser adequadamente representadas apenas por meio da interação de um ator.

Requisitos funcionais e histórias de usuário

A história de usuário apresenta uma necessidade a partir da perspectiva de quem receberá valor. É comum utilizar a seguinte estrutura:

Como gestor, quero consultar as despesas mensais por unidade para acompanhar a execução orçamentária.

A história comunica a necessidade e sua finalidade, mas não costuma apresentar todos os detalhes necessários para o desenvolvimento. Ela precisa ser complementada por conversas, regras de negócio, exemplos e critérios de aceitação.

O requisito funcional correspondente poderia ser escrito da seguinte maneira:

O sistema deve permitir que o gestor consulte as despesas mensais agrupadas por unidade administrativa.

Histórias de usuário e requisitos funcionais podem ser empregados conjuntamente. A história evidencia quem precisa da funcionalidade e qual valor será obtido, enquanto os requisitos e critérios de aceitação detalham os comportamentos esperados.

Critérios de aceitação

Os critérios de aceitação indicam as condições que deverão ser atendidas para que uma funcionalidade seja considerada correta e aceita.

Na consulta de despesas, os critérios podem determinar que apenas gestores tenham acesso, que o período seja obrigatório, que os resultados sejam agrupados por unidade e que o relatório possa ser exportado em PDF.

Uma forma conhecida de registrar esses critérios utiliza a estrutura “Dado que, quando, então”:

Dado que o usuário possui perfil de gestor, quando informar um período válido e solicitar a consulta, então o sistema deve apresentar as despesas agrupadas por unidade administrativa.

Os critérios de aceitação reduzem interpretações divergentes. Além de orientar o desenvolvimento, servem como referência para validação e testes.

Verificação e validação dos requisitos

A verificação procura determinar se os requisitos foram documentados corretamente. Nesse momento, são avaliados aspectos como clareza, consistência, completude e ausência de ambiguidades.

A validação procura confirmar se os requisitos representam as necessidades reais das partes interessadas. Um documento pode estar tecnicamente bem escrito e, ainda assim, descrever uma solução que não resolve o problema do usuário.

Uma forma conhecida de memorizar a diferença é associar a verificação à pergunta “estamos construindo corretamente o produto?” e a validação à pergunta “estamos construindo o produto correto?”.

Revisões, inspeções, protótipos, simulações e elaboração antecipada de testes podem revelar conflitos, omissões e interpretações diferentes.

Rastreabilidade dos requisitos

A rastreabilidade permite acompanhar as relações entre um requisito e sua origem, suas regras de negócio, seus componentes, seus testes e as entregas produzidas.

A rastreabilidade para trás identifica de onde o requisito surgiu e por que ele existe. A rastreabilidade para frente mostra quais elementos da solução foram criados para atendê-lo.

Quando um requisito é alterado, essas relações apoiam a análise de impacto. A equipe pode identificar quais documentos, funcionalidades, integrações e testes deverão ser revistos.

Uma matriz de rastreabilidade pode relacionar requisitos, casos de uso, histórias de usuário, componentes e casos de teste. Esse mecanismo é particularmente importante em projetos sujeitos a auditorias ou controles regulatórios.

Problemas frequentes na especificação

A ambiguidade é um dos defeitos mais comuns. Termos como “rápido”, “adequado”, “simples” e “preferencialmente” podem assumir significados diferentes para usuários, desenvolvedores e testadores.

A incompletude também merece atenção. O requisito descreve o fluxo principal, mas não informa o que deverá acontecer quando os dados forem inválidos, o usuário não possuir autorização ou o serviço externo estiver indisponível.

Outro problema ocorre quando dois requisitos estabelecem comportamentos incompatíveis. Uma área pode solicitar a exclusão imediata de determinados registros, enquanto outra exige que eles sejam preservados durante vários anos.

As mudanças também precisam ser controladas. Novas solicitações devem ser analisadas, priorizadas e submetidas ao processo de gerenciamento de requisitos, evitando o crescimento desordenado do escopo.

Como os requisitos funcionais são cobrados em concursos?

As bancas cobram com frequência a diferença entre requisitos funcionais e não funcionais. Em muitos casos, apresentam exemplos e solicitam que o candidato realize a classificação.

Outra abordagem recorrente envolve os atributos de um bom requisito, como consistência, completude, rastreabilidade, viabilidade e verificabilidade.

Também aparecem questões sobre elicitação, análise, especificação, validação, gerenciamento de mudanças, casos de uso, histórias de usuário e critérios de aceitação.

Uma pegadinha comum é classificar automaticamente desempenho e segurança como requisitos funcionais apenas porque dependem de recursos implementados no software. Quando expressam atributos de qualidade ou restrições, esses elementos são normalmente não funcionais.

A prova também pode afirmar que os requisitos funcionais descrevem apenas ações iniciadas pelo usuário. A afirmação está errada, pois cálculos, notificações, validações e integrações automáticas também podem representar comportamentos funcionais.

Algumas questões comentadas

Questão 1 — CEBRASPE — FUB — Técnico de Tecnologia da Informação

Com relação a requisitos de software, julgue o item a seguir.

Os requisitos associados a um sistema para que ele reaja ao receber dados nulos são denominados requisitos funcionais.

Gabarito: CERTO.

Comentário: o item descreve como o sistema deverá reagir diante de uma entrada específica: o recebimento de dados nulos. Essa reação corresponde a um comportamento do sistema e, portanto, caracteriza um requisito funcional.

Questão 2 — VUNESP — SAEG — Analista de Tecnologia da Informação

A especificação de requisitos constitui-se em uma importante atividade no escopo da engenharia de software. Dessa forma, é correto afirmar que requisitos

a) não funcionais devem descrever como o sistema deve ser comportar em situações particulares.

b) não funcionais devem ser explícitos em determinadas ações que o sistema não deva executar.

c) funcionais devem descrever restrições ou limitações de tempo impostas ao sistema.

d) funcionais devem atender a restrições impostas por normas e procedimentos.

e) funcionais devem conter, dentre outros aspectos, como o sistema alvo deve reagir a determinados tipos de entradas.

Gabarito: E.

Comentário: os requisitos funcionais podem especificar como o sistema deverá reagir ao receber determinados dados ou entradas. Isso faz parte da descrição dos serviços e comportamentos esperados do software.

As limitações de tempo mencionadas na alternativa C são requisitos não funcionais de desempenho. As restrições decorrentes de normas e procedimentos, apresentadas na alternativa D, estão normalmente associadas aos requisitos não funcionais externos.

Questão 3 — CEBRASPE — PGDF — Técnico Jurídico: Área Tecnologia e Informação

Os requisitos não funcionais para o desenvolvimento de sistemas estabelecem padrões a respeito de como o sistema deve se comportar, e os requisitos funcionais definem o que o sistema deve fazer.

Gabarito: CERTO.

Comentário: os requisitos funcionais descrevem os serviços e comportamentos que o sistema deverá oferecer. Em outras palavras, indicam aquilo que o software fará.

Os requisitos não funcionais estabelecem restrições e atributos de qualidade, como desempenho, segurança, disponibilidade, confiabilidade e usabilidade.

Questão 4 — CEBRASPE — DATAPREV — 2023 — Analista de Tecnologia da Informação

Julgue o item a seguir, que tratam de engenharia de requisitos, CSS, PWA e HTTPS.

Os requisitos funcionais de um software descrevem o que o software deve fazer, considerando critérios de desempenho das funcionalidades.

Gabarito: ERRADO.

Comentário: a primeira parte está correta, pois os requisitos funcionais descrevem o que o software deverá fazer. O erro está em incluir os critérios de desempenho nessa definição.

Tempo de resposta, capacidade de carga, escalabilidade e eficiência são normalmente tratados como requisitos não funcionais de desempenho.

Questão 5 — CEBRASPE — DATAPREV — 2023

No que se refere à engenharia de requisitos, julgue o item a seguir.

Os requisitos de usuário de um sistema devem descrever os requisitos funcionais, de modo que eles sejam compreensíveis pelos usuários do sistema que não possuem conhecimento técnico detalhado, abstendo-se de inserir requisitos não funcionais.

Gabarito: ERRADO.

Comentário: os requisitos de usuário podem apresentar tanto requisitos funcionais quanto requisitos não funcionais. Sua redação deve ser compreensível para clientes, usuários e outras partes interessadas que não possuem conhecimentos técnicos detalhados.

O erro está em afirmar que os requisitos de usuário devem se abster de apresentar requisitos não funcionais.

FAQ — Requisitos funcionais

1. O que são requisitos funcionais?

São declarações dos serviços, das operações e dos comportamentos que um sistema deverá oferecer aos usuários ou executar automaticamente.

2. Qual é a diferença entre requisitos funcionais e não funcionais?

Os requisitos funcionais descrevem o que o sistema deverá fazer. Os requisitos não funcionais estabelecem restrições ou atributos de qualidade, como desempenho, segurança, disponibilidade e usabilidade.

3. Quais são exemplos de requisitos funcionais?

Cadastrar usuário, consultar processo, calcular multa, emitir relatório, autenticar usuário, registrar pagamento e enviar notificações são exemplos comuns.

4. Como escrever um requisito funcional?

O requisito deve apresentar uma função clara, normalmente utilizando a estrutura “O sistema deve”, seguida da ação, das condições relevantes e do resultado esperado.

5. Como transformar um requisito vago em um requisito testável?

É necessário substituir termos subjetivos por critérios objetivos, identificar quem utilizará a função, definir as entradas e indicar claramente o resultado esperado.

6. Qual é a diferença entre requisito funcional e regra de negócio?

A regra de negócio representa uma política ou condição pertencente ao domínio da organização. O requisito funcional descreve como o sistema deverá agir para executar ou apoiar essa regra.

7. Qual é a diferença entre requisito funcional, caso de uso e história de usuário?

O requisito funcional declara uma capacidade do sistema. O caso de uso detalha a interação entre um ator e o sistema. A história de usuário apresenta uma necessidade sob a perspectiva de quem receberá valor.

8. Como os requisitos funcionais são cobrados em concursos públicos?

As provas cobram principalmente a classificação dos requisitos, a diferença entre requisitos funcionais e não funcionais, as etapas da Engenharia de Requisitos, a rastreabilidade, os casos de uso, as histórias de usuário e os critérios de aceitação.

Imagem ilustrativa sobre requisitos funcionais

Referências bibliográficas

AGILE ALLIANCE. User stories. Disponível em: https://agilealliance.org/glossary/user-stories/.  A referência diferencia histórias de usuário, casos de uso e critérios de aceitação. 

IEEE COMPUTER SOCIETY. Guide to the Software Engineering Body of Knowledge — SWEBOK Guide: version 4.0a. Los Alamitos: IEEE Computer Society, 2025. Disponível em: https://www.computer.org/education/bodies-of-knowledge/software-engineering/v4. 

INTERNATIONAL INSTITUTE OF BUSINESS ANALYSIS. A Guide to the Business Analysis Body of Knowledge — BABOK Guide. Versão 3. Toronto: IIBA, 2015. Disponível em: https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/. 

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION; INTERNATIONAL ELECTROTECHNICAL COMMISSION; INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS. ISO/IEC/IEEE 29148:2018: Systems and software engineering — Life cycle processes — Requirements engineering. Genebra: ISO, 2018. Disponível em: https://www.iso.org/standard/72089.html.  Requirements engineering

PRESSMAN, Roger S.; MAXIM, Bruce R. Software engineering: a practitioner’s approach. 9. ed. New York: McGraw-Hill Education, 2019. mheducation.com

SOMMERVILLE, Ian. Software engineering. 10. ed. Boston: Pearson, 2015. pearson.com