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
2
Q
O que é abstração?
A
A subtração de detalhes.
3
Q
A classificação quanto á abstração de sistemas se divide em:
A
- Requisitos de Usuário
- Requisitos de Sistema
4
Q
CERTO OU ERRADO
O requisito de usuário é mais abstrato que o requisito de sistema.
A
CERTO!
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
6
Q
Os Requisitos de Usuários podem ser:
A
funcionais ou não funcionais.
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
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.
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.
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
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.
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
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.
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
15
Q
Na classificação quanto à evolução de sistemas, estes podem ser:
A
- Requisitos Permanentes
- Requisitos Voláteis
16
Q
Os Requisitos Permanentes estão diretamente ligados a:
A
atividade principal da organização.
17
Q
Os Requisitos Permanentes, em geral, são derivados do:
A
Modelo de Domínio.
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.
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
20
Q
Instanciação é o processo de:
A
ler ou especificar informações.
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.
22
Q
CERTO OU ERRADO
Os Requisitos Voláteis podem se modificar quando o sistema está em desenvolvimento ou em uso.
A
CERTO!
23
Q
O Requisitos Voláteis podem ser subclassificados em:
A
- mutáveis
- emergentes
- consequentes
- de compatibilidade
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).
25
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)**.
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**.
26
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.
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*
27
Os _Requisitos Voláteis de Compatibilidade_ são os requisitos que dependem de:
outro equipamento, processo, componente ou elemento.
28
CERTO OU ERRADO
Nos Requisitos Voláteis de Compatibilidade, conforme outros elementos mudam, esses requisitos também mudam.
CERTO!
29
Quanto à funcionalidade do sistema, podem ser classificados em:
- Requisitos Funcionais
- Requisitos Não Funcionais
- Requisitos de Domínio
30
Os _Requisitos Funcionais_ são ações ou funcionalidades que o sistema deve fornecer para:
atingir seus objetivos.
31
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.
CERTO!
32
CERTO OU ERRADO
Os Requisitos Funcionais no tocante à funcionalidade dizem respeito como o sistema deve reagir a entradas específicas.
CERTO!
33
CERTO OU ERRADO
Os Requisitos Funcionais no tocante à funcionalidade dizem respeito como o sistema deve comportar em determinadas situações.
CERTO!
34
CERTO OU ERRADO
Em regra, os Requisitos Funcionais descrevem a função do sistema detalhadamente, com entradas, saídas, exceções, etc
CERTO!
35
A especificação do Requisito Funcional deve ser **(1)** e **(2)**.
A especificação do Requisito Funcional deve ser **completa e consistente**.
36
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.
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.
37
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
**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
38
Requisitos Não-Funcionais são **(1)** estipuladas sobre as quais o sistema deve **(2)**.
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*
39
CERTO OU ERRADO
Os Requisitos Não Funcionais definem restrições globais fazem parte da arquitetura técnica de um sistema.
CERTO!
40
CERTO OU ERRADO
Os Requisitos Não Funcionais estão diretamente relacionados às funções específicas do sistema.
ERRADO! Esse são os Requisitos Funcionais.
Os Não Funcionais não estão diretamente relacionados às funções específicas.
41
Os Requisitos Não Funcionais incluem características como:
confiabilidade, segurança, usabilidade, performance, custos, robustez, etc.
42
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)**.
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**.
43
**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.
44
Os Requisitos de Domínio são requisitos derivados do domínio da **(1)** e refletem características de sua área de **(2)**.
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**.
45
CERTO OU ERRADO
Os Requisitos de Domínio podem ser requisitos funcionais ou não-funcionais.
CERTO!
46
CERTO OU ERRADO
Caso os Requisitos de Domínio não sejam satisfeitos, o sistema pode não ser realizável.
CERTO!
*ex: se o sistema identificar que o requisito de domínio não foi atendido, ele não inicia*
47
O problema do Requisito de Domínio é que, frequentemente, são descritos na **(1)** ou **(2)** do domínio da aplicação.
O problema do Requisito de Domínio é que, frequentemente, são descritos na **linguagem ou jargão** do domínio da aplicação.
48
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:
- requisitos de produto
- requisitos organizacionais
- requisitos externos.
49
Requisitos de Produto, característica do requisito não funcional, especificam o **(1)** do produto.
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.*
50
Requisitos Organizacionais, característica do requisito não funcional, são derivados de políticas e procedimentos da:
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*
51
Requisitos Externos, característica do requisito não funcional, abrange todos os requisitos derivados de fatores **(1)** ao sistema e seu processo de **(2)**.
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.*
52
CERTO OU ERRADO
A Interoperabilidade é um requisito de Produto, Organizacional.
ERRADO! É um requisito externo. Depende da padronização fora de controle.
53
O requisito de confiabilidade diz que o sistema não deve ficar fora do ar por mais de:
5 segundos durante o dia.
54
O requisito de proteção diz que o sistema não deve permitir que os usuários **(1)** que eles não **(2)**.
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
O requisito de desempenho diz que o sistema deverá ser capaz de processar:
oitocentas requisições por segundo.
56
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.
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
O requisito de usabilidade diz que os usuários deverão operar todas as funcionalidades do sistema após:
2 horas de treino.
58
O requisito de segurança diz que o sistema não deve permitir a ativação **(1)** de mais de **(2)** de alarme.
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
O requisito ético diz que o sistema não apresentará aos usuários quaisquer dados de natureza **(1)** de outras **(2)**.
O requisito ético diz que o sistema não apresentará aos usuários quaisquer dados de natureza **confidencial** de outras **outras pessoas**.
60
No requisito de implementação, a interface de usuário deve ser implementada em **(1)** e não se deve utilizar **(2)**.
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
O termo engenharia de software foi utilizado pela primeira vez na década de:
70.
62
_Engenharia de Requisitos_ é uma abordagem sistemática para a formulação, análise, documentação e manutenção de:
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
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.
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
A fase mais crítica no desenvolvimento de um software é a:
engenharia de requisitos.
65
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.
ERRADO! A engenharia de requisitos não consegue mitigar todos os problemas, apenas grande parte.
66
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.
CERTO!
67
CERTO OU ERRADO
Os requisitos de sistema são imutáveis.
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
Quantos por cento dos principais defeitos de software são oriundos da fase de especificação de software?
50%.
69
Quantos por cento das principais causas de sucesso em projetos são oriundos de requisitos consistentes?
12%.
70
Quantos por cento das principais causas de fracassos em projetos são oriundos de requisitos incompletos?
12%.
71
Quais são as fases do processo de Engenharia de Requisitos de acordo com Roger Presmann?
- **Con**cepção
- **Levan**tamento
- **Ela**boração
- **Negocia**ção
- **Especi**ficação
- **Va**lidação
- **Ge**stão
**Con levan (fermento) ela negocia especificação da vagena**
72
Quais são as fases do processo de Engenharia de Requisitos de acordo com Ian Sommerville?
- **Est**udo de **Via**bilidade
- **Eli**citação e Análise de **Requ**isitos
- **Especificação**
- **Va**lidação
- **Ge**stã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
Sommerville afirma que o objetivo da engenharia de requisitos é criar e manter um:
documento de requisitos de sistema;
74
As fases do processo especificados por Sommerville e Pressman servem de insumo para construir o:
Documento de Requisitos.
75
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 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
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.
CERTO!
77
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:
**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
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 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
As principais atividades do processo de elicitação e análise de requisitos são:
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
Para auxiliar a assegurar uma cobertura ampla dos requisitos de um sistema de software, utilizam-se as seguintes técnicas:
**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
Etnografia é uma técnica de observação para compreender os:
requisitos organizacionais e sociais.
82
A JAD (Joint Application Design) é a reunião dos usuários e
desenvolvedores em um workshop estruturado para:
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
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.
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
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.
CERTO!
85
CERTO OU ERRADO
A História de Trabalho precisa ser concisa e objetiva.
CERTO!
86
Critérios de aceitação são condições que uma história do usuário deve satisfazer para ser considerada:
completa e funcionando como desejado.
87
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
88
Uma história de usuário pode ser vista como a composição de três componentes principais:
OS TRÊS C's!
- Cartão
- Conversação
- Confirmação
89
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)**.
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
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 _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
A Conversação da História de Usuário pode acontecer das seguintes formas:
- durante as reuniões de planejamento,
- sessões de refinamento do backlog
- informalmente, conforme necessário.
92
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 _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
Os critérios de aceitação de uma História de Usuário é realizado por quem?
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
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 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
Qual a diferença da fase Elicitação e Análise de Requisitos para a fase de Especificação de Requisitos?
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
CERTO OU ERRADO
O documento de Especificação de Requisitos serve para engenheiros de software e também para clientes.
CERTO! Esse documento terá requisitos de usuários e requisitos de sistema.
97
Na Especificação de Requisitos, na parte de _requisitos de usuário_, o documento pode utilizar uma linguagem **(1)**, contendo **(2)**, **(3)** ou **(4)**.
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
Na Especificação de Requisitos, na parte de _requisitos de sistema_, o documento pode utilizar:
modelos matemáticos formais, cenários de casos de uso, entre outras técnicas.
99
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.
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
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.
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
A Especificação de Usuários apenas descrevem os requisitos através de um documento. Esse documento é chamado de:
Documento de Requisitos.
102
CERTO OU ERRADO
A fase de Especificação de Requisitos gera o conjunto de requisitos que, na próxima fase, apenas será validada.
CERTO!
103
A atividade de Validação de Requisitos é responsável por verificar os requisitos em relação ao:
realismo, consistência, abrangência, validade, completude, etc.
104
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.
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
CERTO OU ERRADO
A fase de Validação de Requisitos é focado no cliente e está relacionado à descoberta de problemas com requisitos.
CERTO!
106
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)**.
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
Uma série de técnicas de validação de requisitos pode ser usada, tais como:
- Revisão de Requisitos
- Prototipação
- Geração de Casos de Teste
108
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.
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
Os seguintes atributos devem ser levados em consideração na revisão de requisitos:
- Validade
- Consistência
- Compreensibilidade
- Completude
- Realismo
- Verificabilidade
- Rastreabilidade
- Adaptabilidade
- Conformidade com a Norma
110
Revisão Técnica se divide em:
- Comentários
- Inspeções
- Walkthroughs (passo-a-passo)
111
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:
encontrar erros.
112
No Walkthrough (passo-a-passo) da revisão técnica, são feitos três passos:
- simulação por cada revisor
- controle por cada revisor depois de vários testes
- monitoramento dos resultados por cada revisor
113
CERTO OU ERRADO
Walkthrough é um processo de duas etapas: preparação, seguida de análise do documento pela equipe.
CERTO!
114
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?
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
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 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
O processo de gerenciamento de requisitos deve se iniciar assim que:
uma versão inicial do documento de requisitos esteja disponível.
117
O planejamento das mudanças de requisitos deve ser iniciado durante o processo de:
Elicitação dos Requisitos.
118
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.
CERTO! Rastreabilidade.
119
Em uma matriz de rastreabilidade de requisitos, cada requisito é introduzido em:
uma linha e uma coluna da matriz.
120
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:
célula correspondente à intersecção de linha e coluna.
121
Existem três tipos de informações de rastreabilidade que podem ser mantidas na matriz:
- informações de rastreabilidade de origem
- informações de rastreabilidade de requisitos
- informações de rastreabilidade de projeto
122
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.
CERTO!
123
CERTO OU ERRADO
O gerenciamento formal de requisitos é iniciado somente para grandes projetos com centenas de requisitos
identificáveis.
CERTO! Como projetos pequenos são menos formais, se torna dispensável.
124
Podemos classificar a rastreabilidade em:
horizontal ou vertical.
125
A rastreabilidade horizontal é a
rastreabilidade entre **(1)** ou **(2)** de requisitos, ou outros artefatos, em uma fase **(3)** do ciclo de vida.
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
A rastreabilidade vertical é realizada entre requisitos e
artefatos produzidos pelo:
processo de desenvolvimento ao longo do ciclo de vida do projeto.
127
Rastreabilidade de _Frente-Para (Forward-to Traceability)_ é a rastreabilidade de **(1)** para **(2)**.
Rastreabilidade de _Frente-Para (Forward-to Traceability)_ é a rastreabilidade de **origens** (requisitos de clientes, requisitos no nível de sistema, etc.) para **requisitos**.
128
Rastreabilidade de _Frente-De (Forward-from Traceability)_ é a rastreabilidade de **(1)** para **(2)**.
Rastreabilidade de _Frente-De (Forward-from Traceability)_ é a rastreabilidade de **requisitos** para **especificações do projeto**.
129
Rastreabilidade de _Trás-para (Backward–to Traceability)_ é a rastreabilidade de **(1)** para **(2)**.
Rastreabilidade de _Trás-para (Backward–to Traceability)_ é a rastreabilidade de **especificações de proejto** para **requisitos**.
130
Rastreabilidade de _Trás-de (Backward–from Traceability)_ é a rastreabilidade de **(1)** para suas **(2)**.
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
