Questão 1222243

• Banca: FCC
• Órgão: SABESP
• Ano: 2014
• Provas: FCC - 2014 - SABESP - Analista de Gestão - Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Engenharia de Requisitos

Após um estudo inicial de viabilidade, o próximo estágio do processo de engenharia de requisitos é a elicitação e análise de requisitos. Nesta atividade deve-se

• A. permitir que os engenheiros de software trabalhem com os clientes e os usuários finais para obterem apenas informações sobre o domínio da aplicação e os serviços que o sistema pode oferecer.
• B. interagir com os stakeholders por meio da observação e de entrevistas. Cenários e protótipos podem ser utilizados para ajudar os stakeholders a compreenderem o que o sistema vai incorporar.
• C. considerar apenas os requisitos vindos dos stakeholders, descartando-se os requisitos provenientes de todos os outros sistemas.
• D. realizar entrevistas, que são a melhor técnica para compreender os requisitos do domínio da aplicação, pois o conhecimento de domínio é tão familiar aos stakeholders que eles têm facilidade de explicá-lo.
• E. usar entrevistas, que são uma técnica eficaz para a elicitação do conhecimento sobre os requisitos e restrições organizacionais porque as estruturas organizacionais que serão descritas corresponderão fielmente à realidade do processo de tomada de decisão.

Gabarito: B

Comentários

• Elicitar: descobrir, tornar explícito,obter o máximo de informações parao conhecimento do objeto em questão

  => A equipe técnica deve esclarecer:

       ◦ O domínio da aplicação

       ◦ Os serviços que a aplicação deve oferecer 

       ◦ As restrições sob as quais a aplicação deve operar

  => Envolve vários stakeholders;

  => Técnicas de Elicitação:

       ◦ Entrevistas

       ◦ Questionários

       ◦ Leituras de documentos

       ◦ Observações e análises sociais (etnografia)

       ◦ Workshops de requisitos

       ◦ Cenários (Casos de Uso)

       ◦ Prototipagem

• falou em elicitação e analise de requisitos = interação com stakeholders
  

• Técnicas de Elicitação de Requisitos

  1. Entrevistas

  2. WorkShop de Requisitos

  3. Brainstorming

  4. Questionário

  5. Grupo Focal

  6. Etnografia

  7. Observação

  8. Análise de Protocolo

  9. Pontos de vista

  10. Reuso de Requisitos

  11. Estudo de Documentação / Analise de Conteúdo

  12. Sessões JAD (Joint Application Design)

  13. Prototipação

  14. Cenários

  15. Casos de Uso

• questão difícil, fácil pra confundir minha cuca

• a) permitir que os engenheiros de software trabalhem com os clientes e os usuários finais para obterem apenas informações sobre o domínio da aplicação e os serviços que o sistema pode oferecer. ERRADO: na elicitação deve ser obtido o máximo de informações.
  
  

  b) interagir com os stakeholders por meio da observação e de entrevistas. Cenários e protótipos podem ser utilizados para ajudar os stakeholders a compreenderem o que o sistema vai incorporar. CORRETO
  
  

  c) considerar apenas os requisitos vindos dos stakeholders, descartando-se os requisitos provenientes de todos os outros sistemas. ERRADO: na elicitação deve ser obtido o máximo de informações.
  
  

  d) realizar entrevistas, que são a melhor técnica para compreender os requisitos do domínio da aplicação, pois o conhecimento de domínio é tão familiar aos stakeholders que eles têm facilidade de explicá-lo. ERRADO: quem disse ser a melhor técnica? Se basear apenas em entrevistas é muito arriscado pois os stakeholders, exatamente por muito entender sua área de negócio, podem omitir alguns requisitos, subentendendo que os engenheiros de software já saibam.
  
  

  e)usar entrevistas, que são uma técnica eficaz para a elicitação do conhecimento sobre os requisitos e restrições 
  organizacionais porque as estruturas organizacionais que serão descritas corresponderão fielmente à realidade do processo de tomada de decisão. ERRADO: mesmo motivo da D.

• Fique encucado... B)"(...) Cenários e protótipos podem ser utilizados para ajudar os stakeholders a compreenderem o que o sistema vai incorporar". Pensei que as tecnicas de levantamento permitiam a compreensão dos desenvolvedores para o que o sistema vai incorporar. Pergunta: desenvolvedores podem ser stakeholders?

• Discordo do gabarito ao afirmar ".... para ajudar os stakeholders a compreenderem o que o sistema vai incorporar"

  
  

  A elicitação de requisitos é na verdade uma etapa em que os ENGENHEIROS DE SOFTWARE buscam entender o quê os stakeholders esperam do software, e não o contrário.
  

• essa questão não tem mistério vamos lá:
  a) o inicio estava  tudo certinho e depois que vem a palavra "apenas" deixa ela errada porque queremos sim informações sobre o domínio e o que sistema deve fornecer, mas não é só isso, queremos mais coisa tipo RNF logo queremos também o desempenho exigido do sistema, restrições de hardware e assim por diante.
  b) especificação e analise de requisitos dando um resumo rápido nós queremos aqui levantar os requisitos e gerar um documento preliminar a alternativa diz que queremos descobrir por meio da observação (etnografia) e de entrevistas. Correto até aqui vejam que ele não limitou as técnicas utilizadas lembre-se que estamos querendo levantar informações e a gente faz isso como? Interagindo com os stakeholders (partes interessadas).  Cenários e protótipos podem ser utilizados para ajudar os stakeholders a compreenderem o que o sistema vai incorporar. Correto também pessoal, se estamos ainda na coleta de requisitos é claro que eu posso já criar um protótipo aqui nessa fase para o cliente ir analisando e verificar se é realmente isso que ele vai querer e ainda podemos coletar mais requisitos com essa prototipação. Lembrem-se de novo que estamos buscando informações para gerar um documento preliminar de requisitos.
  c)  espera aí, e a técnica de Leitura de documento cadê? Mais uma vez a alternativa limitando "apenas" requisitos vindo de stakeholders o que torna essa alternativa errada. Requisitos podem vim também daqueles sistemas antigos, aqueles absoletos que rodam na sua empresa mais que são importantes. Então esses sistemas ele tem por pior que seja algum tipo de documentação que você pode utilizar e fazer a leitura desses documentos para possivelmente descobrir novos requisitos. 
  d) os stakeholders não tem facilidade de explicar esses requisitos, muitas vezes eles nem sabe o quer do sistema computacional e o analista tem que ter a habilidade de extrair aquele conhecimento tácito que para o cliente parece ser muito óbvio mais para nós não.
  e) a explicação da D serve para essa também. 

• Cenários e protótipos podem ser utilizados para ajudar os stakeholders a compreenderem o que o sistema vai incorporar. Correto também pessoal, se estamos ainda na coleta de requisitos é claro que eu posso já criar um protótipo aqui nessa fase para o cliente ir analisando e verificar se é realmente isso que ele vai querer e ainda podemos coletar mais requisitos com essa prototipação.