Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

TECNOLOGIA DA INFORMAÇÃO > Arquitetura e análise de requisitos para sistemas analíticos > Flashcards

Arquitetura e análise de requisitos para sistemas analíticos Flashcards

1
Q

Os requisitos de software podem ser classificados quanto à:

A
  • nível de abstração
  • qualidade
  • evolução
  • funcionalidade
  • origem
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

O que é abstração?

A

A subtração de detalhes.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

A classificação quanto á abstração de sistemas se divide em:

A
  • Requisitos de Usuário
  • Requisitos de Sistema
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

CERTO OU ERRADO

O requisito de usuário é mais abstrato que o requisito de sistema.

A

CERTO!

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Os Requistos de Usuários são descrições, em linguagem (1) e com (2), de quais serviços o sistema deve (3) e as restrições sob as quais deve (4). São requisitos com alto nível de abstração, ou seja, pouco nível de (5), feitos para serem lidos por pessoas (6).

A

Os Requistos de Usuários são descrições, em linguagem natural e com diagramas, de quais serviços o sistema deve fornecer e as restrições sob as quais deve operar. São requisitos com alto nível de abstração, ou seja, pouco nível de detalhes, feitos para serem lidos por pessoas leigas.
ex: o sistema deve gerar um relatório de acompanhamento mensal e enviar para os usuários por e-mail, ou seja, pouco nível de detalhe

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Os Requisitos de Usuários podem ser:

A

funcionais ou não funcionais.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Os Requisitos de Sistema são descrições detalhadas sobre as funções, operações e restrições de sistema que definem o que deve ser (1) de forma (2). São requisitos com baixo nível de abstração, ou seja, com (3), feitos para serem lidos por pessoas (4).

A

Os Requisitos de Sistema descrições detalhadas sobre as funções, operações e restrições de sistema que definem o que deve ser implementados de forma exata. São requisitos com baixo nível de abstração, ou seja, com muitos detalhes, feitos para serem lidos por pessoas experientes.
ex: o sistema deve gerar um relatório com índices a partir de views materializadas gerados a partir de um banco multidimensional, ou seja, bem mais técnico e detalhado

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

CERTO OU ERRADO

Ao escrever requisitos, deve-se considerar quem serão seus leitores e, portanto, diferentes níveis de detalhamento.

A

CERTO! Cada leitor tem seu nível de conhecimento.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

A Quality Function Deployment (QFD) (Disponibilização da Função de Qualidade), trata-se de uma técnica de gestão da qualidade aplicada ao levantamento de requisitos que traduz as (1) do cliente em requisitos (2) buscando maximizar a (3) do cliente e enfatizando o entendimento do que é (4) para o cliente.

A

A Quality Function Deployment (QFD) (Disponibilização da Função de Qualidade), trata-se de uma técnica de gestão da qualidade aplicada ao levantamento de requisitos que traduz as necessidades do cliente em requisitos técnicos buscando maximizar a satisfação do cliente e enfatizando o entendimento do que é valioso para o cliente.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

A Quality Function Deployment (QFD) (Disponibilização da Função de Qualidade) possui três tipos de requisitos:

A
  • Requisitos Normais
  • Requisitos Específicos
  • Requisitos Fascinantes
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Os Requisitos Normais são os (1) e (2) estabelecidos para um produto ou sistema durante (3) com o cliente.

A

Os Requisitos Normais são os objetivos e metas estabelecidos para um produto ou sistema durante reuniões com o cliente.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

CERTO OU ERRADO

Os Requisitos Normais de qualidade do sistema são aqueles comuns, em que, estando presentes, o cliente fica satisfeito.

A

CERTO!
tipos de displays gráficos solicitados, funções de sistema específicas e níveis de desempenho definidos

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Os Requisitos Esperados de qualidade do sistema estão (1) no produto ou sistema e podem ser tão fundamentais que o cliente não os declare (2). Sua ausência será causa de (3).

A

Os Requisitos Esperados de qualidade do sistema estão implícitos no produto ou sistema e podem ser tão fundamentais que o cliente não os declare explicitamente. Sua ausência será causa de grande insatisfação.
ex: facilidade na interação homem-máquina, confiabilidade e correção operacional global e facilidade na instalação do software.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Os Requisitos Fascinantes de qualidade do sistema são os recursos que vão:

A

além da expectativa dos clientes e demonstram ser muito satisfatórios quando presentes.
o software para um novo celular vem com recursos-padrão, mas junto vem um conjunto de capacidades não esperadas: tela multi-toque, correio de voz visual para cegos

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Na classificação quanto à evolução de sistemas, estes podem ser:

