Engenharia de Software Unidade II

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.