Compartilhando | Teste 1: Análise de Requisitos de Software

#1. (CESPE – TCU/2015) Em todos os sistemas novos, o processo de engenharia de requisitos deve começar por um estudo de viabilidade.

Verdadeiro

Falso

#2. (FCC – 2010 – DPE-SP) Sobre análise de requisitos da engenharia de software, considere:
I. Os requisitos de usuário podem descrever tanto requisitos funcionais quanto requisitos não-funcionais.
II. Os requisitos de sistema podem descrever apenas requisitos não funcionais.
III. Os requisitos não-funcionais podem ser divididos em requisitos de produto, organizacionais e externos.
Está correto o que se afirma em

I e II, apenas.

II e III, apenas.

I, II e III.

III, apenas.

I e III, apenas.

#3. (FCC – 2010 – DPE-SP) Na Engenharia de Software, a frase “identificar os aspectos importantes, ignorando os detalhes” define o princípio

Decomposição.

Formalidade.

Flexibilização.

Generalização.

Abstração.

#4. (CESPE – 2008 – STJ) Os requisitos de um sistema podem ser descrições dos serviços fornecidos ou restrições operacionais. Requisitos podem ainda ser classificados como funcionais, não funcionais, ou de domínio. A engenharia de requisitos visa compreender e definir os requisitos. Um processo de engenharia de requisitos pode envolver o estudo de viabilidade, a análise, a especificação e a validação de requisitos.

Falso

Verdadeiro

#5. (CESPE – 2008 – STJ) Entre as atividades em um processo de projeto de software, pode-se ter: a identificação e a documentação dos subsistemas existentes e os seus relacionamentos; a especificação dos serviços providos por cada subsistema e das restrições de operação dos mesmos; a documentação da interface entre subsistemas; a especificação de estruturas de dados e algoritmos usados.

Falso

Verdadeiro

#6. (CESPE – 2013 – INPI) A engenharia de requisitos demonstrada na forma de espiral compõe-se de três fases: elicitação de requisitos (compreensão de requisitos funcionais e de usuário), especificação de requisitos (requisitos de usuário e de sistema) e validação de requisitos (estudo de viabilidade, prototipação e revisão).

Falso

Verdadeiro

#7. (CESPE – 2013 – TCE-RO) Na análise estruturada, o modelo criado representa o fluxo e o conteúdo da informação, dividido em partições funcionais e comportamentais. Na análise orientada a objetos, o objetivo é modelar os objetos do domínio do produto, seus relacionamentos e comportamentos

Verdadeiro

Falso

#8. (ESAF – 2004 – CGU) Analise as seguintes afirmações relativas à Engenharia de Software:
I. A análise de requisitos é responsável pela especificação dos requisitos de software e hardware que serão utilizados durante o processo de desenvolvimento de um sistema.
II. A análise de requisitos define a metodologia de programação a ser utilizada no desenvolvimento do sistema.
III. A especificação de requisitos fornece ao desenvolvedor e ao cliente os parâmetros para avaliar a qualidade logo que o sistema for construído.
IV. A análise de requisitos possibilita que o engenheiro de software especifique a função e o desempenho do sistema e estabeleça quais são as restrições de projeto que o sistema deve atender.
Estão corretos os itens:

I e II

II e III

III e IV

I e III

II e IV

#9. (CESPE – 2013 – INPI) De acordo com os princípios da engenharia de software relacionados à independência funcional, os algoritmos devem ser construídos por módulos visando unicamente ao alto acoplamento e à baixa coesão, caso a interface entre os módulos dê-se pela passagem de dados.

Verdadeiro

Falso

#10. (CESPE – 2013 – TCE-RO) De acordo com a evolução dos requisitos, estes podem ser classificados em permanentes, que são gerados nas fases iniciais do desenvolvimento, e voláteis, que surgem ao longo do processo de construção do software.

Verdadeiro

Falso

#11. (FURB – ISSBLU/2015) Num sistema web de comércio eletrônico, é considerado um exemplo típico de requisito não funcional:

O sistema deve suportar até dois mil acessos simultâneos.

O sistema deve permitir o cadastro de produtos e seus fornecedores.

O sistema deve calcular os descontos para clientes especiais.

O sistema deve permitir o pagamento de um pedido.

O sistema deve gerar um relatório de faturamento mensal.