A
  • Requisitos Permanentes
  • Requisitos Voláteis
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Os Requisitos Permanentes estão diretamente ligados a:

A

atividade principal da organização.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Os Requisitos Permanentes, em geral, são derivados do:

A

Modelo de Domínio.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

CERTO OU ERRADO

Os Requisitos Permanentes possuem esse nome porque são imutáveis.

A

ERRADO! Recebem esse nome porque são mais estáveis e que mudam pouco ou demoram bastante para mudar.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

EXEMPLO DE REQUISITO PERMANENTE

Um sistema da Bolsa de Valores – existam sempre requisitos relacionados a ações, câmbio, cotações, índices, etc.
Se, daqui vinte anos, um outro sistema for feito para a Bolsa de Valores, é bem provável que continue existindo requisitos relacionados a ações, câmbio, cotações, índices, etc. Pode mudar uma coisa ou outra, mas esses requisitos são mais estáveis com o passar do tempo.

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Instanciação é o processo de:

A

ler ou especificar informações.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Os Requisitos Voláteis também chamados de Requisitos (1), são específicos para a (2) de um sistema em um (3) ou um (4) e são mais propensos a (5).

A

Os Requisitos Voláteis também chamados de Requisitos Instáveis, são específicos para a instanciação de um sistema em um ambiente ou um cliente particular e são mais propensos a mudança.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

CERTO OU ERRADO

Os Requisitos Voláteis podem se modificar quando o sistema está em desenvolvimento ou em uso.

A

CERTO!

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

O Requisitos Voláteis podem ser subclassificados em:

A
  • mutáveis
  • emergentes
  • consequentes
  • de compatibilidade
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Os Requisitos Voláteis Mutáveis são os requisitos que se modificam em função de:

A

mudança no ambiente em que operam.
ex: os requisitos para um sistema que calcula taxas de dedução que evoluem conforme as leis fiscais são atualizadas (muito comum no Brasil).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Os Requisitos Voláteis Emergentes são os requisitos que não podem ser completamente definidos quando o sistema é (1) e emergem (olha a dica!) à medida que a compreensão do cliente sobre o sistema se (2). Em geral, aparecem durante a fase de (3).

A

Os Requisitos Voláteis Emergentes são os requisitos que não podem ser completamente definidos quando o sistema é especificado e emergem (olha a dica!) à medida que a compreensão do cliente sobre o sistema se desenvolve. Em geral, aparecem durante a fase de desenvolvimento.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Os Requisitos Voláteis Consequentes são os requisitos baseados em (1) de como o sistema será (2), isto é, são resultado da introdução do sistema no (3) do usuário.

A

Os Requisitos Voláteis Consequentes são os requisitos baseados em suposições de como o sistema será utilizado, isto é, são resultado da introdução do sistema no ambiente do usuário.
o usuário percebe as necessidades enquanto utiliza sistema e esses requisitos são uma consequência do uso

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

Os Requisitos Voláteis de Compatibilidade são os requisitos que dependem de:

A

outro equipamento, processo, componente ou elemento.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

CERTO OU ERRADO

Nos Requisitos Voláteis de Compatibilidade, conforme outros elementos mudam, esses requisitos também mudam.

A

CERTO!

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

Quanto à funcionalidade do sistema, podem ser classificados em:

A
  • Requisitos Funcionais
  • Requisitos Não Funcionais
  • Requisitos de Domínio
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

Os Requisitos Funcionais são ações ou funcionalidades que o sistema deve fornecer para:

A

atingir seus objetivos.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

CERTO OU ERRADO

Quanto à funcionalidade de um sistema, os Requisitos Funcionais dependem do tipo de software, dos usuários esperados e do tipo de sistema onde o software será implantado e fazem parte da arquitetura de um sistema.

A

CERTO!

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

CERTO OU ERRADO

Os Requisitos Funcionais no tocante à funcionalidade dizem respeito como o sistema deve reagir a entradas específicas.

A

CERTO!

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q

CERTO OU ERRADO

Os Requisitos Funcionais no tocante à funcionalidade dizem respeito como o sistema deve comportar em determinadas situações.

A

CERTO!

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q

CERTO OU ERRADO

Em regra, os Requisitos Funcionais descrevem a função do sistema detalhadamente, com entradas, saídas, exceções, etc

A

CERTO!

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
Q

A especificação do Requisito Funcional deve ser (1) e (2).

A

