Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante

Transcrição

1 1 - Q ( Prova: FCC TRT - 19ª Região (AL) - Analista Judiciário - Tecnologia da Informação / Engenharia de Software / 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. 2 - Q ( Prova: FCC TRT - 19ª Região (AL) - Analista Judiciário - Tecnologia da Informação / A avaliação do impacto de mudança de um requisito, muitas vezes, faz com que seja necessário retornar à sua fonte. Na validação dos requisitos, a equipe deve estar atenta, portanto, à a) rastreabilidade. b) adaptabilidade. c) qualidade. d) facilidade de compreensão. e) facilidade de verificação. 3 - Q ( Prova: CESPE SAD-PE - Analista de Controle Interno Tecnologia da Informação / Engenharia de Software / Análise de Requisitos; 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.

2 4 - Q ( Prova: FGV FIOCRUZ - Tecnologista em Saúde - TI - Sistemas de Informação / Sobre os processos de engenharia de requisitos, na elicitação e na análise ocorre total interação com os stakeholders no sistema, sendo o principal objetivo: a) a obtenção dos requisitos. b) a homologação do sistema. c) a elaboração do manual do usuário. d) a conversão de especificações em requisitos. e) a execução do estudo de viabilidade do sistema. 5 - Q ( Prova: UFBA UFBA - Analista de Tecnologia da Informação / Engenharia de Software / Engenharia de Requisitos; ) Em sistemas grandes e complexos, a determinação das conexões entre os requisitos torna-se geralmente uma tarefa difícil, sendo que as Tabelas de Rastreamento constituem uma ferramenta que ajuda a minimizar essa dificuldade. a) Certo b) Errado 7 - Q ( Prova: FCC TRT - 23ª REGIÃO (MT) - Analista Judiciário - Tecnologia da Informação / Tabelas de rastreamento para relacionar os requisitos identificados a um ou mais aspectos do sistema ou do seu ambiente devem ser desenvolvidas, segundo Pressman, na engenharia de requisitos, por meio da função de a) gestão. b) especificação. c) elaboração. d) negociação. e) validação.

3 8 - Q ( Prova: FCC INFRAERO - Analista de Sistemas - Gestão de TI / Engenharia de Software / Engenharia de Requisitos; ) Em relação à Engenharia de Software, é INCORRETO afirmar: a) O design de software, ao descrever os diversos aspectos que estarão presentes no sistema quando construído, permite que se faça a avaliação prévia para garantir que ele alcance os objetivos propostos pelos interessados. b) A representação de um design de software mais simples para representar apenas as suas características essenciais busca atender ao princípio da abstração. c) Iniciar a entrevista para obtenção dos requisitos de software com perguntas mais genéricas e finalizar com perguntas mais específicas sobre o sistema é o que caracteriza a técnica de entrevista estruturada em funil. d) No contexto de levantamento de requisitos, funcionalidade é um dos aspectos que deve ser levado em conta na abordagem dos requisitos funcionais. e) A representação é a linguagem do design, cujo único propósito é descrever um sistema de software que seja possível construir. 9 - Q ( Prova: FCC INFRAERO - Analista de Sistemas - Desenvolvimento e Manutenção / Engenharia de Software / Análise de Requisitos; Engenharia de Requisitos; ) Os produtos de trabalho resultantes da engenharia de requisitos são avaliados quanto à qualidade durante a etapa de validação de requisitos. Analise os itens a seguir referentes a essa etapa: I) Um dos principais mecanismos de validação de requisitos é a avaliação técnica formal. II) O modelo de análise pode garantir que os requisitos foram consistentemente declarados. III) É frequentemente útil examinar cada requisito em face de um conjunto de questões do tipo checklist. IV) A equipe de revisão que avalia os requisitos inclui apenas pessoas com conhecimento técnico na área de TI, como engenheiros de softwares, desenvolvedores etc. Está correto o que consta em a) I, II, III e IV. b) II e IV, apenas. c) I, II e IV, apenas. d) II, III e IV, apenas. e) I, II e III, apenas.

