Como já sabemos, desenvolver um software não é uma tarefa trivial, já que, além da habilidade em programação, também é necessário compreender a regra de negócio do cliente. Durante o desenvolvimento, o nosso maior objetivo obviamente é satisfazer as necessidades pelas quais o sistema foi concebido.
Mas será que só isso é importante?
Antes de entrar no assunto, vale ressaltar o conceito de “requisitos funcionais” e a sua importância na qualidade do produto final.
Requisitos funcionais são as necessidades apontadas pelo cliente, ou seja, o que ele quer que o sistema faça. Gerenciar vendas, manter fornecedores e emitir relatórios mensais são exemplos de requisitos funcionais, que geralmente são obtidos durante a etapa de levantamento de requisitos junto ao cliente e demais usuários. Portanto, boa parte da qualidade do software está centrada em atender tais requisitos, uma vez que esse é o comportamento esperado pelo cliente. Imagine um sistema onde somente 8 das 10 funções solicitadas foram implementadas. Em uma analogia, é a mesma coisa que comprar um carro que não possui freios e faróis: ele anda, mas uma hora irá bater. É importante implementar cada requisito do cliente, e é justamente por isso que existem as fases de análise e modelagem em um projeto.
O problema é que, na preocupação de satisfazer as necessidades do cliente, os responsáveis pelo projeto esquecem que existem os requisitos não-funcionais, que também influenciam bastante na qualidade do software.
Requisitos não-funcionais são as características e aspectos internos do sistema, envolvendo especificamente a parte técnica. Ao contrário dos requisitos funcionais, estes requisitos não são explicitamente expostos pelo cliente, mas devem ser implicitamente compreendidos pelo desenvolvedor. Os requisitos não-funcionais basicamente se resumem em seis itens, descritos logo abaixo.
Segurança: o software deve garantir a segurança dos dados, bem como as permissões de acesso às suas funcionalidades, como por exemplo, usar criptografia em senhas e liberar acesso aos menus do sistema de acordo com a hierarquia do usuário. Quando se trata de um software com informações confidenciais (como dados de vendas, faturamentos ou citações de pessoas), este item se torna indispensável.
Usabilidade: procure desenvolver um sistema fácil de usar, que dispense muitos recursos gráficos. Se possível, adicione descrições das funções (hints) aos botões e configure teclas de atalho para as funções mais utilizadas. Quanto mais simples for a usabilidade, maior será a aceitação dos usuários.
Confiabilidade: determina a capacidade do sistema em lidar com eventos inesperados. Suponha que o usuário esteja cadastrando um novo registro, e após inserir todas as informações, ocorre um erro no sistema e o usuário acaba perdendo as informações digitadas. Revoltante, não? A confiabilidade significa que o sistema deve ser capaz de tratar exceções e se recuperar de falhas, sem que haja perda de dados. Backup e restauração do banco de dados também se encaixam neste item.
Padrão: define a padronização de interface e código utilizada no desenvolvimento do software. Embora seja mais voltado para a equipe de desenvolvimento, é essencial para facilitar a manutenção e atualização do sistema. Este item também envolve conceitos de arquitetura, como utilizar MVC, padrões de projeto ou frameworks.
Desempenho: de nada adianta ter um sistema seguro, interativo e confiável se ele consome muitos recursos do computador e demora pra executar os processamentos. Um sistema lento é alvo de crítica dos usuários, mesmo que seja funcional. A performance do software pode ser melhorada utilizando técnicas de programação orientada a objetos, threads e otimização de código. Outros fatores como consultas SQL aprimoradas no banco de dados e liberação de recursos da memória também devem ser estudados para aprimorar o desempenho.
Hardware e Software: define os requisitos mínimos para o funcionamento adequado do software. Por exemplo, se o sistema faz integração com o Microsoft Outlook, este deve estar instalado no computador como pré-requisito. Da mesma forma, se o sistema trabalha em rede, é necessário que o computador tenha uma interface física de rede instalada. Esse item também abrange a portabilidade do software para outros sistemas, tal como a sua facilidade de configuração.
Além dos itens acima, outras características também podem ser citadas, respeitando os fundamentos da Engenharia de Software. É por esse motivo que no enunciando do artigo mencionei sobre o domínio da regra de negócio e habilidade de programação. O primeiro se refere aos requisitos funcionais, enquanto o segundo trata de ambos.
Conclusão: ser programador realmente não é fácil… rs.
Abraço!
Publicado originalmente no blog André Celestino
11 Comentários
Muito interessante esses artigo.
Um bom programador deve saber que os requisitos não funcionais são tão importantes quanto os requisitos funcionais. Desenvolver um dos dois com menos atenção acaba em um sistema insatisfatório no final . E isso que torna a programação mais interessante e aumenta o desafio. Programar por programar qualquer um consegue.
Ótima observação, Wanderson.
Há uma fronteira que define bons programadores, e um dos fatores que compõem essa fronteira é a habilidade em cumprir requisitos funcionais e não-funcionais em um software.
Obrigado pelo comentário!
Para mim quem defjne os requisitos é o analista e não um programador.
Jones, obrigado pelo comentário, mas não concordo com a sua afirmação. Eu acredito que programadores devem trabalhar requisitos não-funcionais mesmo quando não estão especificados. Por exemplo, você deixaria de tratar uma possível exceção no sistema (repercutindo o requisito de confiabilidade) somente porque o analista não a definiu?
Aquela história de que “o analista não definiu isso, então não vou fazer”, só traz mais conflitos e redirecionamento de culpa, ao invés de contribuir para a solução.
Gostei muito do artigo, muitos profissionais de TI não dão a devida importância as Requisitos Não Funcionais (E alguns não sabem nem o que são Requisitos Funcionais).
Mas aproveitando o debate, eu não vejo que o Analista de Sistemas deva depositar muita atenção em definir os requisitos não funcionais, visto que as definições de cada Requisito Não Funcional já são claras e serão as praticamente as mesmas para todas as aplicação que venha a ser desenvolvida, ou seja, deve ser rotina de um desenvolvedor. Isso não quer dizer que o Analista não eva entender e não seva estar por dentro das novidades destes requisitos, mas não vejo necessidade de estar documentado detalhadamente para seja desenvolvido.
Olá, Bruno! Concordo com o seu ponto de vista, porém, em certas ocasiões, cada requisito funcional pode ter requisitos não funcionais particulares, principalmente relacionados à segurança, desempenho e usabilidade. Por exemplo, permissões de campo na tela, eventos que disparam consultas no banco de dados e a adequada distribuição dos campos na tela são pontos que, apesar de serem técnicos, acredito que devem ser contemplados pelo Analista.
Obrigado pelo comentário!
Muito boa a matéria!
Na faculdade foi tão difícil de entender as diferenças entre requisitos funcionais e não funcionais, e agora pude entender bem do que se trata e da sua importância no desenvolvimento. Infelizmente essa matéria de Engenharia de Software ficou a desejar na faculdade, nossa turma deixou de aprender muita coisa, pois a professora oficial não pode dar as aulas, e no lugar ficou um professor que bem, não sabia muita coisa. rsrs
Mas parabéns pelo post, muito bom e esclarecedor, principalmente para mim que estou iniciando agora na carreira.
Obrigado!
Olá, Alexandre! Obrigado pelo feedback!
Realmente, algumas disciplinas nas faculdades deixam a desejar mesmo, mas, como todos dizem, quem faz a faculdade é o aluno! Neste caso, a saída é se especializar por contra própria!
Bons estudos!
Pingback: A CRUELDADE DE UM SOFTWARE LENTO | Glanz TI | empresa em tecnologia da Informação | A Glanz TI é uma empresa de vanguarda em Tecnologia da Informação, com profissionais que estão há mais de 38 anos no mercado
Acabei de publicar um artigo também falando sobre a importância em diferênciar um requisito funcional de um não funcional, e o impacto de requisitos não funcionais mal especificados.
http://www.analisederequisitos.com.br/requisitos-funcionais-e-requisitos-nao-funcionais-o-que-sao/
Muito bom o seu artigo, Chico! Bem instrutivo. Parabéns! 🙂