Investigação do ensino de engenharia de requisitos na perspectiva da academia e da indústria: um enfoque em documentação de requisitos

Programa de Pós-Graduação em Sistemas e Computação Mestrado Acadêmico em Sistemas e Computação

Investigação do Ensino de Engenharia de

Requisitos na Perspectiva da Academia e da

Indústria: Um enfoque em Documentação de

Requisitos

João Carlos Epifanio

Natal-RN Agosto 2018

Investigação do Ensino de Engenharia de Requisitos na

Perspectiva da Academia e da Indústria: Um enfoque

em Documentação de Requisitos

Dissertação de Mestrado apresentada ao Pro-grama de Pós-Graduação em Sistemas e Computação do Departamento de Informá-tica e MatemáInformá-tica Aplicada da Universidade Federal do Rio Grande do Norte como re-quisito parcial para a obtenção do grau de Mestre em Sistemas e Computação.

Linha de pesquisa: Engenharia de Software

Orientadora

Profa. Dra. Marcia Jacyntha Nunes Rodrigues Lucena

PPgSC  Programa de Pós-Graduação em Sistemas e Computação DIMAp  Departamento de Informática e Matemática Aplicada

CCET  Centro de Ciências Exatas e da Terra UFRN  Universidade Federal do Rio Grande do Norte

Natal-RN Novembro 2011

Epifanio, João Carlos.

Investigação do ensino de engenharia de requisitos na perspectiva da academia e da indústria: um enfoque em documentação de requisitos / João Carlos Epifanio. - 2018. 133f.: il.

Dissertação (mestrado) - Universidade Federal do Rio Grande do Norte, Centro de Ciências Exatas e da Terra, Programa de Pós-Graduação em Sistemas e Computação. Natal, 2018.

Orientadora: Marcia Jacyntha Nunes Rodrigues Lucena.

1. Engenharia de Requisitos - Dissertação. 2. Ensino-aprendizagem - Dissertação. 3. Recomendações - Dissertação. I. Lucena, Marcia Jacyntha Nunes Rodrigues. II. Título.

RN/UF/CCET CDU 004.414.22

Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Ronaldo Xavier de Arruda - CCET

Agradecimentos

Obrigado Deus. Agradeço a meus pais que zeram de tudo para que mais um sonho fosse possível. Aos meus irmãos por sonharem comigo, me motivarem e por todas as ligações e mensagens que me zeram ter mais fôlego por mais que achassem que era um simples 'oi'. A minha orientadora, Márcia, por ter me dado a oportunidade e um momento de muita incerteza. Ao LETS, por todo acolhimento, os risos e a grande ajuda dada. Em especial a Érica e Gabriela que sempre tiveram comigo. As grandes amizades que conquistei em Natal e tiveram seu peso nos momentos de desabafo e descontração. Por causa de vocês eu me senti amado em uma rotina completamente nova, cheio de desaos e incríveis momentos felizes. As minhas amizades da antiga Universidade que continuaram mesmo que com toda distância. Ao Léuson e Rafael Toledo por compartilharmos da mesma experiência acadêmica de mestrado e pela grande amizade que levarei pela vida. Eu serei eternamente grato a todos vocês e por tudo que zeram e me desejaram.

compasso, inexoravelmente chega lá. Se avexe não. Observe quem vai subindo a ladeira, seja princesa ou seja lavandeira, pra ir mais alto vai ter que suar.

Perspectiva da Academia e da Indústria: Um enfoque

em Documentação de Requisitos

Autor: João Carlos Epifanio Orientador(a): Profa. Dra. Marcia Jacyntha Nunes Rodrigues Lucena

Resumo

Na literatura muitos problemas são apontados referentes ao processo da Engenharia de Requisitos. Pesquisas recentes demonstram que os ambientes de desenvolvimento de soft-ware enfrentam muitos desaos que vão desde a elicitação de requisitos até à sua validação. Os desaos listados na literatura fazem parte de tópicos ensinados na disciplina de En-genharia de Requisitos oferecidos nos cursos de graduação em Ciência da Computação e cursos ans. Esses desaos impactam na qualidade dos produtos e podem colocar em risco a continuidade de um projeto. Logo, percebe-se a existência de um décit no ensino da disciplina que impacta na indústria bem como a falta de conexão em ambos os contextos. A disciplina costuma ter um modelo de ensino tradicional, diante desse cenário, este tra-balho elencou metodologias e atividades, com foco em documentação, que dinamizem o ensino. Foi necessário realizar uma revisão sistemática da literatura bem como a realização de survey com professores e engenheiros. Concluiu-se que no contexto da academia muitos desaos, que impactam na indústria, podem ser contornados. Há também a necessidade de atividades mais práticas e novas abordagens em sala de aula. Na indústria, recomenda-se a colaboração com à academia. Desta forma, uma vez identicadas as demandas do setor, a academia pode proporcionar aos futuros prossionais uma formação baseada nas habilidades esperadas.

the Academy and Industry Perspective: A Focus on

Requirements Documentation.

Author: João Carlos Epifanio Supervisor: Profa. Dra. Marcia Jacyntha Nunes Rodrigues Lucena

Abstract

In the literature, many problems are pointed out regarding the process of Requirements Engineering. Recent research shows that software development environments face many challenges ranging from requirement elicitation to validation. The challenges listed in the literature are part of topics within the academy in the lecture of Requirements Engine-ering in undergraduate courses in Computer Science and related elds. Those challenges impact on product quality and may compromise the continuity of a project. Therefore, we believe that maybe there is a decit in the teaching of the lecture that impacts on the industry, besides a possible lack of connection in both contexts. The discipline usually has a traditional teaching model, concerning that scenario, this work lists methodologies and activities with a focus on requirements documentation. For that, it was necessary to perform a systematic review of the literature and a survey directed to professors and industry. It was concluded that in the context of academia many challenges, which impact on industry, can be overcome. There is Also a need for more practical activities and new approaches in the classroom. In the industry, we recommend that they collaborate with the academy. In this way, once the industry demands are identied, academy can provide, for the future professionals, a formation based on expected skills.

Lista de guras

1 Procedimentos Metodológicos . . . p. 19 2 Processo de Engenharia de Requisitos (SOMMERVILLE, 2004) . . . p. 24

3 Processo de Especicação e Análise de Requisitos (SOMMERVILLE, 2004) p. 25

4 Processo de Revisão Sistemática . . . p. 32 5 Etapas da condução da Revisão . . . p. 36 6 Estados que possuem a disciplina como obrigatória . . . p. 52 7 Estados participantes na pesquisa . . . p. 55 8 Regiões dos participantes . . . p. 56 9 Metodologias e abordagens utilizadas . . . p. 58 10 Processo ou atividades em foco na disciplina . . . p. 59 11 Tópicos ou etapas mais difíceis de se ensinar . . . p. 61 12 Diculdades e desaos no ensino da disciplina . . . p. 63 13 Abordagens para o ensino de documentação . . . p. 65 14 Desaos no ensino de documentação . . . p. 66 15 Desaos percebidos com base na observação dos alunos . . . p. 68 16 Desaos no ensino de documentação . . . p. 77 17 Documentação gerada pela empresa . . . p. 79 18 Média de horas para documentação . . . p. 80 19 Artefatos listados pelas empresas . . . p. 81 20 Cenário 1 . . . p. 83 21 Cenário 2 . . . p. 83 22 Cenário 3 . . . p. 84

24 Cenário 5 . . . p. 84 25 Modelo de desenho abstrato para exercitar descrição e interpretação . . p. 96 26 Modelo apresentado para avaliação da ecácia das atividades . . . p. 103 27 Modelo apresentado para avaliação quanto ao conhecimento das atividadesp. 104

Lista de tabelas

1 Desaos na Engenharia de Requisitos (INAYAT et al., 2015) . . . p. 26

2 Questões de Pesquisa da Revisão Sistemática . . . p. 33 3 Temas de interesse da String . . . p. 34 4 Trabalhos selecionados . . . p. 38 5 Período onde a disciplina se encontra na grade curricular . . . p. 39 6 Trabalhos que descreviam os tópicos lecionados na disciplina . . . p. 40 7 Metodologias e técnicas de ensino aplicadas a disciplina . . . p. 41 8 Artefatos gerados ou usados na disciplina . . . p. 45 9 Cursos com Disciplina de Engenharia de Requisitos . . . p. 52 10 Relação de questões do survey dos docentes . . . p. 53 11 Resumo dos docentes participantes . . . p. 56 12 Pontos em comum e diferenças com os achados na revisão da literatura p. 70 13 Relação de questões do survey para indústria . . . p. 76 14 Exemplo de questão para Quiz . . . p. 93 15 Avaliação dos docentes quanto a ecácia e dinâmica das atividades . . . p. 105 16 Avaliação dos docentes quanto ao conhecimento das atividades . . . p. 106 17 Semelhanças e diferenças entre os trabalhos . . . p. 113

