Questão 360157

• Banca: CESPE / CEBRASPE
• Órgão: SAD-PE
• Ano: 2010
• Provas: CESPE - 2010 - SAD-PE - Analista de Controle Interno – Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Engenharia de Requisitos

Um requisito de software expressa as necessidades e restrições colocadas em um produto de software que contribuem para a solução de algum problema do mundo real. Acerca desse assunto, assinale a opção correta.

• A. Os contratantes ou clientes são os principais colaboradores envolvidos no fornecimento de informações para o processo de levantamento ou elicitação de requisitos de software, os demais grupos de pessoas que podem fornecer informações são considerados de importância secundária.
• B. As necessidades dos usuários a serem atendidas por um produto de software constituem a classe de requisitos funcionais, e as restrições mencionadas na definição de requisitos constituem a classe de requisitos não funcionais.
• C. Entre as fontes de informação para a elicitação de requisitos, destacam-se, além dos colaboradores, o conhecimento do domínio de aplicação em que o software funcionará, o ambiente operacional do software e o ambiente organizacional.
• D. A negociação de requisitos, de forma similar à observação do ambiente organizacional, é uma atividade típica da fase de elicitação de requisitos.
• E. A técnica de casos de uso, empregada em alguns modelos de desenvolvimento de software atuais, é mais aderente à construção de cenários durante a construção de protótipos que durante a elicitação de requisitos.

Gabarito: C

Comentários

• a) E.Todos os envolvidos têm importância no levantamento de requisitos, sejam clientes sejam demais grupos.
  b) E. As necessidades dos usuários correspondem sim aos requisitos funcionais, porém as restrições mencionadas na definição de requisitos não correspondem aos requisitos não-funcionais. Requisitos não-funcionais descrevem a qualidade do produto no que tange a desempenho, usabilidade, confidencialidade, segurança, disponibilidade,...
  c) C.
  d) E. A elicitação de requisitos corresponde ao levantamento de requisitos junto ao cliente.
  e) E. A técnica de casos de uso é utilizada para descrever um cenário passível de iteração, cada caso foca numa característica do sistema. Os protótipos não precisam suportar todos os casos de uso.
  
  Fonte: http://www.wthreex.com/rup/portugues/index.htm
  
• a. E - Os Contratantes (clientes) normalmente são da direção da empresa e devem ser ouvidos. Todavia, os usuários são imprescindíveis para o levantamento.
  b. E - requisitos funcionais OK. Requisitos não-funcionais envolve não só restrições, mas também propriedades emergentes que envolvem funcionalidade, usabilidade, confiabilidade, desempenho e suportabilidade.
  c. C
  d. Negocião é atividade típica da fase de análise
  e. Na elicitação o caso de uso é bastante utilizado, pois é compreensível para os usuários.
• Adicionando aos comentários dos colegas, especificamente sobre a letra D, Sommerville diz: "são atividades do processo de elicitação de requisitos, pela ordem: obtenção; classificação e organização; priorização e negociação; documentação."
• Eu acho que a grande dúvida está entre b e c.
  
  Na letra b temos:
  
  "As necessidades dos usuários a serem atendidas por um produto de software constituem a classe de requisitos funcionais, e as restrições mencionadas na definição de requisitos constituem a classe de requisitos não funcionais."
  
  Os requisitos funcionais realmente visam atender as funções de um software, função que eu entro com uma ação e o software me retorna um resultado.
  
  Os requisitos não-funcionais da mesma forma eles expressão as restrições funcionais, não são diretamente especificados mas são propriedades emergentes, isto é, espera-se que eles sejam alcançados partindo a especificação atual. Eles são inferidos e difíceis de serem validados quantitativamente.
  
  O grande erro, ao meu ver, está em dizer que os requisitos funcionais são os que atendem as necessidades dos usuráios. Ora, se eu quero um software que me dê o menor caminho entre russas e joão pessoa (requisito funcional), porém o software tem que ter um bom desempenho porque não adianta calcular a rota depois que a entrada para a estrada passou..." Nesse caso os requisitos não-funcionais são também uma necessidade do cliente.
  
  Na letra d, como o colega já disse, "observação do ambiente organizacional" é uma técnica de levantamento de requisitos, não uma atividade.