#12. (FGV – IBGE/2016) Durante a fase de levantamento de requisitos do sistema financeiro do Banco SOJUROS, o analista João percebeu a necessidade de o cliente consultar sua conta. No início da consulta da conta, deve ser verificada a identidade do cliente. O Banco solicitou a utilização de dados biométricos para realizar essa identificação. João deve listar a necessidade de utilização de dados biométricos como: ? A correção aparecerá no rodapé da questão, caso você erre ou não selecione uma opção de resposta.

Requisito Funcional;

Padrão de Arquitetura;

Requisito Não Funcional;

Restrição de Integridade.

Regra de Negócio;

Em engenharia de software, um requisito funcional define uma função de um sistema de software ou seu componente. O requisito funcional representa o quê o software faz, em termos de tarefas e serviços.^[1] Uma função é descrita como um conjunto de entradas, seu comportamento e as saídas. Os requisitos funcionais podem ser cálculos, detalhes técnicos, manipulação de dados e de processamento e outras funcionalidades específicas que definem o que um sistema, idealmente, será capaz de realizar. Requisitos comportamentais, que descrevem todos os casos em que o sistema utiliza os requisitos funcionais, são extraídos dos casos de uso. Também, os requisitos funcionais são suportados por requisitos não-funcionais (também conhecidos como requisitos de qualidade), que impõem restrições sobre o projeto ou execução (tais como requisitos de desempenho, segurança ou confiabilidade). O plano para a implementação dos requisitos funcionais é detalhado no projeto do sistema. Já o plano para a implementação de requisitos não funcionais é detalhado na arquitetura do sistema.

Para ler mais sobre o assunto, acesse: Requisitos Funcionais e Requisitos Não-funcionais ( )

#13. (VUNESP – TCE-SP/2015) O gerenciamento de requisitos constitui-se em uma fase importante na engenharia de requisitos. Nesse gerenciamento, deve haver o acompanhamento e o conhecimento da origem dos requisitos do sistema, o que corresponde à propriedade de

rastreabilidade.

redundância.

durabilidade.

integridade.

atomicidade.

#14. (FCC – SEFAZ/SP/2013) A empresa Express conta com diversas equipes de desenvolvimento, nas áreas de software em geral, incluindo técnicas estruturadas e de orientação a objetos. Essas equipes estão em constante aperfeiçoamento, visando mantê-las sempre atualizadas com as técnicas mais recentes da engenharia de software, incluindo-se aí a área de bancos de dados.
A Express atende clientes de diversos perfis, abrangendo pequenas, médias e grandes empresas. Dessa forma, os sistemas de computação solicitados também atendem a esse perfil, compreendendo sistemas de pequeno, médio e grande porte.
A Express conta com equipes especializadas, de grande experiência nas áreas acima destacadas, estando, portanto, apta a atender desde um simples produto até um grande sistema de software. Dessa forma, os produtos desenvolvidos pela Express possuem, normalmente, uma qualidade bastante apurada, o que pode ser verificado pelas diversas técnicas existentes.
Uma das normas da Express é a de produzir documentação de excelente qualidade, cuja finalidade é, não apenas para entrega aos clientes, mas também para possibilitar a manutenção adequada dos produtos desenvolvidos.
A Express utiliza diversos ciclos de vida de desenvolvimento de software, conforme o acordo feito com cada cliente. Em se tratando dos ciclos de vida de desenvolvimento de software, a maioria dos processos considera, na etapa de especificação do software, as seguintes atividades a serem realizadas:
A − Especificação de Requisitos
B − Levantamento e Análise de Requisitos
C − Estudo de Viabilidade
D − Validação de Requisitos
A ordem indicada para a realização dessas atividades é

A – D – B – C.

B – A – D – C.

A – B – C – D.

D – A – B – C.

C – B – A – D.

#15. (CESPE – 2013 – TCE-RO) A gerência de requisitos deve manter a matriz de rastreabilidade atualizada para, caso o cliente solicite uma mudança, o item de configuração correspondente seja implementado.

Falso

Verdadeiro

#16. (CESPE – 2013 – TCE-RO) Após a identificação, os requisitos devem ser modelados para se obter uma melhor compreensão do produto a ser desenvolvido. Os principais paradigmas de modelagem de requisitos são análise estruturada e análise orientada a objetos.

Verdadeiro

Falso

#17. (CESPE – 2013 – TCE-RO) O desenvolvimento de requisitos é constituído por processos de elicitação de requisitos, análise e negociação de requisitos, especificação e modelagem dos requisitos e validação de requisitos.

Falso

Verdadeiro

