Questão de Engenharia de Software — Engenharia de Requisitos — VUNESP 2023

Requisitos funcionais e não funcionais: a relação de derivação

Gabarito: letra E. A alternativa correta captura uma relação fundamental da engenharia de requisitos: um requisito não funcional (como segurança ou desempenho) frequentemente impõe restrições que geram a necessidade de novos requisitos funcionais para satisfazê-lo. Essa relação de derivação é explicitamente reconhecida na literatura clássica de engenharia de software, como em Sommerville, e é o ponto central que a questão explora.

Para entender por que a letra E é a correta, é preciso dominar a distinção entre os dois tipos de requisito. Requisitos funcionais (RF) descrevem o que o sistema deve fazer: os serviços que oferece, suas reações a entradas específicas e seu comportamento em determinadas situações. São exemplos: "o sistema deve permitir ao usuário pesquisar cursos disponíveis" ou "o sistema deve calcular o imposto devido". Já requisitos não funcionais (RNF) descrevem como o sistema opera, ou seja, as restrições aos serviços ou funções oferecidas. Eles especificam ou restringem características do sistema como um todo, como desempenho (tempo de resposta), segurança, usabilidade, confiabilidade e disponibilidade. Um exemplo seria: "o sistema deve responder a qualquer consulta em no máximo 2 segundos".

A relação entre eles não é de exclusão, mas de complementaridade e derivação. Um RNF, por ser uma restrição global, muitas vezes não pode ser satisfeito diretamente por uma única funcionalidade; ele exige que várias funcionalidades específicas sejam implementadas para que a restrição seja cumprida. Por exemplo, um requisito não funcional de segurança ("apenas usuários autenticados podem acessar o sistema") gera requisitos funcionais como "o sistema deve permitir login com usuário e senha", "o sistema deve encerrar a sessão após inatividade" e "o sistema deve registrar tentativas de acesso". É exatamente essa a ideia da alternativa E: o RNF atua como uma fonte que gera novos RFs.

Essa relação é tão importante que aparece em questões de diversas bancas. Uma questão da FCC, por exemplo, afirmava corretamente que "um único requisito não funcional, como um requisito de proteção, pode gerar uma série de requisitos funcionais relacionados que definam os serviços necessários no novo sistema". O material de apoio também reforça: enquanto "mais de um requisito funcional pode garantir um requisito não funcional", o RNF "pode gerar uma série de requisitos funcionais".

A pegadinha central desta questão é a tentativa de estabelecer relações de exclusão ou hierarquia entre RF e RNF, quando na verdade eles coexistem e se influenciam mutuamente. As alternativas A, B, C e D exploram exatamente esses equívocos: atribuição exclusiva a um cargo, limitação numérica, inaplicabilidade a um domínio e exclusão mútua. Nenhuma dessas relações existe na teoria de requisitos. Guarde a relação de derivação: RNF → gera novos RFs; é nela que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Afirma que a atribuição de requisitos funcionais e não funcionais é de responsabilidade exclusiva da gerência e diretoria administrativa da empresa desenvolvedora. Isso é um erro grave. A definição de requisitos é uma atividade colaborativa que envolve todas as partes interessadas (stakeholders): clientes, usuários finais, analistas de negócio, engenheiros de requisitos, arquitetos de software e, sim, também a gerência. A engenharia de requisitos é o processo de descobrir, analisar, documentar e verificar os serviços e restrições do sistema, e esse processo depende fundamentalmente da interação com o cliente e os usuários para identificar as reais necessidades. A palavra "exclusiva" torna a alternativa insustentável, pois exclui os principais atores do processo de levantamento de requisitos.

Alternativa B — ❌ Incorreta

Afirma que o número de requisitos não funcionais não pode ser superior ao número de requisitos funcionais. Não existe nenhuma regra, norma ou princípio na engenharia de requisitos que estabeleça qualquer proporção ou limite numérico entre a quantidade de RFs e RNFs. A quantidade de cada tipo de requisito depende inteiramente da natureza, complexidade e domínio do sistema. Um sistema de controle de equipamentos industriais, por exemplo, pode ter pouquíssimos requisitos funcionais (ligar, desligar, ajustar) e uma quantidade enorme de requisitos não funcionais (tempo de resposta em milissegundos, disponibilidade 24/7, tolerância a falhas, segurança). A alternativa inventa uma limitação que simplesmente não existe na teoria.

Alternativa C — ❌ Incorreta

Afirma que a atribuição de requisitos não funcionais não se aplica a softwares voltados a sistemas de controle de equipamentos. Isso é exatamente o oposto da realidade. Sistemas de controle de equipamentos (como controladores industriais, sistemas embarcados, automação) são, na verdade, altamente dependentes de requisitos não funcionais. Um sistema de controle de uma usina nuclear ou de um braço robótico cirúrgico exige requisitos rigorosos de tempo real (resposta em milissegundos), confiabilidade, disponibilidade e segurança. Sem esses RNFs, o sistema seria inútil ou perigoso. A alternativa tenta excluir um domínio que é, na prática, um dos que mais dependem de RNFs.

Alternativa D — ❌ Incorreta

Afirma que, se forem atribuídos requisitos funcionais a um software, não será possível atribuir requisitos não funcionais a esse mesmo software. Isso estabelece uma relação de exclusão mútua que não existe. Todo software real possui simultaneamente requisitos funcionais e não funcionais. Um sistema bancário, por exemplo, tem RFs (transferir valores, consultar saldo, emitir extrato) e RNFs (segurança das transações, disponibilidade do sistema, tempo de resposta). A alternativa D é a mais absurda, pois nega a coexistência fundamental que define a natureza complementar dos dois tipos de requisitos.

Alternativa E — ✅ Correta ⟵ GABARITO

Afirma que um requisito não funcional pode gerar a necessidade da definição de requisitos funcionais até então não considerados. Esta é a relação de derivação correta e amplamente reconhecida. Um RNF, por ser uma restrição global ao sistema, frequentemente não pode ser satisfeito sem a criação de novas funcionalidades. Por exemplo, um requisito não funcional de segurança ("o sistema deve proteger os dados dos usuários") gera requisitos funcionais como "o sistema deve exigir autenticação por senha", "o sistema deve criptografar os dados em repouso" e "o sistema deve permitir ao usuário alterar sua senha". O material de apoio confirma explicitamente: o RNF "pode gerar uma série de requisitos funcionais". A alternativa E espelha exatamente essa relação de derivação, sendo a única correta.

Gabarito: letra E — um requisito não funcional pode, e frequentemente deve, gerar novos requisitos funcionais para que a restrição imposta seja atendida.