O que são requisitos funcionais e não funcionais?

Entenda o que são requisitos de software, a diferença entre requisito funcional e não funcional, e como identificar e documentar cada um deles.

Os requisitos de sistema ou software são as características e comportamentos esperados de um sistema, e são classificados em dois principais tipos: requisitos funcionais e requisitos não funcionais. Mas você sabe qual a diferença entre os dois? Entenda como é feita uma boa documentação dos requisitos e funcionalidades de um software.

Resposta Rápida

Requisitos funcionais definem o que um sistema deve fazer, como ações e funcionalidades específicas. Requisitos não funcionais determinam como o sistema deve operar, focando em atributos de qualidade, desempenho e restrições. A distinção é crucial: enquanto os funcionais descrevem comportamentos, os não funcionais estabelecem critérios mensuráveis e verificáveis. Exemplos incluem “O sistema deve processar dados em menos de 2 segundos” ou “Deve ser compatível com navegadores modernos”. A documentação precisa garantir clareza e viabilidade técnica para evitar falhas críticas no desenvolvimento.

Direto ao ponto, sem perda de tempo! Resumo descritivo, conceitual e com aquilo que é mais relevante no artigo.

O que são requisitos funcionais e não funcionais?

De forma muito simplista, podemos considerar que um requisitos de software é toda abstração de um recurso, funcionalidade ou resultado esperado de um sistema.

O levantamento de requisitos é responsável por identificar todas as necessidades, manter a documentação de requisitos do software, e especificar os requisitos através de funcionalidades, comportamentos e características necessárias para atender tais solicitações.

A documentação dos requisitos pode ser feita através do uso de um software especializado, que possibilite a documentação detalhada, o gerenciamento dos requisitos e a manutenção de uma matriz de rastreabilidade.

É mais comum porém, que a especificação dos requisitos e o detalhamento dos casos de uso envolvidos seja feito utilizando um documento padrão, desenvolvido internamente pela organização ou equipe de projeto.

Elaboramos um template de exemplo de um documento de especificação de requisitos, que pode ser descarregado através do link.

É válido ressaltar, este exemplo deve ser analisado e adaptado conforme as necessidades e características do ambiente e do projeto no qual será utilizado.

Tipos e classificação de requisitos

A jornada entre uma necessidade ou ideia de negócio e uma solução real e viável depende da sincronia e assertividade das áreas envolvidas em em todas as fases do projeto, entretanto talvez nenhuma delas seja tão comprometedora quanto a análise de requisitos

O levantamento de requisitos de sistema é responsável por identificar, individualizar e detalhar os comportamentos, resultados esperados e objetivos de negócio que devem ser cumpridos pelo software ou sistema.

Falhas durante a análise de requisitos podem ser catastróficas para o projeto, uma vez que um requisito de sistema mal interpretado ou negligenciado irá repercutir ao longo de toda a cadeia de desenvolvimento do projeto.

Requisitos de negócios

Atualmente é normal que os requisitos de negócio sejam chamados de regras de negócio, trata-se apenas de uma convenção extraoficial que acabou ganhando popularidade, ambas estão corretas e possuem o mesmo significado.

As regras de negócio incluem em sua maioria demandas de alto nível. Por exemplo, são regras de negócio os processos de negócio e resultados esperados em determinada condição.

Requisitos de usuário

Os requisitos provenientes dos stakeholders primários são a fonte mais importante de informações para o entendimento das necessidades reais do cliente.

É fundamental que além de competência e conhecimento técnico da engenharia de software, o analista que seja um exímio ouvinte e saiba em cada ocasião qual a melhor maneira de extrair as verdadeiras “dores” dos stakeholders do projeto.

Requisitos sistema ou de solução

Essa categoria de requisitos caracteriza-se por descrever as características do produto que atenderão às suas expectativas e necessidades de negócios.

Os requisitos de solução são divididos em dois tipos

  • Requisitos funcionais descrevem as maneiras como um produto deve se comportar.
  • Requisitos não funcionais, também conhecidos como atributos de qualidade, descrevem as características gerais do software.

Agora que você já sabe o que são requisitos de software e quais são as melhores técnicas para levantá-los, precisamos esclarecer que existem dois tipos de requisitos: “Requisitos Funcionais” e “Requisitos Não Funcionais”.