A especificação do Requisito Funcional deve ser completa e consistente.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
36
Q

Os Problemas dos Requisitos Funcionais é que, frequentemente, não são
estabelecidos de forma (1), ocasionando requisitos (2), (3) e que não capazes de descrever toda a (4) do serviço.

A

Os Problemas dos Requisitos Funcionais é que, frequentemente, não são
estabelecidos de forma precisa, ocasionando requisitos incompletos, ambíguos e que não capazes de descrever toda a funcionalidiade do serviço.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
37
Q

Dê o exemplo dos seguintes Requisitos Funcionais nos seguintes casos:

1) Uso do Outlook
2) Visualização de vídeo no Youtube
3) Uso do Google Maps

A

1) Uso do Outlook: sistema deve conter sistema de combate à spams
2) Visualização de vídeo no Youtube: sistema deve retirar vídeo sem direitos autorias
3) Uso do Google Maps: caso não ache a rua certa, procurar a mais próxima

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
38
Q

Requisitos Não-Funcionais são (1) estipuladas sobre as quais o sistema deve (2).

A

Requisitos Não-Funcionais são condições estipuladas sobre as quais o sistema deve funcionar.
essas condições podem ser permissões ou restrições

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
39
Q

CERTO OU ERRADO

Os Requisitos Não Funcionais definem restrições globais fazem parte da arquitetura técnica de um sistema.

A

CERTO!

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
40
Q

CERTO OU ERRADO

Os Requisitos Não Funcionais estão diretamente relacionados às funções específicas do sistema.

A

ERRADO! Esse são os Requisitos Funcionais.

Os Não Funcionais não estão diretamente relacionados às funções específicas.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
41
Q

Os Requisitos Não Funcionais incluem características como:

A

confiabilidade, segurança, usabilidade, performance, custos, robustez, etc.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
42
Q

O problema dos Requisitos Não Funcionais é que, frequentemente, são
bastante difíceis de se (1) objetivamente. Para tal, utilizam-se medidas que possam ser (2) ou (3). No entanto, o problema mais comum são os requisitos (4).

A

O problema dos Requisitos Não Funcionais é que, frequentemente, são
bastante difíceis de se especificar objetivamente. Para tal, utilizam-se medidas que possam ser testados ou mensurados. No entanto, o problema mais comum são os requisitos conflitantes.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
43
Q

Exemplos de Requisitos Não-Funcionais:

▪ Pensemos em um Requisito do Whatsapp: Sistema deverá fornecer disponibilidade mínima de 99,8%.
▪ Pensemos em um Requisito do Facebook: Sistema deverá ser desenvolvido utilizando a linguagem Java.
▪ Pensemos em um Requisito do Android: Sistema deverá ser capaz de rodar com apenas 1Gb de RAM.

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
44
Q

Os Requisitos de Domínio são requisitos derivados do domínio da (1) e refletem características de sua área de (2).

A

Os Requisitos de Domínio são requisitos derivados do domínio da aplicação e refletem características de sua área de negócio.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
45
Q

CERTO OU ERRADO

Os Requisitos de Domínio podem ser requisitos funcionais ou não-funcionais.

A

CERTO!

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
46
Q

CERTO OU ERRADO

Caso os Requisitos de Domínio não sejam satisfeitos, o sistema pode não ser realizável.

A

CERTO!
ex: se o sistema identificar que o requisito de domínio não foi atendido, ele não inicia

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
47
Q

O problema do Requisito de Domínio é que, frequentemente, são descritos na (1) ou (2) do domínio da aplicação.

A

O problema do Requisito de Domínio é que, frequentemente, são descritos na linguagem ou jargão do domínio da aplicação.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
48
Q

Os requisitos não-funcionais também podiam ser agrupados por meio de suas características comuns. Para tanto, criou-se a
subclassificação dos requisitos não-funcionais em:

A
  • requisitos de produto
  • requisitos organizacionais
  • requisitos externos.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
49
Q

Requisitos de Produto, característica do requisito não funcional, especificam o (1) do produto.

A

Requisitos de Produto, característica do requisito não funcional, especificam o comportamento do produto.
ex: rapidez com que o sistema deve operar e quanto de
memória ele requer, requisitos de confiabilidade que definem a taxa aceitável de falhas, requisitos de portabilidade e requisitos de usabilidade.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
50
Q

Requisitos Organizacionais, característica do requisito não funcional, são derivados de políticas e procedimentos da:

A