• Ilustrando como eu entendo o erro da opção (B).
  Você está fazendo a elicitação dos requisitos e o cliente, por exemplo, o chefe do DP,  indica um requisito funcional - calcular o salário - e ao mencionar este requisito ele já determina as restrições - Olha, utiliza modelo espiral, codifica em Java, lembre-se de privacidade, segurança, usabilidade, blablablabla.
  
  Os RNF não são mencionados na definição dos RF.  Como bem disse o T.Renegado, eles "não são diretamente especificados mas são propriedades emergentes".
  
  Quanto a opção (D), "observação do ambiente organizacional" (Etnografia) é uma técnica e não uma atividade.
  A dificuldade maior está na redação da opção.
• Segundo essa questao aqui da FCC , cita Sommerville afirmando que negociacao faz parte do processo de elicitacao...
  
  
  13 • Q193183      

  Prova: FCC - 2011 - TRT - 19ª Região (AL) - Analista Judiciário - Tecnologia da Informação

  Disciplina: Engenharia de Software | Assuntos: Análise de Requisitos;  Engenharia de Requisitos; 

  De acordo com Sommerville, são atividades do processo de elicitação de requisitos, pela ordem:

   

  • a) casos de uso; análise; projeto; arquitetura.
  • b) etnografia; casos de uso; análise; validação; arquitetura.
  • c) entrevista; etnografia; documentação; registro.
  • d) cenários; classificação; organização; priorização; documentação.
  • e) obtenção; classificação e organização; priorização e negociação; documentação.
  O Gabarito dessa questao e' letra E....
  fiquei em duvida agora, pois para mim negociacao faria aprte do processo de elicitacao...
  
• Apenas retirando a dúvida do colega acima: a negociação faz parte da elicitação de requisitos, porém a questão diz "de forma similar à observação do ambiente organizacional". Ou seja, a questão afirma que observação do ambiente organizacional também é uma atividade TÍPICA de elicitação de requisitos, e não é.
• Quanto a alternativa D e ao comnetário do Luiz Cláudio...
  A observação do ambiente organizacional é sim uma técnica de elicitação, chamda de etnografia. O erro da alternativa D é que a negociação de requisitos é uma atividade típica da fase de análise e não da fase de elicitação.
  
  Na verdade, na visão do Sommerville, elicitação e análise são como se fosse duas etapas de uma mesma fase (Elicitação e Análise), mas algumas bancas cobram como se fossem fases diferentes, talvez se baseando na visão do Pressman, que separa a engenharia de requisitos de forma mais granular.
• Ao meu ver essa questão teria que ser anulada, pois a questão B também está correta. Sammervile em seu livro de engenharia de requisitos 8º edição, menciona no caítulo 6 página 82. Requisitos não funcionais ... Como alternativa, eles podem definir restrições, como capacidade dos dispositivos de E/S (entrada e saída) e as representações de dados usadas nas interfaces do sistema.
  Como a questão mencionou, restrições na definição de requisitos, pode ser interpretada que o usuário quer uma capacidade de E/S mas rápida.
• Eu acho que essa expressão "necessidades do usuário" é muito vaga pra falar que é requisito funcional. Pensa só: em uma aplicação de tempo real, é necessidade do usuário que a aplicação não demore pra responder e isso é um requisito não-funcional. Pra mim, um erro na letra B é esse.
• OS RNF não são sempre restrições e nem toda restrição é um RNF. Exemplo: "O usuário fecha o pedido. O sistema apresenta um sumário da compra especificando o preço final dos produtos e incluindo o frete e o desconto. Caso exista desconto, o valor mínimo deve ser de R$ 10,00". 
• Não concordo muito com a afirmaçào do colega acima que diz que "..todo RNF é uma restrição".
  Existem vários requisitos não funcionais (confiabilidade, padrão..) que não são propiamente restrições...