Requisitos de Software

Questionário 05

1. São considerados como causas de falhas em Projetos de Software, exceto:
   1. Requisitos incompletos
   2. Falta de envolvimento por parte do usuário
   3. Férias de um funcionário chave ao projeto
   4. Expectativas não realistas
   
   
2. Requisitos podem ser classificados como funcionais, não funcionais e um terceiro grupo que trata de situações que não devem ocorrer denominado:
   1. Inversos
   2. Especificado
   3. Codificados
   4. Documentados
   
   
3. São especificações dos requisitos funcionais, exceto:
   1. Descrever as funcionalidades do sistema desejadas pelos clientes (o que ele faz)
   2. O QUE esperar que o software realize
   3. Descrever a funcionalidade ou os serviços do sistema
   4. Descrever as qualidades do sistema (como ele é)
   
   
4. Exemplos de requisitos funcionais:
   1. Tempo de resposta não deve ultrapassar 10 segundos
   2. Software deve ser operacionalizado no sistema Windows
   3. Banco de dados protegido para o acesso apenas de usuários autorizados
   4. Emitir relatórios gerenciais
   
   
5. São especificações dos requisitos não-funcionais, exceto:
   1. Descrever as qualidades do sistema (como ele é)
   2. A qualidade afeta diretamente a satisfação do cliente e envolvidos com o sistema
   3. O QUE esperar que o software realize
   4. A qualidade de um software pode ser avaliada de duas maneiras
   
   
6. Exemplos de requisitos funcionais:
   1. Permitir a baixa automática do estoque quando da venda de um produto
   2. Possibilitar o cadastramento dos dados pessoais dos clientes
   3. Possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal
   4. Tempo de desenvolvimento não deve ultrapassar seis meses
   
   
7. São tipos de requisitos não-funcionais, exceto:
   1. Requisitos de Produto
   2. Requisitos Autorizados
   3. Requisitos Organizacionais
   4. Requisitos Externos
   
   
8. O perfil profissional envolvido na "Análise do Problema" é:
   1. Analista de Sistema
   2. Especificador de Requisitos
   3. Arquiteto de Software
   4. Designer de Interface com o Usuário
   
   
9. A finalidade da Análise do Problema é:
   1. Estabelecer acordo sobre o problema a ser resolvido
   2. Identificar o salário dos envolvidos
   3. Definir os marcos do sistema para modificá-los
   4. Solucionar as restrições impostas ao sistema
   
   
10. Para evitar mal-entendidos:
    1. Concordar com uma terminologia comum a ser usada no decorrer do projeto
    2. Não definir os termos de nosso projeto em um glossário visando as mudanças dinâmicas
    3. Compreender parcialmente o(s) problema(s) tratado(s) e conhecer os envolvidos
    4. Alguns desses envolvidos serão representados por atores em nosso Diagrama de Classe
    
    
11. A categoria dos atores podem ser: Pessoas, Organizações, ...
    1. Outros sistemas e Equipamentos
    2. Empregado e Cliente
    3. Externo e Interno
    4. Sistema e Estrutura
    
    
12. Para definirmos o nome de um Ator (em um Diagrama de Caso de Uso):
    1. Devemos fazer referência ao seu papel
    2. Convém utilizar siglas e número
    3. Definir com base em quem ele representa
    4. Definido pela Qualidade de Software
    
    
13. São tipos de especificação dos requisitos, exceto:
    1. Requisitos do Sistema
    2. Requisitos do Usuário
    3. Requisitos do Software
    4. Requisitos do Ator
    
    
14. São exemplos de Requisitos de Sistema, exceto:
    1. O usuário deve dispor de recursos para definir o tipo dos arquivos externos
    2. Cada tipo de arquivo externo pode ter uma ferramenta associada que pode ser aplicada a ele
    3. Cada tipo de arquivo externo pode ser representado como um ícone específico na tela do usuário
    4. O software deve oferecer um meio de representar e acessar arquivos externos criados por outra ferramenta
    
    
15. São parte da estrutura para documentos de requisitos no padrão IEEE 830/1998, exceto:
    1. Propósito do documento de requisitos
    2. Escopo do produto
    3. Definições, acrônimos e abreviações
    4. Pessoas Utilizadas