image

Acesse bootcamps ilimitados e +650 cursos

50
%OFF
Article image
Antonio Dionisio
Antonio Dionisio26/10/2023 02:15
Compartilhe
WEX - End to End EngineeringRecomendados para vocêWEX - End to End Engineering

Relação entre Engenharia de Requisitos e a Filosofia Clean Code

  • #Arquitetura de Sistemas

Introdução

A engenharia de requisitos é um processo da Engenharia de Software responsável pelo levantamento e gerenciamento dos requisitos de um sistema a ser desenvolvido ou durante seu desenvolvimento.

Parte do princípio geral de que é impossível prever todos os requisitos necessários para a concepção de um sistema baseado nas necessidades do usuário do sistema.

Já o movimento “Clean Code” (Código Limpo) preza pelo desenvolvimento de software levando em conta a importância de ter um código legível e limpo para facilitar o trabalho em equipe, mas também agilizar a manutenção.

Mais adiante, há um resumo básico dos conceitos envolvidos na engenharia de requisitos e da sua relação com a filosofia Clean Code, defendida por Robert Cecil Martin, que é renomado desenvolvedor de software e foi um dos coautores do manifesto ágil.


Do que se trata a Engenharia de Requisitos e qual é a importância do Clean Code nesse contexto

A engenharia de requisitos é parte da Engenharia de Software que realiza a interação entre requisitante e desenvolvedores levando em conta “o que” e “o como” pra desenvolver um sistema qualquer baseado nas necessidades do usuário.

De modo geral, representa um amplo espectro de tarefas e técnicas que levam a um entendimento, mútuo entre os stakeholders e desenvolvedores, dos requisitos dos sistemas. Stakeholders são quaisquer pessoas que podem ser beneficiadas ou influenciadas direta ou indiretamente pelo sistema desenvolvido.

Os requisitos podem ser divididos em funcionais ou não-funcionais:

  • Os primeiros lidam com aspectos relativos ao funcionamento, descrevendo o que o sistema deve fazer. Dependem do tipo de software, dos interessados e da abordagem de requisitos adotadas e podem variar de gerais a muito específicos, considerando que imprecisões nas descrições podem causar problemas.
  • Já requisitos não-funcionais, não estão diretamente relacionados as características funcionais do sistema em si, embora possam afetá-lo em geral, mas se preocupam com as propriedades mais emergentes e difíceis de relacionar do sistema, como: segurança, usabilidade e etc.

Também temos requisitos de domínio que se referem ao domínio geral de aplicação do sistema, podendo ser de um negócio, ou de gerência, por exemplo. Requisitos de domínio determinam as restrições do sistema.

Há outros processos envolvidos e que são relevantes:

  • Elicitação se refere a obtenção de informações sobre o domínio, os serviços, o desempenho, as restrições, enfim, de todas as características do sistema. Sempre envolvem muitas pessoas;
  • A validação dos requisitos que trata de verificar se os requisitos definem de fato o sistema necessário ou requisitado e é importante para evitar custos com retrabalho;
  • E o Gerenciamento de requisitos que é a maneira de acompanhar, compreender e controlar a evolução dos requisitos durante todo o processo de concepção do sistema.

Contudo, como já indicado, os requisitos funcionais e não-funcionais de uma aplicação indicarão o que o sistema precisa fazer e como deve ser feito, mas a forma final com o qual os sistemas lidarão com tais requisitos é através da codificação, o que a torna uma atividade de grande responsabilidade.

Ao discutir o pensamento de que um dia os softwares serão gerados e não mais escritos, Martin (2009, p.2) afirma: “Nunca nos livraremos dos códigos, pois eles representam os detalhes dos nossos requisitos”.

E ele vai além, um pouco mais abaixo:

“Lembre-se de que o código é a linguagem na qual expressamos os nossos requisitos. Podemos criar linguagens que sejam mais próximas a eles. Podemos criar ferramentas que nos ajudem a analisar a sintaxe e unir tais requisitos em estruturas formais. Mas jamais eliminaremos a precisão necessária – portanto, sempre haverá um código.” (MARTIN, 2009, p.2).

Essas afirmações determinam um possível entendimento da filosofia do código limpo, contudo não há uma única definição. Até mesmo o Robert trouxe diversas definições no seu livro, resultando na apresentação de um conhecimento base para quando criamos, lemos e limpamos um código.

Mas, em Almeida e Miranda (2023), encontramos uma forma de “entender” melhor o conceito. Eles definem um Código Limpo como aquele que mais se aproxima dos seguintes valores:

  • Expressividade – é a facilidade em que um desenvolvedor, que não é o autor original do código, tem para o entender, modificar e utilizar;
  • Simplicidade – tem relação com a quantidade de informações que o leitor deve compreender para fazer alterações em um trecho de código;
  • Flexibilidade – trata-se da facilidade com que o código da aplicação é estendido sem grandes alterações na estrutura já implementada.

Outro ponto de partida para entender esse conceito, e que corrobora com os atributos da engenharia de requisitos, é a frase atribuída ao Engenheiro de Software Martin Fowler: “Qualquer um consegue escrever um código que um computador entende. Bons programadores escrevem código que humanos entendem”.

Conclusão

A engenharia de requisitos se trata de uma etapa de extrema importância da Engenharia de Software, pois contribui com o estudo de ferramentas e processos necessários para a melhor forma de construir um software, sempre visando as melhores práticas.

Por outro lado, a filosofia “Clean Code”, defendida por Robert C. Martin, coloca luz sobre como os softwares devem ser desenvolvidos/codificados de forma a contribuir para rápido e seguro desenvolvimento e manutenção.

De fato, indo mais afundo nas proposições da filosofia apresentada, vemos que as regras devem ser aplicadas conforme o contexto do projeto, suas regras de negócios, partindo da análise dos stakeholders, ou seja, considerando e refinando todos os requisitos do projeto.

Pode-se afirmar assim que, quanto mais legível for um código, mais próximo ele estará de atender e/ou traduzir as expectativas propostas no levantamento de requisitos.


Referências

ALMEIDA, L. T., MIRANDA, J. M. Código Limpo e seu Mapeamento para Métricas de Código Fonte. Monografia. Departamento de Ciência da Computação. USP . Disponível em: <https://www.ime.usp.br/~cef/mac499-10/monografias/lucianna-joao/#>. Acesso em: 25 out. 2023.


MARTIN, R. C. Código limpo: habilidades práticas do Agile software. Alta Books; 1ª edição, 2009.


PRESSMAN, R.S. Engenharia de Software. McGraw-Hill, 7ª edição, 2011.


SOMMERVILLE, I. Engenharia de Software, 8ª edição, São Paulo: Pearson Addison-Wesley, 2007.


Compartilhe
Recomendados para você
TONNIE - Java and AI in Europe
WEX - End to End Engineering
Microsoft 50 Anos - Prompts Inteligentes
Comentários (1)

AJ

Antônio Jesus - 26/10/2023 09:54

Muito bom cheio de coisas novas e interessantes pra mim tb muito esclarecedor obrigado

Recomendados para vocêWEX - End to End Engineering