Por que eu devo ler este artigo:Os requisitos não funcionais tendem a ser postergados para o final do projeto. No entanto, o que muitos profissionais esquecem é que eles podem definir até mesmo a arquitetura de hardware e software a ser adotada em produção. Não falar de desempenho, segurança ou escalabilidade na fase de especificação de requisitos pode impactar nos requisitos funcionais, aumentando o custo do projeto e, no pior caso, causando perdas financeiras para a organização e o usuário final. A maturidade no desenvolvimento de software é um tema sempre atual. A engenharia de requisitos está fortemente ligada a ela na forma de promover softwares de boa qualidade, e esses estão intimamente ligados aos requisitos não funcionais. Este artigo discorre sobre a importância dos requisitos não funcionais na qualidade do produto final e como eles podem elevar o nível de maturidade de uma organização, citando exemplos de perdas quando negligenciados ou mal projetados e ainda situações em que são bem projetados, mas que podem ser aperfeiçoados

Falar sobre requisitos não funcionais não é uma tarefa corriqueira ou de fácil abordagem. Primeiro porque muitos profissionais tendem a não os abordar diretamente no documento de requisitos, e isso é um motivo de reflexão, e segundo porque eles estão implícitos no produto e muitas vezes são difíceis de detectar e passam despercebidos na análise. O segundo aspecto, o fato de estarem implicitamente no produto de software, é que nos leva a reflexão de considerá-los ou não no documento de requisitos.

Primeiramente, o que são requisitos não funcionais? Existe uma ampla literatura na área de engenharia de software que irão defini-los com precisão. No entanto, é possível dizer que esses requisitos são aqueles que o usuário, ou até mesmo os profissionais de software, esperam que o produto atenda mesmo que eles não estejam definidos formalmente em um documento, uma vez que eles não descrevem exatamente uma funcionalidade do produto. É como se fosse o óbvio e por isso não é dito. Por exemplo: espera-se que o produto registre uma compra sem levar um tempo longo para executar essa função. Então surge a pergunta: Quanto tempo o produto deve levar para registrar uma compra? E nos deparamos com um requisito não funcional de desempenho.

Não identificar os requisitos não funcionais e não os formalizar para o usuário e o time pode ser um erro de projeto que futuramente irá impactar nos custos e na entrega do produto, e até mesmo na sua arquitetura. Isso gera um stress que poderia ser evitado se os aspectos inerentes do produto não fossem negligenciados.

Muitas vezes a própria cultura contribui para que os requisitos não funcionais sejam negligenciados, pois existe uma forma muito arbitrária de pensar no que é relevante ou não para uma situação ou, no caso, um produto.

Importância dos requisitos não funcionais

Metaforicamente falando, utilizemos uma situação fora do contexto da engenharia de requisitos: imagine uma pessoa que possua restrição auditiva e que não reconhece uma gama muito grande de sons. Para os profissionais da área, o que é relevante é aumentar a gama de sons que essa pessoa ouve (requisito funcional). E para alguns, é somente isso que interessa. Mas qual o impacto disso na pessoa que vai passar a ouvir coisas que ela nem supunha que existia (requisito não funcional)? O que é para ela o barulho da chuva? Como o cérebro dela vai interpretar essa informação? Será satisfatória ou perturbadora? Quais dos sons de um automóvel são considerados normais e quais indicam uma anomalia?

Sob o aspecto negativo d ...

Quer ler esse conteúdo completo? Seja um assinante e descubra as vantagens.
  • 473 Cursos
  • 10K Artigos
  • 100 DevCasts
  • 30 Projetos
  • 80 Guias
Tenha acesso completo