#18. (CESPE – 2013 – TCE-RO) A rastreabilidade bidirecional deve ocorrer tanto de forma horizontal quanto vertical. A horizontal estabelece a dependência de um requisito-fonte até o nível de decomposição mais baixo do produto, enquanto a rastreabilidade vertical estabelece a dependência dos requisitos entre si

Verdadeiro

Falso

#19. (CESPE – 2013 – TCE-RO) Requisitos não funcionais do sistema podem influenciar o estilo e a estrutura escolhida para uma aplicação, pois a arquitetura de sistema afeta seu desempenho, sua distribuição e manutenção.

Verdadeiro

Falso

#20. (FCC – 2014 – TRF – 3ª REGIÃO) A figura abaixo mostra um diagrama com as atividades relativas ao levantamento de requisitos. O diagrama e a lacuna da caixa em branco referem-se, respectivamente, aos diagramas UML de

Fluxo de Dados e Atividade.

Sequência e Casos de Uso.

Componentes e Atividade.

Atividade e Casos de Uso.

Requisitos e Classes.

#21. (UEL/COPS – UEL/2015) Sobre projetos de software e gerência de projetos, considere as afirmativas a seguir.
I. Modelos em cascata são utilizados para capturar o que um sistema deve fazer.
II. A coleta de requisitos pode incluir entrevistas com possíveis usuários do sistema.
III. Os requisitos de sistema servem para orientar os projetistas de sistemas.
IV. O ciclo de vida especifica as etapas pelas quais um software passa em seu desenvolvimento.
Assinale a alternativa correta.

Somente as afirmativas III e IV são corretas.

Somente as afirmativas II, III e IV são corretas.

Somente as afirmativas I e II são corretas.

Somente as afirmativas I e IV são corretas.

Somente as afirmativas I, II e III são corretas.

#22. (FCC – 2014 – TRF – 3ª REGIÃO) A figura abaixo mostra um diagrama com as atividades relativas ao levantamento de requisitos. O diagrama e a lacuna da caixa em branco referem-se, respectivamente, aos diagramas UML de

Atividade e Casos de Uso.

Sequência e Casos de Uso.

Fluxo de Dados e Atividade.

Requisitos e Classes.

Componentes e Atividade.

#23. (CESPE – 2013 – TCE-RO) Requisitos não funcionais do sistema podem influenciar o estilo e a estrutura escolhida para uma aplicação, pois a arquitetura de sistema afeta seu desempenho, sua distribuição e manutenção.

Falso

Verdadeiro

#24. (CESPE/UnB – TCDF/ANAP – 2014) Um protótipo de sistema auxilia na validação de requisitos, no projeto de interface com o usuário, podendo, ainda, ser usado para a realização de testes. ? A correção aparecerá no rodapé da questão, caso você erre ou não selecione uma opção de resposta.

Verdadeiro

Falso

Protótipos são modelos construídos para simular a aparência e a funcionalidade de um produto em desenvolvimento. Funciona como uma representação da interface com a qual o usuário pode interagir e oferecer informações para propor mudanças e melhorias (validação e testes).

Para ler mais sobre o assunto, acesse: Prototipagem ( )

#25. (FCC – 2014 – TRF – 3ª REGIÃO) Considere as seguintes atividades:
1. Compreensão do domínio: os analistas devem desenvolver sua compreensão do domínio da aplicação.
2. Coleta de requisitos: processo de interagir com os stakeholders do sistema para descobrir seus requisitos.
3. Classificação: atividade que considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes.
4. Resolução de conflitos: Solucionar conflitos decorrentes do envolvimento de múltiplos stakeholders.
5. Definição das prioridades: envolve a interação com os stakeholders para a definição dos requisitos mais importantes.
6. Descarte de requisitos: atividade de descartar requisitos menos importantes, baseando-se nas indicações dos stakeholders.
7. Verificação de requisitos: os requisitos são verificados para descobrir se estão completos e consistentes e se estão em concordância com o que os stakeholders desejam do sistema.
8. Modelagem de requisitos: os requisitos são modelados utilizando-se o diagrama de casos de uso e de sequência da UML.
Faz parte do processo de levantamento e análise de requisitos o que consta em APENAS 1, 2,

3, 4, 5, 7 e 8.

3, 4, 6 e 8.

4, 5, 7 e 8.

3, 4, 5, 6.

3, 4, 5 e 7.