organização do cliente e do desenvolvedor.
padrões de processo que devem ser usados, linguagem de programação ou o método de projeto usado, e requisitos de entrega que especificam quando o produto e a sua documentação devem ser entregues

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
51
Q

Requisitos Externos, característica do requisito não funcional, abrange todos os requisitos derivados de fatores (1) ao sistema e seu processo de (2).

A

Requisitos Externos, característica do requisito não funcional, abrange todos os requisitos derivados de fatores externos ao sistema e seu processo de desenvolvimento.
a interoperabilidade que define como o sistema interage com outros sistemas, requisitos legais que devem ser seguidos, requisitos éticos sistema para assegurar que ele será aceito por todos.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
52
Q

CERTO OU ERRADO

A Interoperabilidade é um requisito de Produto, Organizacional.

A

ERRADO! É um requisito externo. Depende da padronização fora de controle.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
53
Q

O requisito de confiabilidade diz que o sistema não deve ficar fora do ar por mais de:

A

5 segundos durante o dia.

54
Q

O requisito de proteção diz que o sistema não deve permitir que os usuários (1) que eles não (2).

A

O requisito de proteção diz que o sistema não deve permitir que os usuários modifiquem senhas de acesso que eles não criaram.

55
Q

O requisito de desempenho diz que o sistema deverá ser capaz de processar:

A

oitocentas requisições por segundo.

56
Q

O requisito de espaço, também chamado de Requisitos de (1), o sistema deverá ocupar, no máximo, (2) da memória interna do dispositivo.

A

O requisito de espaço, também chamado de Requisitos de Armazenamento, o sistema deverá ocupar, no máximo, 80Mb da memória interna do dispositivo.

57
Q

O requisito de usabilidade diz que os usuários deverão operar todas as funcionalidades do sistema após:

A

2 horas de treino.

58
Q

O requisito de segurança diz que o sistema não deve permitir a ativação (1) de mais de (2) de alarme.

A

O requisito de segurança diz que o sistema não deve permitir a ativação simultânea de mais de três sinais de alarme.

59
Q

O requisito ético diz que o sistema não apresentará aos usuários quaisquer dados de natureza (1) de outras (2).

A

O requisito ético diz que o sistema não apresentará aos usuários quaisquer dados de natureza confidencial de outras outras pessoas.

60
Q

No requisito de implementação, a interface de usuário deve ser implementada em (1) e não se deve utilizar (2).

A

No requisito de implementação, a interface de usuário deve ser implementada em HTML e não se deve utilizar Applets de Java.

61
Q

O termo engenharia de software foi utilizado pela primeira vez na década de:

A

70.

62
Q

Engenharia de Requisitos é uma abordagem sistemática para a formulação, análise, documentação e manutenção de:

A

requisitos de um sistema.
sempre que a palavra engenharia aparece, você já pode considerar que se trata de uma abordagem ou processo formal e sistemático. Então se uma prova discursiva te pergunta o que é Engenharia de Requisitos, você já sabe que se trata de algo formal, metodológico, sistemático, processual, repetível, etc.

63
Q

CERTO OU ERRADO

A Engenharia de Requisitos é processo formal que engloba todas as atividades que contribuem para a produção de um documento de requisitos.

A

CERTO!
sempre que a palavra engenharia aparece, você já pode considerar que se trata de uma abordagem ou processo formal e sistemático. Então se uma prova discursiva te pergunta o que é Engenharia de Requisitos, você já sabe que se trata de algo formal, metodológico, sistemático, processual, repetível, etc.

64
Q

A fase mais crítica no desenvolvimento de um software é a:

A

engenharia de requisitos.

65
Q

CERTO OU ERRADO

A engenharia de requisitos nos traz ferramentas e técnicas para ajudar a mitigar todos os problemas de requisitos solicitados pelos usuários.

A

ERRADO! A engenharia de requisitos não consegue mitigar todos os problemas, apenas grande parte.

66
Q

CERTO OU ERRADO

Um sólido processo de engenharia de requisitos é capaz de encontrar a melhor
solução viável no momento para os requisitos do cliente.

A

CERTO!

67
Q

CERTO OU ERRADO

Os requisitos de sistema são imutáveis.

A

ERRADO! Muito errado! Com o passar do tempo haverão outras necessidades e atualização. O ambiente de trabalho muda, a organização muda, os softwares se atualizam…

68
Q

Quantos por cento dos principais defeitos de software são oriundos da fase de especificação de software?

A

50%.

69
Q

Quantos por cento das principais causas de sucesso em projetos são oriundos de requisitos consistentes?

A

12%.

70
Q

