Arquitetura e análise de requisitos para sistemas analíticos Flashcards
Os requisitos de software podem ser classificados quanto à:
- nível de abstração
- qualidade
- evolução
- funcionalidade
- origem
O que é abstração?
A subtração de detalhes.
A classificação quanto á abstração de sistemas se divide em:
- Requisitos de Usuário
- Requisitos de Sistema
CERTO OU ERRADO
O requisito de usuário é mais abstrato que o requisito de sistema.
CERTO!
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).
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
Os Requisitos de Usuários podem ser:
funcionais ou não funcionais.
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).
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
CERTO OU ERRADO
Ao escrever requisitos, deve-se considerar quem serão seus leitores e, portanto, diferentes níveis de detalhamento.
CERTO! Cada leitor tem seu nível de conhecimento.
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 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.
A Quality Function Deployment (QFD) (Disponibilização da Função de Qualidade) possui três tipos de requisitos:
- Requisitos Normais
- Requisitos Específicos
- Requisitos Fascinantes
Os Requisitos Normais são os (1) e (2) estabelecidos para um produto ou sistema durante (3) com o cliente.
Os Requisitos Normais são os objetivos e metas estabelecidos para um produto ou sistema durante reuniões com o cliente.
CERTO OU ERRADO
Os Requisitos Normais de qualidade do sistema são aqueles comuns, em que, estando presentes, o cliente fica satisfeito.
CERTO!
tipos de displays gráficos solicitados, funções de sistema específicas e níveis de desempenho definidos
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).
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.
Os Requisitos Fascinantes de qualidade do sistema são os recursos que vão:
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
Na classificação quanto à evolução de sistemas, estes podem ser:
- Requisitos Permanentes
- Requisitos Voláteis
Os Requisitos Permanentes estão diretamente ligados a:
atividade principal da organização.
Os Requisitos Permanentes, em geral, são derivados do:
Modelo de Domínio.
CERTO OU ERRADO
Os Requisitos Permanentes possuem esse nome porque são imutáveis.
ERRADO! Recebem esse nome porque são mais estáveis e que mudam pouco ou demoram bastante para mudar.
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.
Instanciação é o processo de:
ler ou especificar informações.
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).
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.
CERTO OU ERRADO
Os Requisitos Voláteis podem se modificar quando o sistema está em desenvolvimento ou em uso.
CERTO!
O Requisitos Voláteis podem ser subclassificados em:
- mutáveis
- emergentes
- consequentes
- de compatibilidade
Os Requisitos Voláteis Mutáveis são os requisitos que se modificam em função de:
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).
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.
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
Os Requisitos Voláteis de Compatibilidade são os requisitos que dependem de:
outro equipamento, processo, componente ou elemento.
CERTO OU ERRADO
Nos Requisitos Voláteis de Compatibilidade, conforme outros elementos mudam, esses requisitos também mudam.
CERTO!
Quanto à funcionalidade do sistema, podem ser classificados em:
- Requisitos Funcionais
- Requisitos Não Funcionais
- Requisitos de Domínio
Os Requisitos Funcionais são ações ou funcionalidades que o sistema deve fornecer para:
atingir seus objetivos.
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!
CERTO OU ERRADO
Os Requisitos Funcionais no tocante à funcionalidade dizem respeito como o sistema deve reagir a entradas específicas.
CERTO!
CERTO OU ERRADO
Os Requisitos Funcionais no tocante à funcionalidade dizem respeito como o sistema deve comportar em determinadas situações.
CERTO!
CERTO OU ERRADO
Em regra, os Requisitos Funcionais descrevem a função do sistema detalhadamente, com entradas, saídas, exceções, etc
CERTO!
A especificação do Requisito Funcional deve ser (1) e (2).
A especificação do Requisito Funcional deve ser completa e consistente.
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.
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
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
CERTO OU ERRADO
Os Requisitos Não Funcionais definem restrições globais fazem parte da arquitetura técnica de um sistema.
CERTO!
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.
Os Requisitos Não Funcionais incluem características como:
confiabilidade, segurança, usabilidade, performance, custos, robustez, etc.
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.
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.
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.
CERTO OU ERRADO
Os Requisitos de Domínio podem ser requisitos funcionais ou não-funcionais.
CERTO!
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
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.
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.
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.
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
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.
CERTO OU ERRADO
A Interoperabilidade é um requisito de Produto, Organizacional.
ERRADO! É um requisito externo. Depende da padronização fora de controle.
O requisito de confiabilidade diz que o sistema não deve ficar fora do ar por mais de:
5 segundos durante o dia.
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.
O requisito de desempenho diz que o sistema deverá ser capaz de processar:
oitocentas requisições por segundo.
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.
O requisito de usabilidade diz que os usuários deverão operar todas as funcionalidades do sistema após:
2 horas de treino.
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.
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.
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.
O termo engenharia de software foi utilizado pela primeira vez na década de:
70.
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.
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.
A fase mais crítica no desenvolvimento de um software é a:
engenharia de requisitos.
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.
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!
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…
Quantos por cento dos principais defeitos de software são oriundos da fase de especificação de software?
50%.
Quantos por cento das principais causas de sucesso em projetos são oriundos de requisitos consistentes?
12%.
Quantos por cento das principais causas de fracassos em projetos são oriundos de requisitos incompletos?
12%.
Quais são as fases do processo de Engenharia de Requisitos de acordo com Roger Presmann?
- Concepção
- Levantamento
- Elaboração
- Negociação
- Especificação
- Validação
-
Gestão
Con levan (fermento) ela negocia especificação da vagena
Quais são as fases do processo de Engenharia de Requisitos de acordo com Ian Sommerville?
- 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
Sommerville afirma que o objetivo da engenharia de requisitos é criar e manter um:
documento de requisitos de sistema;
As fases do processo especificados por Sommerville e Pressman servem de insumo para construir o:
Documento de Requisitos.
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
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!
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?
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.
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.
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
Etnografia é uma técnica de observação para compreender os:
requisitos organizacionais e sociais.
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.
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.
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!
CERTO OU ERRADO
A História de Trabalho precisa ser concisa e objetiva.
CERTO!
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.
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
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
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]”.
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.
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.
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.
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”.
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.
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.
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.
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.
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.
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
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.
A Especificação de Usuários apenas descrevem os requisitos através de um documento. Esse documento é chamado de:
Documento de Requisitos.
CERTO OU ERRADO
A fase de Especificação de Requisitos gera o conjunto de requisitos que, na próxima fase, apenas será validada.
CERTO!
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.
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.
CERTO OU ERRADO
A fase de Validação de Requisitos é focado no cliente e está relacionado à descoberta de problemas com requisitos.
CERTO!
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
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
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.
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
Revisão Técnica se divide em:
- Comentários
- Inspeções
- Walkthroughs (passo-a-passo)
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.
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
CERTO OU ERRADO
Walkthrough é um processo de duas etapas: preparação, seguida de análise do documento pela equipe.
CERTO!
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.
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.
O processo de gerenciamento de requisitos deve se iniciar assim que:
uma versão inicial do documento de requisitos esteja disponível.
O planejamento das mudanças de requisitos deve ser iniciado durante o processo de:
Elicitação dos Requisitos.
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.
Em uma matriz de rastreabilidade de requisitos, cada requisito é introduzido em:
uma linha e uma coluna da matriz.
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.
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
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!
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.
Podemos classificar a rastreabilidade em:
horizontal ou vertical.
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.
A rastreabilidade vertical é realizada entre requisitos e
artefatos produzidos pelo:
processo de desenvolvimento ao longo do ciclo de vida do projeto.
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.
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.
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.
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).