Sumário

3 Revisão Sistemática p. 32

3.1 Planejamento . . . p. 32 3.2 Condução . . . p. 36 3.3 Resultados . . . p. 37

3.3.1 Como a disciplina de Engenharia de Requisitos está estruturada

nos currículos de ensino superior? (QP1) . . . p. 37 3.3.2 Quais tópicos são lecionados? (QP2) . . . p. 37 3.3.3 Quais metodologias/técnicas de ensino são utilizadas em sala

pe-los docentes? (QP3) . . . p. 40 3.3.4 Que tipo de material é produzido nas aulas? (QP4) . . . p. 44 3.4 Discussão . . . p. 45

4 Ensino de Engenharia de Requisitos na Perspectiva de docentes p. 49 4.1 Contexto . . . p. 49 4.2 Objetivos . . . p. 50 4.2.1 Cenário da disciplina no país . . . p. 50 4.3 Questões de Pesquisa . . . p. 52 4.4 Metodologia . . . p. 53 4.4.1 Questões do Survey e Motivação . . . p. 54 4.5 Resultados . . . p. 55 4.6 Discussão . . . p. 69 4.7 Considerações . . . p. 72 5 Desaos e Recomendações de Engenharia de Requisitos na

Indús-tria p. 74

5.1 Objetivos . . . p. 74 5.2 Questões de Pesquisa . . . p. 75 5.3 Metodologia . . . p. 75 5.3.1 Questões do Survey e Motivação . . . p. 76 5.4 Dados do survey destinado à indústria . . . p. 77 5.5 Discussão . . . p. 87 5.6 Considerações . . . p. 89 6 Atividades para o Ensino de Documentação de Requisitos p. 91 6.1 Contexto e Motivação . . . p. 91 6.2 Listagem de Atividades . . . p. 93 6.2.1 Quiz . . . p. 93 6.2.2 Palestra . . . p. 94

6.2.4 Trabalhando descrição com blocos de montar . . . p. 95 6.2.5 Trabalhando descrição com jogos antigos . . . p. 97 6.2.6 Reconhecendo erros na especicação de requisitos . . . p. 97 6.2.7 Exercitando técnicas de documentação em sistemas reais com

cli-entes reais . . . p. 99 6.2.8 Debate com artigos de eventos especícos . . . p. 99 6.2.9 Interdisciplinaridade . . . p. 100 6.2.10 Trabalhando especicação com cenários . . . p. 100 6.2.11 Dramatizações . . . p. 101 6.2.12 Jogos . . . p. 101 6.2.13 Ferramentas . . . p. 102 6.3 Avaliação . . . p. 102 6.3.1 Análise dos Dados . . . p. 103 6.4 Discussão . . . p. 106 6.5 Considerações Finais . . . p. 107

7 Trabalhos Relacionados p. 108

7.1 Proposta de Benitti (2017) . . . p. 108 7.2 Proposta de Calazans et al. (2017a) . . . p. 109 7.3 Proposta de Inayat et al. (2015) . . . p. 110 7.4 Proposta de Andrade et al. (2008) . . . p. 111 7.5 Proposta de Minor e Armarego (2005a) . . . p. 112 7.6 Semelhanças e Diferenças . . . p. 113

8 Considerações Finais p. 114

8.1 Contribuição . . . p. 114 8.2 Ameaças e Limitações . . . p. 117

Referências p. 118 Apêndice A -- Referências da Revisão Sistemática p. 126

Apêndice B -- Survey professores p. 128

1 Introdução

A Engenharia de Requisitos é conhecida por tratar-se de uma área onde os seus problemas impactam na qualidade do software em desenvolvimento (NIAZI; SHASTRY,

2003). A correção de problemas após a entrega do software pode custar muito mais caro do que se a mesma fosse feita nas fases iniciais do projeto (BOEHM; BASILI, 2001).

No desenvolvimento de software a primeira atividade a ser feita é a especicação das funcionalidades e restrições do sistema, atividades iniciais do processo de Engenharia de Requisitos (SOMMERVILLE, 2004). A ausência de detalhes na especicação do sistema ou

uma incorreta especicação pode gerar grandes prejuízos (BULLET, 1987). Logo, a

especi-cação dos requisitos está entre as atividades mais importantes durante o desenvolvimento do software. Segundo Sedelmaier e Landes (2014), essa área é o centro da Engenharia de Software.

A Engenharia de Software é o uso de princípios bem fundamentados da engenharia para gerar um produto econômico, conável e que seja funcional (PRESSMAN, 2011).

Assim, a aplicação correta do processo impacta no produto ou serviço construído. Ao nal do processo, espera-se ter um produto de qualidade que, de acordo com Nuseibeh e Easterbrook (2000), implica no quão el o sistema é com relação à nalidade na qual foi construído.

Mesmo com anos de uso do processo de Engenharia de Requisitos, muitas empresas ainda enfrentam diculdades no que diz respeito ao entendimento, documentação e geren-ciamento de requisitos. Segundo o estudo de Wiegers e Beatty (2013), dentre as principais causas de falha nos projetos, podem-se encontrar a incompletude de requisitos e o mau entendimento do negócio. No estudo realizado por Khan e Malik (2017) foram listados: má otimização de cronograma, complexidade de software e mudança de requisitos. Jack-son (2006) cita a mudança de requisitos como um dos principais motivos de falha nos projetos. Também, Marçal et al. (2010) mostra que o mau gerenciamento de requisitos corresponde a um dos principais problemas no desenvolvimento de software.

Como visto, a área de Engenharia de Requisitos apresenta muitos desaos a serem vencidos. Consequentemente isso oferece uma oportunidade, para que haja melhoria nesse processo.

1.1 Motivação

Atualmente, a indústria ainda busca por melhores práticas na Engenharia de Requisi-tos, como mencionado nos estudos conduzidos por: Minor e Armarego (2005b), Inayat et al. (2015), Vilela et al. (2017), Schön, Thomaschewski e Escalona (2017). Nesse contexto, Andrade et al. (2008) levanta um questionamento importante: ou ainda não se dedica tempo para especicação de requisitos, ou o ensino de Engenharia de Requisitos poderia ser melhorado para aumentar a qualidade do processo de Engenharia de Requisitos.

O ensino da Engenharia de Requisitos envolve um conjunto de conceitos que vão desde a contextualização do que é um requisito, como especicá-lo e todo processo relativo a essa área (SEDELMAIER; LANDES, 2017a). Além dos conceitos, ainda são ensinados as

atividades, métodos e técnicas fundamentais para a realização do processo de Engenharia de Requisitos (LIANG; GRAAF, 2010).

Pesquisas voltadas para o desenvolvimento de software identicaram que as falhas nos sistemas estão, muitas vezes, relacionadas às atividades de requisitos (JOHNSON, 2009). A

Engenharia de Software possui inúmeras atividades onde cada uma delas detêm uma certa complexidade tornando difícil o ensino-aprendizagem (ABKE et al., 2013). A Engenharia

de Requisitos é o centro da Engenharia de Software, e todo processo parte a partir dela, logo a área concentra um fator de diculdade (SEDELMAIER; LANDES, 2014).

Nas pesquisas recentemente feitas, que identicaram problemas no processo, foram elencados (INAYAT et al., 2015): comunicação, validação, documentação, negligência de

requisitos não funcionais e mudança de requisitos . Outro trabalho, identica a falta de preparação das pessoas que realizam atividades relacionadas a área de requisitos (MINOR; ARMAREGO, 2005a).

As pessoas que lidam com Engenharia de Requisitos precisam da preparação no que diz respeito não só a conhecimentos, mas também às habilidades e atitudes a serem de-sempenhadas. Tendo em vista a formação desses prossionais, identica-se que a academia pode oferecer os ensinamentos/suporte para os que irão ingressar nessa carreira. Traçando um paralelo entre indústria e academia, é possível identicar que os problemas apresen-tados nos estudos, são tópicos que podem ser ensinados na disciplina de Engenharia de

Requisitos (ZORZO A. F.; NUNES, 2017) ou em disciplinas ans. O ensino ecaz sobre

requisitos tem uma missão importante para os prossionais que irão desempenhar esse papel. Tamanha importância dos conhecimentos e habilidades (SEEK, 2003), levaram, nas

últimas décadas, à adesão de temas relacionados a requisitos nos cursos de graduação em computação e ans.

Nas ementas de cursos de computação e informática, propostos pela Sociedade Brasi-leira de Computação por Zorzo A. F.; Nunes (2017), é possível encontrar como a Engenha-ria de Requisitos pode ser lecionada, caso tenha a disciplina de EngenhaEngenha-ria de Requisitos. Em outra disciplina, como Gerenciamento de Projetos, o processo de elicitação de requi-sitos também pode ser ensinado. Considerando a importância da disciplina de requirequi-sitos de software, alguns cursos a colocam de forma individual e especíca em seu currículo, aprofundando ainda mais seus conceitos.