Quantos por cento das principais causas de fracassos em projetos são oriundos de requisitos incompletos?

A

12%.

71
Q

Quais são as fases do processo de Engenharia de Requisitos de acordo com Roger Presmann?

A
  • Concepção
  • Levantamento
  • Elaboração
  • Negociação
  • Especificação
  • Validação
  • Gestão
    Con levan (fermento) ela negocia especificação da vagena
72
Q

Quais são as fases do processo de Engenharia de Requisitos de acordo com Ian Sommerville?

A
  • Estudo de Viabilidade
  • Elicitação e Análise de Requisitos
  • Especificação
  • Validação
  • Gestão
    este viado, eli requer especificação da vagena

o Estudo de Viabilidade é o Relatório de Viabilidade; o resultado da Elicitação e Análise de Requisitos é um conjunto de Modelos do Sistema

73
Q

Sommerville afirma que o objetivo da engenharia de requisitos é criar e manter um:

A

documento de requisitos de sistema;

74
Q

As fases do processo especificados por Sommerville e Pressman servem de insumo para construir o:

A

Documento de Requisitos.

75
Q

A fase de _Estudo de Viabilidade- trata da realização de uma avaliação relativamente (1) e (2) para verificar se as necessidades identificadas dos usuários podem ser satisfeitas por meio das tecnologias (3) de sistemas de software e hardware. O resultado dessa avaliação deve fornecer informações para que a alta direção da organização tome uma decisão mais embasada quanto a (4) ou não.

A

A fase de Estudo de Viabilidade trata da realização de uma avaliação relativamente rápida e barata para verificar se as necessidades identificadas dos usuários podem ser satisfeitas por meio das tecnologias usuais de sistemas de software e hardware. O resultado dessa avaliação deve fornecer informações para que a alta direção da organização tome uma decisão mais embasada quanto a prosseguir para uma análise mais detalhada ou não.
momento de fazer questionamentos importantes

76
Q

CERTO OU ERRADO

A fase de elicitação e análise dos requisitos utiliza as informações do estudo de viabilidade como base para o levantamento de requisitos.

A

CERTO!

77
Q

O Estudo de Viabilidade deve responder três questões em que, caso alguma delas tenha uma resposta negativa, o projeto não deve seguir adiante. São elas:

A

1. O sistema contribui para os objetivos gerais da organização?
2. O sistema pode ser implementado com tecnologia atual e dentro do custo e prazo?
3. O sistema pode ser integrado a outros sistemas já implantados?

78
Q

A fase de Elicitação e Análise de Requisitos serve descobrir,
identificar, deduzir, extrair, evocar, obter informações sobre uma (1). Nessa fase os engenheiros de software devem trabalhar em conjunto com os (2) e os (3).

A

A fase de Elicitação e Análise de Requisitos serve descobrir,
identificar, deduzir, extrair, evocar, obter informações sobre uma questão específica. Nessa fase os engenheiros de software devem trabalhar em conjunto com os clientes e os usuários finais.

79
Q

As principais atividades do processo de elicitação e análise de requisitos são:

A

a. Obtenção de Requisitos: processo de interação com os stakeholders para coletar requisitos. Os requisitos de domínio também são descobertos durante essa atividade.
b. Classificação e organização de requisitos: esta atividade envolve a coleção de requisitos não estruturados, agrupa os requisitos relacionados e os organiza em conjuntos coerentes.
c. Priorização e negociação de requisitos: inevitavelmente, os requisitos serão conflitantes. Assim, busca-se priorizar os requisitos e resolver conflitos por meio da negociação.
d. Documentação de requisitos: os requisitos são documentados e colocados na próxima volta da espiral. Podem ser produzidos documentos de requisitos formais ou informais.

80
Q

Para auxiliar a assegurar uma cobertura ampla dos requisitos de um sistema de software, utilizam-se as seguintes técnicas:

A

1) Entrevistas (formais ou informais) com stackholders
2) Etnografia
3) Cenários
4) Questionários
5) Workshop de requisitos
6) Brainstorm
7) Leitura de documentos
8) JAD (Joint Application Design)
9) Prototipação
10) Reuso de Usuários
11) Histórias de Usuários
12) Participação Ativa de Usuários
13) Encenação
14) Interpretação de Papéis
15) Grupo Focal
16) Análise de Protocolos
17) Pontos de vista

81
Q

Etnografia é uma técnica de observação para compreender os:

A

requisitos organizacionais e sociais.

82
Q