Estrutura de organização da análise durante o processo de levantamento e análise de requisitos.
Estrutura de organização da análise durante o processo de levantamento e análise de requisitos.
Estrutura dos requisitos existentes durante o processo de análise de requisitos: A base da pirâmide é composta pelos requisitos de sistema (requisito funcional e requisito não funcional) que atendem aos requisitos do usuário para só assim atingir a solução proposta na regra ne negócio.

Ambos os tipos expressam em grande linha uma necessidade, característica ou funcionalidade de um software, porém em dois universos diferentes. Vamos entender melhor a diferença entre um requisito funcional e um requisito não funcional.

O que é Requisito Funcional?

Requisitos funcionais são todas as necessidades, características ou funcionalidades esperadas em um processo que podem ser atendidos pelo software.

De forma geral, um requisito funcional expressa uma ação que deve ser realizada através do sistema, ou seja, um requisito funcional é “o que sistema DEVE fazer“.

Tabela para entender o que é um requisito funcional, itens classificatórios.
Tabela para entender o que é um requisito funcional. Característica, funcionalidade, necessidade e solicitação são os itens que configuram um requisito funcional.
Um clássico e simples exemplo de requisito funcional é a funcionalidade “MANTER USUÁRIO” (o verbo “manter” é utilizado na documentação de software para referir-se à uma funcionalidade de cadastro, que contempla a inclusão de um novo item, a alteração de um item, a exclusão de um item além de da leitura de suas informações).

O requisito que detalha a funcionalidade “MANTER USUÁRIO” engloba uma série de outros requisitos menores, por vezes chamados de “features“, como no exemplo abaixo:

  1. Manter usuário
    1. Cadastrar novo usuário
    2. Alterar usuário
    3. Excluir usuário
    4. Consultar usuário

O requisito principal de negócio “manter usuário” é responsável por toda a manutenção do cadastro usuários, por isso a utilização do verbo “manter“.

Dentro desta funcionalidade macro, são incluídas as funcionalidades de cadastro de usuário, alteração de usuário e deleção de usuário. Esses três requisitos são requisitos não funcionais, e compõem o requisito principal de manutenção de usuário.

Características de um requisito funcional?

Mas afinal, por que eles são chamados de requisitos funcionais? A categorização dos requisitos citados como requisitos funcionais se deve ao fato de que todos eles são funcionalidades atendidas através de uma ação do software ou comportamento específico do sistema.

Podemos dizer que é considerado um requisito funcional, todo cenário onde o usuário informa um dado, ou um sistema terceiro realiza uma solicitação qualquer durante uma interação com o sistema, que então, responde com determinada ação correspondente.

Ainda como requisitos funcionais, podemos citar algumas funcionalidades muito comuns durante o processo de análise e levantamento de requisitos em um projeto de software.

Esses cinco requisitos que citamos acima são muito comuns em sistemas de controle financeiro, fiscal ou contábil. Todos eles representam uma funcionalidade que o sistema deve executar em decorrência de uma solicitação ou ação do usuário, assim podemos facilmente identificá-los como requisitos funcionais.

Devemos porém lembrar, de que um requisito funcional pode também ser executado como sequência da execução de um requisito anterior, que incluí tal requisito em sua execução.

Quando o sistema executa um requisito funcional?

Para ficar claro esta característica dos requisitos funcionais basta pegar como exemplo o caso de um sistema de vendas online.

Imagine que um sistema possua um requisito chamado “FECHAR VENDA”, durante sua execução ele inclui outros dois requisitos funcionais – ou features: “EMITIR NF-C” e “ATUALIZAR ESTOQUE”.

Requisitos de software estão diretamente ligados e relacionados com as regras de negócio. Existem dois tipos de requisitos de software: os requisito funcionais e os requisitos não funcionais.
Requisitos de software estão diretamente ligados e relacionados com as regras de negócio. Existem dois tipos de requisitos de software: os requisito funcionais e os requisitos não funcionais.
A inclusão dos requisitos “emitir nf-c” e “atualizar estoque” significa que durante o a finalização processo (ou execução, segundo as características do requisito) descrito pelo requisito funcional “FECHAR VENDA”.

É obrigatória, ou seja, ao executar o “fechar venda”, o próprio sistema solicita a execução do “emitir nfc-e” e “atualizar estoque”. Este relacionamento entre requisitos é chamado de inclusão – include, em inglês, e é muito comum em diagramas de caso de uso UML.

Requisitos funcionais X Requisitos não funcionais

Os requisitos funcionais por definição, e conforme explicamos, é uma característica, funcionalidade ou necessidade que o sistema deve contemplar, ou seja, um requisito funcional é, ‘tudo aquilo que o sistema “DEVE FAZER”.