#26. (FCC – 2012 – TCE-AP) Em relação a requisitos de sistemas, considere:
I. O modo como um sistema deve reagir a certas entradas e o comportamento em que o sistema deve ter em certas situações e, em alguns casos, especificar o que o sistema não deve fazer, são chamados de requisitos não-funcionais.
II. As restrições aos serviços ou funções de um sistema, como, por exemplo, processos de desenvolvimento ou utilização de padrões, são requisitos de funcionamento do sistema ou requisitos funcionais.
III. Requisitos que vem do domínio da aplicação do sistema e refletem características ou restrições para aquele domínio são chamados de requisitos de domínio e podem ser requisitos funcionais e/ou não-funcionais.
Está correto o que se afirma em

II e III, apenas.

I e II, apenas.

III, apenas

I, apenas.

I, II e III.

#27. (CESGRANRIO – 2010 – IBGE) Com o objetivo de minimizar os problemas enfrentados e melhorar o processo de engenharia de requisitos, um engenheiro de requisitos decidiu elencar uma série de medidas que poderá empregar em seus futuros projetos, tais como:
I – aplicar a técnica de IFQ (Implantação da Função de Qualidade) que permite coletar os requisitos excitantes, os quais refletem características que vão além das expectativas do cliente e mostram ser muito satisfatórios quando presentes;
II – utilizar tabelas de rastreamento que relacionam os requisitos identificados a um ou mais aspectos do sistema;
III – utilizar casos de uso para fazer uma coleta iterativa de requisitos, uma vez que o processo de levantamento de requisitos é uma atividade evolutiva.
Está(ão) correta(s) a(s) medida(s)
? A correção aparecerá no rodapé da questão, caso você erre ou não selecione uma opção de resposta.

I, apenas.

II, apenas.

I, II e III.

I e II, apenas

III, apenas.

I- A Implantação da Função de Qualidade (IFQ), em inglês Quality Function Deployment (QFD), é uma técnica que traduz as necessidades do cliente para requisitos técnicos do software. A IFQ concentra-se em maximizar a satisfação do cliente a partir do processo de engenharia de software (ZUL92). Para conseguir isso, a IFQ enfatiza o entendimento do que tem valor para o cliente e depois implanta esses valores por meio do processo de engenharia. A IFQ identifica três tipos de requisitos:

requisitos normais: esses requisitos refletem os objetivos e metas estabelecidos para um produto ou sistema durante as reuniões com o cliente. Se esses requisitos estiverem presentes, o cliente fica satisfeito (gráficos requeridos, funções específicas do sistema e níveis de desempenho definidos);
requisitos esperados: esses requisitos estão implícitos no produto ou sistema e podem ser tão fundamentais que o cliente não se refere a eles explicitamente. Sua ausência seria causa de insatisfação significativa (facilidade de interação homem/máquina, correção e confiabilidade operacional global e facilidade de instalação do software);
requisitos instigantes: esses requisitos refletem características que vão além das expectativas do cliente e mostram ser muito satisfatórias quando presentes.

Para ler mais sobre o assunto, acesse: Implantação da Função de Qualidade ( )

II- A gestão de requisitos começa com a identificação. A cada requisito é atribuído um modo identificador. Uma vez identificados os requisitos, tabelas de rastreamento são desenvolvidas.

Para ler mais sobre o assunto, acesse: Gestão de Requisitos – Rastreamento de Requisitos ( )

III- À medida que os requisitos são coletados, uma visão geral das funções e características do sistema começam a se materializar. No entanto, é difícil avançar para atividades mais técnicas de engenharia de software até que a equipe de software entenda como essas funções e características serão usadas por diferentes classes de usuários finais. Para tanto, desenvolvedores e usuários podem criar um conjunto de cenários que identifiquem uma linha de uso para o sistema a ser construído. Os cenários, frequentemente chamados de Casos de Uso ( ), fornecem uma descrição de como o sistema será usado.

Para ler mais sobre o assunto, acesse: Cenários de Usuários ( )

#28. (FCC – 2011 – INFRAERO) Os produtos de trabalho resultantes da engenharia de requisitos são avaliados quanto à qualidade durante a etapa de validação de requisitos. Analise os itens a seguir referentes a essa etapa:
I. Um dos principais mecanismos de validação de requisitos é a avaliação técnica formal.
II. O modelo de análise pode garantir que os requisitos foram consistentemente declarados.
III. É frequentemente útil examinar cada requisito em face de um conjunto de questões do tipo checklist.
IV. A equipe de revisão que avalia os requisitos inclui apenas pessoas com conhecimento técnico na área de TI, como engenheiros de softwares, desenvolvedores etc.
Está correto o que consta em

