Questão de Engenharia de Software — Geral — FCC 2025
Engenharia de Software›Geral
Código
fc150561
Banca
FCC
Órgão
TRT 2
Ano
2025
Cargo
TJ TRT2
Uma nova solução de software está sendo desenvolvida em um Tribunal do Trabalho para gerenciar os acordos coletivos firmados entre sindicatos e empresas. Durante a elaboração dos requisitos, a equipe precisa definir claramente requisitos funcionais e não funcionais, envolvendo usuários finais, advogados especializados e analistas.
Considerando as boas práticas de Engenharia de Requisitos, para garantir a qualidade e a completude dos requisitos coletados, deve-se
Autilizar técnicas complementares de elicitação, como prototipação, análise de documentos e QFD (Quality Function Deployment), para capturar de forma abrangente tanto requisitos explícitos quanto latentes, aumentando a precisão das especificações.
Bconcentrar a elicitação em entrevistas com especialistas jurídicos, uma vez que as regras de negócio são fortemente baseadas na legislação vigente e, portanto, menos suscetíveis a variações de uso pelos demais usuários.
Cpriorizar os requisitos não funcionais durante as primeiras reuniões, garantindo que aspectos como desempenho e segurança estejam definidos antes de discutir as funcionalidades.
Dadotar um processo iterativo de validação de requisitos, como a análise de protocolos, realizando rodas de conversas com usuários e especialistas, para garantir a obtenção de informações confiáveis dentre os diferentes stakeholders.
Eaplicar a técnica JAD (Joint Application Deployment), realizando entrevistas individuais com representantes de cada área, evitando reuniões conjuntas para prevenir conflitos entre as visões dos stakeholders.
Revelar gabarito e comentário▾
GabaritoA — utilizar técnicas complementares de elicitação, como prototipação, análise de documentos e QFD (Quality Function Deployment), para capturar de forma abrangente tanto requisitos explícitos quanto latentes, aumentando a precisão das especificações.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Elicitação de Requisitos: técnicas complementares para capturar requisitos explícitos e latentes
Gabarito: letra A. A alternativa A é a correta porque reflete a boa prática de Engenharia de Requisitos de combinar técnicas complementares de elicitação — como prototipação, análise de documentos e QFD — para capturar tanto requisitos explícitos quanto latentes, aumentando a precisão das especificações. Essa abordagem é defendida por autores clássicos como Sommerville e Pressman, que recomendam o uso de múltiplas técnicas para obter uma visão abrangente das necessidades dos stakeholders.
A elicitação de requisitos é a primeira atividade da Engenharia de Requisitos, responsável por descobrir as necessidades dos stakeholders e as restrições do sistema. Ela envolve interação com usuários, clientes e demais envolvidos, além da análise de documentos e do ambiente. O objetivo é identificar tanto os requisitos explícitos (aqueles que os stakeholders conseguem expressar diretamente) quanto os latentes (aqueles que não são ditos, mas que são essenciais para o sucesso do sistema).
Para garantir a completude, a boa prática é não depender de uma única técnica, mas sim combinar várias, pois cada uma tem pontos fortes e limitações. Por exemplo:
Entrevistas: boas para obter informações diretas, mas podem não revelar requisitos implícitos.
Prototipação: permite que os usuários visualizem o sistema e identifiquem necessidades que não conseguiriam expressar abstratamente.
Análise de documentos: útil para extrair requisitos de manuais, regulamentos e sistemas legados.
QFD (Quality Function Deployment): técnica que traduz as necessidades do cliente em requisitos técnicos, priorizando-os com base na importância para o cliente.
Etnografia: observação do ambiente de trabalho para descobrir requisitos implícitos.
JAD (Joint Application Development): workshops com stakeholders para discutir e definir requisitos em conjunto.
A combinação dessas técnicas aumenta a precisão e reduz o risco de requisitos incompletos ou ambíguos. Além disso, a validação dos requisitos é um processo contínuo, que deve envolver os stakeholders para garantir que as especificações reflitam suas reais necessidades.
A banca explora aqui a complementaridade das técnicas como critério decisivo: a alternativa correta é a que reconhece a necessidade de usar múltiplas abordagens, enquanto as incorretas propõem uma única técnica ou uma abordagem equivocada.
Elicitação de requisitos
1Técnicas complementares
Entrevistas
Prototipação
Análise de documentos
QFD
Etnografia
JAD (workshop em grupo)
2Tipos de requisitos
Explícitos (ditos)
Latentes (implícitos)
3Boa prática
Combinar múltiplas técnicas
Envolver todos os stakeholders
Evitar técnica única
LEVEL · soulevel.com.br
Alternativa A — ✅ Correta ⟵ GABARITO
A alternativa A está correta porque recomenda utilizar técnicas complementares de elicitação, como prototipação, análise de documentos e QFD, para capturar tanto requisitos explícitos quanto latentes. Essa é a prática recomendada na Engenharia de Requisitos, pois cada técnica tem limitações e a combinação delas aumenta a abrangência e a precisão das especificações. A prototipação ajuda a revelar requisitos que os usuários não conseguem expressar abstratamente; a análise de documentos extrai requisitos de fontes existentes; e o QFD prioriza as necessidades do cliente, traduzindo-as em requisitos técnicos.
Alternativa B — ❌ Incorreta
A alternativa B está incorreta porque concentrar a elicitação apenas em entrevistas com especialistas jurídicos é uma abordagem limitada. Embora as regras de negócio sejam baseadas na legislação, os usuários finais (como os servidores que operarão o sistema) têm necessidades práticas que não podem ser capturadas apenas com especialistas jurídicos. A boa prática é envolver todos os stakeholders e usar múltiplas técnicas, não apenas entrevistas com um grupo específico.
Alternativa C — ❌ Incorreta
A alternativa C está incorreta porque priorizar requisitos não funcionais antes de discutir funcionalidades não é uma prática recomendada. Os requisitos funcionais e não funcionais devem ser elicitados de forma integrada, pois os não funcionais (como desempenho e segurança) dependem das funcionalidades que o sistema deve oferecer. Não há uma ordem rígida que coloque os não funcionais antes dos funcionais; ambos devem ser considerados em conjunto durante o processo de elicitação.
Alternativa D — ❌ Incorreta
A alternativa D está incorreta porque análise de protocolos não é uma técnica de validação de requisitos, mas sim uma técnica de elicitação que envolve a observação do usuário executando tarefas e verbalizando seu raciocínio. Além disso, a descrição de "rodas de conversas" não corresponde a uma técnica formal de validação. A validação de requisitos é feita por meio de revisões, prototipação e testes de aceitação, não por análise de protocolos.
Alternativa E — ❌ Incorreta
A alternativa E está incorreta porque JAD (Joint Application Development) é uma técnica que envolve workshops com todos os stakeholders em conjunto, não entrevistas individuais. O objetivo do JAD é justamente reunir as partes interessadas para discutir e resolver conflitos de requisitos em grupo, promovendo a colaboração. A alternativa inverte o conceito ao afirmar que evita reuniões conjuntas, o que contraria a essência da técnica.
NÃO CAIA NESSA!
A banca explora a confusão entre JAD e entrevistas individuais. O JAD é uma técnica de workshop em grupo, não de entrevistas individuais. Lembre-se: JAD = Joint Application Development (não "Deployment"), e sua essência é a reunião conjunta de stakeholders para definir requisitos.
PEGA ESSA DICA!
Para questões de elicitação, lembre-se de que a complementaridade de técnicas é a chave. Quando a alternativa propõe usar apenas uma técnica ou um grupo restrito de stakeholders, desconfie. A boa prática é combinar métodos como entrevistas, prototipação, análise de documentos, etnografia e QFD para capturar requisitos explícitos e latentes.