Correto! A atividade que objetiva descobrir os requisitos é conhecida como elicitação e análise de requisitos. Essa atividade envolve a coleta e compreensão das necessidades dos stakeholders, a identificação e documentação dos requisitos funcionais e não funcionais, e a análise dos requisitos para garantir sua completude e consistência. A elicitação e análise de requisitos é uma etapa essencial no processo de engenharia de requisitos, pois estabelece a base para o desenvolvimento de um sistema ou software que atenda às necessidades dos usuários e das partes interessadas.

 priorização e negociação de requisitos.

 classificação e organização de requisitos.

<!DOCTYPE html>
<html lang="pt-BR">
<head>
 <meta charset="UTF-8">
 <style>
 body {
 font-size: 16px;
 line-height: 1.5;
 }
 .blue {
 color: blue;
 }
 math {
 font-size: 16px;
 }
 </style>
</head>
<body>
 A questão em análise aborda um problema que ocorreu no relacionamento entre a implementação do sistema e a manutenção do documento de requisitos. O enunciado descreve um cenário onde alterações foram primeiramente efetuadas no sistema e somente depois no documento de requisitos, enquanto algumas modificações foram esquecidas ou foram inseridas de modo inconsistente.
 
 
 Este cenário permite analisar a eficácia dos processos envolvidos na engenharia de requisitos, mais especificamente no gerenciamento de requisitos. A engenharia de requisitos compreende várias etapas que incluem:
 <ul>
 <li>Levantamento de requisitos: Onde os requisitos são inicialmente identificados.</li>
 <li>Análise de requisitos: Refinamento e elaboração detalhada dos requisitos.</li>
 <li>Classificação e organização de requisitos: Agrupamento e priorização de requisitos com base em critérios relevantes.</li>
 <li>Gerenciamento de requisitos: Processo de administrar as mudanças nos requisitos durante todo o projeto.</li>
 </ul>
 

 A falha descrita no enunciado está diretamente relacionada ao gerenciamento ineficaz dos requisitos. Alterações nos requisitos, depois de sua inicial aprovação, devem ser meticulosamente rastreadas e documentadas. A falta de um seguimento preciso, como descrito no texto, representa uma falha crítica no processo de gerenciamento de requisitos.
 

 Analisando cada alternativa:
 <ul>
 <li>A) Análise de requisitos: 
 Incorreta, porque trata do entendimento e refinamento dos requisitos, e o problema revelado não está na análise, mas no seguimento após mudanças no sistema.
 </li>
 <li>B) Priorização e negociação de requisitos:
 Incorreta, porque está associada à determinação do que é mais importante tratar primeiro e o que pode ser negociado, o que não é mencionado no cenário.
 </li>
 <li>C) Classificação e organização de requisitos:
 Incorreta, porque trata da organização e categorização dos requisitos, não do monitoramento ou acompanhamento das mudanças nos requisitos após a implementação.
 </li>
 <li>D) Levantamento de requisitos:
 Incorreta, porque está relacionada à fase inicial de descoberta de requisitos, e não ao que ocorre após a implementação.
 </li>
 <li>E) Gerenciamento de requisitos:
 Correta, pois envolve a maneira como as mudanças nos requisitos são monitoradas e mantidas consistentes com a implementação ao longo do desenvolvimento.
 </li>
 </ul>
 

 Portanto, a alternativa correta é E.
 

</body>
</html>

 dos níveis de maturidade 0 e 1, respectivamente.

 dos níveis de maturidade 2 e 3, respectivamente.

<!DOCTYPE html>
<html lang="pt-BR">
<head>
 <meta charset="UTF-8">
 <style>
 body {
 font-size: 16px;
 line-height: 1.5;
 }
 .blue {
 color: blue;
 }
 math {
 font-size: 16px;
 }
 </style>
</head>
<body>
 A questão está relacionada ao Capability Maturity Model Integration (CMMI) versão 1.3, especificamente ao modelo CMMI para Desenvolvimento (CMMI-DEV), onde o foco é em áreas de processo dentro de níveis de maturidade no desenvolvimento de software e produtos.
 

 O CMMI-DEV estabelece uma série de práticas para melhorar a maturidade de processos em organizações de desenvolvimento de software. Um elemento chave deste modelo são os níveis de maturidade, que se estendem de 1 a 5, descrevendo progressivamente processos mais sofisticados e previsíveis.
 

 As áreas de processo mencionadas na questão, REQM (Gerenciamento de Requisitos) e RD (Desenvolvimento de Requisitos), são fundamentais para o entendimento e gerenciamento adequado dos requisitos do projeto.
 

 Concentrando-se em cada alternativa:
 <ul>
 <li>A) do nível de maturidade 2.
 Esta alternativa é incorreta porque embora REQM faça parte do nível 2, RD pertence ao nível 3, demonstrando que a resposta precisa englobar ambos os níveis.
 </li>
 
 <li>B) dos níveis de maturidade 0 e 1, respectivamente.
 Incorreta porque nenhuma dessas áreas de processo pertence aos níveis 0 ou 1. Ambas estão em níveis mais elevados no CMMI-DEV.
 </li>
 
 <li>C) do nível de maturidade 4.
 Incorreta porque o nível 4 do CMMI-DEV lida primariamente com gestão de quantitativos e desempenho do processo, o que não inclui diretamente as áreas de REQM e RD.
 </li>
 
 <li>D) dos níveis de maturidade 2 e 3, respectivamente.
 Correta. REQM está no nível de maturidade 2, focado em gerenciar os requisitos dos projetos e dos produtos e garantir alinhamento com os planos e produtos de trabalho. RD está no nível 3, envolvendo a definição dos requisitos dos produtos e componentes de produto e a identificação de incoerências entre os requisitos, os planos do projeto e os produtos de trabalho.
 </li>
 
 <li>E) do nível de maturidade 3.
 Incorreta porque apenas a área RD é do nível 3, enquanto REQM é do nível 2.
 </li>
 
 </ul>
 

 Portanto, a alternativa correta é D.
 