II, III e IV, apenas.

I, II e IV, apenas.

II e IV, apenas.

I, II e III, apenas.

I, II, III e IV.

#29. (FCC – 2011 – INFRAERO) A engenharia de requisitos ajuda os engenheiros de software a compreender melhor o problema que eles vão trabalhar para resolver. Ela inclui um conjunto de tarefas que levam a um entendimento de qual será o impacto do software sobre o negócio, do que o cliente quer e de como os usuários finais vão interagir com o software. A função de negociação no processo de engenharia de requisitos

refina e modifica os requisitos. É uma ação de modelagem de análise composta de várias tarefas de modelagem e refinamento.

ajuda o cliente a definir o que é necessário.

especifica, revisa e valida o problema de modo a garantir que seu entendimento e o entendimento do cliente sobre o problema coincidam.

define quais são as prioridades, o que é essencial, o que é necessário. Clientes, usuários e outros interessados são solicitados a ordenar os requisitos e depois discutir os conflitos de prioridade.

define o escopo e a natureza do problema a ser resolvido.

#30. (CESPE – 2013 – TCE-RO) A fase de análise define os requisitos do cliente, conforme as necessidades de negócio, e as considerações técnicas envolvidas, que se agrupam em uma solução tecnológica, compõem a fase de projeto de software.

Falso

Verdadeiro

Teste 1: Análise de Requisitos de Software

Material de Estudo Disponível

Teste 1: Análise de Requisitos de Software

Results

#1. (CESPE – TCU/2015) Em todos os sistemas novos, o processo de engenharia de requisitos deve começar por um estudo de viabilidade.

#3. (FCC – 2010 – DPE-SP) Na Engenharia de Software, a frase “identificar os aspectos importantes, ignorando os detalhes” define o princípio

#10. (CESPE – 2013 – TCE-RO) De acordo com a evolução dos requisitos, estes podem ser classificados em permanentes, que são gerados nas fases iniciais do desenvolvimento, e voláteis, que surgem ao longo do processo de construção do software.

#11. (FURB – ISSBLU/2015) Num sistema web de comércio eletrônico, é considerado um exemplo típico de requisito não funcional:

#13. (VUNESP – TCE-SP/2015) O gerenciamento de requisitos constitui-se em uma fase importante na engenharia de requisitos. Nesse gerenciamento, deve haver o acompanhamento e o conhecimento da origem dos requisitos do sistema, o que corresponde à propriedade de

#15. (CESPE – 2013 – TCE-RO) A gerência de requisitos deve manter a matriz de rastreabilidade atualizada para, caso o cliente solicite uma mudança, o item de configuração correspondente seja implementado.

#16. (CESPE – 2013 – TCE-RO) Após a identificação, os requisitos devem ser modelados para se obter uma melhor compreensão do produto a ser desenvolvido. Os principais paradigmas de modelagem de requisitos são análise estruturada e análise orientada a objetos.

#17. (CESPE – 2013 – TCE-RO) O desenvolvimento de requisitos é constituído por processos de elicitação de requisitos, análise e negociação de requisitos, especificação e modelagem dos requisitos e validação de requisitos.

#19. (CESPE – 2013 – TCE-RO) Requisitos não funcionais do sistema podem influenciar o estilo e a estrutura escolhida para uma aplicação, pois a arquitetura de sistema afeta seu desempenho, sua distribuição e manutenção.

#20. (FCC – 2014 – TRF – 3ª REGIÃO) A figura abaixo mostra um diagrama com as atividades relativas ao levantamento de requisitos. O diagrama e a lacuna da caixa em branco referem-se, respectivamente, aos diagramas UML de

#22. (FCC – 2014 – TRF – 3ª REGIÃO) A figura abaixo mostra um diagrama com as atividades relativas ao levantamento de requisitos. O diagrama e a lacuna da caixa em branco referem-se, respectivamente, aos diagramas UML de

#23. (CESPE – 2013 – TCE-RO) Requisitos não funcionais do sistema podem influenciar o estilo e a estrutura escolhida para uma aplicação, pois a arquitetura de sistema afeta seu desempenho, sua distribuição e manutenção.

#30. (CESPE – 2013 – TCE-RO) A fase de análise define os requisitos do cliente, conforme as necessidades de negócio, e as considerações técnicas envolvidas, que se agrupam em uma solução tecnológica, compõem a fase de projeto de software.

Deixe uma resposta Cancelar resposta