<!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>
 No campo da engenharia de requisitos, a capacidade de identificar a origem de problemas de sistema após a implantação é crucial para garantir a eficácia dos processos de desenvolvimento. Essa disciplina de engenharia enfoca a correta definição e gerenciamento dos requisitos de sistemas de software.
 
 
 O problema apresentado na questão descreve uma situação em que um sistema, após ser implantado, não conseguiu atender eficazmente às necessidades de análise gerencial por parte da empresa cliente, apesar de todos os requisitos documentados terem sido atendidos e os padrões organizacionais terem sido seguidos. Isso sugere um problema de validação de requisitos.
 
 
 Análise das Alternativas:
 
 <ul>
 <li>A) Levantamento de Requisitos:
 Esta etapa envolve a coleta inicial de requisitos. No entanto, o problema não parece estar na coleta, mas na adequação e verificação dos requisitos em relação às necessidades reais de negócio.
 </li>
 
 <li>B) Análise de classes:
 Está mais relacionada com a modelagem e o design estrutural do software do que com a validação da funcionalidade em relação às expectativas do cliente.
 </li>
 
 <li>C) Documentação de Requisitos:
 Embora fundamental para o processo, a simples documentação dos requisitos não garante que eles foram validados ou testados contra as necessidades reais do negócio. A falha descrita mais parece relacionada à aplicação dos requisitos documentados.
 </li>
 
 <li>D) Validação de Requisitos:
 Essa etapa envolve a confirmação de que os requisitos atendem às necessidades dos usuários e do negócio. É nesse estágio que se deveria ter identificado que o sistema, embora atendendo aos requisitos especificados, não forneceria análises gerenciais apropriadas para a tomada de decisão.
 </li>
 
 <li>E) Avaliação de Entradas e Saídas:
 Ainda que relevante, esta etapa é mais técnica e focada no funcionamento prático do sistema do que na sua adequação estratégica às necessidades de negócio.
 </li>
 
 </ul>
 
 
 Concluindo, a validação de requisitos é uma etapa essencial no processo de desenvolvimento de software que assegura a conformidade do produto final com as expectativas e necessidades do usuário final. No contexto da questão, onde o sistema não pôde fornecer análises gerenciais úteis apesar de tecnicamente cumprir os requisitos, o problema evidencia uma falha na validação de requisitos, onde essas necessidades deveriam ter sido mais completamente avaliadas e testadas.
 
 
 Portanto, a alternativa correta é D.
 

</body>
</html>

<!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 Gerência de Requisitos é um componente crucial em engenharia de software, fundamental para alcançar os objetivos de desenvolvimento de forma eficiente e eficaz. Envolve a identificação, organização, documentação e acompanhamento dos requisitos ao longo do projeto. Uma das práticas essenciais na gerência de requisitos é a rastreabilidade.
 

 Rastreabilidade refere-se à capacidade de documentar a linha do tempo dos requisitos através de todas as fases do projeto, desde sua concepção até a implementação final. Ela permite que os desenvolvedores e gestores de projeto possam verificar como cada requisito influencia outras partes do sistema, e vice-versa. Importante destacar, ela possibilita uma "progressão progressiva em direção aos requisitos", o que significa um movimento ordenado e bem definido através das várias fases de destrinchamento e especificação dos requisitos.
 

 As alternativas fornecidas para a questão são:
 <ul>
 <li>A) Rastreabilidade: Esta opção é a mais correta para completar a lacuna na pergunta. Ao falar de progressão progressiva em direção aos requisitos, a rastreabilidade é um conceito que se encaixa perfeitamente, pois é essencial para acompanhar os requisitos ao longo de todo o projeto.</li>
 
 <li>B) Gerência: Apesar de estar diretamente relacionada ao conceito de rastreabilidade, a palavra "gerência" em si é ampla demais e não especifica como a progressão dos requisitos é realizada de forma progressiva.</li>
 
 <li>C) Análise: A análise de requisitos é importante para entender cada requisito, mas não cobre especificamente o aspecto progressivo mencionado na pergunta, que é melhor representado pela rastreabilidade.</li>
 
 <li>D) Validação: Validar os requisitos é essencial para garantir que atendam às necessidades do usuário; no entanto, não é o termo correto para descrever a progressão progressiva, pois foca mais na correção dos requisitos em relação às necessidades do usuário.</li>
 
 <li>E) Conformidade: Conformidade garante que os requisitos estejam de acordo com normas e regulamentos, mas novamente, não aborda diretamente a progressão dos requisitos ao longo do tempo.</li>
 
 </ul>
 

 Portanto, a alternativa correta é A.
 

