O que são Requisitos Não Funcionais

A engenharia de requisitos define os requisitos não funcionais, ou requisitos de qualidade, como sendo os requisitos que especificam critérios que podem ser usados para descrever o funcionamento de um sistema, e não os comportamentos específicos, pois para isso é utilizado os requisitos funcionais. Os não funcionais estão ligados ao limite de uso e as propriedades da aplicação e são muito importantes no projeto de desenvolvimento de um software, pois caso sejam negligenciados, podem trazer prejuízo para o seu projeto.

O usuário não sabe o que é, por isso é difícil elicitá-lo

Nossos Usuários costumam pensar apenas nas funcionalidades que o sistema deverá ter e como deverá ajudar em seu negócio, esquecendo de pensar sobre questões como a quantidade de dados que o sistema deverá trafegar, qual a quantidade de acessos simultâneos e até menos em quais sistemas operacionais o sistema deverá funcionar. E muitas vezes o usuário realmente não sabe como levantar essas informações ou que essas informações são vitais para o projeto. E uma das tarefas dos analistas é ajudar os clientes a levantar esses dados ao iniciar um projeto.

Requisitos Não-Funcionais são difíceis de estimar

É difícil estimar prazo e custo para implementação de requisitos não-funcionais. Em termos de volume de trabalho (para criação do requisito e desenvolvimento), geralmente isso é feito baseado na “opinião de especialista”.

Medidas como: Ponto de Função, Linha de Código, Pontos por Caso de Uso e técnicas semelhantes mensuram apenas o que é perceptível para o usuário, e geralmente requisitos não-funcionais não são. Uma maneira para minimizar essa questão é utilizar uma base histórica, com base em situações já ocorridas no passado.

Categorias de um Requisito Não-Funcional

Para uma melhor organização da especificação e semântica do projeto do software, requisitos não-funcionais são separados por categorias, conforme o propósito de cada requisito. Podemos citar a seguir as principais categorias existentes:

• Desempenho;
• Disponibilidade;
• Segurança;
• Interoperabilidade;
• Usabilidade;
• Compatibilidade;
• Confiabilidade;
• Padrões;

Além das características citadas acima, existem outras categorias que seguem as boas práticas da engenharia de software.

Como documentá-los e organizá-los

Por padrão, costuma-se ter apenas um documento abordando todos os requisitos não funcionais de um Sistema. Analistas experientes já sabem que negligenciar este item geralmente impacta em muito retrabalho para o time, e claro, uma grande insatisfação por parte do seu Cliente.  Outro ponto que muitos Profissionais costumam falhar é abordar este item de maneira subjetiva ou superficial. Por exemplo:

“A interface deverá ser fácil e intuitiva” 

“O Login não poderá ser demorado” 

Exemplos como estes são subjetivos e falhos, do ponto de vista sistêmico, sendo impossíveis de serem validados. Portanto, ao documentar um requisito não funcional, procure evidenciar parâmetros para validá-lo. Desta forma, poderíamos descrever corretamente estes exemplos como:

“Cada interface não poderá ter mais do que 6 (seis) botões de acionamento, sendo acompanhados por ícones que correspondam à funcionalidade relacionada e uma tecla de atalho para o acionamento do mesmo” 

“A resposta da funcionalidade de Login do Sistema, não poderá ser superior a 3 segundos” 

Para mitigarmos situações como esta, é aconselhável que o documento de requisitos não-funcionais seja abordado (de forma assertiva), logo após o kick-off de um projeto. E que o restante dos requisitos funcionais, aguardem a sua aprovação para serem iniciados.

Conclusão

Requisitos não funcionais não podem ser negligenciados na elicitação dos requisitos, uma vez que podem trazer prejuízos financeiros para o seu projeto. Conheça a existência deles e confira que eles foram elicitados e documentados pelos analistas e engenheiros responsáveis do projeto.

Uma dica para auxiliar os profissionais é a certificação para um Engenheiro de Requisitos, que é um diferencial. A certificação guiará o entendimento destas boas práticas de elicitação, evitando com que o Profissional tenha que aprender com seus próprios erros e gere retrabalho para a equipe, e consecutivamente, para o Projeto.

Leia mais informações sobre a importância de uma certificação na Carreira de um Engenheiro de Requisitos.

Qual sua experiência com requisitos não-funcionais? Deixe um comentário!

 

Autores

Vinicius Carvalho

Engenheiro de Software, apaixonado por tecnologia e desenvolvimento de software. Focado no desenvolvimento de projetos que gerem resultados positivos e valor para as pessoas e/ou empresas. Tem atuado desde de 2010 na área de tecnologia de informação e desempenhado diversas funções de desenvolvedor a gerente de projetos. É certificado em Engenharia de Requisitos (CPRE-FL). Atua como Analista de Negócio utilizando as melhores práticas de engenharia de requisitos e gerenciamento ágil. Outros artigos de Vinicius: https://goo.gl/ZVnNK2

Diogo Pereira

Bacharel em Informática na UEM e MBA em Gerenciamento de Projetos de TI. Analista de Negócios na DB1 Global Software com certificação em Engenharia de Requisitos (CPRE-FL), atua em elicitação de softwares, prototipação, documentação funcional e não-funcional, além de fazer a ponte entre Product Owner e Desenvolvedores.

Fabiano Bonvino

Fabiano Bonvino é Analista de Negócios na DB1 Global Software. É graduado em Sistemas de informações pela Faculdade Mater Dei. Possui MBA em tecnologia da Informação pela Faculdade Maringá, e cursa MBA em Gerenciamento de Projetos em T.I. pela Faculdade Cidade Verde. É certificado em Engenharia de Requisitos (CPRE-FL). Atua na área de Desenvolvimento de Sistemas há mais de quinze Anos.