Analista de Infraestrutura e Requisito Não Funcional

Como mitigar a omissão com o aspecto não funcional do software?

Compartilhe!

Em modelagem de software, quando falamos de performance, escalabilidade, disponibilidade, volume, capacidade, padrões aplicados etc. estamos no campo do Requisito Não Funcional.

Aqui você pode saber mais sobre Requisito Não Funcional, mas se for lá volte aqui para concluir o estudo ok? 🙂

Mas pouca atenção se dá a isso.

Um dos motivos mais comuns para essa omissão é que o Analista de Sistemas (ou Negócios, ou Funcional, ou equivalente) está focado em entender o aspecto funcional da solução que será dada para o problema do cliente.

Ainda, além do foco na funcionalidade, tem as pressões para atender os prazos, para não ultrapassar os custos, para não deixar a qualidade dos requisitos de lado etc.

Entretanto, isso é muito ruim.

Mas como podemos mitigar este problema, sem tirar o foco do Analista de Sistemas?

Nesse vídeo vamos falar rapidamente sobre a participação do profissional de infraestrutura no processo de desenvolvimento de software.

Após o vídeo, a transcrição do conteúdo.

Concepção e Requisito Não Funcional

Em tempo de concepção de software, quando a ideia da solução está nascendo, quando os primeiros esforços de análise estão ocorrendo, é muito comum que nós sequer pensemos no envolvimento de algum profissional de infraestrutura/operações nesse momento do ciclo de vida do projeto.

Acontece com frequência de o profissional de Análise de Sistemas (seja ele Desenvolvedor, Full Stack, Analista de Sistemas mais tradicional etc.) enviar o que foi especificado para para construção e quando se está na reta final da construção (ou quando estamos em homologação), perceber-se uma série de gaps pertinentes a questões envolvendo infraestrutura.

/* Os Gaps citados são considerados defeitos (ou bugs) de análise. Trata-se de coisas que deveriam ter sido identificadas/analisadas/especificadas em tempo de Concepção/Análise, mas que “passaram batido”.*/

Quando falamos de infraestrutura, os gaps estão no contexto de segurança, firewall, regras de acesso, sub-redes, conectividade, questões pertinentes a telecomunicações (link, banda, QOS), volume de dados, capacidade de armazenamento e etc.

Esse tipo de informação (os gaps citados, e o contexto onde as questões devem ser tratadas) fica no domínio do Requisito Não Funcional.

Entretanto, como no inicio do projeto (momento de concepção) não se envolveu o profissional especializado, o profissional que tem olhos para esse tipo de disciplina, é fatal que os gaps vão surgir.

Como diminuir a ocorrência do problema?

Como boa prática, para diminuir esse problema de descoberta tardia de Escopo Não Funcional, recomendamos envolver um profissional de infraestrutura no momento da Concepção.

Geralmente este profissional é chamado de Analista de Suporte, Analista de Infraestrutura, Analista de Operações, ou outros nomes (a depender do organograma da empresa).

É muito importante envolver este profissional no início do projeto, na etapa de concepção, mesmo que ele seja apenas um Consultado ou um Informado. Engenharia de Requisitos - Analista de Infraestrutura x Requisito Não Funcional

Se neste momento este profissional perceber algum Requisito Não Funcional no contexto de segurança, performance, confiabilidade, volume, capacidade etc. ele já aponta isso neste momento, e antes de se começar a desenhar a parte funcional, comportamental, arquitetural e estrutural da solução, já se tem uma opinião de um profissional com olhos para a parte “não funcional”.

O que não pode ocorrer, que ainda é o que infelizmente mais ocorre, é os gaps não funcionais aparecerem apenas ao final do projeto, quando as coisas já deram errado.

Aí o retrabalho e o desperdício de recurso vão acontecer de qualquer jeito.

Este ônus, inevitavelmente, deverá ser absorvido pelo projeto.

Grande abraço!

Engenharia de Software