A JAD (Joint Application Design) é a reunião dos usuários e
desenvolvedores em um workshop estruturado para:

A

levantar requisitos e promover a tomada de decisões por meio de diversos tipos de dinâmicas de grupo, técnicas visuais, processos racionais e até documentação.

83
Q

Prototipação é uma técnica de (1), que independe de (2), utilizada no estágio (3) do projeto, ajudando stakeholders a desenvolverem uma forte noção sobre a (5) a ser implementada.

A

Prototipação é uma técnica de elicitação, que independe de tecologia, utilizada no estágio inicial do projeto, ajudando stakeholders a desenvolverem uma forte noção sobre a aplicação a ser implementada.

84
Q

CERTO OU ERRADO

A História de Usuário é uma história contada na linguagem do usuário final, que deve ser capaz de capturar aquilo que o usuário de fato necessita fazer para realizar seu trabalho.

A

CERTO!

85
Q

CERTO OU ERRADO

A História de Trabalho precisa ser concisa e objetiva.

A

CERTO!

86
Q

Critérios de aceitação são condições que uma história do usuário deve satisfazer para ser considerada:

A

completa e funcionando como desejado.

87
Q

EXEMPLO DE HISTÓRIA DE USUÁRIO E CRITÉRIOS DE ACEITAÇÃO

HISTÓRIA DE USUÁRIO:
“Como um turista, eu quero alugar um equipamento de snorkel para poder explorar o fundo do mar e ter uma experiência única”.

CRITÉRIOS DE ACEITAÇÃO:
- Disponibilidade de Equipamento
- Seleção do equipamento
- Informações do Aluguel
- Como funciona o processo de reserva
- Confirmação da reserva
- Como funciona cancelamentos e alterações
- Instruções de Uso
- Suporte do guia

A
88
Q

Uma história de usuário pode ser vista como a composição de três componentes principais:

A

OS TRÊS C’s!
- Cartão
- Conversação
- Confirmação

89
Q

O Cartão, um dos três principais componentes da História do Usuário, é uma breve (1) da história de usuário escrita em um formato (2), geralmente em (3) ou em uma ferramenta de (4). Ele deve ser (5), mas suficiente para lembrar a equipe do que se (6).

A

O Cartão, um dos três principais componentes da História do Usuário, é uma breve descrição da história de usuário escrita em um formato padronizado, geralmente em cartão físico ou em uma ferramenta de gerenciamento de projetos. Ele deve ser conciso, mas suficiente para lembrar a equipe do que se trata a história.
Um formato comum para escrever histórias de usuário é: “Como [tipo de usuário], eu quero [alguma funcionalidade] para [alguma razão/benefício]”.

90
Q

A Conversação, uma das três principais características da História de Usuário, refere-se ao diálogo (1) entre os (2) e os (3) (como por exemplo os (4) ou (5)) para esclarecer os (6) e entender melhor a (7).

A

A Conversação, uma das três principais características da História de Usuário, refere-se ao diálogo contínuo entre os membros da equipe e os stakeholders (como por exemplo os clientes ou usuários finais) para esclarecer os detalhes e entender melhor a história de usuário.

91
Q

A Conversação da História de Usuário pode acontecer das seguintes formas:

A
  • durante as reuniões de planejamento,
  • sessões de refinamento do backlog
  • informalmente, conforme necessário.
92
Q

A Confimação, uma das três principais características da História de Usuário, envolve a definição de (1) que especificam as condições que devem ser atendidas para que a história de usuário seja considerada (2).

A

A Confimação, uma das três principais características da História de Usuário, envolve a definição de critérios de aceitação que especificam as condições que devem ser atendidas para que a história de usuário seja considerada concluída.

93
Q

Os critérios de aceitação de uma História de Usuário é realizado por quem?

A

Membros da equipe e stakeholders.
“O cliente deve ser capaz de adicionar até 10 itens diferentes ao carrinho. O carrinho deve exibir corretamente o nome, quantidade e preço de cada item. O total do carrinho deve ser atualizado automaticamente quando novos itens são adicionados”.

94
Q

A Especificação de Requisitos trata-se da atividade de traduzir as (1) durante a atividade de (2) e análise em um documento que define um conjunto de requisitos.

A

A Especificação de Requisitos trata-se da atividade de traduzir as informações coletadas durante a atividade de elicitação e análise em um documento que define um conjunto de requisitos.

95
Q

Qual a diferença da fase Elicitação e Análise de Requisitos para a fase de Especificação de Requisitos?

A