</body>
</html>

Viewpoint-Oriented Requirements Elicitation (VORE ).

<!DOCTYPE html>
<html lang="pt-BR">
<head>
 <meta charset="UTF-8">
 <style>
 body {
 font-size: 16px;
 line-height: 1.5;
 }
 .blue {
 color: blue;
 }
 math {
 font-size: 16px;
 }
 </style>
</head>
<body>
Para analisar a questão proposta pelo Instituto Quadrix sobre a técnica de engenharia de requisitos, é essencial começar pelo entendimento de cada técnica mencionada nas alternativas e verificar qual delas corresponde à descrição fornecida no enunciado.
 

Segundo o enunciado, a técnica em questão promove a cooperação e entendimento mútuo entre usuários e desenvolvedores, visando uma visão compartilhada do produto de software. Além disso, seguem-se quatro princípios: dinâmica de grupo, uso de técnicas visuais, manutenção do processo organizado e racional e utilização de documentação padrão. A técnica é dividida nas etapas de planejamento e projeto, sendo cada uma dessas etapas composta pelas fases de adaptação, sessão e finalização.
 

As alternativas e suas análises são:
<ul>
 <li>
 A) Joint Application Design (JAD):
 É uma técnica empregada para facilitar a definição de requisitos do sistema e do software por meio de workshops que reúnem desenvolvedores e usuários. Essa técnica envolve múltiplos stakeholders num ambiente que promove a comunicação efetiva e o entendimento mútuo. Crescimentoi satisfaz o que foi mencionado no enunciado acerca dos princípios básicos e etapas.
 </li>
 
 <li>
 B) Brainstorming:
 Técnica utilizada para gerar uma grande quantidade de ideias em um curto período de tempo, baseada na coleta de ideias lançadas pelos participantes antes de serem discutidas e avaliadas. Embora promova o engajamento do grupo, não possui uma estrutura tão definida como as etapas descritas para JAD e não segue necessariamente a utilização de técnicas visuais ou documentação padrão.
 </li>
 
 <li>
 C) Viewpoint-Oriented Requirements Elicitation (VORE):
 Essa técnica se concentra na identificação de diferentes perspectivas ou "viewpoints" dos stakeholders para compreender melhor os requisitos do sistema. Não possui estrutura definida em etapas como o enunciado descreve e foca mais na diversidade de opiniões do que na dinâmica de grupo liderada.
 </li>
 
 <li>
 D) Ethnography:
 Uma técnica de pesquisa que envolve a observação dos usuários em seu ambiente natural para compreender como interagem com o sistema em questões do dia a dia. Mais uma vez, difere dos princípios e etapas apresentadas no enunciado quanto à estrutura organizada e formal.
 </li>
 
 <li>
 E) Workshop:
 Embora workshops sejam um formato utilizado em várias técnicas de elicitação de requisitos, por si só, não define claramente as fases e princípios citados no enunciado. Além disso, "workshop" é um termo mais genérico e pode não atingir todas as especificações mencionadas.
 </li>
 
</ul>
 

Portanto, a alternativa correta é A, Joint Application Design (JAD).
 

</body>
</html>

 Estabelecer e manter concordância com os clientes, e outros direta e indiretamente envolvidos, sobre o que o sistema deve fazer 

 A requisição de todos os recursos de software e hardware para a chefia mais imediata, antes da entrevista com os usuários 

 Requerer a autorização de desenvolvimento de sistemas pelas autoridades legais, governamentais e sindicatos patronais 

Elaborar software conforme os requisitos da Engenharia de Software, principalmente no padrão RUP (Rational Unified Process)

 Desenvolver o sistema conforme os requisitos estabelecidos pela declaração dos princípios do Manifesto Ágil

A alternativa correta é a alternativa (A) - Estabelecer e manter concordância com os clientes, e outros direta e indiretamente envolvidos, sobre o que o sistema deve fazer. Justificativa: A disciplina de requisitos de software na Engenharia de Software tem como principal finalidade estabelecer e manter a concordância entre os desenvolvedores e os clientes, bem como outras partes interessadas, sobre o que o sistema de software deve fazer. Essa disciplina envolve a elicitação, análise, documentação e validação dos requisitos do software, que são as funcionalidades, características e restrições que o sistema deve atender para satisfazer as necessidades dos usuários e das partes interessadas. As demais alternativas não representam as principais finalidades da disciplina de requisitos de software: - A alternativa (B) refere-se à requisição de recursos de software e hardware, mas não está relacionada diretamente à disciplina de requisitos de software. - A alternativa (C) menciona a necessidade de autorização de desenvolvimento de sistemas, mas não está relacionada à finalidade da disciplina de requisitos de software. - A alternativa (D) menciona o uso do processo de desenvolvimento RUP (Rational Unified Process), mas não especifica a finalidade da disciplina de requisitos de software. - A alternativa (E) menciona o desenvolvimento de sistemas conforme os princípios do Manifesto Ágil, mas não aborda especificamente a finalidade da disciplina de requisitos de software. Portanto, a alternativa correta é a (A) - Estabelecer e manter concordância com os clientes, e outros direta e indiretamente envolvidos, sobre o que o sistema deve fazer.

Questões de Tecnologia da Informação - Engenharia de Software - Engenharia de requisitos