Questão de Engenharia de Software — Geral — FCC 2025

Ciclo de vida do software e engenharia de requisitos

Gabarito: letra C. A prática mais adequada para o desenvolvimento de um sistema de gestão processual é a abordagem iterativa e incremental, com ciclos curtos (sprints), em que a engenharia de requisitos é contínua e o sistema é entregue em partes funcionais — exatamente o que descreve a alternativa C. Essa abordagem combina a flexibilidade para lidar com requisitos que evoluem (típicos de sistemas complexos como o de um tribunal) com a entrega de valor incremental ao usuário.

O ciclo de vida do software (SDLC) é o conjunto de fases pelas quais um produto de software passa, desde a concepção até a retirada de uso. Os modelos de processo são representações simplificadas desse ciclo, e a escolha do modelo adequado depende das características do projeto: complexidade, clareza dos requisitos, necessidade de flexibilidade e envolvimento do cliente. No caso de um sistema de gestão processual, os requisitos tendem a ser numerosos, interconectados e sujeitos a mudanças decorrentes de alterações na legislação ou nos procedimentos internos do tribunal. Por isso, um modelo que permita refinamento contínuo e entregas parciais é mais adequado do que um modelo sequencial rígido.

A engenharia de requisitos é o processo de descobrir, analisar, documentar e verificar os serviços e restrições que o sistema deve atender. Em abordagens ágeis, esse processo não é uma fase única e inicial, mas uma atividade contínua, que se repete a cada iteração. Isso contrasta com o modelo em cascata, em que os requisitos são definidos integralmente no início e a fase seguinte só começa após a aprovação da anterior. A abordagem iterativa e incremental permite que o cliente (no caso, o tribunal) receba partes funcionais do sistema ao longo do desenvolvimento, validando cada incremento e fornecendo feedback que realimenta o processo.

Um exemplo prático: em um sistema de gestão processual, a primeira sprint pode entregar o módulo de cadastro de processos; a segunda, o módulo de distribuição; a terceira, o módulo de acompanhamento de prazos. Cada módulo é uma parte funcional que agrega valor imediato, e os requisitos de cada módulo são detalhados e refinados na iteração correspondente, com base no feedback dos usuários (servidores do tribunal). Isso reduz riscos, permite ajustes precoces e aumenta a satisfação do cliente.

A distinção central que a questão explora é entre modelos sequenciais (cascata, V) e modelos iterativos/incrementais (ágeis, espiral, prototipação). Enquanto os primeiros assumem que os requisitos são bem compreendidos desde o início e raramente mudam, os segundos reconhecem a incerteza e a evolução natural dos requisitos. A banca testa exatamente essa fronteira: qual modelo melhor se adapta a um contexto de requisitos dinâmicos e necessidade de entregas frequentes.

A pegadinha da questão está em alternativas que descrevem modelos válidos, mas com características distorcidas ou incompletas. Por exemplo, a alternativa A menciona entregas frequentes (característica ágil), mas despreza a documentação de requisitos, o que não é uma prática recomendada — mesmo em métodos ágeis, a documentação existe, ainda que enxuta. A alternativa D fala em prototipação, mas a descreve de forma incompleta, como se a documentação fosse gerada apenas ao final. A alternativa E distorce o modelo em V, que na verdade prevê validação em cada nível de desenvolvimento, não apenas no final. A alternativa B descreve corretamente o cascata, mas esse modelo não é o mais adequado para o contexto de requisitos dinâmicos.

Guarde o critério decisivo: a adequação do modelo de ciclo de vida ao contexto de requisitos dinâmicos e necessidade de entregas incrementais. É exatamente nesse critério que as alternativas se dividem.

Alternativa A — ❌ Incorreta

A alternativa A descreve uma abordagem ágil com entregas frequentes, o que é positivo, mas afirma que a equipe não se preocupa com a documentação detalhada dos requisitos. Isso é uma distorção: mesmo em métodos ágeis, a documentação de requisitos existe, embora seja mais enxuta e focada no essencial (por exemplo, histórias de usuário, critérios de aceitação). A ausência total de documentação é uma prática inadequada, pois compromete a rastreabilidade e a manutenção do sistema. Além disso, a alternativa não menciona a priorização e o refinamento contínuo dos requisitos, que são centrais na abordagem ágil.

Alternativa B — ❌ Incorreta

A alternativa B descreve corretamente o modelo em cascata: fases sequenciais, sem sobreposição, com a fase de requisitos concluída por um documento aprovado. No entanto, esse modelo não é o mais adequado para o contexto de um sistema de gestão processual, em que os requisitos são complexos e sujeitos a mudanças. O cascata é recomendado quando os requisitos são bem compreendidos e estáveis desde o início, o que não é o caso típico de sistemas institucionais. A rigidez do modelo dificulta a adaptação a mudanças e atrasa a entrega de valor ao usuário.

Alternativa C — ✅ Correta ⟵ GABARITO

A alternativa C descreve a abordagem iterativa e incremental, com sprints, priorização de requisitos e refinamento contínuo. Essa é a prática mais adequada para o contexto: permite entregar partes funcionais do sistema ao tribunal ao longo do desenvolvimento, obter feedback dos usuários e ajustar os requisitos a cada iteração. A engenharia de requisitos como processo contínuo é exatamente o que se espera em métodos ágeis, como Scrum. A alternativa está correta porque combina os elementos essenciais: ciclos curtos, priorização, refinamento e entrega incremental.

Alternativa D — ❌ Incorreta

A alternativa D foca na prototipação rápida, criando interfaces de baixa fidelidade para validar requisitos. Embora a prototipação seja uma técnica válida de elicitação e validação de requisitos, a alternativa a descreve de forma incompleta e distorcida: afirma que o ciclo de vida é definido após a aprovação do protótipo e que a documentação é gerada apenas ao final do projeto. Na prática, a prototipação é uma ferramenta dentro de um processo mais amplo, e a documentação deve ser produzida ao longo do desenvolvimento, não apenas no final. Além disso, a alternativa não menciona a entrega incremental de funcionalidades, que é um diferencial importante.

Alternativa E — ❌ Incorreta

A alternativa E descreve o modelo em V de forma incorreta. No modelo em V, os requisitos são validados em cada nível de desenvolvimento, por meio de testes correspondentes a cada fase (por exemplo, testes de aceitação validam os requisitos, testes de sistema validam o projeto, etc.). Não é correto afirmar que os requisitos são validados apenas na fase de testes, após a implementação completa. Além disso, a engenharia de requisitos não se resume à coleta inicial de informações; ela envolve análise, especificação, validação e gestão contínua. A alternativa distorce tanto o modelo em V quanto o processo de engenharia de requisitos.

Gabarito: letra C