O objetivo da Elicitação e Análise de requisitos é criar um documento preliminar de requisitos.
Na Especificação de Requisitos a o objetivo é criar uma documentação formal, como um contrato dos requisitos de um sistema, um contrato.

96
Q

CERTO OU ERRADO

O documento de Especificação de Requisitos serve para engenheiros de software e também para clientes.

A

CERTO! Esse documento terá requisitos de usuários e requisitos de sistema.

97
Q

Na Especificação de Requisitos, na parte de requisitos de usuário, o documento pode utilizar uma linguagem (1), contendo (2), (3) ou (4).

A

Na Especificação de Requisitos, na parte de requisitos de usuário, o documento pode utilizar uma linguagem natural, contendo tabelas simples, diagramas ou imagens.

98
Q

Na Especificação de Requisitos, na parte de requisitos de sistema, o documento pode utilizar:

A

modelos matemáticos formais, cenários de casos de uso, entre outras técnicas.

99
Q

CERTO OU ERRADO

Obrigatoriamente, os requisitos de usuário e sistema devem ser claros, não-ambíguos, fáceis de
entender, completos e consistentes.

A

ERRADO! É praticamente impossível garantir que tudo será claro, que não haverá nenhuma ambiguidade, que todos que lerem entenderão facilmente, que será bastante completo e não faltará nada, e que o documento não possui nenhuma inconsistência

100
Q

CERTO OU ERRADO

A Especificação de Usuários é a fase responsável por verificar se os requisitos estão claros, não-ambíguos, consistentes, fáceis de entender, etc.

A

ERRADO! A fase responsável por isso é a Validação de Requisitos. A Especificação de Usuários apenas descrevem os requisitos através de um documento.

101
Q

A Especificação de Usuários apenas descrevem os requisitos através de um documento. Esse documento é chamado de:

A

Documento de Requisitos.

102
Q

CERTO OU ERRADO

A fase de Especificação de Requisitos gera o conjunto de requisitos que, na próxima fase, apenas será validada.

A

CERTO!

103
Q

A atividade de Validação de Requisitos é responsável por verificar os requisitos em relação ao:

A

realismo, consistência, abrangência, validade, completude, etc.

104
Q

Na fase de Validação de Requisitos, erros no documento de requisitos são inevitavelmente descobertos. Devem, então, ser feitas (1) no problema. Também se busca demonstrar se os requisitos definem, de fato, o que o usuário (2) em seu sistema.

A

Na fase de Validação de Requisitos, erros no documento de requisitos são inevitavelmente descobertos. Devem, então, ser feitas correções no problema. Também se busca demonstrar se os requisitos definem, de fato, o que o usuário deseja em seu sistema.

105
Q

CERTO OU ERRADO

A fase de Validação de Requisitos é focado no cliente e está relacionado à descoberta de problemas com requisitos.

A

CERTO!

106
Q

Uma mudança de requisitos significa geralmente que o (1) e a (2) do sistema devem também ser mudados e o sistema deve ser (3).

A

Uma mudança de requisitos significa geralmente que o projeto e a implementação do sistema devem também ser mudados e o sistema deve ser testado novamente.
ou seja, um processo mais caro

107
Q

Uma série de técnicas de validação de requisitos pode ser usada, tais como:

A
  • Revisão de Requisitos
  • Prototipação
  • Geração de Casos de Teste
108
Q

No planejamento de revisão de requisitos, devem ser preparadas **(1) de revisão que não deverão incidir sobre requisitos (2), mas sobre as relações entre requisitos, assim como as propriedades de
(3) do documento.

A

No planejamento de revisão de requisitos, devem ser preparadas checklists genéricos de revisão que não deverão incidir sobre requisitos individuais, mas sobre as relações entre requisitos, assim como as propriedades de
qualidade do documento.

109
Q

Os seguintes atributos devem ser levados em consideração na revisão de requisitos:

A
  • Validade
  • Consistência
  • Compreensibilidade
  • Completude
  • Realismo
  • Verificabilidade
  • Rastreabilidade
  • Adaptabilidade
  • Conformidade com a Norma
110
Q

Revisão Técnica se divide em:

A
  • Comentários
  • Inspeções
  • Walkthroughs (passo-a-passo)
111
Q

Os Walkthroughs são realizados através de uma execução passo a passo de um procedimento ou programa (no papel), com a finalidade de:

A

encontrar erros.

112
Q

No Walkthrough (passo-a-passo) da revisão técnica, são feitos três passos:

A
  • simulação por cada revisor
  • controle por cada revisor depois de vários testes
  • monitoramento dos resultados por cada revisor