Enquanto no contexto da indústria, são muitos os processos adotados pelas empresas. Sabe-se que nem todas possuem cargos voltados especicamente para Engenharia de Re-quisitos. Em casos onde não exista, certamente desenvolvedores farão esse papel cedo ou tarde. Em estudo realizado por Paldês et al. (2017) os autores listam as habilidades pre-sentes nas vagas para Engenheiro de Requisitos no Brasil. Dentre as habilidades prepre-sentes encontram-se as relativas à elicitação, comunicação e documentação. Essas habilidades são bastante citadas na literatura como desaos na área, bem como motivo de falha em projetos.

É preciso que membros de equipe possuam habilidades sociais para saber interagir com os stakeholders, pessoas com interesse ou afetadas pelo projeto (FREEMAN; REED, 1983) ,

que muitas vezes podem não saber detalhes técnicos (NUSEIBEH; EASTERBROOK, 2000).

Os prossionais devem estar preparados para lidar com clientes que muitas vezes podem informar descrições imprecisas, confusas e(ou) complexas demais do que será construído. Na academia, os alunos possuem diculdade em entender a disciplina de requisitos, por isso acabam não compreendendo a importância da área bem como seu impacto ( SEDEL-MAIER; LANDES, 2014; PENZENSTADLER et al., 2014; PEIXOTO et al., 2011). Considerando

o papel do professor, estes precisam utilizar técnicas dinâmicas para atrair o interesse dos alunos (PINHEIRO; GONÇALVES, 2001).

1.2 Problema e Hipótese

A questão central desta pesquisa, visualizando a academia é: Há obstáculos no pro-cesso de ensino-aprendizagem que reete no conhecimento supercial dos propro-cessos, téc-nicas e métodos da disciplina. Ao chegarem na indústria, esses prossionais não estando preparados, afetam negativamente o processo de desenvolvimento como um todo.

Considerando o problema, as seguintes hipóteses são levantadas: (a) existe uma ca-rência na formação dos estudantes com relação à ecácia das metodologias aplicadas, abordagens e(ou) atividades utilizadas na engenharia de requisitos; (b) o perl formado pela academia é diferente do perl esperado pela indústria.

Os estudantes após formados costumam ingressar no mercado de trabalho e, sem o devido conhecimento em assuntos como o de Engenharia de Requisitos, podem gerar alguns dos problemas citados anteriormente nas seções anteriores. Os tópicos elencados como causadores de problemas na indústria podem não ser bem aprofundados em sala de aula, talvez pela forma como são apresentados em sala de aula (através de dinâmicas e/ou metodologias de ensino).

1.3 Objetivos

O objetivo deste trabalho é investigar o ensino de Engenharia de Requisitos relacio-nando a visão da academia e da indústria no Brasil.

Para alcançar o objetivo geral, têm-se os seguintes objetivos especícos: • Identicar os fundamentos da área de Engenharia de Requisitos;

• Realizar uma Revisão Sistemática na Literatura a respeito de relatos acadêmicos do ensino de Engenharia de Requisitos;

• Analisar as ementas e planos de curso de Engenharia de Requisitos em currículos das áreas de Computação e Engenharia do Brasil;

• Conhecer a visão dos docentes sobre o ensino da Engenharia de Requisitos;

• Conhecer a visão de Engenheiros de Requisitos sobre desaos enfrentados na reali-zação das tarefas que fazem na indústria e sugestões para a academia;

• Listar atividades, metodologias, práticas e artefatos para o ensino de Engenharia de Requisitos;

• Validar as atividades elencadas com docentes que lecionam ou lecionaram Engenha-ria de Requisitos.

1.4 Metodologia

A pesquisa é um processo que requer um procedimento formal, realizado de maneira sistemática com o emprego de métodos e técnicas especícas (RUDIO, 2010). Neste

traba-lho a pesquisa é identicada como (PRODANOV; FREITAS, 2013):

• Pesquisa bibliográca por envolver a análise de publicações para identicar meto-dologias e propostas curriculares na literatura existente;

• Uma forma de gerar conhecimento para solução de problemas por incluir a listagem de atividades para auxiliar os professores na escolha de abordagens e metodologias no ensino de Engenharia de Requisitos;

• Levantamento e análise de dados através de questionário, por envolver um grupo especíco de pessoas para questionar sobre motivação entre outros aspectos sobre o ensino de Engenharia de Requisitos; Uma abordagem qualitativa por analisar opiniões de envolvidos na pesquisa.

A Figura 1 mostra resumidamente as atividades desta pesquisa. Inicialmente, para este trabalho foi feita uma Revisão Sistemática da Literatura que identicou os princi-pais trabalhos da literatura relacionadas ao ensino de Engenharia de Requisitos. Com a revisão, foram identicados os conteúdos lecionados, foco do ensino, tipos de metodologia utilizadas em sala, materiais e exercícios utilizados.

Em paralelo à revisão, foi feita a análise curricular dos cursos de graduação do Brasil. Para isso algumas restrições foram aplicadas como, por exemplo: a análise foi feita em cursos pertencentes a Universidades Federais do país e que possuíam boa avaliação quanto ao seu ensino de pós graduação. Esse critério foi aplicado devido a grande quantidade de universidades com cursos de computação.

Dois surveys foram feitos: o dos docentes buscava identicar como a disciplina era lecionada, conteúdo e desaos. O segundo, voltado para Engenheiros, buscando identicar

desaos da área, enfrentados no processo e por recém ingressos. Foram feitas também recomendações para o cenário acadêmico.

Ao nal do trabalho elencou-se atividades, que foram validadas por docentes que lecionam ou lecionaram a disciplina de Engenharia de Requisitos com foco nos pontos identicados a serem melhorados na perspectiva tanto de docentes como de Engenheiros de Requisitos da indústria.

Figura 1: Procedimentos Metodológicos

1.5 Organização do Trabalho

Esta dissertação está estruturada em 7 capítulos, com as respectivas descrições de con-teúdo e seções. No capítulo 1 temos a motivação, problemas, objetivos e os procedimentos metodológicos. No capítulo 2 encontram-se os trabalhos relacionados e seus respectivos resumos bem como as semelhanças e diferenças com este trabalho. A Revisão Sistemática com planejamento e condução encontram-se no capítulo 3. No capítulo 4 e 5 são apresen-tados os survey que serviram de coleta de dados com as questões de pesquisa, motivação e metodologia. O capítulo, 7, trata da lista de atividades com foco em interpretação de cenário, soluções e escrita de requisitos. O capítulo 8 trata da Fundamentação Teórica, iniciando com os conceitos de Engenharia de Requisitos e por m sobre o seu ensino. No

capítulo 8 encontra-se a conclusão com limitações e trabalhos futuros. Os anexos A,B e C, disponíveis no nal desta dissertação mostram os trabalhos analisados na Revisão Sistemática da Literatura e os surveys enviados.

2 Fundamentação Teórica

A seguir serão apresentados os conceitos de Engenharia de Requisitos quanto os seus tipos e processos. Em seguida, é apresentado um contexto sobre o ensino da disciplina de Engenharia de Requisitos no Brasil, contexto onde a pesquisa está sendo realizada. Para isso são apontados as grades curriculares disponíveis bem como as cláusulas das diretrizes do Ministério da educação que enfatizam as habilidades referentes a área de requisitos nos prossionais de tecnologia.

2.1 Contexto

O desenvolvimento de software é uma atividade complexa, segundo Sommerville (2004), e a denição de um processo, que auxilie esse desenvolvimento, é imprescindível. Exis-tem quatro atividades básicas, nesse processo: especicação, desenvolvimento, validação e evolução. Na especicação, são denidas as funcionalidades e as restrições do sistema. Enquanto, no desenvolvimento, o sistema é produzido de acordo com os critérios de-nidos, anteriormente. Na validação, é feita a análise para vericar se as funcionalidades estabelecidas foram implementadas. Na atividade evolução, o sistema é adaptado para continuar sendo útil.

Ao nal de todo processo, espera-se ter construído um software de qualidade, e que tenha alcançado o status de sucesso. O sucesso, nesse contexto, é denido por Nuseibeh e Easterbrook (2000) pelo grau de delidade do sistema com a nalidade para a qual o mesmo foi construído; e é através da identicação e da documentação das necessidades do software antes de sua construção, atividades realizadas pela Engenharia de Requisitos, que o sucesso é atingido.

Segundo Lopes e Audy (2003), é importante que haja uma compreensão do ambiente do software, das regras de negócio, da possibilidade de modicações com a utilização e mudanças de mercado e de contexto, bem como as necessidades reais do que se quer

