Questão de Engenharia de Software — Engenharia de Requisitos — INSTITUTO AOCP 2025

Dívida Técnica na Engenharia de Requisitos

Gabarito: letra B. Requisitos mal definidos ou não validados corretamente podem contribuir para a geração de dívida técnica, pois a engenharia de requisitos é a base do projeto — defeitos nessa fase se propagam para as fases posteriores, aumentando o custo de correção. A dívida técnica não se restringe ao código-fonte; ela pode ser originada em qualquer etapa do ciclo de vida, inclusive na especificação de requisitos.

A dívida técnica é uma metáfora que descreve o custo implícito de escolhas de desenvolvimento que priorizam a entrega rápida em detrimento da qualidade de longo prazo. Ela pode ser intencional (quando a equipe decide adiar uma refatoração para cumprir um prazo) ou não intencional (quando surge de erros, falta de clareza ou documentação deficiente). No contexto da engenharia de requisitos, requisitos ambíguos, incompletos ou não validados geram retrabalho: o sistema é construído com base em premissas erradas, e corrigir isso depois exige mais esforço do que ter feito certo desde o início.

A engenharia de requisitos é o processo de descobrir, analisar, documentar e verificar os serviços e restrições do sistema. Segundo Sommerville, as fases são: estudo de viabilidade, elicitação e análise, especificação, validação e gestão de requisitos. A validação é o momento de confirmar que os requisitos realmente atendem às necessidades do cliente — se essa etapa é negligenciada, o software pode ser entregue com funcionalidades que ninguém pediu ou sem as que eram essenciais, gerando dívida técnica que se manifesta como retrabalho, correções e manutenção adicional.

A dívida técnica não é benéfica por si só; mesmo quando acumulada intencionalmente, precisa ser monitorada e planejada para ser quitada no futuro. Ela não é eliminada automaticamente após os testes — os testes podem revelar defeitos, mas não removem a dívida estrutural. Além disso, tanto requisitos funcionais quanto não funcionais podem gerar dívida técnica: um requisito não funcional negligenciado (como desempenho ou segurança) pode exigir uma reescrita significativa do sistema.

A pegadinha desta questão está em associar dívida técnica exclusivamente ao código-fonte. Na prática, a dívida pode nascer em qualquer fase — e a engenharia de requisitos é uma das mais críticas, pois erros ali são os mais caros de corrigir. Guarde isso: a dívida técnica é transversal ao ciclo de vida, e a qualidade dos requisitos é a primeira linha de defesa contra ela.

Alternativa A — ❌ Incorreta

Afirma que a dívida técnica está associada somente ao código-fonte. Isso é falso: a dívida técnica pode ser originada em qualquer fase do desenvolvimento, incluindo a engenharia de requisitos. Requisitos mal definidos, falta de rastreabilidade ou validação inadequada geram retrabalho e custos futuros, caracterizando dívida técnica. A alternativa confunde o conceito ao restringi-lo a uma única fase.

Alternativa B — ✅ Correta ⟵ GABARITO

Requisitos mal definidos ou não validados corretamente contribuem para a geração de dívida técnica. Isso está alinhado com a engenharia de requisitos: se a especificação é ambígua, incompleta ou não validada com o cliente, o sistema será construído sobre premissas erradas, exigindo correções posteriores — exatamente o que caracteriza dívida técnica. A validação de requisitos é a etapa que confirma se o que foi documentado atende às necessidades reais; sem ela, o risco de retrabalho aumenta.

Alternativa C — ❌ Incorreta

Diz que a dívida técnica é benéfica quando acumulada intencionalmente e não precisa ser monitorada. Isso é duplamente errado: mesmo quando intencional, a dívida técnica deve ser monitorada e planejada para ser quitada — caso contrário, os juros (custo de manutenção) crescem. A dívida técnica nunca é benéfica por si só; é um trade-off que precisa ser gerenciado.

Alternativa D — ❌ Incorreta

Afirma que apenas requisitos funcionais podem gerar dívida técnica. Isso é falso: requisitos não funcionais (como desempenho, segurança, usabilidade) também podem gerar dívida técnica. Por exemplo, negligenciar um requisito de desempenho pode exigir uma reescrita da arquitetura no futuro. A alternativa restringe indevidamente o escopo.

Alternativa E — ❌ Incorreta

Diz que a dívida técnica é automaticamente eliminada após a fase de testes. Isso é incorreto: os testes podem revelar defeitos, mas não removem a dívida estrutural acumulada em fases anteriores. A dívida técnica só é quitada com refatoração, correção de requisitos ou reescrita — ações deliberadas, não automáticas.

Gabarito: letra B