</body>
</html>

<!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 resolver essa questão sobre a engenharia de requisitos e o modelo entidade relacionamento (MER), vamos primeiro entender a estrutura e os relacionamentos detalhados no cenário proposto.
 

 O enunciado descreve um sistema de controle de empréstimos de DVDs, onde existem cadastros de filmes, autores, clientes e empréstimos de DVDs. Especificamente, é mencionado um relacionamento entre as entidades Filme e Autor.
 

 Um Filme pode ser associado a um ou mais Autores e, inversamente, um Autor pode estar associado a um ou mais Filmes. Este tipo de relacionamento é conhecido como muitos-para-muitos, ou N:N.
 

 <ul>
 <li>A) 1:N: 
 Incorreta porque sugere que um autor está vinculado a um único filme ou um filme possui vários autores, mas não ambos vice-versa, o que contradiz o enunciado.
 </li>
 
 <li>B) N:N: 
 Correta por representar que tanto autores quanto filmes podem ter múltiplas associações um com o outro, o que está em conformidade com o enunciado que descreve que um autor pode estar vinculado a vários filmes e vice-versa.
 </li>
 
 <li>C) N:1: 
 Incorreta porque sugere que vários filmes podem estar associados a um único autor, mas não permite que um autor possa estar associado a múltiplos filmes, o que não se alinha com o cenário proposto.
 </li>
 
 <li>D) Chave Primária: 
 Incorreta porque esta opção refere-se a um conceito de banco de dados usado para identificar de maneira única cada registro de uma tabela, o que não se aplica ao tipo de relação entre entidades descritas no enunciado.
 </li>
 
 <li>E) Chave Secundária: 
 Incorreta visto que envolve conceitos de identificação e referência em banco de dados para relações de entidades, mas a questão especificamente pergunta sobre o tipo de relação entre filmes e autores.
 </li>
 
 </ul>
 

 Portanto, a alternativa correta é B.
 

</body>
</html>

 funcional, não funcional, não funcional e funcional.

 funcional, técnico, de sistema e não funcional.

 não funcional, não funcional, técnico e de sistema.

 não funcional, de usuário, técnico e funcional.

 funcional, técnico, de usuário e não funcional.

Os requisitos de software podem ser classificados em diferentes tipos, dependendo do aspecto que abordam. Analisando as especificações dadas: I. O sistema deve calcular a dívida do contribuinte aplicando a alíquota de 15% quando o lucro ultrapassar o teto de contribuição. Tipo: FuncionalII. O tempo de resposta da consulta à dívida ativa da empresa não deve ultrapassar os 13 ms em situações normais de processamento. Tipo: Não funcionalIII. O SLA (Acordo de Nível de Serviço) com o contribuinte consulente deve prever jornada de 24 horas/dia × 7 dias por semana. Tipo: Não funcionalIV. A tela de consulta à dívida ativa só pode ser acessada mediante login e senha corretos correspondentes àqueles designados ao CNPJ do contribuinte consulente. Tipo: FuncionalPortanto, os requisitos são, correta e respectivamente: funcional, não funcional, não funcional e funcional.

Os requisitos não funcionais solicitados pelo cliente devem ser classificados pelo Grupo de Desenvolvimento de Software (GDS) como requisitos "externos". Isso se deve ao fato de que esses requisitos dizem respeito a preocupações externas ao funcionamento direto do aplicativo, como conformidade com legislações de privacidade e proteção de dados, e não afetam diretamente a funcionalidade principal do produto, mas são essenciais para garantir sua legalidade e segurança. Portanto, a resposta correta é a opção (A) - "externos".

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