construir. Ressalta-se para isso o papel da Engenharia de Requisitos no desenvolvimento de software, descrito por Zave (1997), que é estar preocupada com o relacionamento dos objetivos, funções e restrições de sistema, além de especicações do comportamento do software, e com a sua evolução com o passar do tempo.

2.2 Engenharia de Requisitos

A Engenharia de Requisitos dene as funcionalidades que um software deverá possuir para resolver um determinado problema do mundo real. Requisitos, segundo Sommerville (2004) são as denições do que o sistema deve fazer, além de suas restrições. Enquanto, Abran et al. (2001) dene requisito como a capacidade de um sistema para resolver um determinado problema. Teoricamente, eles reetem a necessidade dos clientes em relação ao sistema, que tem uma nalidade especíca, como dito por Amaral et al. (2006). Para Robertson e Robertson (1996), um requisito é algo que o sistema tem que fazer, ou uma qualidade, que o sistema deve evidenciar. Isto está em consonância com a denição dada pela IEEE (1990): um requisito é uma condição ou capacidade, que deve ser cumprida ou estar presente em um sistema, ou módulo do sistema.

Como dito anteriormente, a especicação é a primeira etapa do processo de desenvol-vimento de software. Por se tratar da denição do que se quer construir, o impacto dessa atividade tem um grande efeito no software. Quanto mais tarde forem detectados proble-mas nessa atividade, maior será o custo para correção. Para Neto (2008), o sucesso do processo de desenvolvimento é intrinsecamente dependente da qualidade da especicação dos requisitos do sistema.

Como explicado por Hofniai e Lehner (2006), a denição dos requisitos é o fator mais importante em um projeto de software. O processo de Engenharia de Requisitos pode variar muito dependendo da maturidade, do envolvimento no processo, da cultura da empresa e do domínio, onde a engenharia será aplicada, como explica Vara et al. (2016). Inicialmente um software é algo invisível, o que apresenta um primeiro desao, no processo de desenvolvimento. O software permanece nesse estado até que sua construção seja realizada. Inicialmente, os requisitos fornecem uma perspectiva visível do sistema (KHAN; MALIK, 2017).

Os requisitos podem ser declarados de três formas, segundo Sommerville (2004), Pres-sman (2011) e Peeger e Atlee (2001): requisitos funcionais, não funcionais e de domínio.

• Requisitos funcionais descrevem o que o sistema deve fazer. Esse tipo de requisito pode descrever desde o que o sistema deve fazer até condições muito especícas, denem recursos especícos, que o sistema deve oferecer, e a sua falta de clareza leva a muitos problemas, como: uma funcionalidade que o usuário não solicitou ou não é feita conforme especicado.

• Requisitos não funcionais estão associados às propriedades de qualidade do sistema, como conabilidade e tempo de resposta, por exemplo. Esse tipo de requisito é mais crítico por lidar com características de um sistema como um todo. Por exemplo: o cliente queria que o cadastro fosse também oine, porém o requisito de disponibi-lidade foi negligenciado.

• Requisitos de domínio são aqueles que podem ser funcionais ou não funcionais, e dependem da natureza e do contexto do sistema, que será construído. Isto pode ocasionar diculdades, como: um sistema que funciona perfeitamente, porém vai contra as regras de um determinado órgão.

A Engenharia de Requisitos, segundo Bourque, Fairley et al. (2014), é uma expressão utilizada para indicar um processo sistemático para lidar com requisitos. Já Neto (2008) diz que essa área envolve atividades de compreender as necessidades do usuário em um determinado contexto. Essa área possui inúmeras responsabilidades, no que diz respeito a elicitar, analisar, especicar, validar os requisitos além de gerenciá-los durante todo o processo de desenvolvimento do software.

Sommerville (2004) retrata que o processo de Engenharia de Requisitos é composto por quatro atividades, como pode ser visto na Figura 2. Nela é possível ver vários ciclos de um processo de Engenharia de Requisitos. Segundo Pressman (2011), existem sete ativi-dades, que são: concepção, levantamento, elaboração, negociação, especicação, validação e gestão. Contudo, as atividades são as mesmas e apesar de estarem divididas de formas diferentes.

No processo de requisitos, inicialmente é feito o estudo de viabilidade onde ao nal têm-se um relatório com informações do sistema a ser construído e seus objetivos bem como a efetivação da implementação considerando prazos e recursos.

Em seguida, no processo de elicitação e análise, ocorre o envolvimento de diversos tipos de pessoas por que informações sobre o domínio da aplicação, serviços do sistema, desempenho e restrições de hardware entre outras informações são levantadas. Na indús-tria e na academia o conhecimento de que projetos de software que não realizam um

levantamento preciso de requisitos se tornam vulneráveis, é bem conhecido (BOURQUE; FAIRLEY et al., 2014). Nesse processo é feita a descoberta de requisitos, a classicação que

une requisitos relacionados, a priorização do que deverá ser implementado inicialmente de forma que não haja conitos entre requisitos dependentes. A Figura 3 mostra o processo de elicitação e análise de requisitos. Inicialmente descobrem-se as funcionalidades do sis-tema e em seguida são organizados e classicados. Por m os requisitos são priorizados e especicados.

Figura 2: Processo de Engenharia de Requisitos (SOMMERVILLE, 2004)

Na especicação será feita a descrição dos requisitos funcionais, não funcionais e de domínio tanto do usuário como do sistema. E por m, a validação corresponde a vericação dos requisitos quanto ao atendimento dos objetivos expressados pelo cliente. Logo, a engenharia de requisitos tem-se como resultado um documento contendo os requisitos informados pelo cliente bem como priorizações e restrições.

O produto nal da Engenharia de Requisitos é um documento de especicação, onde consta uma descrição de todos as condições daquele projeto. O documento de requisitos, que alcança o critério de qualidade, deve ser, segundo Pádua (2003), claro, completo, sem ambiguidade, implementável, consistente e testável.

Vários autores citam um conjunto de atividades referentes a essa engenharia, logo não existe um modelo ideal de processo e isso pode variar de acordo com a realidade da

empresa e vários outros fatores como o modelo de desenvolvimento adotado.

Existem algumas metodologias de desenvolvimento e elas possuem um conjunto de práticas que auxiliam o desenvolvimento de software. Essas práticas são divididas em um conjunto de passos para melhorar a ordenação e gerenciamento, como citado por (SOMMERVILLE, 2004).

Figura 3: Processo de Especicação e Análise de Requisitos (SOMMERVILLE, 2004)

O modelo cascata de desenvolvimento, por exemplo, possui o processo de requisitos no começo do desenvolvimento (PRESSMAN, 2011). No Rational Unifed Process (RUP) são utilizados casos de uso para modelagem de requisitos além de linguagem UML (ABRAN et al., 2001). No desenvolvimento Extreme Programming (XP) os requisitos são representados

como histórias de usuário (BECK et al., 2001). No Scrum, a cada começo de ciclo tem-se

uma lista de requisitos (SCHWABER; BEEDLE, 2002). A forma como as atividades são feitas varia de acordo com a metodologia, porém, todas ressaltam a importância dos requisitos na qualidade do projeto que irá reetir no produto.

Apesar de existirem vários processos de desenvolvimento de software com atividades bem estruturadas, muitos projetos ainda falham. No estudo realizado por Khan e Malik (2017) foram listados fatores de falhas dos projetos como, por exemplo, otimização de cronograma, complexidade de software e mudança de requisitos.

A Manifesto (2013) realizou um estudo que mostra fatores que prejudicam o projeto de software, dentre eles os mais citados estão problemas relacionados à disponibilidade do cliente, especicação de requisitos e mudança de requisitos. Foram listados também fatores que causaram cancelamento de projetos, como a incompletude de requisitos.

A especicação da área de requisitos não é nova, porém, os problemas identicados são comumente encontrados ainda hoje. Em 2000 já se demonstravam problemas relacionados

a negligência de requisitos não funcionais, evolução de requisitos e elicitação, por exemplo, (NUSEIBEH; EASTERBROOK, 2000). Dadas as recentes pesquisas sobre desaos, ainda há

o que evoluir na Engenharia de Requisitos quando às técnicas e abordagens.

No estudo feito por Inayat et al. (2015) os desaos da Engenharia de Requisitos nas metodologias tradicionais são relacionados á sobreposição de requisitos e validação, por exemplo. Já nas metodologias ágeis são apontados desaos no que diz respeito a documentação mínima e disponibilidade do cliente, entre outros. A Tabela 1 mostra todos os desaos identicados pelos autores em ambas metodologias de desenvolvimento.

Tabela 1: Desaos na Engenharia de Requisitos (INAYAT et al., 2015)

Metodologias Tradicionais Metodologias Ágeis Problemas de Comunicação Documentação