4 10 - Q ( Prova: FCC INFRAERO - Analista de Sistemas - Desenvolvimento e Manutenção / A engenharia de requisitos ajuda os engenheiros de software a compreender melhor o problema que eles vão trabalhar para resolver. Ela inclui um conjunto de tarefas que levam a um entendimento de qual será o impacto do software sobre o negócio, do que o cliente quer e de como os usuários finais vão interagir com o software. A função de negociação no processo de engenharia de requisitos a) especifica, revisa e valida o problema de modo a garantir que seu entendimento e o entendimento do cliente sobre o problema coincidam. b) refina e modifica os requisitos. É uma ação de modelagem de análise composta de várias tarefas de modelagem e refinamento. c) define quais são as prioridades, o que é essencial, o que é necessário. Clientes, usuários e outros interessados são solicitados a ordenar os requisitos e depois discutir os conflitos de prioridade. d) ajuda o cliente a definir o que é necessário. e) define o escopo e a natureza do problema a ser resolvido. 11. Para o desenvolvimento de um sistema de supermercado, mais especificamente para a conferência de produtos em estoque e prateleira, cite quatro requisitos funcionais e outros não funcionais. Funcionais: 1. O sistema deve permitir (ou implementar) a leitura de código de barras 2. Deve-se ler o código de barras da prateleira, para ver se os produtos estão no lugar certo 3. Deve-se ler o código de barras de cada produto (ou categoria de produtos) 4. Assim que a leitura for feita, deve-se consultar a base de dados para conferir se é o adequado 5. Conferir se o produto está dentro do prazo de validade 6. Conferir se o produto está dentro da margem de estoque Não funcionais: 1. O sistema deve operar em Android, para a leitura, e em Windows, no Servidor 2. No momento da conferência, a resposta deve ser rápida 3. Os resultados apresentados devem ser confiáveis, especialmente quanto às validades 4. As telas devem ter ícones de fácil compreensão e aparência simplificada 12. Explique a razão de haver dificuldade na definição dos requisitos de um sistema já na primeira entrevista e exemplifique tal situação. 1. A primeira reunião é aberta e, portanto, não destinada à elicitação de requisitos 2. Na primeira reunião, por ser mais informal, as informações tendem a ser desorganizadas, inespecíficas, genéricas e, portanto, poucos detalhes deverão surgir. 3. Os requisitos devem surgir ao longo de muitos encontros e atividades específicos para a sua elicitação 13. Exemplifique dois sistemas em que três ou mais requisitos não funcionais têm prioridades distintas uma sobre a outra, e porque. 1. Sistema de controle aéreo: 1.1. Tempo de resposta = muito curto. PORQUE: A maior urgência é evitar colisões, impactos 1.2. Facilidade de uso = importante. PORQUE: A interface pode colaborar diretamente na resposta 1.3. Portabilidade = bom. PORQUE: Pode haver S.O.s distintos operando em conjunto 2. Sistema de controle de estoque: 2.1. Portabilidade = muito importante. PORQUE: A leitura é realizada com máquinas com Android Facilidade de uso = importante. PORQUE: Em boa parte das vezes, o estoquista tem domínio específico e não muito tempo entre operações ou para detalhes minuciosos Tempo de resposta = bom. PORQUE: É mais importante ter a inteireza das informações do que a rapidez com que chegam.

