O que são requisitos funcionais, e requisitos não funcionais? Qual a diferença?
O que são requisitos funcionais, e requisitos não funcionais? Qual a diferença?

Requisitos funcionais e requisitos não funcionais: qual a diferença? 

Na engenharia de software, mais precisamente na engenharia de requisitos, podemos definir como um requisito toda solicitação, necessidade, funcionalidade ou característica de um sistema. O processo de levantamento de requisitos de software é responsável por identificar todas essas necessidades e funcionalidades, além de documentá-las

Está querendo mais detalhes sobre a definição de requisitos de software? Ou então quer conhecer melhor as técnicas de levantamento de requisitos? 

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: “Funcionais” e “Não Funcionais”. 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 é um Requisito funcional?

Os 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.

Um exemplo clássico e simples de requisito funcional é a funcionalidade de “MANTER USUÁRIO”. 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 – REQUISITO PRIMÁRIO;

    1. CADASTRAR USUÁRIO – REQUISITO SECUNDÁRIO;

    2. ALTERAR USUÁRIO – REQUISITO SECUNDÁRIO;

    3. DELETAR USUÁRIO- REQUISITO SECUNDÁRIO;

O requisito principal “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.

Requisitos funcionais: não fique com dúvidas!

Mas por que eles são 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 pelo software, ou seja, o usuário insere informação a respeito da ação que deseja tomar, e o software executa tal ação.

Principais tipos de requisitos funcionais: características, funcionalidades, necessidades, solicitações.
Principais tipos de requisitos funcionais: características, funcionalidades, necessidades, solicitações.

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:

  • Gerar relatório de vendas;

  • Emitir cupom fiscal;

  • Emitir nota fiscal;

  • Emitir boleto;

  • Consultar estoque;

Esses cinco requisitos que citamos acima são muito comuns em qualquer software financeiro, fiscal ou contábil. Todos eles expressão 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.

E 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 tal sistema possui um requisito chamado “FECHAR VENDA”, durante sua execução ele inclui outros dois requisitos funcionais – ou features: “EMITIR NF-C” e “ATUALIZAR ESTOQUE”.

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 nf-c” 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.

O que é um Requisito NÃO funcional?

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. Um requisito NÃO funcional por sua vez pode ser definido como “de qual maneira” o sistema deve fazer. Parece muito vago e com pouco sentido, mas é muito simples.

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. 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.

Requisito não funcional: entenda o que é de uma vez por todas!

Vamos dar alguns exemplos básicos e clássicos de requisitos NÃO funcionais que são comuns durante o levantamento de requisitos de software:

  • O sistema deve ser multiplataforma – Windows, Linux e MAC;
  • O sistema deve ser desenvolvido em C++;
  • O sistema deve funcionar off-line;
  • 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 características de como ele irá executar determinadas ações. De forma simples: um requisito funcional é “O QUE” o sistema deve fazer, um requisito não funcional é “COMO” 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.

O que NÃO é um requisito não funcional!

Pelo fato da distinção entre requisitos funcionais e não funcionais parecer subjetiva, é comum encontrar documentações de requisitos de software onde o analista indicou como requisito não funcional uma condição não mensurável ou não verificável. Deve tomar muito cuidado ao descrever requisitos não funcionais, lembre-se sempre que um requisito não funcional deve ser SEMPRE verificável, caso contrário ele não pode ser interpretado como tal.

Exemplos de requisitos que NÃO podem ser considerados requisitos não funcionais:

  • O sistema deve ser rápido;

  • O sistema deve ser seguro;

  • O sistema não deve corromper dados;

Esses três requisitos citados acima não podem ser considerados como requisitos não funcionais. O motivo é o simples fato que nenhum deles é passível de verificação. O que significa ser rápido? Ou então, o que define se o sistema é seguro? Ou permite então que dados sejam corrompidos ou perdidos.

Para não errar nunca na hora de categorizar um requisito como funcional ou não funcional basta responder a duas perguntas simples:

  1. O objeto da característica é sobre O QUE o sistema fará ou COMO o sistema fará?

  2. Posso verificar se este requisito não funcional está sendo atendido ou respeitado?

São duas perguntas muito simples. Tão simples que podem até parecer idiotas, mas acredite, não são. Muitos analistas de requisitos comentem erros fundamentais durante o levantamento e especificação dos requisitos de um sistema.

Está querendo mais detalhes sobre a definição de requisitos de software? Ou então quer conhecer melhor as técnicas de levantamento de requisitos? 

DEIXE SEU COMENTÁRIO
Artigo anteriorLIVRO GRÁTIS: Gestão de Projetos
Próximo artigoLIVRO – GESTÃO DE PROJETOS – LUIZ CAMPOS
Chico Alff é o nome da persona de batalha de Francilvio Roberto Alff. Paranaense apaixonado por São Paulo, possui formação em Engenharia de Software, Análise e Desenvolvimento de Sistemas para Internet, História e Língua italialana e recentemente Engenharia Civil. Frequentou os bancos acadêmicos tanto no Brasil quando na Itália, precisamente na Università degli Studi di Verona. Trabalha com  desenvolvimento de software desde 2010, tendo lançado âncora no mar da Análise de Requisitos, Análise de Negócios e Gerenciamento de Projetos, com experiência em projetos para a administração pública, sistemas de ERP, contábil e fiscal. Atualmente trabalha com consultoria e desenvolvimento de projetos ad hoc na sua pequena cria do coração, a Walküre Smart, e mantém o portal AnálisedeRequisitos.com.br como paixão.