Sobreposição de requisitos Disponibilidade do cliente Validação de requisitos Arquitetura inapropriada

Documentação Estimativa de tempo e orçamento

Envolvimento do Cliente Requisitos não funcionais negligenciados Falta de habilidade e acordo com cliente Limitação contratual

Mudança de requisitos e avaliação

As metodologias ágeis e tradicionais possuem diversas diferenças, entre elas estão a maneira como os requisitos são coletados e o tempo das atividades de todo processo (LAPLANTE, 2013).

O modo tradicional de desenvolvimento auxiliava a especicação de requisitos mais completa, porém é comum que ambiente de software estejam imerso em constantes mu-danças. Paetsch, Eberlein e Maurer (2003) e Sommerville (2004) demonstram que todo processo relacionado a requisitos, em desenvolvimento tradicional, é feito no início do pro-jeto. Logo, as empresas precisavam de uma abordagem que era um desao para o modo tradicional (CAO; RAMESH, 2008). Os processos de desenvolvimento menos restritivos,

considerados ágeis, se adaptaram melhor ao cenário de competitividade das empresas. Segundo Ramesh, Cao e Baskerville (2010) e Beck et al. (2001), os requisitos, em ambientes ágeis, evoluem ao longo do ciclo de vida do projeto.

Em um estudo feito pela Jackson (2006), 42% dos projetos tinha a mudança de requi-sitos como motivo de falha. Marçal et al. (2010) informa que os requirequi-sitos mal gerenciados correspondem a 30% dos problemas envolvidos no desenvolvimento de software. Ou seja, requisitos são fatores que impactam fortemente o sucesso dos projetos.

2.3 Ensino da Engenharia de Requisitos em cursos de

ensino superior

A Engenharia de software é uma disciplina que foca todo o processo de produção de um software (SOMMERVILLE, 2004), desde o que se quer construir até à evolução desse

sistema após sua implantação em um ambiente real. Essa disciplina está presente na mai-oria dos currículos de cursos de tecnologia da informação. Nesse processo, a Engenharia de requisitos é a primeira fase, logo é a disciplina fundamental que está no centro da Engenharia de Software por se tratar da ideia do que se quer construir, restrições e como fazer. A Engenharia de Software, segundo Abke et al. (2013), já traz consigo uma dicul-dade de ensino e aprendizagem por se tratar de um processo complexo e abstrato, logo a Engenharia de Requisitos enfrenta esses mesmo problemas.

Um currículo, segundo Roldão e Curricular (1999), expressa um conjunto de assuntos e habilidades consideradas necessárias para um determinado contexto e tempo, além de uma sequência para sua efetivação ou desenvolvimento.

A disciplina de Engenharia de Requisitos é dada, inicialmente, na graduação podendo ser também encontrada na pós graduação latus e stricto sensus. No portal da Educação (MEC, 2015), é possível encontrar a diretriz curricular, ou currículo, e ementa dos cursos

de graduação na área de Computação que envolvem Ciência da Computação, Sistemas de Informação, Engenharia da Computação, Engenharia de Software em seus graus de título de bacharel ou licenciatura.

Ementa é entendida como a relação de tópicos em programas de ensino (GUIMARÃES,

2004). Ela descreve de forma discursiva e resumida o conteúdo conceitual e processual de uma disciplina.

Na resolução CNE/CES de número 5, publicada em 16 de novembro de 2016 e ho-mologado em 28 de outubro do mesmo ano, é possível encontrar elementos especícos da área de requisitos e que deverão ser incluídos na matriz curricular dos cursos (MEC, 2016).

No artigo 4, inciso II, parágrafo 4, da resolução encontramos que os egressos dos cursos de Sistemas de informação:

 possam determinar os requisitos, desenvolver, evoluir e administrar os sistemas de informação das organizações, assegurando que elas tenham as in-formações e os sistemas de que necessitam para prover suporte às suas operações e obter vantagem competitiva .

No artigo 5, inciso IV, parágrafo 1, da resolução têm-se que os cursos de bachare-lado em Ciências da Computação devem prover uma formação que estimule a habilidade de identicar e analisar requisitos e especicações para problemas especícos e plane-jar estratégias para suas soluções (MEC, 2016). Ainda no mesmo artigo, no parágrafo 3 encontra-se que os cursos de bacharelado em Engenharia de Software devem prover uma formação prossional que revele a habilidade de:

 XIV - identicar e analisar problemas avaliando as necessidades dos cli-entes, especicar os requisitos de software, projetar, desenvolver, implementar, vericar e documentar soluções de software baseadas no conhecimento apropri-ado de teorias, modelos e técnicas. .

No inciso X do parágrafo 4 também é citado que os bacharelados em Sistemas da Informação devam representar os modelos mentais dos indivíduos e do coletivo na análise de requisitos de um Sistema de Informação (MEC, 2016). No parágrafo 5 os licenciados em Computação devem prover habilidades para especicar requisitos na interação humano-computador - IHC.

A disciplina de Requisitos poderá ser a preparação inicial dos alunos antes mesmo que ele torne-se desenvolvedor. Nos ambientes de desenvolvimento certamente eles irão exercer atividades relacionadas a requisitos mais cedo ou mais tarde, e é importante que eles estejam preparados para lidar com situações que vão além da implementação de linha de código. É necessário entender que requisitos representam a expressão das necessidades do cliente (GAUSE; WEINBERG, 1989).

No trabalho de Connolly e Begg (2006) os autores questionam o fato de que os alunos enfrentam um desao quando trata-se de coisas que vão além da implementação, como por exemplo a descrição da solução de um problema não relacionado à linha de código.

O ensino de requisitos deve dar ao usuário habilidades técnicas e não técnicas por se tratar de uma área que exige de habilidades sociais (NUSEIBEH; EASTERBROOK, 2000). Na

atividade de elicitação os desenvolvedores irão interagir com uma variedade de stakehol-ders e clientes no mais alto nível de abstração técnica. Conhecer os desejos das pessoas diante de um sistema e poder expressá-los de maneira consistente é essencial.

Regev, Gause e Wegmann (2008) relatam um problema dos cursos relacionados à maneira como as aulas são planejadas. Em sua maioria a disciplina de requisitos é dada de maneira tradicional, composto por um conjunto de aulas expositivas e exercícios simples. O plano de aula visa a importância de se planejar todas as etapas no processo de

ensino aprendizagem (TAKAHASHI; FERNANDES, 2004). Ele é composto por uma estrutura

didática, um tema, objetivos, conteúdo programático, estratégias bem como seus recursos didáticos, além de duração e referências.

Madhavji e Miller (2005) e Damian et al. (2005) dizem que é preciso que haja ativi-dades que vão além de opiniões e palestras sobre a área.

A Sociedade Brasileira de Computação - SBC, que entre suas obrigações está a contri-buição para formação prossional dos prossionais de computação, apresenta currículos de referência que devem servir de base para os cursos de computação do país. Dentre os apresentados pela SBC encontra-se o currículo de referência para cursos de gradua-ção em computagradua-ção e informática, além de Ciências da Computagradua-ção e Engenharia da Computação.

Compreende-se por Computação ou Informática os conhecimentos que dizem respeito a computadores, sistemas de computação, bem como suas aplicações, além de aspectos teóricos, experimentais, de modelagem e projeto (COMPUTACAO, 1999).

Sobre o perl prossional, o autor demonstra que os egressos devam ser prossionais que, entre outras atribuições, tenham habilidades de comunicação e expressão. Também é esperado que tenham conhecimento para modelar e especicar soluções para diversos tipos de problemas. Ambas habilidades fazem parte do perl de um engenheiro de requisitos. Pressman (2011) destaca que entender um problema e propor uma solução é uma atividade extremamente complexa e importante para qualquer projeto de desenvolvimento.

Um plano de curso é a organização de várias matérias que irão ser ensinadas e de-senvolvidas em uma instituição de ensino durante um determinado tempo de um curso (VASCONCELLOS, 1995). A estruturação das matérias, nos currículos de Computação ou

Informática, estão divididas em três núcleos:

• Fundamentos da Computação, onde encontram-se disciplinas como linguagens de programação e análise de algoritmos;

• Tecnologia da Computação, onde pode ser encontrado a matéria T7 que trata de Engenharia de Software, grande área que envolve o processo de Engenharia de Re-quisitos;

• Sistemas de Informação, onde encontra-se a matéria I3 sobre Gerenciamento de Projetos, que envolve o processo de elicitação de requisitos;

Para os cursos de Ciências da Computação e Engenharia da Computação, as matérias estão divididas nas áreas de:

• Fundamentos da Computação, onde têm-se o F5 Fundamentos de Sistemas com conceitos de Especicação. No artigo 5, inciso IV, parágrafo 1, da resolução têm-se que os cursos de bacharelado em Ciências da Computação devem prover uma formação que estimule a habilidade de identicar e analisar requisitos e especicações para problemas especícos e planejar estratégias para suas soluções (MEC, 2016). Ainda no mesmo artigo, no parágrafo 3 encontra-se que os cursos de bacharelado em Engenharia de Software devem prover uma formação prossional que revele a habilidade de:

 XIV - identicar e analisar problemas avaliando as necessidades dos clientes, especicar os requisitos de software, projetar, desenvolver, im-plementar, vericar e documentar soluções de software baseadas no co-nhecimento apropriado de teorias, modelos e técnicas. .

No inciso X do parágrafo 4 também é citado que os bacharelados em Sistemas da Informação devam representar os modelos mentais dos indivíduos e do coletivo na análise de requisitos de um Sistema de Informação (MEC, 2016). No parágrafo 5 os

licenciados em Computação devem prover habilidades para especicar requisitos na interação humano-computador - IHC.

No âmbito internacional, a cerca de 10 anos a ACM juntamente com a IEEE- Com-puter Society estabelecem diretrizes curriculares para o programa de graduação em Ciência da Computação. Em sua última versão, lançada em 2013, encontra-se uma atualização da versão anterior de 2008 que mais se adapta ao cenário de constantes evoluções na área tecnológica (ACM, 2013).

No currículo proposto pela ACM, para Ciências da Computação, existe um tópico relacionado a Engenharia de Requisitos que inclui:

 Gerenciamento de Projetos de software que lida com estabilidade dos requisitos (incluindo não funcionais);

 Ferramentas e Ambiente que lida com análise de requisitos e rastreabilidade;  Engenharia de Requisitos que lida com tipo e propriedade dos requisitos bem

como todo processo da área;

 Contexto Social que envolve requisitos legais;

Para os cursos de Sistema de Informação, a ACM elenca a área de Análise de Sis-tema e Design que entre outras atividades incluem a especicação de requisitos para soluções de sistema. Envolve ainda a documentação de requisitos, análise e especi-cação de requisitos de sistema, métodos de construção e comuniespeci-cação de requisitos, considerações éticas na especicação dos requisitos, impacto dos requisitos.

Para os cursos de Engenharia de Software há o tópico de Especicação e Análise de Requisitos. Dentro desse são encontrados os fundamentos dos requisitos, elicitação dos requisitos, especicação e documentação de requisitos além de validação de requisitos.

Em contexto nacional e internacional nos cursos de tecnologia, disciplinas voltadas para requisitos fazem parte dos currículos propostos. Requisitos de Sistemas de Informação.

• Tecnologia da Informação, onde no T7 Engenharia de Software e T20 Sistemas Em-barcados tratam da Engenharia de Requisitos, sendo o T20 especíco para sistemas embarcados.

3 Revisão Sistemática

Neste capítulo é apresentado o planejamento e os resultados de uma revisão sistemá-tica voltada para o ensino da disciplina. Essa etapa fez-se necessário devido a ausência de uma revisão na literatura focando em questões relativas ao ensino da disciplina, suas metodologias e artefatos. É descrito aqui o planejamento da revisão além da condução e resultados.

3.1 Planejamento

Na etapa de planejamento foi identicada a necessidade da revisão bem como a de-nição de um protocolo.

De modo a identicar na literatura, trabalhos que tratem do ensino da disciplina de Engenharia de Requisitos em cursos de nível superior de Computação e Engenharia, foi realizada uma Revisão Sistemática da Literatura (RSL). Buscamos por trabalhos que propuseram metodologias de ensino, materiais de aula ou apresentaram currículos com foco nas necessidades da indústria e nos desaos apresentados em outras pesquisas. A revisão contemplou trabalhos publicados entre os anos de 2014 a 2017, e seguiu uma adaptação do protocolo de Kitchenham et al. (2009). O intervalo de ano escolhido é justicado pelo interesse em se identicar achados mais recentes a certa da disciplina. Para melhor organizar, o processo da revisão foi dividido em etapas como mostrado na Figura 4.

Questões de Pesquisa

Segundo Keele et al. (2007), as questões de pesquisa são importantes por darem um direcionamento a revisão. É através delas que será possível identicar os artigos que farão parte da pesquisa e como eles serão analisados. Para este trabalho foram criadas 4 questões de pesquisa, citadas na Tabela 2.

Tabela 2: Questões de Pesquisa da Revisão Sistemática

Número Questão Motivação

QP1 Como a disciplina de Enge-nharia de Requisitos está es-truturada nos currículos de ensino superior?

Para identicar a obrigatoriedade, se é divi-dida em módulos, se o ensino é teórico e(ou) prático, se é interdisciplinar e como é feita a avaliação. Ainda mais, tentar identicar o ní-vel de maturidade dos alunos a depender do semestre a qual a disciplina é apresentada. QP2 Quais tópicos são

leciona-dos? Para identicar o que é ensinado na disci-plina e se existe um foco em alguma parte especíca do processo que envolve requisitos. QP3 Quais

metodolo-gias/técnicas de ensino são utilizadas em sala pelos docentes?

Para identicar como os docentes conduzem o processo de aprendizagem. Se são aulas ex-positivas, se são debates ou aulas em campo por exemplo.

QP4 Que tipo de material é

usado nas aulas? Para identicar os artefatos usados em salade aula como vídeos, jogos e documentos. Matriz de Sinônimos

Uma matriz de sinônimos foi criada para ajudar na seleção de palavras que iriam compor a string de busca. Os temas de interesse utilizados foram: aprendizagem, ensino, análise, metodologia, currículo, Engenharia de Requisitos, tópicos, disciplina e cursos de nível superior. As palavras, que zeram parte da matriz, para cada tema de interesse

listado acima estão listados na Tabela 3:

Tabela 3: Temas de interesse da String

Tema Palavras

APRENDIZAGEM ability, education, experience, knowledge, le-arning, practice, skill, understanding

ENSINO coaching, exercise, teaching, training

ANÁLISE analysis

METODOLOGIA approach, didactic, method, methodological, methodology, pedagogical, pedagogy, pro-cess, strategy, technique

CURRÍCULO course, curricula, curriculum, programme ENG DE REQUISITOS requirements engineering

TÓPICOS education knowledge, subject DISCIPLINA course

NÍVEL SUPERIOR degree program, graduate, graduation course, higher education, undergraduate, undergraduate degree

A junção dos termos resultou na seguinte string de busca:

(TITLE-ABS-KEY ( ( "requirements engineering"OR "software engineering") AND ( curriculum OR curricula OR programme OR course OR learning OR education OR knowledge OR skill OR ability OR understanding OR experience OR practice OR exper-tise OR teaching OR coaching OR training OR exercise OR methodology OR strategy OR process OR method OR didactic OR methodological OR technique OR pedagogy OR pedagogical OR approach OR subject OR "education knowledge") AND ( graduation OR graduate OR undergraduate OR university OR "higher education"OR undergraduation OR "undergraduate degree"OR "degree program")))

Critérios de Seleção e Fonte de Busca

Critérios foram adotados para inclusão e exclusão de artigos. Foram considerados os seguintes critérios de inclusão:

1. Trabalhos que propuseram tópicos para compor currículo da disciplina de Engenha-ria de Requisitos

2. Trabalhos que propuseram metodologia de ensino de Engenharia de Requisitos 3. Trabalhos publicados entre os anos de 2014 a 2017

5. Trabalhos da área de conhecimento de Ciências da Computação; Engenharia e Mul-tidisciplinar

6. Trabalhos que estavam escritos na Língua Inglesa e na Língua Portuguesa; e por m 7. Trabalhos com a palavra-chave: Engenharia de Requisitos ou Engenharia de Software (em inglês: Requirements Engineering ou Software Engineering, respectivamente) Foram considerados critérios de exclusão:

1. Trabalhos que não foram completamente concluídos 2. Trabalhos replicados

3. Trabalhos que não responderam a nenhuma questão de pesquisa 4. Trabalhos que se opuseram aos critérios de inclusão

Ao nal do processo de criação, obtivemos a string que foi usada para obtenção dos dados. Para essa etapa do trabalho usamos o SCOPUS por indexar trabalhos de diver-sas outras fontes como ACM e IEEE, por exemplo. Além disso, foram feitas buscas em eventos realizados entre os anos de 2013 a 2017, da área de Tecnologia da Informação e Computação voltados para ensino de computação:

• SBIE - Simpósio Brasileiro de Informática na Educação, • WIE - Workshop de Informática na Escola,

• RE - Requirements Engineering,

• WER - Requirements Engineering Track,

• iTICSE - Innovation and Technology in Computer Science Education, • RBIE - Revista Brasileira de Informática na Educação,

• SIGCSE - Technical Symposium on Computer Science Education, • SBSI - Simpósio Brasileiro de Sistemas de Informação,

• FEES - Fórum de Educação em Engenharia de Software, • CBIE - Congresso Brasileiro de Informática na Educação,

• CISTI - Conferência Ibérica de Sistemas e Tecnologias de Informação, • CBSOFT - Congresso Brasileiro de Software.

Figura 5: Etapas da condução da Revisão

3.2 Condução

Nessa etapa aplicamos a string de busca no indexador de artigos, o Scopus. A Figura 5 mostra as etapas e a quantidade de trabalhos retornados em cada uma delas. No Scopus, na etapa 1 da condução zemos a busca por string que nos retornou artigos a serem renados com a aplicação dos critérios de inclusão e exclusão, ao nal tivemos 1055 artigos. Na etapa 2 ocorreu a leitura dos títulos e abstract de cada artigo. Logo ao nal dessa etapa tivemos 105 artigos. Na etapa 3, selecionamos os artigos que respondiam a alguma das questões de pesquisa. Nessa etapa tivemos uma seleção de 13 artigos.

Em relação à busca nos eventos, foi feita a busca nos anais de cada evento nos anos especicados anteriormente. Na etapa 1, onde se leu títulos e abstracts, tivemos a seleção de 49 artigos. Após lidos, partimos para a etapa de selecionar os artigos que respondiam às nossas questões de pesquisa, a etapa 2. Nessa etapa tivemos apenas um artigo selecionado. Ao nal do processo foi aplicada ainda a técnica de Snowballing onde analisamos os trabalhos referenciados pelos artigos selecionados. Nesse processo aplicamos os mesmo critérios de inclusão e exclusão. Ao nal da técnica obtivemos um retorno de 4 artigos.

3.3 Resultados

Ao nal de todas as etapas, tivemos um total de 18 artigos, descritos na Tabela 4. A maioria dos artigos estão datados entre os anos de 2016 e 2017, podendo ser um indício de que as pesquisas voltadas para essa área são novas. Outro indício da ascensão do tema das pesquisas foi visto na mesa redonda que aconteceu no Simpósio Brasileiro de Engenharia de Software - SBES em 2017 na Trilha Educação com tema Desaos na Educação em Engenharia de Software. Nessa mesa redonda, foi discutida a necessidades de pesquisas sobre melhores abordagens para ensino de temas relacionado a Engenharia de Software.

3.3.1 Como a disciplina de Engenharia de Requisitos está

estru-turada nos currículos de ensino superior? (QP1)

Na leitura dos artigos buscamos informações sobre qual semestre no curso a disciplina era apresentada, entre outras informações descritas no decorrer deste tópico. Com isso, por exemplo, buscamos vericar sobre o grau de maturidade dos alunos para cursar a dis-ciplina. A área envolve uma certa maturidade adquirida na medida em que o aluno avança no curso e vivência de experiências. Por exemplo, durante sua experiência acadêmica o aluno é induzido a especicar algo que se quer construir bem como restrições, contudo, inicialmente, isso será feito sem a formalidade exigida pela Engenharia de Requisitos.

Os trabalhos descritos, na Tabela 5, demonstram que a disciplina encontra-se no 3.o_,

5.o _{ou 6.}o _{semestre do curso. A duração da disciplina foi descrita nos respectivos trabalhos}

ID 07 (60 horas) e ID 11 (42 horas). O trabalho ID 05 possui a disciplina sendo lecionada de maneira interdisciplinar. Sobre avaliação, foi identicado que a mesma é feita através de projetos desenvolvidos pela turma.

3.3.2 Quais tópicos são lecionados? (QP2)

Na Tabela 6, encontram-se os tópicos, focos da disciplina, que foram identicados nos artigos. A Engenharia de Requisitos possui um processo com algumas atividades, e cada uma dessas é listada como tópicos a serem aprendidos. Sabemos que as disciplinas dependem muito da dinâmica do docente ou do contexto especíco, onde é lecionada. Podem existir docentes que dão um foco maior a determinados tópicos por sentirem uma carência de conhecimento percebida no mercado.

Tabela 4: Trabalhos selecionados

ID Ano Título Autor

01 2017 Experiences in Teaching and Learning Requi-rements Engineering on a Sound Didactical Basis

(SEDELMAIER; LANDES, 2017)

02 2017 Is role playing in Requirements Engineering

Education increasing learning outcome? (SVENSSON;MEÇÇ, 2017) REGE-03 2017 Jogos Educativos no Ensino da Engenharia

de Requisitos (ARAUJO et al., 2016) 04 2017 Work in Progress: Teaching-Obstacles in

Higher Software Engineering Education (REUTER; BESLMEISL;MOTTOK, 2017) 05 2016 An integrated approach to the Requirements

Engineering and Process Modelling teaching (MARSICANO et al., 2016) 06 2016 Assessing Problem-Based Learning in a

Soft-ware Engineering Curriculum Using Bloom?s Taxonomy and the IEEE Software Enginee-ring Body of Knowledge

(DOLOG; THOMSEN; THOMSEN, 2016)

07 2016 Facing the challenges of teaching

require-ments engineering (PORTUGAL et al., 2016) 08 2016 Use of the Essence and Kuali-Beh to

Struc-ture Software Engineering Courses (OKTABA et al., 2016) 09 2015 A Case study based Software Engineering

Education using Open Source Tools (SOWMYA;NAIAH; SRINIVASA, HIRIYAN-2015)

10 2015 Active and Inductive Learning in Software

Engineering Education (SEDELMAIER; LANDES,2015) 11 2015 Requirements and Architecture Modeling in

Software Engineering Courses (GRBAC; CAR; VUKO-VIC, 2015) 12 2015 Teaching Requirements Engineering:

EU-ROWEB experience (SCEPANOVIC;DUKIC, 2015) BEUS-13 2015 The Monopoly Game to Teach ERi*c -

In-tentional Requirements Engineering (OLIVEIRA et al., 2015) 14 2014 Implementation of Practical Exercises in

Software Engineering Education to Improve the Acquirement of Functional and Non-Functional Competences. A eld report about project-based learning in software en-gineering

(SOSKA; SCHOLL-DECKER; MOTTOK, 2014)

15 2014 Requirements Engineering Education using

Expert System and Role-Play Training (NAKAMURA; KAI; TA-CHIKAWA, 2014) 16 2006 Teaching Requirements Engineering to an

Unsuspecting Audience (CALLELE; MAKAROFF,2006) 17 2004 Role-Playing, Group Work and Other

Ambi-tious Teaching Methods in a Large Require-ments Engineering Course

(AL-ANI; YUSOP, 2004) 18 2003 Teaching Requirements Engineering through

Tabela 5: Período onde a disciplina se encontra na grade curricular

ID Artigos Semestre Duração

05 (MARSICANO et al., 2016) 5o semestre

-06 (DOLOG; THOMSEN; THOMSEN, 2016) 5o semestre

-07 (PORTUGAL et al., 2016a) 6o semestre 60 horas

10 (SEDELMAIER; LANDES, 2015) 3o semestre

-11 (GRBAC; CAR; VUKOVI‚, 2015) 3o semestre 42 horas

descrevem de forma geral todos os assuntos da disciplina e diante dos outros trabalhos foram o que envolveu mais tópicos. Nos trabalhos dos autores é descrito o ensino de Requisitos de Software desde a contextualização, tipos (funcionais, não funcionais e de domínio) e qualidade do requisito. Na parte de processo são apresentados modelos, tipos de atores bem como gerenciamento. Além disso, é apresentada a criação de um escopo, técnicas de elicitação, análise de requisitos, especicação de requisitos de sistema e de software. Para nalizar ainda é visto a validação, bem como considerações práticas no que se refere a mudança de requisitos, rastreabilidade e medição.

Grbac, Car e Vukovi¢ (2015) e Oktaba et al. (2016), relatam os tópicos de processo, análise, especicação, design e validação. Os trabalhos dos autores destacam a documen-tação e técnicas de especicação, e informam que na disciplina os alunos não são forçados a aprender um modelo de atributos de um documento especíco. Na disciplina os alunos são ensinados a criar seus próprios documentos e entender a importância e necessidade de cada atributo presente nele. Atributos são vistos como dados presentes no documento: identicador do requisito, descrição, herança entre outros.

No trabalho desenvolvido por Marsicano et al. (2016) é ensinado o Processo Unicado - UP bem como o framework Escala Agile - SAFe (Scaled Agile Framework). Ainda são ensinados os modelos de maturidade CMMI (Capability Maturity Model Integration) e MPS-SW (Modelo de Referência MPS para Software). Além disso, técnicas de eliciação e ferramentas são demonstradas para melhorar ainda mais o conhecimento dos alunos. É possível identicar que no trabalho a disciplina de Engenharia de Requisitos envolve os conceitos de modelagem de processos.

Em Sedelmaier e Landes (2015) tem-se o ensino da introdução à área, a importância da elicitação, a criação dos diagramas de estado e sequência bem como a documentação dos requisitos. Sowmya, Hiriyannaiah e Srinivasa (2015) descrevem tópicos similares ao trabalho anterior porém adicionando diagramas de classe e o ensino de ferramentas vol-tadas para a área. Em Nakamura, Kai e Tachikawa (2014) só foi percebido o ensino de elicitação bem como suas técnicas e análise.

Tabela 6: Trabalhos que descreviam os tópicos lecionados na disciplina Artigos Tópicos

(SVENSSON;

REG-NELL, 2017)

Requisitos no mercado e Processos de desenvolvimento

(MARSICANO et al.,

2016) Modelos de Desenvolvimento, Modelosde Maturidade de Processo, Técnicas e Ferramentas

(DOLOG; THOMSEN;

THOMSEN, 2016)(

SE-DELMAIER; LANDES,

2017b)

Contextualização, Tipos, Qualidade, Modelos de processo, Gerenciamento, Técnicas, Rastreabilidade e Mensura de requisito

(SOWMYA;

HIRIYAN-NAIAH; SRINIVASA,

2015)

Processo, Análise, Especicação, De-sign, Validação, Documentação e Fer-ramentas

(SEDELMAIER;

LAN-DES, 2015)

Introdução a área, Diagramas e Docu-mentação

(GRBAC; CAR; VUKO-VI‚, 2015)(OKTABA et al., 2016)

Processo, Análise, Especicação, De-sign, Validação e Documentação

(NAKAMURA; KAI; TA-CHIKAWA, 2014)

Técnicas de elicitação e análise

(ZOWGHI; PARYANI,

2003) Habilidades de um Engenheiro de Re-quisitos

(SCEPANOVIC; BEUS-DUKIC, 2015)

Avaliação crítica de processos, Técni-cas, Métodos e Ferramentas

Scepanovic e Beus-Dukic (2015) ensinam os alunos a avaliarem criticamente processos, técnicas, métodos e ferramentas voltada para a área. Em Svensson e Regnell (2017) é descrito que o ensino é orientado ao mercado e visto em um processo de desenvolvimento ágil. Em Zowghi e Paryani (2003) a disciplina exercita as habilidades de um Engenheiro. Nela estão descritas: (a) habilidades de entrevista e groupware para elicitação e validação, (b) habilidades de análise e modelagem para resolver problemas e (c) habilidades de escrita para especicação e documentação.

3.3.3 Quais metodologias/técnicas de ensino são utilizadas em

sala pelos docentes? (QP3)

A maioria dos trabalhos respondeu a essa questão. A disciplina de Engenharia de Requisitos possui muitas questões práticas bem como teóricas. Através do relato dos trabalhos extraímos suas metodologias de ensino que nos demonstram como a disciplina é ensinada pelos autores. A Tabela 7 mostra a relação das metodologias de ensino.

Tabela 7: Metodologias e técnicas de ensino aplicadas a disciplina

Descrição ID Autores

Dedicação Orientado a

Compe-tências 01 (SEDELMAIER; LANDES, 2017b) Aula Expositiva 02,

12, 17

(SVENSSON; REGNELL, 2017; SCEPANOVIC; BEUS-DUKIC, 2015; AL-ANI; YUSOP, 2004)

Gamecação 02 (SVENSSON; REGNELL, 2017)

Aprendizagem Baseada em Jogos 03,

13 (ARAUJO et al., 2016; OLIVEIRA et al., 2015) Aprendizagem Online 04 (REUTER; BESLMEISL; MOTTOK, 2017)

Exercício Acompanhado 04 (REUTER; BESLMEISL; MOTTOK, 2017)

Aprendizagem Baseada em

Pro-jeto Interdisciplinar 05 (MARSICANO et al., 2016) Aprendizagem Baseada em

Pro-blema 06,12 (NOVIC; BEUS-DUKICDOLOG; THOMSEN; THOMSEN, 2015) , 2016;

SCEPA-Aprendizagem Baseada em

Pro-jeto 07,11,

14

(PORTUGAL et al., 2016a; GRBAC; CAR; VUKOVI‚, 2015; SOSKA; SCHROLL-DECKER; MOTTOK, 2014)

Aula Expositiva 07,

11 (KOVI‚PORTUGAL et al., 2015) , 2016a; GRBAC; CAR;

VU-Aprendizagem Indutiva 09,

01 (SEDELMAIER; LANDESSOWMYA; HIRIYANNAIAH; SRINIVASA, 2017b) , 2015;

Aulas em Laboratório 11 (GRBAC; CAR; VUKOVI‚, 2015)

Tutoriais 12 (SCEPANOVIC; BEUS-DUKIC, 2015)

Aprendizagem Online 15 (NAKAMURA; KAI; TACHIKAWA, 2014)

Pedagogia Construtiva Estritiva 16 (CALLELE; MAKAROFF, 2006)

Gamecação em projetos 18 (ZOWGHI; PARYANI, 2003)

No trabalho de Dolog, Thomsen e Thomsen (2016) os autores evidenciam o uso de Aprendizagem Baseada em Problemas - PBL. Os alunos escolhiam um sistema a ser desen-volvido e passavam por um processo de apresentação com conversas em grupo e discussão de problemas associados ao projeto. Durante o projeto havia um foco nas necessidades dos clientes e avaliação de interface. Os alunos trabalham questões técnicas da Engenharia de Requisitos bem como testes. Segundo Cowan (1998), a metodologia cria um cenário na qual o estudante motivado irá ter uma melhor experiência de aprendizagem. Ou seja, torna o ensino centrado no aluno uma vez que o docente passa a ser um mediador.

Os autores Grbac, Car e Vukovi¢ (2015) demonstram aulas no modelo tradicional e expositivas bem como aulas de laboratórios. Nas aulas são aprendidos as especicações de requisitos e o processo que envolve elicitar, analisar, projetar e validar. Em paralelo a esse modelo os alunos têm que criar um projeto onde o mesmo deverá ser desenvolvido em linguagem Android e semanalmente acontecerá reuniões para solução de dúvidas. Para o

desenvolvimento os alunos contam com uma lista de requisitos a serem implementados. A aula expositiva é um método onde o docente expõe em sala os conteúdos visando sua compreensão pelos alunos (LEAL; JR, 2006).

Marsicano et al. (2016) utilizam da interdisciplinaridade em suas aulas. A disciplina de requisitos é lecionada em conjunto com Modelagem de Processos. A disciplina oferece uma abordagem que leva em consideração o mercado, para isso usam o Ensino Baseado em Problemas. Nessa metodologia os alunos do curso de requisitos cam responsáveis por denir um processo de ER, técnicas de elicitação, ferramentas de gerenciamento, identi-cação e descrição de problemas, especiidenti-cação de requisitos, modelo de desenvolvimento e de maturidade. Os problemas a serem trabalhados surgem quando a equipe da disciplina de Modelagem de Processos iniciam o processo do projeto. Pontos de melhorias e ajustes devem ser feitos para que o processo de requisitos esteja bem aderente. Anteriormente am-bas as equipes zeram um planejamento do projeto que quando executado foi necessária melhorias.

A metodologia de aprendizagem indutiva foi observada nos seguintes trabalhos: Se-delmaier e Landes (2015) e Sowmya, Hiriyannaiah e Srinivasa (2015). Em SeSe-delmaier e Landes (2015), os problemas são apresentados antes da solução. Em sala os alunos são divididos em turmas onde exercem papel de desenhista ou descritores. O docente entrega um desenho para a turma de descritores que devem retratá-lo posteriormente em forma textual. Em seguida o texto é entregue aos desenhistas que deverão reproduzi-lo em forma de desenho. Nesse contexto eles aprendem a difícil tarefa de elicitação bem como perce-bem que a comunicação é muito importante. É comum que se tenha em sala de aula métodos dedutivos onde são apresentados os princípios e só no nal é feita a avaliação e consequentemente se tem o nível de conhecimento esperado (PRINCE; FELDER, 2006).

Em Sowmya, Hiriyannaiah e Srinivasa (2015) os alunos recebem contextos de apli-cações de comércio eletrônico, social e de gerenciamento. Com base nesses cenários eles recebem a declaração de um problema e descrevem a especicação de requisitos para suportá-lo. Essa metodologia é caracterizada pela introdução de proposições por meio de observações, casos de uso ou problemas, onde o estudante é estimulado quanto a percepção de regras e teorias, como explicado por Prince e Felder (2006).

O trabalho de Soska, Schroll-Decker e Mottok (2014) lida com a aprendizagem base-ada em projeto. O autor relata que isso traz um aumento da compreensão do aluno frente a disciplina e auxilia na obtenção de competências funcionais e metódicas, sociais e pes-soais. Em sala os alunos desenvolvem um documento de requisitos para uma máquina de