Principais tipos de requisitos não funcionais: desempenho, segurança, disponibilidade, interoperabilidade.
Principais tipos de requisitos não funcionais: desempenho, segurança, disponibilidade, interoperabilidade.

Já um requisito NÃO FUNCIONAL, por sua vez pode ser definido como “de qual maneira o sistema deve fazer“. Por outro lado pode parecer muito vago e com pouco sentido, mas é muito simples assimilar o conceito.

Uma forma simples de entender o que é um requisito funcional é ter por base que todo requisito não funcional deve expressar uma premissa ou restrição do sistema.

Dessa forma, requisitos não funcionais devem sempre ser mensuráveis, ou seja, deve ser possível verificar se ele está ou não sendo atendido pelo software.

Exemplo de Requisito não Funcional

Vamos dar alguns clássicos e básicos exemplos de requisitos não funcionais de software, que são comuns durante o levantamento de requisitos de projeto de desenvolvimento:

  • O sistema deve ser multiplataforma – Windows, Linux e macOS
  • O desenvolvimento deve ser em linguagem C++
  • O programa deve funcionar offline
  • O sistema deve respeitar o tempo máximo de 160 segundos durante processamentos

Os quatro requisitos acima citados, são requisitos não funcionais, pois eles indicam condições ou então características de COMO será executada determinada ação pelo sistema. Lembre-se: requisitos não funcionais devem sempre ser mensuráveis! A tirinha Dilbert de Scott Adms resume exatamente isso.

Tirinha de Dilbert: A definição e o entendimento do escopo de negócio e dos requisitos de software nem sempre são entendidos ou respeitados
Tirinha de Dilbert: A definição e o entendimento do escopo de negócio e dos requisitos de software nem sempre são entendidos ou respeitados

Não é um Requisito não Funcional

Pelo fato da distinção entre requisitos funcionais e não funcionais parecer subjetiva, é comum encontrar documentos de levantamento de requisitos de software onde o analista indicou de forma equivocada como requisito não funcional uma condição não mensurável ou não verificável.

Logo, deve-se tomar muito cuidado ao descrever requisitos não funcionais, e realizar sua categorização. É necessário lembrar que um requisito não funcional deve ser SEMPRE verificável, caso contrário ele não pode ser interpretado como tal.

Esses três requisitos abaixo, NÃO podem ser considerados como requisitos não funcionais. O motivo é simples, visto que nenhum deles é passível de verificação.

Nenhum desses requisitos pode ser medido, aferido ou mensurado para comprovar sua conformidade:

  • O sistema deve ser rápido.
  • Não deve corromper dados.
  • O programa deve ser seguro.

Durante o processo de levantamento de requisitos e sua documentação, o analista deve sempre questionar a coerência dos atributos dos requisitos não funcionais, como no caso acima, as perguntas a serem feitas para garantir a qualidade dos requisitos seriam:

  • O que significa ser rápido, o que é um sistema rápido?
  • A velocidade de um sistema é medida com qual “régua”, com a do desenvolvedor ou com a do testador?
  • Como pode ser verificada a integridade de seus dados, como verificar essa capacidade do sistema antes mesmo da ocorrência de um incidente com os dados aconteça?
  • O que define se o sistema é seguro, quais são os critérios de segurança, e se existirem tais critérios, quem é o provedor?

Identificando o tipo do requisito com 2 perguntas

Para não errar nunca na hora de categorizar um requisito como funcional ou não funcional basta responder suas perguntas obrigatórias para garantir a coerência da da categorização dos requisitos

A característica é sobre O QUE o sistema fará, ou COMO o sistema fará?
É possível verificar se requisito não funcional está sendo atendido ou respeitado?

São duas perguntas muito simples, mas à primeira vista, pode ser que que pareça idiota, porém mas acredite, não são. Muitos analistas de requisitos comentem erros fundamentais durante o levantamento e especificação dos requisitos de um sistema.

Exemplos de requisitos funcionais

O detalhamento dos requisitos (requisitos funcionais e requisitos não funcionais) de software que atenderão a solução para o problema de negócio identificado são, a grande modo divididos em dois tipos: funcionais e não funcionais.

Lembre-se: requisito funcional é todo recurso ou funcionalidade do software, que pode ou não interagir com o usuário. Veja mais alguns exemplos:

  • O sistema deve permitir o cadastro de novos usuários, realizando a validação através de um e-mail de confirmação. REQUISITO FUNCIONAL OBRIGATÓRIO.
  • Deve ser possível ao usuário solicitar a redefinição de sua senha, informando o e-mail cadastrado.

Modelo de documento de requisitos pronto

Preparamos um modelo de documento de requisitos de software para download em formato Microsoft Word e também no Google Docs: Documento de requisitos de software

Outros artigos que você precisa ler

Se você deseja aprender mais sobre desenvolvimento de software, metodologias ágeis ou gerenciamento de projetos, veja os artigos exclusivos que preparamos:

Glossário de Termos

requisitos funcionais

Requisitos funcionais descrevem as ações e funcionalidades que um sistema deve executar, respondendo à pergunta 'O QUE o sistema DEVE fazer'. Eles são essenciais para definir as operações específicas do software, como cadastrar, alterar, excluir e consultar dados.

requisitos não funcionais

Requisitos não funcionais descrevem como o sistema deve operar, focando em atributos de qualidade, restrições e premissas. Eles são mensuráveis e verificáveis, como desempenho, segurança e interoperabilidade.

mensurabilidade (de requisitos não funcionais)

Capacidade de um requisito não funcional ser quantificado e avaliado objetivamente, permitindo verificação e validação através de critérios claros e mensuráveis. Definição objetiva com contexto técnico, uso prático e relação direta com o artigo.

documentação de requisitos

Processo de registro detalhado e organizado das necessidades, funcionalidades e características esperadas de um sistema, garantindo clareza e precisão para o desenvolvimento de software.

hierarquia de requisitos

Estrutura organizacional que classifica requisitos em níveis, como requisitos de negócio, requisitos de usuário e requisitos de sistema, facilitando a compreensão e gestão das necessidades do projeto.

casos de uso UML

Casos de uso UML representam a interação entre usuários e sistemas, modelando funcionalidades e requisitos funcionais. Eles são diagramas que ilustram cenários de uso, atores envolvidos e fluxos de interação, facilitando a compreensão e documentação de sistemas.

verificabilidade

Capacidade de um requisito ser validado ou testado para garantir que atenda aos critérios estabelecidos. Em engenharia de software, é crucial para requisitos não funcionais, assegurando que sejam mensuráveis e possam ser comprovados.

regras de negócio

Regras de negócio são diretrizes e políticas que definem como as operações de uma organização devem ser conduzidas, estabelecendo padrões e restrições para processos e funcionalidades do sistema.

matriz de rastreabilidade

Uma matriz de rastreabilidade é uma ferramenta que mapeia e documenta a relação entre requisitos e outros artefatos de projeto, como casos de uso, testes e componentes de software, garantindo a consistência e a cobertura dos requisitos ao longo do ciclo de vida do desenvolvimento.

'O QUE' vs. 'COMO' (critério de diferenciação)

Critério usado para diferenciar requisitos funcionais e não funcionais em engenharia de software, onde 'O QUE' refere-se às funcionalidades do sistema e 'COMO' aos atributos de qualidade e restrições.

Dicíonario de Termos: definições diretas e concisas de termos técnicos, jargões, siglas, abreviações e outros termos específicos do setor.

Perguntas Frequentes

O que são requisitos funcionais?

Requisitos funcionais são ações ou funcionalidades que o sistema deve executar, como 'manter usuário' ou 'fechar venda'.

Como identificar um requisito funcional?

Um requisito funcional expressa 'o que o sistema deve fazer', como cadastrar, alterar ou excluir dados.

O que são requisitos não funcionais?

Requisitos não funcionais descrevem 'como o sistema deve fazer', como desempenho, segurança e interoperabilidade.

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

Requisitos funcionais definem ações do sistema, enquanto não funcionais definem características gerais e restrições.

Por que requisitos não funcionais devem ser mensuráveis?

Para garantir que sejam verificáveis e atendidos pelo sistema, como tempo de resposta ou compatibilidade com plataformas.

Quais são exemplos de requisitos não funcionais válidos?

'O sistema deve ser multiplataforma' ou 'o programa deve funcionar offline' são exemplos mensuráveis.

Como evitar erros na categorização de requisitos?

Responda se o requisito é sobre 'o que' o sistema faz ou 'como' ele faz, e se é verificável.

FAQ: Dúvidas e Perguntas comuns nesse artigo.

Artigos relacionados

3 Comentários

Deixe um comentário

Botão Voltar ao topo