WorksheetsEngenharia de Software Unidade II
Total questions: 27
Worksheet time: 14mins
Na engenharia de requisitos, os requisitos não funcionais referem-se:
Às funções principais que o sistema deve executar para atender o usuário.
Às ações do usuário que determinam como o sistema deve responder.
Ao conjunto de regras do negócio que guiam os cálculos do sistema.
À forma como o sistema deve se comportar em termos de desempenho e qualidade.
Às informações inseridas pelo cliente durante o cadastro no sistema.
Qual das técnicas abaixo é geralmente utilizada primeiro para identificar requisitos?
Observação in loco com acompanhamento diário da rotina do cliente.
Entrevistas estruturadas ou abertas com os clientes do sistema.
Estudo de protótipos construídos pelos analistas de negócio.
Questionários aplicados em massa aos usuários potenciais.
Consultas diretas aos relatórios gerados por softwares antigos.
Um requisito funcional pode ser entendido como:
A característica que define como o sistema será implantado em servidores externos.
O comportamento que descreve o que o sistema deve realizar em resposta a entradas.
O critério usado para medir a qualidade do desempenho do software em operação.
A limitação que impede que o sistema seja integrado a plataformas de terceiros.
O atributo que descreve a forma de interação entre usuários e documentos físicos.
Durante a elicitação, os questionários são mais adequados quando:
Deseja-se obter respostas detalhadas sobre a experiência pessoal dos usuários.
Busca-se coletar informações de um grande número de pessoas em pouco tempo.
O analista precisa observar em profundidade o comportamento em campo.
O cliente não deseja compartilhar informações de forma estruturada.
O objetivo principal é validar cenários já documentados em protótipos.
Os encontros de grupo no levantamento de requisitos têm como benefício:
Proporcionar interação coletiva que facilita consenso entre diferentes atores.
Garantir que todos os requisitos sejam definidos em apenas um dia.
Servir como substituto integral para a validação de cenários.
Ser aplicados exclusivamente no final do processo de modelagem.
Evitar conflitos de interesse entre usuários e desenvolvedores.
Um requisito do tipo “o sistema deve estar disponível 24 horas por dia” é:
Funcional, pois trata de serviços oferecidos ao cliente do sistema.
Não funcional, pois se refere a disponibilidade e confiabilidade.
Funcional, porque descreve interações diretas entre usuários.
Não funcional, já que está ligado ao cadastro de clientes.
Funcional, pois descreve um fluxo essencial de transações.
A elicitação de requisitos pode ser prejudicada quando:
O cliente utiliza jargões técnicos que dificultam a comunicação.
O analista prepara entrevistas abertas para detalhar necessidades.
São aplicados questionários de forma clara e objetiva.
Há encontros de grupo com diferentes perfis de usuários.
O processo inclui observação direta no ambiente de trabalho.
Um requisito não funcional de segurança pode ser:
O sistema deve exigir autenticação por senha forte para acesso.
O sistema deve permitir ao usuário cadastrar novos clientes.
O sistema deve calcular automaticamente o valor da fatura.
O sistema deve emitir relatório de vendas em PDF.
O sistema deve apresentar o estoque atualizado em tempo real.
A escolha da técnica de elicitação depende principalmente:
Do tipo de informação que se deseja obter com o cliente.
Da quantidade de código que já foi desenvolvido no sistema.
Do número de programadores envolvidos no projeto.
Da linguagem de programação que será utilizada.
Do orçamento disponível para a compra de ferramentas.
As entrevistas abertas são úteis principalmente porque:
Permitem descobrir informações inesperadas e detalhes do processo.
Reduzem o tempo de reunião com clientes e desenvolvedores.
São mais fáceis de registrar e tabular em planilhas.
Substituem totalmente a observação direta no ambiente.
Garantem que todos os requisitos sejam sempre objetivos.
Na técnica de observação in loco, o analista deve:
Acompanhar o trabalho do usuário para compreender como o processo realmente ocorre.
Distribuir formulários para coletar respostas fechadas em grande escala.
Aplicar entrevistas formais com roteiro fixo e perguntas específicas à todos funcionários.
Apresentar protótipos já implementados para observação e validação do cliente in loco.
Discutir apenas com gestores os objetivos estratégicos do sistema.
A validação de requisitos busca confirmar se:
O sistema foi implementado de acordo com os padrões de programação da equipe.
O software que será construído corresponde ao que os usuários realmente desejam.
O cliente está disposto a aceitar ajustes futuros durante o desenvolvimento.
Os desenvolvedores dominam completamente a linguagem de programação usada.
O sistema terá desempenho melhor do que outros já existentes no mercado.
No contexto da validação de requisitos, um cenário bem descrito deve conter:
Uma visão técnica do sistema, incluindo linguagens e ferramentas utilizadas.
Um contexto inicial, uma sequência de ações e o resultado esperado.
Uma tabela com métricas de desempenho e tempo de resposta do sistema.
Apenas uma narrativa de erros críticos que podem ocorrer no software.
Um detalhamento dos requisitos não funcionais e seus impactos na empresa.
O uso de prototipagem auxilia principalmente porque:
Ajuda a explorar ideias iniciais e validar entendimento com os usuários.
Garante que o código do protótipo será sempre reutilizado no produto final.
Substitui a etapa de modelagem de processos de negócio.
Impede alterações no escopo durante o desenvolvimento do sistema.
Elimina a necessidade de validação de requisitos funcionais.
Na construção de cenários, o termo “fluxo alternativo” significa:
A sequência de eventos que ocorre em condições específicas, diferentes da principal.
A descrição de falhas críticas que interrompem o sistema.
O conjunto de requisitos descartados durante a análise do sistema.
A lista de ações que devem ser realizadas após a execução do caso.
A sequência de atividades obrigatórias no processo de negócio.
Um cenário de exceção tem como objetivo:
Demonstrar o que acontece quando algo inesperado ocorre no fluxo.
Substituir a execução normal de um processo de negócio.
Eliminar alternativas consideradas redundantes pelo analista.
Relatar os requisitos não funcionais aplicados ao sistema.
Representar o desempenho em diferentes plataformas.
A prototipagem é considerada útil porque:
Torna visível rapidamente uma ideia de solução antes da implementação.
Evita que usuários participem de reuniões iniciais com analistas.
Reduz a necessidade de testes finais no sistema completo.
Substitui por completo os diagramas de casos de uso.
Impede mudanças de requisitos ao longo do projeto.
Um benefício do uso de cenários é:
Facilitar a comunicação, tornando requisitos abstratos mais concretos.
Garantir que todos os requisitos serão escritos em linguagem técnica.
Substituir a necessidade de casos de uso no projeto.
Eliminar a participação dos clientes durante a validação.
Garantir que não haverá alterações nos requisitos ao longo do tempo.
Um benefício direto da validação de requisitos é:
Evitar retrabalho decorrente de interpretações incorretas.
Garantir que o código final será mais eficiente e compacto.
Reduzir a complexidade técnica durante a programação.
Substituir a prototipagem por cenários alternativos.
Eliminar a necessidade de documentação complementar.
No contexto de prioridade de casos de uso, qual alternativa descreve corretamente a categoria “Essencial”?
É importante, mas não impede a entrega do sistema caso não seja implementada.
É dispensável, pois o sistema pode funcionar plenamente sem ela.
É fundamental, sem a qual o sistema não pode ser considerado completo.
É opcional, podendo ser substituída por soluções manuais externas.
É útil, mas pode ser adiada para versões futuras sem impacto imediato.
Um ator principal em um caso de uso é definido como:
Qualquer dispositivo ou sistema externo que troca dados com outro sistema.
Aquele que interage diretamente com o sistema em análise.
Um ator que atua indiretamente através de um intermediário humano.
O cliente que fornece as regras de negócio para o analista.
O usuário secundário que acompanha o processo sem registrar ações.
Em casos de uso, uma pré-condição em casos de uso tem como característica:
Deve ser atendida antes da execução do caso de uso.
É sempre obrigatória e eventualmente pode ser opcional.
É verificada apenas após a conclusão da transação.
Refere-se exclusivamente ao desempenho do sistema.
Substitui o fluxo de eventos no caso de uso principal.
O fluxo de exceção em casos de uso caracteriza-se por:
Estar associado a erros inesperados ou interrupções no processo.
Ser a trajetória mais comum utilizada pelos usuários do sistema.
Descrever apenas os objetivos principais do negócio que são excedidos.
Detalhar os cálculos financeiros necessários ao sistema.
Representar a sequência normal de passos do cliente.
A classificação de prioridade como “Desejável” significa que:
É dispensável, já que o sistema funcionará plenamente sem ela.
É obrigatória, caso contrário o sistema não será implantado.
É essencial, pois sem ela o sistema não está completo.
É importante, mas impede a entrega inicial do projeto.
É fundamental, sendo a primeira a ser implementada no sistema.
Um ator secundário em um caso de uso pode ser:
Um usuário que não interage diretamente, mas fornece serviços ao sistema.
O cliente principal que opera diretamente todas as funções do software.
Um desenvolvedor responsável pela codificação da aplicação final.
Um gerente de projeto que valida os relatórios do andamento do sistema.
O fornecedor que vendeu a licença do software utilizado na empresa.
A pós-condição de um caso de uso refere-se a:
O estado que o sistema deve apresentar após a execução do caso.
As regras que precisam ser atendidas antes da execução do caso.
A sequência de eventos descritos no fluxo de exceção.
O resultado de cenários que ainda não foram implementados.
O comportamento alternativo do sistema diante de falhas técnicas.
Um exemplo de pré-condição em um caso de uso seria:
O usuário deve estar autenticado antes de acessar o sistema.
O sistema deve registrar o pedido após sua execução.
O relatório deve estar disponível após a consulta.
O cliente deve receber e-mail ao concluir a compra.
O pagamento deve ser confirmado antes do início da transação.