113
Q

CERTO OU ERRADO

Walkthrough é um processo de duas etapas: preparação, seguida de análise do documento pela equipe.

A

CERTO!

114
Q

Qual a diferença entre a técnica de prototipação mencionada na fase de Elicitação de Requisitos e a técnica de prototipação mencionada agora na fase de Validação de Requisitos?

A

Na Elicitação de Requisitos o objetivo é descobrir, levantar, elicitar novos requisitos do
sistema.
Na fase de Validação, é validar – por meio de um protótipo – se os requisitos elicitados são
realmente o que o usuário pensava.

115
Q

A fase de Gerenciamento de Requisitos, última fase da Engenharia de Requisitos, é o processo responsável por compreender, acompanhar e controlar as (1) dos requisitos de sistema, identificando (2).

A

A fase de Gerenciamento de Requisitos, última fase da Engenharia de Requisitos, é o processo responsável por compreender, acompanhar e controlar as mudanças dos requisitos de sistema, identificando inconsistências.

116
Q

O processo de gerenciamento de requisitos deve se iniciar assim que:

A

uma versão inicial do documento de requisitos esteja disponível.

117
Q

O planejamento das mudanças de requisitos deve ser iniciado durante o processo de:

A

Elicitação dos Requisitos.

118
Q

CERTO OU ERRADO

Em um gerenciamento de requisitos, quando as mudanças são propostas, deve-se rastrear seu impacto em outros requisitos e no projeto do sistema.

A

CERTO! Rastreabilidade.

119
Q

Em uma matriz de rastreabilidade de requisitos, cada requisito é introduzido em:

A

uma linha e uma coluna da matriz.

120
Q

Em uma matriz de rastreabilidade de requisitos, cada requisito é introduzido em uma linha e uma coluna da matriz. As dependências entre diferentes requisitos são registradas na:

A

célula correspondente à intersecção de linha e coluna.

121
Q

Existem três tipos de informações de rastreabilidade que podem ser mantidas na matriz:

A
  • informações de rastreabilidade de origem
  • informações de rastreabilidade de requisitos
  • informações de rastreabilidade de projeto
122
Q

CERTO OU ERRADO

As matrizes de rastreabilidade podem ser usadas quando um pequeno número de requisitos deve ser gerenciado, mas para sistemas de grande porte, com muitos requisitos, tornam-se muito difíceis de serem gerenciadas e sua manutenção é dispendiosa.

A

CERTO!

123
Q

CERTO OU ERRADO

O gerenciamento formal de requisitos é iniciado somente para grandes projetos com centenas de requisitos
identificáveis.

A

CERTO! Como projetos pequenos são menos formais, se torna dispensável.

124
Q

Podemos classificar a rastreabilidade em:

A

horizontal ou vertical.

125
Q

A rastreabilidade horizontal é a
rastreabilidade entre (1) ou (2) de requisitos, ou outros artefatos, em uma fase (3) do ciclo de vida.

A

A rastreabilidade horizontal é a
rastreabilidade entre diferentes versões ou variações de requisitos, ou outros artefatos, em uma fase particular do ciclo de vida.

126
Q

A rastreabilidade vertical é realizada entre requisitos e
artefatos produzidos pelo:

A

processo de desenvolvimento ao longo do ciclo de vida do projeto.

127
Q

Rastreabilidade de Frente-Para (Forward-to Traceability) é a rastreabilidade de (1) para (2).

A

Rastreabilidade de Frente-Para (Forward-to Traceability) é a rastreabilidade de origens (requisitos de clientes, requisitos no nível de sistema, etc.) para requisitos.

128
Q

Rastreabilidade de Frente-De (Forward-from Traceability) é a rastreabilidade de (1) para (2).

A

Rastreabilidade de Frente-De (Forward-from Traceability) é a rastreabilidade de requisitos para especificações do projeto.

129
Q

Rastreabilidade de Trás-para (Backward–to Traceability) é a rastreabilidade de (1) para (2).

A

Rastreabilidade de Trás-para (Backward–to Traceability) é a rastreabilidade de especificações de proejto para requisitos.

130
Q

Rastreabilidade de Trás-de (Backward–from Traceability) é a rastreabilidade de (1) para suas (2).

A

Rastreabilidade de Trás-de (Backward–from Traceability) é a rastreabilidade de (1) para suas origens (requisitos de clientes, requisitos no nível de sistema, etc).

131
Q
A

TECNOLOGIA DA INFORMAÇÃO (20 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions