Requisitos de Software

Questionário 08

1. São princípios de uma boa especificação, exceto:
   1. Separar a funcionalidade de implementação
   2. Abranger o sistema do qual o software é um componente
   3. Abranger o ambiente no qual o sistema opera
   4. Ser centralizada e fortemente acoplada
   
   
2. O que melhor define o termo Especificação é:
   1. Documentar e formalizar os resultados da elicitação e da análise
   2. Desenvolver um sistema de software
   3. Realizar testes de um projeto de sistemas
   4. Corrigir os problemas encontrados em um projeto
   
   
3. Para registrar os vários tipos de informações dos requisitos para facilitar a comunicação entre os stakeholders do Projeto não devemos utilizar:
   1. Documentações em linguagem natural
   2. Modelos gráficos de análise
   3. Eliminar qualquer informação sobre os requisitos
   4. Ferramentas de gerenciamento comercial
   
   
4. Não é um fator de importância para uma especificação correta:
   1. Compreensão parcial
   2. Reduz o custo e o retrabalho
   3. Referência para validação final
   4. Base de concordância Cliente e Fornecedor
   
   
5. A pergunta que não podemos utilizar para definirmos os artefatos de Visão é:
   1. Onde o problema é definido?
   2. Onde os stakeholders e usuários são listados?
   3. Onde os ambientes e plataformas são identificadas?
   4. Onde os casos de uso são mantidos?
   
   
6. Um Documento de Visão é utilizado para:
   1. Fornecer um feedback inicial do cliente
   2. Promover várias compreensões sobre um assunto de modo a termos dados para um Brainstorm
   3. Definir o escopo e a prioridade em baixo nível das requisições do analista e suas características
   4. Um documento de sistema que descreve o "Como" e o "Quanto"
   
   
7. Para identificar as restrições dos requisitos, não precisamos analisar a visão:
   1. De Ambiente
   2. Econômica
   3. Popular
   4. Técnica
   
   
8. São check-points para o Caso de Uso, exceto:
   1. Verificar o comportamento do sistema
   2. Todos foram identificados
   3. Todas as características estão mapeadas
   4. Todos os atores estão identificados
   
   
9. Para relacionamentos de casos de uso, entre si, não temos o tipo:
   1. Generalização
   2. Extensão
   3. Inclusão
   4. Abstração
   
   
10. A interação entre o Ator e o Caso de Uso é feito por meio:
    1. de simulação
    2. de utilização de problemas
    3. de prototipação
    4. do envio e recebimento de mensagens
    
    
11. Pode ocorrer tanto entre Casos de uso ou entre atores:
    1. Simulação
    2. Especificação
    3. Validação
    4. Generalização
    
    
12. Indica que um dos Casos de Uso terá seu procedimento acrescido, em um ponto de extensão, de outro caso de uso, identificado como base:
    1. Inclusão
    2. Abstração
    3. Extensão
    4. Generalização
    
    
13. Indica que um deles terá seu procedimento copiado num local especificado no outro caso de uso identificado como base
    1. Inclusão
    2. Abstração
    3. Extensão
    4. Generalização
    
    
14. Para dividirmos Casos de Uso, utilizamos o conceito de:
    1. Encapsulamento
    2. Especificação
    3. Pacote
    4. Classe
    
    
15. Processo de verificar os requisitos quanto a sua validade, consistência, completeza, realismo e sua facilidade de verificação:
    1. Simulação
    2. Especificação
    3. Validação
    4. Generalização