5 14. Em que momento é mais adequado envolver os usuários secundários na discussão sobre o sistema? Após a primeira (ou até mesmo a segunda) reunião, dedicadas às descobertas primárias do Sistema. Após as (principais ou mais restritas) reuniões com os usuários primários (aqueles que diretamente influenciarão ou serão influenciados pelo sistema em questão). 15. Defina, em poucas palavras, requisitos, requisitos funcionais, não-funcionais e de domínio REQUISITOS: Necessidades a serem atendidas pelo sistema REQUISITOS FUNCIONAIS: REQUISITOS FUNCIONAIS: NÃO Requisitos que expressam necessidades diretas ou funcionais Slide: Declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações. Requisitos que atendem a necessidades globais, que não expressam uma operação direta Slide: Restrições sobre serviços ou funções oferecidos pelo sistema tais como restrições de timing, restrições sobre o processo de desenvolvimento, padrões, etc. Requisitos advindos do domínio de aplicação do sistema (e do domínio de atividade da instituição) e que refletem as características deste domínio. REQUISITOS DE DOMÍNIO: 16. Quais as diferenças entre requisitos de usuário e de sistema? DE USUÁRIO: Requisitos expressos em linguagem natural, sem jargões técnicos, ou seja, inteligíveis e com foco no próprio usuário. DE SISTEMA: Requisitos expressos em linguagem mais técnica, com foco no desenvolvimento do sistema e, portanto, compreensível pelo corpo técnico. 17. Como gerar resultados de viabilidade, se este antecede a elicitação de requisitos? Embora a viabilidade anteceda a elicitação de requisitos, esta deve ser baseada em um conjunto básico de requisitos levantado nas primeiras reuniões, podendo ser adicionado por outros advindos de observação e de experiências anteriores ou de outros (sistemas e analistas). 18. Gere uma lista com cinco questões que podem anteceder (preparar) a primeira reunião com o cliente. 1. Quais necessidades fundamentais da instituição este sistema deve atender? 2. Quais prioridades a instituição tem para que o sistema atenda? 3. Quais necessidades o sistema semelhante atual em execução não atende? 4. Como este sistema afetará ou influenciará os resultados da instituição? 5. O que ocorre sem a execução deste sistema na instituição? 6. Além das expectativas empresariais e gerenciais, a mesma ocorre nos níveis operacionais? 7. Quais as expectativas que os usuários finais e clientes depositam neste sistema? 19. Cite e classifique alguns pontos de vista (como o das prateleiras de supermercado, por exemplo). Gerente de estoque: Observa os valores totais e finais, de forma a poder tomar decisões quanto às falhas Repositor: Tem que saber se há produtos vencidos, se há a necessidade de reposição Vendedor: Precisa apenas saber se há o produto no estoque para poder concretizar a venda 20. Para uma compreensão mais geral, defina stakeholder, restrições e abstração. Stakeholder: Todo aquele (pessoa, sistema ou até hardware) envolvido com o sistema, que o influencia ou por ele é influenciado, de forma direta ou indireta. Restrições: Conjunto de regras que define o que deve (ou pode) ou não ser feito. Abstração: Captação do que é e como funciona (a instituição, a atividade, o sistema ) 21. Durante quanto tempo os requisitos podem se alterar? Por que? Até quando são aceitáveis? Os requisitos podem SEMPRE se alterar, porém isto não é muito conveniente, e deve ser evitado. PORQUE: Isto ocorre por várias razões, entre as quais, a possibilidade de má definição ou interpretação, as mudanças de regras ou comportamentos institucionais ou governamentais Estas mudanças, especialmente se não impactantes, são aceitáveis até antes da implementação (às vezes ocorrem durante a mesma). Se impactantes, portanto, deveriam se modificar antes da implementação, ou seja, até as fases de análise e projeto.

6 22. Defina requisitos voláteis e requisitos permanentes. VOLÁTEIS: Requisitos que podem perder ser valor ou efeito durante a criação do sistema PERMANENTES: Requisitos, de certa forma imutáveis, que não se alteram durante todo o processo. 23. O que são e o que envolvem as entrevistas abertas e as fechadas? ABERTAS: São reuniões mais informais, sem um roteiro predefinido, normalmente com informações esparsas e genéricas. FECHADAS: Estas são reuniões mais formais, com roteiros bem definidos, cujas informações são organizadas e propositais. 24. Qual a importância da etnografia? A etnografia é fundamental para a elicitação de requisitos, pois corresponde à observação do ambiente, das atividades e dos comportamentos operacionais, que muitas vezes podem ser mais expressivos e evidentes que os requisitos citados formalmente. 25. Quais diferenças há entre a análise e as revisões de requisitos, e quais são os envolvidos em ambas? Análise: Observação da real existência, realidades, expressões e conflitos dos requisitos, pois há muita dificuldade do stakeholder em expressar-se ou demonstrar o que realmente desejam. Corpo técnico e stakeholders devem participar. Revisão: Análise manual sistemática de requisitos (já processados pela sua análise). Idem 26. O que se define na matriz de rastreabilidade de requisitos? Definem-se as prioridades e caminhos dos requisitos, levando em consideração as dependências e relacionamentos que há entre os requisitos. 27. O que ocorre no gerenciamento de requisitos e quem está envolvido nesta fase? O gerenciamento de mudanças de requisitos ocorre durante a engenharia de requisitos (elicitação, análise e revisão, e validação) e desenvolvimento do sistema, que procura garantir o máximo de completeza e consistência dos requisitos. As participações devem contar mais especialmente com o corpo técnico que atua diretamente na concepção do sistema, mas também com os stakeholders diretos (cliente e usuários que fornecem os requisitos).